it is not possible to get the original c++ code from compiled executable because c++ gets compiled to native machine code. imho the best way to reverse native executables is by disassembling. Check OllyDbg ([http://ollydbg.de/](<http://ollydbg.de/>)) or IDA / IDA Free ([https://w
> i am not using linux, can i live debugging on my device? like using gdb? I'm using IDA and gdbserver for remote debugging. IDA v5.0 is free https://www.hex-rays.com/products/ida/support/download_freeware.shtml and a very good debugging tool. gdbserver gets shipped with the ndk.
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
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 start
> there is just 'medusah' file on decompiled folder. > > file :[cantdecompile.zip](<http://www58.zippyshare.com/v/yKdPwdJk/file.html>) 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
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 t
> Why I get like android:id="@id/textView1" in xlm and findviewbyid (3523423) in java in Bytecodeviewer? When developing an android app the buildsystem generates a class called *R.java* which holds all references to stuff defined in resource files (like xml files) in static membe
