{
	"id": "9bfafc34-2c72-4ce9-9b75-5b2739542949",
	"created_at": "2026-04-20T02:21:51.640637Z",
	"updated_at": "2026-04-20T02:22:27.768156Z",
	"deleted_at": null,
	"sha1_hash": "f75f7334dbaa0175584e60a262e16cef64bfaa61",
	"title": "Man-in-the-Disk: Android Apps Exposed via External Storage",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 131472,
	"plain_text": "Man-in-the-Disk: Android Apps Exposed via External Storage\r\nBy deugenio\r\nPublished: 2018-08-12 · Archived: 2026-04-20 02:07:09 UTC\r\nResearch By: Slava Makkaveev\r\nRecently, our researchers came across a shortcoming in the design of Android’s use of storage resources. Careless use of\r\nExternal Storage by applications may open the door to an attack resulting in any number of undesired outcomes, such as\r\nsilent installation of unrequested, potentially malicious, apps to the user’s phone, denial of service for legitimate apps, and\r\neven cause applications to crash, opening the door to possible code injection that would then run in the privileged context of\r\nthe attacked application.\r\nThese Man-in-the-Disk attacks are made possible when applications are careless about their use of External Storage, a\r\nresource that is shared across all applications and does not enjoy Android’s built-in Sandbox protection. Failing to employ\r\nsecurity precautions on their own leaves applications vulnerable to the risks of malicious data manipulation.\r\nIn this post we will show how one WRITE_EXTERNAL_STORAGE permission can make it possible for an Android app to\r\nsilently execute privileged code and install other apps.\r\nOverview\r\nThere are two types of Android device storage:\r\nInternal Storage: This is an app’s built-in memory which each application uses separately and is segregated by the\r\nAndroid Sandbox.\r\nExternal Storage: This is a partition in the Internal Storage or SD-card which is shared by all applications.\r\nBefore going any further, though, let’s take a deeper look at Android’s External Storage.\r\nMany high privileged systems and popular apps use Android’s External Storage as a temporary buffer when downloading\r\ndata from the Internet. What’s more, many apps hold working data permanently in the External Storage since the device can\r\noften be limited by using the Internal space only.\r\nAs all third-party apps installed on the device can observe data transferred by other apps via the External Storage, as well as\r\noverwrite a target file, various possibilities are available for a Man-in-the-Disk attack.\r\nFirstly, a malicious app can crash a target app’s native library which parses a storage located data file. This crash can lead to\r\na code execution in the context of a privileged or popular app. Another attack is to hijack an app update flow, overwrite APK\r\nfiles and silently install a rogue app instead of a legitimate one. DoS and EoP vulnerabilities are also possible.\r\nThe Fuzzing Tool\r\nOnce we encountered an app that saves either data or configuration using the External Storage, we decided to use fuzzing\r\ntechniques to try and search for vulnerabilities within the app. However, there are only Black Box Fuzzing available for\r\nAndroid, which would not be an efficient or sufficient, and therefore not really applicable, for our purposes. So in order to\r\nsuccessfully test for vulnerabilities in the target apps our research team adapted an existing fuzzing tool (AFL) to run native\r\nAndroid libraries over the QEMU Emulator. This allowed us to run ‘Grey Box Fuzzing’.\r\nThis tool consists of several parts including patched version of Android Runtime (libart.so), dalvikvm tool, GLib, QEMU\r\nand AFL. The assembly of these tools eventually allows to fuzz a user custom lib wrapped in a DEX file on an actual\r\nAndroid device or an ARM device emulator. The execution flow is as follows: AFL Fuzz Engine → QEMU ARM CPU\r\nemulator → dalvikvm tool → Android Runtime + adapter DEX.\r\nhttps://research.checkpoint.com/androids-man-in-the-disk/\r\nPage 1 of 5\n\nIn the case of some of the apps below, for example Yandex or Google Translate, the ‘Grey Box’ fuzzing allowed us to mutate\r\nthe translation package files in an efficient way until a lib crash was reached. In one case it took just 15 minutes to reach the\r\ncrash, with the other it took half a day.\r\nExamples of a Man-in-the-Disk Attack\r\nLet’s take several examples of how a Man-in-the-Disk attack can be used. These vulnerabilities show that even the biggest\r\nAndroid vendors and developers make dangerous mistakes when working with the External Storage.\r\nGoogle Translate (com.google.android.apps.translate)\r\nGoogle Translate app downloads and holds off-line mode translation packages on external storage –\r\n /storage/emulated/0/Android/data/com.google.android.apps.translate/files/olpv3/v5/25/r11/ . These data files are processed\r\nby libtranslate.so app’s native lib upon entering the first letter for translation. The attacker can then generate a rogue binary,\r\noverwrite original files located in the external storage and crash the lib. This scenario does not require any file observation\r\nfrom the attacker side.\r\nEtt fel inträffade.\r\nDet går inte att köra JavaScript.\r\nVideo: A demonstration of a Man-in-the-Disk attack against Google Translate.\r\nGoogle Voice Assistance (com.google.android.googlequicksearchbox)\r\nThe app downloads offline speech recognition languages to External Storage \r\n(/storage/emulated/0/Android/data/com.google.android.googlequicksearchbox/files/download_cache/) as an archive and\r\nthen decompresses machine learning related binaries in the app’s Internal Storage directory (app_g3_modes). The attacker\r\ncan then overwrite downloaded files and crash libgoogle_speech_jni.so app’s native lib.\r\nhttps://research.checkpoint.com/androids-man-in-the-disk/\r\nPage 2 of 5\n\nEtt fel inträffade.\r\nDet går inte att köra JavaScript.\r\nVideo: A demonstration of a Man-in-the-Disk attack against Google Voice Assistant.\r\nXiaomi Browser (com.android.browser package)\r\nThe Xiaomi Browser downloads a self-updating APK file to External Storage\r\n/storage/emulated/0/Android/data/com.android.browser/files/update, verifies SHA1 and installs the APK. The attacker can\r\nthen overwrite the updated file right after verification since verification and installation are two separated and manually\r\ninvoked actions.\r\nEtt fel inträffade.\r\nDet går inte att köra JavaScript.\r\nVideo: A demonstration of a Man-in-the-Disk attack against Xioami Browser.\r\nhttps://research.checkpoint.com/androids-man-in-the-disk/\r\nPage 3 of 5\n\nYandex Translate (ru.yandex.translate)\r\nThe Yandex Translate app downloads and holds offline mode translation packages on External Storage –\r\n/storage/emulated/0/Android/data/ru.yandex.translate/files/offline/translation/ . The same process follows as was seen with\r\nGoogle Translate, but in this case a different libmobile-android.so native lib is under attack.\r\nEtt fel inträffade.\r\nDet går inte att köra JavaScript.\r\nVideo: A demonstration of a Man-in-the-Disk attack against Yandex Translate.\r\nYandex Search (ru.yandex.searchplugin)\r\nYandex Search downloads and holds offline mode search packages on External Storage –\r\n/storage/emulated/0/Android/data/ru.yandex.searchplugin/files/edge_search_dicts/. The attacker can then generate a rogue\r\nbinary, overwrite the original file located in External Storage and crash liboffline_search-data_reader.so app’s native lib.\r\nhttps://research.checkpoint.com/androids-man-in-the-disk/\r\nPage 4 of 5\n\nEtt fel inträffade.\r\nDet går inte att köra JavaScript.\r\nVideo: A demonstration of a Man-in-the-Disk attack against Yandex Search.\r\nSource: https://research.checkpoint.com/androids-man-in-the-disk/\r\nhttps://research.checkpoint.com/androids-man-in-the-disk/\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://research.checkpoint.com/androids-man-in-the-disk/"
	],
	"report_names": [
		"androids-man-in-the-disk"
	],
	"threat_actors": [],
	"ts_created_at": 1776651711,
	"ts_updated_at": 1776651747,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/f75f7334dbaa0175584e60a262e16cef64bfaa61.pdf",
		"text": "https://archive.orkl.eu/f75f7334dbaa0175584e60a262e16cef64bfaa61.txt",
		"img": "https://archive.orkl.eu/f75f7334dbaa0175584e60a262e16cef64bfaa61.jpg"
	}
}