{
	"id": "2ec2701e-71a2-43f2-abfd-75bebde6507d",
	"created_at": "2026-04-06T01:29:19.356679Z",
	"updated_at": "2026-04-10T13:11:45.459841Z",
	"deleted_at": null,
	"sha1_hash": "079bb924b1486776ae50107eb90b4e359c040133",
	"title": "Teardown of Android/Ztorg (Part 2)",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1087291,
	"plain_text": "Teardown of Android/Ztorg (Part 2)\r\nBy Axelle Apvrille\r\nPublished: 2017-03-15 · Archived: 2026-04-06 00:56:46 UTC\r\nUPDATE March 20, 2017 : the sample does not seem to embed root exploits themselves, but more precisely\r\nexecutables that run rooting tools. Also Agcr64 is curiously a 32-bit executable, not 64-bit.\r\nIn the part 1 of this blog, we saw that Android/Ztorg.AM!tr silently downloads a remote encrypted APK, then\r\ninstalls it and launches a method named c() in the n.a.c.q class. In this blog post, we’ll investigate what this does.\r\nThis is the method c() of n.a.c.q:\r\nThis prints \"world,\" then waits for 200 seconds before starting a thread named n.a.c.a. I'll spare you a few hops,\r\nbut among the first things we notice is that the sample uses the same string obfuscation routine, except this time it\r\nis not named a.b.c.a() but a.a.p.a(). We patch the JEB2 script to deobfuscate those strings:\r\nEmbedded Packages\r\nThe sample checks for various packages (om.android.provider.ring.a, com.ndroid.livct.d). If they are present,\r\nit starts them. If not, it retrieves them and starts them.\r\nThe way it retrieves the application is quite peculiar. By default, it does not download it from the web, but gets it\r\nfrom a hexadecimal string stored in the code itself. It only downloads from the web if the hexstring is not\r\npresent.\r\nhttp://blog.fortinet.com/2017/03/08/teardown-of-android-ztorg-part-2\r\nPage 1 of 9\n\nIt retrieves many files that way: Android applications, ELF executables and scripts. All of these are embedded in\r\nthe sample itself. Sometimes, the sample is embedded in an encrypted form (making it even more difficult to\r\ndetect for an anti-virus engine.) This is the case of the mainmtk.apk application, which is retrieved from a DES\r\nencrypted hex string. The DES key is built using a homemade algorithm, which consists of numerous Base64\r\nencodings and decodings.\r\nResorting to Encrypted File Download\r\nWhen the files are downloaded from the web, they are not sent in clear text, but are XOR encrypted (see\r\nclass b.b.b.a.b). The XOR key is contained within the encrypted stream.\r\nBased on the reverse engineering of the decryption class, we can implement a decryptor. Mine is available here.\r\nFor example, once decrypted, the bx file downloaded from hxxp://ks.freeplayweb.com/lulu/bx turns into an ELF\r\nexecutable (a root exploit):\r\nCreating Scripts\r\nThe sample also uses some shell scripts. They are not included in the assets or resources, but embedded in the\r\ncode. This is probably done so that anti-virus engines cannot directly match or search for those scripts.\r\nFor instance, the code below writes a shell script named boy.\r\nhttp://blog.fortinet.com/2017/03/08/teardown-of-android-ztorg-part-2\r\nPage 2 of 9\n\nThe script will look as follows, and is used to run shell commands.\r\nFiles Summary\r\nNow let's summarize the various files the sample uses. We have applications and ELF executables. If you want to\r\nfollow along in the source code, those are retrieved in the b.b.d.a namespace.\r\nThe files are stored locally in the application's directory, in subdirectories named .zog or .zok. Note, the name\r\nstarting with a point will conceal the file to basic file listings.\r\nhttp://blog.fortinet.com/2017/03/08/teardown-of-android-ztorg-part-2\r\nPage 3 of 9\n\nFile name File type Description\r\nAgcr32\r\nELF\r\nexecutable\r\nRuns root exploit tools, 32 bit version\r\nAgcr64\r\nELF\r\nexecutable\r\nRuns root exploit tools, expected a 64 bit version, but actually it seems it's\r\na 32 bit version too...\r\nbbox.apk Application Installs busybox\r\nbx\r\nELF\r\nexecutable\r\nRuns root exploit tools\r\ncx\r\nELF\r\nexecutable\r\nRuns root exploit tools\r\nexp\r\nELF\r\nexecutable\r\nRuns root exploit tools\r\nmaink.apk Zip Contains boy and bx files\r\nmainmtk.apk\r\nELF\r\nexecutable\r\nRusn root exploit tools\r\nmainm.apk   Replacement for com.android.musitk.b\r\nmainp.apk   Could not be retrieved (server down)\r\nmains.apk Application Replacement for com.ndroid.livct.d\r\nhttp://blog.fortinet.com/2017/03/08/teardown-of-android-ztorg-part-2\r\nPage 4 of 9\n\nFile name File type Description\r\nmains2.apk Application Replacement for com.android.provider.ring.a\r\nnn.zip\r\nELF\r\nexecutable\r\nRuns root exploit tools\r\nnp\r\nELF\r\nexecutable\r\nRuns root exploit tools\r\nsupolicy\r\nELF\r\nexecutable\r\ntool\r\nym32\r\nELF\r\nexecutable\r\nRuns root exploit, 32 bit version\r\nym64\r\nELF\r\nexecutable\r\nRuns root exploit, 64 bit version\r\nWe see we have:\r\nTools such as busybox and supolicy. These are not malicious. Busybox is used to support various Unix\r\ncommands on Android. Supolicy is used to modify the current SE Linux policies on Android, and for\r\ninstance, switch the phone to permissive policies.\r\nRoot exploit tools. For example, the executable Agcr32 tries to root the phone by running rooting tools. It\r\nconsiders it has succeeded if the output contains the keyword TOY. See below. This is the 32-bit variant.\r\nhttp://blog.fortinet.com/2017/03/08/teardown-of-android-ztorg-part-2\r\nPage 5 of 9\n\nScripts to run commands.\r\nRunning the exploits\r\nOnce the root exploits are on the file system, they need to be run. This is done in the code by creating a new\r\nprocess that runs sh, writing the shell commands to the process's output stream, and reading the responses on the\r\ninput stream.\r\nhttp://blog.fortinet.com/2017/03/08/teardown-of-android-ztorg-part-2\r\nPage 6 of 9\n\nPayload\r\nLet's put pieces together.\r\nThe sample:\r\nGets numerous exploits, tools and scripts to root the device. The files are embedded in the code itself, or\r\nretrieved from external websites.\r\nLowers the SE Linux policy and attempts to root the device.\r\nOnce the device is rooted, the sample gets to its real payload:\r\nReplaces some system files with its own versions. For example, it creates a backup of the\r\noriginal /system/bin/debuggerd, replaces it with its own .zog/.k file, assigns it to root, and changes its SE\r\nLinux security context.\r\nInstalls various applications and runs them. In the case of this sample, those applications are\r\ncom.android.provider.ring.a, com.ndroid.livct.d, and com.android.musitk.b. The .zog/.k ELF executable\r\nalso downloads other applications from a remote server and installs them. The screenshot below shows\r\nhttp://blog.fortinet.com/2017/03/08/teardown-of-android-ztorg-part-2\r\nPage 7 of 9\n\nthe .zog/.k starting a key assistance application (am start -n) and downloading from http://api.agoall.com/\r\n(no longer responds.)\r\nSo, we have a malware that roots victims' devices without their knowledge, and uses this privilege to install other\r\nmalicious applications.\r\nConclusion\r\nThis concludes the analysis of the sample silently downloaded by the Android/Ztorg.AM!tr sample that we studied\r\nin Part 1 of this blog.\r\nMy guess is that you will agree with me that this malware is very advanced. There is string obfuscation, multiple\r\nlevels of encryption (nested), root exploits, tools, and scripts hidden inside the code. The malware will be difficult\r\nhttp://blog.fortinet.com/2017/03/08/teardown-of-android-ztorg-part-2\r\nPage 8 of 9\n\nto remove from the device, because it spans across many locations and replaces system binaries.\r\nThis malware is detected as Android/Ztorg.K!tr. Its sha256 sum\r\nis 5324460dfe1d4f774a024ecc375e3a858c96355f71afccf0cb67438037697b06.\r\nThe downloader (see Part 1) is detected as Android/Ztorg.AM!tr.\r\nIts sha256 sum is 2c546ad7f102f2f345f30f556b8d8162bd365a7f1a52967fce906d46a2b0dac4.\r\n-- the Crypto Girl\r\nSource: http://blog.fortinet.com/2017/03/08/teardown-of-android-ztorg-part-2\r\nhttp://blog.fortinet.com/2017/03/08/teardown-of-android-ztorg-part-2\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"http://blog.fortinet.com/2017/03/08/teardown-of-android-ztorg-part-2"
	],
	"report_names": [
		"teardown-of-android-ztorg-part-2"
	],
	"threat_actors": [],
	"ts_created_at": 1775438959,
	"ts_updated_at": 1775826705,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/079bb924b1486776ae50107eb90b4e359c040133.pdf",
		"text": "https://archive.orkl.eu/079bb924b1486776ae50107eb90b4e359c040133.txt",
		"img": "https://archive.orkl.eu/079bb924b1486776ae50107eb90b4e359c040133.jpg"
	}
}