喜欢jadx的人会常常吐槽JEB反编译器：卖的这么贵，反编译效果还不怎么样。这里我想说的是，JEB毕竟是纯dalvik反编译器，从字节码解析到高级代码生成的整个过程都得从头来过，反编译差点也可以理解（ 对于写一款全新的反编译的本人来说深有感触，经典算法和理论也常常有不奏效的时候，因此往往需要改进、优化和扩展，甚至需要提出极端情况下的解决方案，尤其是对抗结构化混淆时）。应该说 JEB 主要槽点是昂贵的费用，其采用的结构化分析技术的确属于比较落后的，但是JEB的功能比jadx更为丰富，更有利于做逆向分析。
(Sorry, my Mandarin is not good enough for me to write an answer in chinese, so I'll type it in English. I hope you don't mind!)
I wanted to give my very different opinion about decompilation results. It seems the author did use an older version of JEB, because I have different results, and in my opinion, they are either as good as JADX or GDA.
Our company pays for JEB Pro, we always use the latest beta version, currently a 3.6 Beta July 2019.
- 1) JEB has discarded x*5 on purpose, since that variable is deemed useless after assignment. (In fact, JEB's deobfuscation capabilities are one of its great strength, as I'll show later)
- 2) OK
- 3) OK
- 4) OK
5) Here, we do have goto, but JEB provides semantically correct results, where the other two tools, eager to avoid gotos, generate wrong results! Something much worse when reversing is done professionally, with various clients expecting accurate information about the whats and hows of a piece of malware.
- (De)Obfuscation -
Now, let's go one step further and perform simple obfuscation of method test1 (Attaching the dex file)
jadx crashes; gda: not tested, unfortunately.
JEB cleans up and decompiles the code almost perfectly: see below (it looks like the obfuscator has inserted a large amount of trampoline and junk code)
It is unfortunate that the original poster seemed to be biased against JEB. I talked to lots of people at conferences and events and it seems almost all companies and research labs doing serious business on the Android security side, at least, use JEB.
All that being said, and in my experience, JEB outperforms all other static analysis tools (_except_ IDA when it comes to arm code analysis) in almost all domains: coverage (full APK support, including obfuscated resources, but also native processors and non-native processors), decompilation, debugging. Not to mention it supports refactioring and cross-references with virtuals and overrides, and has a full API to automate pretty much everything. IDA is really the only real competitor to JEB when it comes to x86 and arm, and HexRays decompiler in that regards still outperform JEB generally. We have examined complicated x86 malware where JEB was doing a better job at deobfuscating the code.
Sorry again for writing in English, I hope that's okay. I'm sometimes browsing pediy because it contains interesting articles, but I rarely post, my Chinese is not good enough for lengthy messages.
(Disclaimer: we use JEB everyday at our for-profit security company, and so we pay for it and to have the latest version at all times. We do Android malware reversing, Windows malware reversing, Ethereum contracts reversing. We love the tool and the support from the PNF Software guys, so obviously our opinion may be a little bit skewed!)
对于test1，你的辩解完全不对："JEB has discarded x*5 on purpose, since that variable is deemed useless after assignment",你认为是因为变量a(v1)分配值(a=Math.getExponent(88))之后后被jeb视为无效，这是不正确的，a(v1)的值是由method的返回值决定，jeb不会去做预判，jeb的问题仍然是结构化算法的问题，所以导致了(a=a*5)语句丢失，实际上是整个基本块的丢失。一个简单的测试就可以证明，我把a的值初始化为能够覆盖>100这个路径，并且给该基本块多加几条语句，jeb仍然将该基本块弄丢失了。test2中也一样，会出现丢失块的情况。
int a = 200;
int y = 0;
Hello. The variable `a` is simply discarded in the first case because the decompiler has determined that it is no longer "in use" (basic data flow analysis here). If you were to make it used, for example by returning it, then it would necessarily be kept.
See the example below, I used JEB 3.6, same as my last message.