{
	"id": "da71b1d6-f06e-4946-a012-64988119163f",
	"created_at": "2026-04-10T03:22:02.542767Z",
	"updated_at": "2026-04-10T03:22:19.624585Z",
	"deleted_at": null,
	"sha1_hash": "ed068acf710f63557ab0dc90ffad175701445bae",
	"title": "Multidex trick to unpack Android/BianLian",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 798252,
	"plain_text": "Multidex trick to unpack Android/BianLian\r\nBy @cryptax\r\nPublished: 2022-05-05 · Archived: 2026-04-10 02:05:24 UTC\r\n5 min read\r\nJan 14, 2022\r\nThis article explains how to unpack sample sha256\r\n5b9049c392eaf83b12b98419f14ece1b00042592b003a17e4e6f0fb466281368 which was served from\r\nhttp://videofullizlesite9356[.]site/ApiServices-Files92752/Down at the beginning of January 2022 (see this tweet). The\r\nmalware poses as a Video player and appears to be a member of the Bian Lian malware family (see former analysis 1 and 2).\r\nAlthough the malware has similarities with BankBot, I believe this precise sample is not a banker malware (it does not\r\nattempt to steal your banking credentials or steal from your bank account) but the Bian Lian bot (bulk send of SMS, USSD\r\ncalls etc).\r\nUpdate Jan 17, 2022. Let’s try and clarify. Bian Lian is a “generic” bot. It may be used to steal passwords of banking apps.\r\nSome current samples seem to be particularly interested in stealing credentials from turkish banks.\r\nKudos to @U039b with whom I began this reverse engineering, and @ReBensk, @malwrhunterteam.\r\nSummary (spoiler?) for those who don’t want to read it all :)\r\nThe malware does not use DexClassLoader to unpack the payload DEX. Instead it loads the payload as a\r\nsecondary DEX through multidex support. The packer re-implements multidex support and mainly changes\r\nnames \u0026 adds asset decryption.\r\nYou can use my Java program to decrypt the asset and access the payload.\r\nWhat makes this sample difficult to unpack\r\nThe most common packing mechanism consists in loading a hidden DEX with DexClassLoader . The sample does not use\r\nDexClassLoader (nor PathClassLoader or InMemoryDexClassLoader ). Therefore, we cannot unpack by creating a hook\r\non DexClassLoader that dumps its first file argument.\r\nMany dynamic tools fail (let me know if you find one that works): RMS times out while trying to launch the app, House\r\nfails, and Dexcalibur fails to load the malware’s project due to a bug.\r\nThis malware uses another mechanism to side load its payload. I’ll discuss at the end of the article (section “So, how is\r\nthe DEX loaded if not with DexClassLoader?”). But first, let’s unpack, because actually if your goal is to analyze the\r\npayload, you don’t really need to understand how it is loaded.\r\nDetecting it is packed\r\nThe main activity is com.pmmynubv.nommztx.MainActivity , which is not present in the wrapping APK but in the contained\r\npayload.\r\nPress enter or click to view image in full size\r\nhttps://cryptax.medium.com/multidex-trick-to-unpack-android-bianlian-ed52eb791e56\r\nPage 1 of 5\n\nDroidLysis detects the sample is packed\r\nUnpacking\r\nUnderstanding the packing mechanism takes a little bit of time, because all strings are obfuscated (fortunately JEB decrypts\r\nnearly all of them) and DexClassLoader — typically to load a DEX — is not used.\r\nThe flow is the following. The manifest references com.brazzers.naughty.g as the application. Indeed, g extends\r\nApplication and can be seen as the main entry point of the app. One of the first methods to be called is the protected\r\nmethod attachBaseContext .\r\nThis is where the unpacking actually begins! For clarity, I renamed the method “install_multidex”. Its original\r\nname was of course obfuscated to “a”. It is a bit difficult to spot so much happens through this simple call…\r\nFrom attachBaseContext , the malware calls a cascade of functions which (1) locate an asset named G9ugwFtlG1.jwi , (2)\r\ndeflates it and (3) finally decrypts it using a home-made algorithm with hard coded key\r\nGIUh9JHGUIGIUHGokfewrofij58YV6UhYUF7gjhgv .\r\nGet @cryptax’s stories in your inbox\r\nJoin Medium for free to get updates from this writer.\r\nRemember me for faster sign in\r\nThe strings G9ugwFtlG1, .jwi, GIUh9JHGUIGIUHGokfewrofij58YV6UhYUF7gjhgv are found in a malware’s configuration\r\nclass com.brazzers.naughty.h, but note they are all obfuscated.\r\nPress enter or click to view image in full size\r\nhttps://cryptax.medium.com/multidex-trick-to-unpack-android-bianlian-ed52eb791e56\r\nPage 2 of 5\n\nObfuscated bot configuration strings. De-obfuscation occurs through i.a()\r\nThe obfuscation is not complex: a XOR with a fixed character, nevertheless I was happy JEB did the work automatically for\r\nme!\r\nPress enter or click to view image in full size\r\nIsn’t that nice? JEB automatically decrypts strings when a simple algorithm is used. JEB doesn’t do all the\r\nwork though, you still have to reverse engineer to understand the meaning: I manually renamed obfuscated\r\nname h.a to h.PAYLOAD_EXTENSION etc.\r\nIf you want to follow the calls:\r\n1. com.brazzers.naughty.g.attachBaseContext(Context)\r\n2. com.brazzers.naughty.a.a(Context)\r\n3. com.brazzers.naughty.a.a(Context, File, File…)\r\n4. com.brazzers.naughty.b.a(Context, String…)\r\n5. com.brazzers.naughty.b.c()\r\n6. com.brazzers.naughty.b.a(ZipFile, ZipEntry…)\r\n7. com.brazzers.naughty.k.a(String, InputStream, OutputStream)\r\nWe’ll see later the malware is actually following the normal flow for loading secondary DEXes, except the names are\r\nobfuscated.\r\nAutomating the unpacking\r\nI basically copied the malware’s unpacking code in com.brazzers.naughty.k.a , did a little adaptation, and finally worked\r\nout a Java program that automatically unpacks the malware (get the code here). Run the program in the directory where\r\nG9ugwFtIG1.jwi is available ( ./assets/7G8Uwty ), and it will unpack and create a unpacked.zip which contains the\r\npayload DEX.\r\nhttps://cryptax.medium.com/multidex-trick-to-unpack-android-bianlian-ed52eb791e56\r\nPage 3 of 5\n\nStatic program to unpack the asset — java UnpackJwi\r\n$ unzip -l unpacked.zip\r\nArchive: unpacked.zip\r\n Length Date Time Name\r\n--------- ---------- ----- ----\r\n 906456 2022-01-14 11:05 classes.dex\r\n--------- -------\r\n 906456 1 file\r\nSo, how is the DEX loaded if not with DexClassLoader?\r\nThe malware uses the multidex scheme to load the payload as secondary DEX. This method has existed for a couple of\r\nyears (e.g. Android/Rootnik using it in 2017), but I hadn’t seen it for a while. In 2022, it seems we have a new packer in the\r\nwild which uses this technique as the same packer is used here in a sample of Flubot.\r\nThe technique consists in re-writing the way applications load multiple DEX. The Android code can be found here. The\r\nclasses MultiDex and MultiDexApplication are the core of the functionality. They implement support of APKs with\r\nmultiple DEX. Everything begins in indeed in attachBaseContext of MultiDexApplication. The malware re-implements\r\nMultiDexApplication , MultiDex and MultiDexExtractor with little changes part code re-organization and obfuscated\r\nnames:\r\nMultiDexApplication is found in com.brazzers.naughty.g\r\nMultiDex is within in com.brazzers.naughty.a\r\nand MultiDexExtractor is com.brazzers.naughty.b\r\nThe two main functional changes are :\r\n1. Changes in file and folder names. The extracted DEX will be located in a directory named hf8U6UUIwiqaGgo\r\ninstead of the standard secondary-dexes name, the extracted suffix will be .weg instead of .zip , and some other\r\nminor details like the lock file name is changed to T9etIiaI.uw87 instead of MultiDex.lock . The goal is\r\nobviously to complicate reverse engineering, but also to make the files less noticeable should they be spotted during\r\nextraction on the device.\r\n2. Deflating and decryption of the secondary DEXes. Compare the original code with the malware’s version below.\r\nPress enter or click to view image in full size\r\nhttps://cryptax.medium.com/multidex-trick-to-unpack-android-bianlian-ed52eb791e56\r\nPage 4 of 5\n\nOriginal code from\r\nhttps://android.googlesource.com/platform/frameworks/multidex/+/refs/heads/master/library/src/androidx/multidex/MultiDexExtra\r\n(not malicious!)\r\nPress enter or click to view image in full size\r\nMalware’s version. The input is deflated and decrypted.\r\nThe next article will deal with the reverse engineering of the payload DEX.\r\nMore recent samples of January 14 (today)\r\nSome newer samples of that malicious video application have been released today: see Twitter. I haven’t looked in all\r\nsamples yet, but at least the first one, 01658_Video_Oynatıcı.apk (sha256:\r\nd105764cd5383acacd463517691a0a7578847a8174664fc2c1da5efd8a30719d ) does not use the same packer. It uses the\r\ncommon DexClassLoader method, actually the same packing mechanism as this sample. Watch for the unpacked payload\r\nin a file named maXclr.json .\r\ngeneric_x86_64:/data/data/com.friend.bronze/app_DynamicOptDex # ls\r\nmaXclr.json maXclr.json.prof\r\nThe payload DEX ( maXclr.json ) is a Bian Lian sample.\r\n— the Crypto Girl\r\nSource: https://cryptax.medium.com/multidex-trick-to-unpack-android-bianlian-ed52eb791e56\r\nhttps://cryptax.medium.com/multidex-trick-to-unpack-android-bianlian-ed52eb791e56\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://cryptax.medium.com/multidex-trick-to-unpack-android-bianlian-ed52eb791e56"
	],
	"report_names": [
		"multidex-trick-to-unpack-android-bianlian-ed52eb791e56"
	],
	"threat_actors": [],
	"ts_created_at": 1775791322,
	"ts_updated_at": 1775791339,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ed068acf710f63557ab0dc90ffad175701445bae.pdf",
		"text": "https://archive.orkl.eu/ed068acf710f63557ab0dc90ffad175701445bae.txt",
		"img": "https://archive.orkl.eu/ed068acf710f63557ab0dc90ffad175701445bae.jpg"
	}
}