0

I'm working on reverse engineering / decompiling an APK file - I was able to use:

http://www.decompileandroid.com/

I'm sure APK tool is a better option (I'd love to hear the reasons why though) but in this instance it worked - sorta.

My problem - and the root of my question/post: is I ended up with over 4000 eclipse errors when I import the source (thankfully they seem to be just a small handful of similar/related errors repeated many many times).

That being said - is there a better method of going about this in order to avoid these errors? (shown below)

Eclipse Errors:

https://docs.google.com/document/d/1gwbZuJ8duQ37JRGeTdqIrv0o_DBNL_xWRxrG9Xxxwy4/edit?usp=sharing

ClawWorm
  • 11
  • 5
  • This question has been answered many times before. The short answer is no. Only very small simple projects seem to decompile without errors, and even that requires a bit of luck. – Stephan Branczyk Jan 02 '14 at 01:14
  • What is the best practice to begin to resolve them? – ClawWorm Jan 06 '14 at 23:29
  • The best practice would be to target a small app that's really old and that predates the standard practice of obfuscating the code (but even that, that doesn't give you any guarantee it will work). At best, reverse-engineering an app could tell you how the assets are organized, how a particular layout is nested, where an encryption key/password is stored, or what preference to mess with in a rooted phone if you want to get a higher score in a game. Right now, those reverse-engineering tools just aren't good enough to do much more than that. So it's best to just keep an eye on them. – Stephan Branczyk Jan 13 '14 at 03:48

1 Answers1

0

I do not know of any Java decompiler that will reliably produce output that can be "round-tripped" (decompiled, then recompiled). There are a few in active development, my own included, for which you could submit bug reports. In the case of Procyon, type inference has become increasingly broken over time, particularly where generics are concerned. Then there are a host of other problems that primarily affect classes converted from Android format.

JARs created by tools like dex2jar tend to be much harder to process because they produce tricky exception handler tables, oddly ordered blocks, local variable slot sharing, etc. I would recommend trying a few different combinations of tools: straight Android decompilers as well as different dex-to-jar rewriters paired with various Java decompilers. You may find that one combination of tools consistently yields better results than others.

That said, I will reiterate my usual advice: never trust the output from a decompiler. Do not assume it is correct, even if it compiles cleanly.

Mike Strobel
  • 25,075
  • 57
  • 69