Introducing Apk2Gold, an easy and comprehensive Android APK decompiler

[dschuler]

I'm amazed at how many comments there are in line with "OMG this is amazing, now I can decompile thousands of apps blah blah". I write Android apps all day long, but I have yet to find a (legitimate) need to decompile someone else's apps. I suspect all this decompiling, repackaging, and re-signing is designed for people to strip license checks, remove ads, add some other nonsense, and repackage the whole deal for distribution on 3rd-party app stores or websites, without the consent of any of the original developers. I've seen this with my own apps, which are repackaged with different resources, while keeping the code mostly intact. The result is then re-published by someone else. Instead of spending so much energy ripping off other apps, why not create something new? We certainly haven't exhausted what's possible in terms of app breadth and quality.

[daeken]

I wrote the first native Dalvik decompiler, and it wasn't used for any of the things you mention. Decompilers of this sort are tremendously useful tools in security work.

[lxdvs]

As I noted in the Github Readme, this tool will not generate code that you will able to REcompile. My tool does a lot of things, but straight-up repackaging/ripping off other people's apps is exactly what apk2gold is bad at.

[javajosh]

Word. But that said, one totally legit use is learning from other coders. I figure as long as you learn from and don't just rip off stuff, apk decoding could enable an almost front-end-web level of collaborative learning.

[megablast]

I guess someone could use it to check that assets were not being stolen, by the creator of the app.

[nviennot]

Haha... I like this :)

So for you guys that are using this to decompile, say 450,000 android apps in a row, I highly recommend to use:

    ulimit -m $((1024*1024))

These tools sometimes flip out, both dex2jar, and jd-core.

[lxdvs]

would have been impossible without your work :) thanks man

[wting]

I'll definitely check this out, thanks lxdvs! I've been doing some research into Android apps and agree that the jumping through all the hoops with dex2jar, jd-gui (which fails to work for me on Linux), etc manually has been a pain.

Another similar tool you might want to look into is Androguard: https://code.google.com/p/androguard/

[lxdvs]

thats totally sweet. Actually had not seen that, which is surprising considering the research I've been doing for this project. Thanks for the heads up!

[iBotPeaches]

Well once v1.5.2 is out. You can trash that 8mb apktool.jar. I got Proguard in v1.5.2 so the jar is only 2.2mb, on top of a lot of fixes.

[lxdvs]

I'm into it. Considering including apktool as submodule and building alongside.

[testimoney]

Does this decompile to the exact code the developer wrote (without comments etc...) ? Or does this decompile to a usable Java code ?

[lxdvs]

It doesn't even decompile to "useable" code, but it does compile to code that will give you the gist of what what the intention was and what the actual commands are.

Decompilation to java is still a lossy process; if you want a non-lossy process you can check out APKTool which will encode/decode Smali (a Dalvik VM representation/assembly lang). But then you have to learn Smali...

[crowell]

very cool. How does the output compare with something like Virtuous 10 Studio?

[lxdvs]

So I have not actually used V10S (dont have a windows machine for one thing), but my impression is that it was only for smali code. This decompiles to Java, and its for Linux/OSX.

I would say that V10S is for small modification/hax, and java decompilation is for understanding how people did things/what they are doing.

Also becoming a smali god is hard.