HackDig : Dig high-quality web security articles for hackers

Sophisticated DEX obfuscation or Proguard configuration issue?

2014-08-10 19:51

Recently, I ran into a malicious sample (Android/Mseg.A!tr.spy) which was causing Baksmali to stall.This does not happen that often. I contacted Jesus Freke, the author of smali/baksmali, who quickly fixed the issue.

A deeper look in the sample turned out to be quite interesting. The sample is highly obfuscated (perhaps actually a bit too much - we'll discuss that later) with very long and strange class and method names. For instance, we note a class named "AFHttpPacket;>" (yes, the ; and > are part of the name) in a no less strange namespace:


(note the ' < Lcom' inside the path).Inside that class, methods have yet again strange names: "ERROR -- call requestTapjoyConnect before any other Tapjoy methods" or "----------------------------------------".

Android Mseg BlockingQueue

Many tools don't like those names at all.

Dex2jar crashes with an exception:

~/softs/dex2jar- ../../original/0C3AB5C5.vnd 
dex2jar ../../original/0C3AB5C5.vnd -> 0C3AB5C5-dex2jar.jar
java.lang.ArrayIndexOutOfBoundsException: 3
at org.objectweb.asm.Type.a(Unknown Source)

IDA Pro (v6.3) also crashes.

Android Mseg crashIDA

Androguard gets partially lost too. It sees the class:

In [6]: d.get_classes_names()

It also actually sees the strange method names:

    In [12]: for current_method in methods:
if current_method.name.startswith('ERROR'):
print current_method.show_info()
########## Method Information
Ljava/util/concurrent/BlockingQueue<Lcom/adfresca/sdk/packet/AFHttpPacket;>;->ERROR -- call requestTapjoyConnect before any other Tapjoy methods(deliverSelfNotifications deliverSelfNotifications mCurItem)Lcom/flurry/android/e; [access_flags=public]

But it does not correctly extend the python namespaces, making it difficult to access and inspect the corresponding methods:

In [18]: d.CLASS_ja
<no completion>

Are there tools which correctly read this malicious DEX file? Yes, but you've got to fall back to low-level tools.

For example, 010 Editor correctly parses the DEX confirming the strange choice of names.

Android Mseg 010 longname

My hidex script also parses it not too bad:

class idx = Ljava/util/concurrent/BlockingQueue<Lcom/adfresca/sdk/packet/AFHttpPacket;>; (0x3AB)
virtual methods:
name=---------------------------------------- (0x1173) (position=0x1899D8)
access = 0x1 (1)
code_offset= 0x10B364 (1094500) [e4 e6 42 ]
idx_diff = 4467
name=ERROR -- call requestTapjoyConnect before any other Tapjoy methods (0x1174) (position=0x1899DE)

A sample which crashes most analysis tools and significantly increases reverse engineering difficulty sounds like a nightmare to analysts. Have we discovered a new sophisticated obfuscation technique in the wild? Fortunately, perhaps not, because the malware authors pushed the obfuscation a bit too far, and those DEX files have the DEX verifier complain. And the DEX is unable to load in the end. [that'll teach ya]

I/PackageManager(   79): Running dexopt on: com.smh.hxcr
E/dalvikvm( 3973): Invalid type descriptor: ' Created new loader '
E/dalvikvm( 3973): Trouble with item 0 @ offset 0x6628
E/dalvikvm( 3973): Cross-item verify of section type 0002 failed
E/dalvikvm( 3973): ERROR: Byte swap + verify failed

It's difficult to know what happened here. Is this an attempt to improve DEX obfuscation, or a configuration error of proguard which ended up in ruining the malware author's DEX.

-- the Crypto Girl

sha256 of DEX: cc42f8a1fc6805a9deeaae198fb4580b304b51489dec4209929a09b9c3868aee

Source: eussi-noitarugifnoc-draugorp-ro-noitacsufbo-xed-detacitsihpos/tsop/moc.tenitrof.golb

Read:3451 | Comments:0 | Tags:No Tag

“Sophisticated DEX obfuscation or Proguard configuration issue?”0 Comments

Submit A Comment



Blog :

Verification Code: