Notice: You have been identified as a bot, so no internal UID will be assigned to you. If you are a real person messing with your useragent, you should change it back to something normal.
Topic: Decompiling Android Apps to compare their sources with the public repositories
tokenizerrr started this discussion 12 years ago#33,785
Tools you will need:
- JDK
- dex2jar (https://code.google.com/p/dex2jar/)
- Java decompiler (https://github.com/Storyyeller/Krakatau)
- Android SDK
- A way to compile Android Apps (ant)
- Some directory diff tool
First you need will need to acquire the source code of the application, and the APK of the application. I shall be using ConnectBot as an example in the following steps. The sources can be found https://github.com/connectbot/connectbot and the Play Store entry can be found https://play.google.com/store/apps/details?id=org.connectbot.
Now the first step is acquiring the APK file. There are several methods to do this, the most secure would be to install the application through the Google Play store to your device (do not run it), then pulling it from your device using ADB (see adb shell and adb pull, there may be apps to help with this). The easiest way is to use, for example, http://apps.evozi.com/apk-downloader/.
Once we have the official APK we will need to decompile it.
jar xvf org.connectbot.apk classes.dex
dex2jar classes.dex
krakatau/decompile.py -path /path/to/android/sdk/platforms/android-19/android.jar (or krakatau/decompile.py -skip classes_dex2jar.jar might also work)
While that's running you can build an unsigned APK from the official sources and repeat the same steps.
git clone https://github.com/connectbot/connectbot.git
cd connectbot
edit local.properties with a path to your Android SDK (sdk.dir=/usr/local/android)
ant release (install the project target required if needed with the Android SDK Manager)
jar xvf bin/ConnectBot-release-unsigned.apk classes.dex
dex2jar classes.dex
krakatau/decompile.py -path /path/to/android/sdk/platforms/android-19/android.jar (or krakatau/decompile.py -skip classes_dex2jar.jar might also work)
At this point the two source trees will not be exactly the same, but with a good directory diff tool it should be fairly trivial to read through the code. You may notice quite a lot of differences like "i3 + 128" VS "128 + i3" and other such small changes where the end result is the same but the (de)compiler made a different decision.
Syntax joined in and replied with this 12 years ago, 2 minutes later, 29 minutes after the original post[^][v]#467,036
@467,028 (D)
To increase skills at jailbreaking AND portions of a source code may be useful in a new app one is working on.
Its all about reverse engineering BUT decompiliers are not all created equal AND many bright programers build in protection from people attempting to steal.
Anonymous C replied with this 12 years ago, 16 minutes later, 46 minutes after the original post[^][v]#467,037
DasSheeple joined in and replied with this 12 years ago, 21 minutes later, 1 hour after the original post[^][v]#467,041
@467,036 (Syntax)
Decompiling Java results in pretty readable code, and there's nothing much to do to protect beside write horrible spaghetti code...
Fake anon !ZkUt8arUCU joined in and replied with this 12 years ago, 8 minutes later, 1 hour after the original post[^][v]#467,043
I wish I could understand this but I'm not a huge nerdvirgin so I do not sorry. I'm sure it's cool or whatever.
tokenizerrr (OP) replied with this 12 years ago, 14 minutes later, 1 hour after the original post[^][v]#467,046
@467,041 (DasSheeple)
There's http://proguard.sourceforge.net/ which can be used to obfuscate method names and stuff like that, but not a lot of apps use it and certainly not the ones that are "open source".
Anonymous C replied with this 12 years ago, 7 minutes later, 1 hour after the original post[^][v]#467,047
@previous (tokenizerrr)
Oh wow, I took apart an app one time and the method names were all a, aab, bda, ccb, and shit like that. That makes sense now.
tokenizerrr (OP) replied with this 12 years ago, 2 minutes later, 1 hour after the original post[^][v]#467,051
@previous (C)
A recent project I have been working on has them like \u0023\u003Dq4xruHRn\u0024\u00240zTzKWs6kCl3NrBIQqciQ\u0024ibcS4IxgfrQ80BAUofMX5LOoGz7A5sTId. It is quite annoying.
(Edited 11 seconds later.)
DasSheeple replied with this 12 years ago, 4 minutes later, 1 hour after the original post[^][v]#467,055
@previous (tokenizerrr)
Annoying, but not much harder to reverse engineer...
tokenizerrr (OP) replied with this 12 years ago, 6 minutes later, 1 hour after the original post[^][v]#467,061
@previous (DasSheeple)
Eh, it makes it so I will need to start find/replacing (using your IDE's smart features or whatever) everything in a class file before I can start to read what's happening. With simple abc names I'm fine following along a snippet and seeing what references what. It gets harder when the code looks like http://hastebin.com/qilacolibu. But hey, at least the strings aren't encrypted.
(Edited 5 seconds later.)
DasSheeple replied with this 12 years ago, 10 minutes later, 2 hours after the original post[^][v]#467,068
@previous (tokenizerrr)
Decompile some .exe that has random functions and variables that do shit but actually do nothing, such assembly makes my brain bleed out through my eyes. But oh well, was fun. No time for it these days... decompiling Java no matter how obfuscated, after that, is pretty straight forward.
tokenizerrr (OP) replied with this 12 years ago, 1 minute later, 2 hours after the original post[^][v]#467,069
@previous (DasSheeple)
Oh very true, and that was C# btw but same thing pretty much decompile wise. I also do my fair share of reading asm when reversing plain old binaries. Ugh.
(Edited 7 seconds later.)
Anonymous H joined in and replied with this 12 years ago, 4 hours later, 6 hours after the original post[^][v]#467,102