04-25-2016, 04:41 PM
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.
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.
libpp.so has to be linked to some other libs but none of them are present in the libs folder.
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
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.
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.