Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[HELP] How to decompile protected classes.dex file
#1
hi, i need your help to decompile classes.dex file that cant be extracting. Original .dex file size is 6mb, bun i extract it just have 6kb size file.and whem i decompiled it just just have 'Medusah' smali folder.

how to decrypt and decompile this file to get original classes.dex file??
i will uplodad the classes.dex file of you want to looking on it.pls help
Reply
#2
Are you using dex2jar?
Reply
#3
yes i am used d2j to convert .dex file to
jar. but still no luck. still getting error, and the file size is only 4kb on .jar format. original .dex file is 6mb.
Reply
#4
looks like this dex is protected/packed in some way. i think the packing process changed dex-headers. at runtime stubcode will "repair" the headers so the dexfile can be loaded again. this is a common technique.

what's in the decompiled classes ?
is there any native libraray in the apk ?

it would be nice if you could share a sample.
Reply
#5
(04-09-2016, 06:01 PM)mik01 Wrote:  looks like this dex is protected/packed in some way. i think the packing process changed dex-headers. at runtime stubcode will "repair" the headers so the dexfile can be loaded again. this is a common technique.

what's in the decompiled classes ?
is there any native libraray in the apk ?

it would be nice if you could share a sample.

there is just 'medusah' file on decompiled folder.

file :cantdecompile.zip

do you using skype sir/
Reply
#6
(04-13-2016, 04:55 AM)youbrey Wrote:  there is just 'medusah' file on decompiled folder.

file :cantdecompile.zip

is the original dex file in the zip? the one in the file is just 3kb. if this is the classes.dex after packing the original apk/dex, there has to be some kind of resource file or asset file which is holding the original code. this can be packed or crypted, too. it would be nice if you could share the apk you're trying to decompile. then we have everything we need to give it a try.

(04-13-2016, 04:55 AM)youbrey Wrote:  do you using skype sir/

nope, just this nice board Smile

--edit--
looks like your target apk was packed using www.medusah.net - please share the target apk.

it would be nice if someone could move this thread to the android forum. thx!
Reply
#7
(04-19-2016, 06:53 AM)mik01 Wrote:  
(04-13-2016, 04:55 AM)youbrey Wrote:  there is just 'medusah' file on decompiled folder.

file :cantdecompile.zip

is the original dex file in the zip? the one in the file is just 3kb. if this is the classes.dex after packing the original apk/dex, there has to be some kind of resource file or asset file which is holding the original code. this can be packed or crypted, too. it would be nice if you could share the apk you're trying to decompile. then we have everything we need to give it a try.

(04-13-2016, 04:55 AM)youbrey Wrote:  do you using skype sir/

nope, just this nice board Smile

--edit--
looks like your target apk was packed using www.medusah.net - please share the target apk.

it would be nice if someone could move this thread to the android forum. thx!

target Apk :
https://drive.google.com/file/d/0B5OJgB4...ef=2&pli=1

do you use facebook?
Reply
#8
thanks for sharing the target!

i had a little bit of spare time to take a look into the apk. here is what i found so far

the target is packed with medusah, or any custom packer which tries to let us think this one is medusah.net Smile

the first class created when an android app starts is the one declared in the <application>-tag in manifest.
Code:
<application android:name="com.seworks.medusah.app">

com.seworks.medusah.app.onCreate() calls methods from com.seworks.medusah.Medusa and passes private fields (object references) from android's internal context objects. i think they are used to make a context switch between the medusah packer app and the packed app. at the first look i think the target app is unpacked at runtime and the packer prepars the context so the original app can run in it.

com.seworks.medusah.Medusa.app also uses com.seworks.medusah.Medusa.qawsefd and passes thinks like the classloader. if we take a look at qawsefd's methods, the signatures let us guess that this class is used as a proxy between native code and java.

Code:
public native String a1(String input, AssetManager assetManager, String input2);
public native void a2(Context context; String input, Application app, ClassLoader classLoader);
public native void a4(Object obj, String, Object, Object);
public native void b(String input, String input2, AssetManager assetManager);
public native Object b1(String input, AssetManager assetManager, Object object);
public native void b2(String input, String input2);

libpp.so has to be linked to some other libs but none of them are present in the libs folder.
Code:
NEEDED               liblog.so
  NEEDED               libz.so
  NEEDED               libdl.so
  NEEDED               libandroid.so
  NEEDED               libstdc++.so
  NEEDED               libm.so
  NEEDED               libc.so

libpp.so directly exports the functions used in java which makes it a little bit easier to follow the code in static analysis. some of the strings in the shared object
are crypted and maybe some code, too - didn't take a look

Code:
0x1458 Java_com_seworks_medusah_qawsefd_a1
0x175C Java_com_seworks_medusah_qawsefd_b1
0x1B10 Java_com_seworks_medusah_qawsefd_a2
0x1BDC Java_com_seworks_medusah_qawsefd_a4
0x1E9C Java_com_seworks_medusah_qawsefd_b
0x1E9E Java_com_seworks_medusah_qawsefd_b2

if you really want to unpack this target there are two options for you:
1. go a head with static analysis. find the code which decrypts / unpacks the original apk - somewhere in the apk is the packed apk. (assets, libs, ...)
2. try to get a memory dump when the app is running. search the dump for the dex header magic. this way you could get the original dex file.
Reply
#9
(04-25-2016, 04:41 PM)mik01 Wrote:  thanks for sharing the target!

i had a little bit of spare time to take a look into the apk. here is what i found so far

the target is packed with medusah, or any custom packer which tries to let us think this one is medusah.net Smile

the first class created when an android app starts is the one declared in the <application>-tag in manifest.
Code:
<application android:name="com.seworks.medusah.app">

com.seworks.medusah.app.onCreate() calls methods from com.seworks.medusah.Medusa and passes private fields (object references) from android's internal context objects. i think they are used to make a context switch between the medusah packer app and the packed app. at the first look i think the target app is unpacked at runtime and the packer prepars the context so the original app can run in it.

com.seworks.medusah.Medusa.app also uses com.seworks.medusah.Medusa.qawsefd and passes thinks like the classloader. if we take a look at qawsefd's methods, the signatures let us guess that this class is used as a proxy between native code and java.

Code:
public native String a1(String input, AssetManager assetManager, String input2);
public native void a2(Context context; String input, Application app, ClassLoader classLoader);
public native void a4(Object obj, String, Object, Object);
public native void b(String input, String input2, AssetManager assetManager);
public native Object b1(String input, AssetManager assetManager, Object object);
public native void b2(String input, String input2);

libpp.so has to be linked to some other libs but none of them are present in the libs folder.
Code:
 NEEDED               liblog.so
 NEEDED               libz.so
 NEEDED               libdl.so
 NEEDED               libandroid.so
 NEEDED               libstdc++.so
 NEEDED               libm.so
 NEEDED               libc.so

libpp.so directly exports the functions used in java which makes it a little bit easier to follow the code in static analysis. some of the strings in the shared object
are crypted and maybe some code, too - didn't take a look

Code:
0x1458 Java_com_seworks_medusah_qawsefd_a1
0x175C Java_com_seworks_medusah_qawsefd_b1
0x1B10 Java_com_seworks_medusah_qawsefd_a2
0x1BDC Java_com_seworks_medusah_qawsefd_a4
0x1E9C Java_com_seworks_medusah_qawsefd_b
0x1E9E Java_com_seworks_medusah_qawsefd_b2

if you really want to unpack this target there are two options for you:
1. go a head with static analysis. find the code which decrypts / unpacks the original apk - somewhere in the apk is the packed apk. (assets, libs, ...)
2. try to get a memory dump when the app is running. search the dump for the dex header magic. this way you could get the original dex file.

sir, i really want to be your student. Sad
do you have look in to high-resolution.png on assets folder sir? my friend told to me that is the original .dex file or hidden on it. on original .apk there is no high-resolution.png file on assets folder.

question : how to do option 2 sir? i really a newbie.
Reply
#10
yes, your friend could be right. I didn't look any further on the target but i've seen libpp.so has some AES decryption routines which get called in almost every jni method. so i guess the original classes.dex is aes encrypted.

libpp.so does export a lot of symbols without hiding the original c/c++ function names. one can easily follow the calls to the encryption and decoding. if i have some time at the weekend i'm going to take a deeper look.

to dump a process' memory you need root in your test environment. then you can read all memory regions for processes in /proc/<pid>/maps. with the valid memory addresses from the maps file you can read the memory from /proc/<pid>/mem. all dexfiles should (some packers try to hide it in memory) start with a magic value. you can search the memory for that value and then dump the regions. this could give you the original classes.dex. the following links should get you into this topic

http://www.tldp.org/LDP/Linux-Filesystem.../proc.html
https://www.youtube.com/watch?v=RNqzF6X9lms
https://github.com/504ensicsLabs/LiME
Reply
 


Forum Jump:


Users browsing this thread: 2 Guest(s)

About The Bytecode Club

We're a community focused on Reverse Engineering, we try to target Java/Android but we also include other langauges/platforms. We pride ourselves in supporting and free and open sourced applications.

Website