04-27-2016, 06:48 PM
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
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