# Multidex trick to unpack Android/BianLian **[cryptax.medium.com/multidex-trick-to-unpack-android-bianlian-ed52eb791e56](https://cryptax.medium.com/multidex-trick-to-unpack-android-bianlian-ed52eb791e56)** @cryptax May 5, 2022 [@cryptax](https://cryptax.medium.com/?source=post_page-----ed52eb791e56--------------------------------) Jan 14 5 min read This article explains how to unpack sample sha256 ``` 5b9049c392eaf83b12b98419f14ece1b00042592b003a17e4e6f0fb466281368 which was ``` served from http://videofullizlesite9356[.]site/ApiServices-Files92752/Down at the beginning [of January 2022 (see this tweet). The malware poses as a Video player and appears to be a](https://twitter.com/ReBensk/status/1478699273558528002?s=20) [member of the Bian Lian malware family (see former analysis 1 and](https://www.threatfabric.com/blogs/bianlian_from_rags_to_riches_the_malware_dropper_that_had_a_dream.html) [2). Although the](https://www.fortinet.com/blog/threat-research/new-wave-bianlian-malware) malware has similarities with BankBot, I believe this precise sample is not a banker malware (it does not attempt to steal your banking credentials or steal from your bank account) but the **Bian Lian bot (bulk send of SMS, USSD calls etc).** _Update Jan 17, 2022. Let’s try and clarify. Bian Lian is a “generic” bot. It may be used to steal_ _passwords of banking apps. Some current samples seem to be particularly interested in_ _stealing credentials from turkish banks._ _Kudos to @U039b with whom I began this reverse engineering, and @ReBensk, ._ **Summary (spoiler?) for those who don’t want to read it all :)** The malware does not use `DexClassLoader to unpack the payload DEX. Instead it` loads the payload as a secondary DEX through multidex support. The packer reimplements multidex support and mainly changes names & adds asset decryption. You can use [my Java program to decrypt the asset and access the payload.](https://github.com/cryptax/misc-code/blob/master/UnpackJwi.java) ## What makes this sample difficult to unpack The most common packing mechanism consists in loading a hidden DEX with ``` DexClassLoader . The sample does not use DexClassLoader (nor PathClassLoader ``` or `InMemoryDexClassLoader ). Therefore, we cannot unpack by creating a hook on` ``` DexClassLoader that dumps its first file argument. ``` ----- Many dynamic tools fail (let me know if you find one that works): [RMS times out while](https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security) [trying to launch the app, House fails, and](https://github.com/nccgroup/house) [Dexcalibur fails to load the malware’s project due](https://github.com/FrenchYeti/dexcalibur/issues/69) to a bug. **This malware uses another mechanism to side load its payload. I’ll discuss at the end** **of the article (section “So, how is the DEX loaded if not with DexClassLoader?”). But first,** let’s unpack, because actually if your goal is to analyze the payload, you don’t really need to understand how it is loaded. ## Detecting it is packed The main activity is `com.pmmynubv.nommztx.MainActivity, which is not present in the` wrapping APK but in the contained payload. DroidLysis detects the sample is packed ## Unpacking Understanding the packing mechanism takes a little bit of time, because all strings are obfuscated (fortunately JEB decrypts nearly all of them) and `DexClassLoader — typically` to load a DEX — is not used. The flow is the following. The manifest references `com.brazzers.naughty.g as the` application. Indeed, `g extends` `Application and can be seen as the main entry point of` the app. One of the first methods to be called is the protected method ``` attachBaseContext . ``` ----- This is where the unpacking actually begins! For clarity, I renamed the method “install_multidex”. Its original name was of course obfuscated to “a”. It is a bit difficult to spot so much happens through this simple call… From `attachBaseContext, the malware calls a cascade of functions which (1) locate an` asset named `G9ugwFtlG1.jwi, (2) deflates it and (3) finally decrypts it using a home-made` algorithm with hard coded key `GIUh9JHGUIGIUHGokfewrofij58YV6UhYUF7gjhgv .` The strings `G9ugwFtlG1, .jwi, GIUh9JHGUIGIUHGokfewrofij58YV6UhYUF7gjhgv are` found in a malware’s configuration class com.brazzers.naughty.h, but note they are all obfuscated. Obfuscated bot configuration strings. De-obfuscation occurs through i.a() The obfuscation is not complex: a XOR with a fixed character, nevertheless I was happy JEB did the work automatically for me! ----- Isn’t that nice? JEB automatically decrypts strings when a simple algorithm is used. JEB doesn’t do all the work though, you still have to reverse engineer to understand the meaning: I manually renamed obfuscated name h.a to h.PAYLOAD_EXTENSION etc. If you want to follow the calls: 1. com.brazzers.naughty.g.attachBaseContext(Context) 2. com.brazzers.naughty.a.a(Context) 3. com.brazzers.naughty.a.a(Context, File, File…) 4. com.brazzers.naughty.b.a(Context, String…) 5. com.brazzers.naughty.b.c() 6. com.brazzers.naughty.b.a(ZipFile, ZipEntry…) 7. com.brazzers.naughty.k.a(String, InputStream, OutputStream) We’ll see later the malware is actually following the normal flow for loading secondary DEXes, except the names are obfuscated. ## Automating the unpacking I basically copied the malware’s unpacking code in `com.brazzers.naughty.k.a, did a` little adaptation, and finally worked out a Java program that automatically unpacks the [malware (get the code here). Run the program in the directory where](https://github.com/cryptax/misc-code/blob/master/UnpackJwi.java) `G9ugwFtIG1.jwi is` available ( ./assets/7G8Uwty ), and it will unpack and create a `unpacked.zip which` contains the payload DEX. ----- Static program to unpack the asset — java UnpackJwi ``` $ unzip -l unpacked.zip Archive: unpacked.zip Length Date Time Name-------- ---------- ----- ---- 906456 2022-01-14 11:05 classes.dex--------- ------- 906456 1 file ## So, how is the DEX loaded if not with DexClassLoader? ``` The malware uses the multidex scheme to load the payload as secondary DEX. This [method has existed for a couple of years (e.g. Android/Rootnik using it in 2017), but I hadn’t](https://www.fortinet.com/blog/threat-research/deep-analysis-of-android-rootnik-malware-using-advanced-anti-debug-and-anti-hook-part-i-debugging-in-the-scope-of-native-layer) seen it for a while. In 2022, it seems we have a new packer in the wild which uses this [technique as the same packer is used here in a sample of Flubot.](https://www.f5.com/labs/articles/threat-intelligence/flubots-authors-employ-creative-and-sophisticated-techniques-to-achieve-their-goals-in-version-50-and-beyond) The technique consists in re-writing the way applications load multiple DEX. The Android [code can be found here. The classes](https://android.googlesource.com/platform/frameworks/multidex/+/refs/heads/master/library/src/androidx/multidex) `MultiDex and` `MultiDexApplication are the core` [of the functionality. They implement support of APKs with multiple DEX. Everything begins in](https://developer.android.com/studio/build/multidex) indeed in `attachBaseContext of` `MultiDexApplication. The malware re-implements` ``` MultiDexApplication, MultiDex and MultiDexExtractor with little changes part ``` code re-organization and obfuscated names: ``` MultiDexApplication is found in com.brazzers.naughty.g MultiDex is within in com.brazzers.naughty.a ``` and `MultiDexExtractor is` `com.brazzers.naughty.b` The two main functional changes are : 1. . The extracted DEX will be located in a directory named `hf8U6UUIwiqaGgo instead` of the standard `secondary-dexes name, the extracted suffix will be` `.weg instead of` ``` .zip, and some other minor details like the lock file name is changed to T9etIiaI.uw87 instead of MultiDex.lock . The goal is obviously to complicate ``` reverse engineering, but also to make the files less noticeable should they be spotted during extraction on the device. 2. . Compare the original code with the malware’s version below. ----- Original code from (not malicious!) Malware’s version. The input is deflated and decrypted. The next article will deal with the reverse engineering of the payload DEX. ## More recent samples of January 14 (today) Some newer samples of that malicious video application have been released today: see [Twitter. I haven’t looked in all samples yet, but at least the first one,](https://twitter.com/malwrhunterteam/status/1481947346619584514?s=20w) 01658_Video_Oynatıcı.apk (sha256: ``` d105764cd5383acacd463517691a0a7578847a8174664fc2c1da5efd8a30719d ) does not ``` use the same packer. It uses the common `DexClassLoader method, actually the same` [packing mechanism as this sample. Watch for the unpacked payload in a file named](https://cryptax.medium.com/unpacking-an-android-malware-with-dexcalibur-and-jeb-59bdd905d4a7) ``` maXclr.json . generic_x86_64:/data/data/com.friend.bronze/app_DynamicOptDex # lsmaXclr.json maXclr.json.prof ``` The payload DEX ( maXclr.json ) is a Bian Lian sample. ----- — the Crypto Girl -----