(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.

(04-13-2016, 04:55 AM)youbrey Wrote:  there is just 'medusah' file on decompiled folder.

file :cantdecompile.zip

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

(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

--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!

(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

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.