[youbrey]

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.

sir, i really want to be your student.
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.