Do you have a brochure/press release/product sheet for JEB?
Yes, we do. The brochure is available in English, French, German, Japanase, Korean, Chinese, and Russian.
How about internationalization support?
JEB is available in English as well as Chinese, French, German, Italian, Japanese, Korean, Portuguese, Russian, Spanish, and Turkish.
Does JEB use its own decompiler or are you wrapping around existing ones?
JEB uses our own decompiler. Moreover, it directly decompiles Dalvik bytecode. (No DEX-to-JAR conversion is needed.)
Do I need a DEX-to-JAR converter to open a file in JEB?
No. JEB decompiles Dalvik bytecode. It takes a DEX or APK file as input.
What's the difference between Dalvik bytecode and Java bytecode and how does that impact the decompilation process?
Many Java decompilers out there work on Java bytecode, not Dalvik (Android) bytecode. Therefore, in order to decompile Android apps, those decompilers require their user to perform a conversion of the Dalvik DEX file to Java class files. This conversion process is often unreliable, especially if the Dalvik bytecode has been obfuscated. On top of that, metadata is lost during the conversion process.
How does JEB compare to other Java decompilers?
(First of all, remember that JEB is not a traditional Java decompiler. It decompiles from Dalvik bytecode to Java source.)
It seems a great number of reverse-engineers and analysts use the "dex2jar + JD|JAD" combo. JEB provides a much cleaner, solid output than these tools do. JEB also handles obfuscation at the bytecode level, such as spaghetti code or junk insertion. Lastly, JEB is not just a decompiler: it is a fully interactive analyzer.
If you want to know more about how a pre-alpha of JEB performs vs the tools cited above, see the Comparison page.
What can JEB do that free Java decompilers cannot do?
A lot. As explained above, free Java decompilers are not reliable when it comes to analyzing Android apps: they do not provide reliable output, do not handle obfuscation well or at all, and they're not flexible. In a word, they're not designed for security engineers.
JEB fills all these gaps: our built-in Dalvik disassembler and decompiler offers a reliable output, you can accurately switch between the disassembly and source views, and it is highly interactive and flexible. One example of that is the renaming feature of JEB: classes, methods, fields, etc. can be renamed, and changes are propagated across the entire DEX file, both in the assembly and decompiled views. Our Youtube clip explicitly shows that.
Can I automatically recompile decompiled Java code?
Generally, no. The output Java code would need to be manually or semi-automatically cleansed first. The main reason behind it is that 'goto' statements sometimes have to be introduced to maintain semantic coherence - at the cost of syntactic inaccuracies.
Can JEB also decompile Java bytecode?
No. JEB decompiles Dalvik bytecode, the bytecode used by Android apps.
Can I decompile ODEX (Optimized DEX) files?
Yes, but not out of the box. First, de-odex the file. Then, open the generated DEX file with JEB.
Deodexing can be achieving using the -x option of baksmali,
for instance. Update: JEB has a module to handle ODEX files directly.
Can I automate tasks using JEB?
Yes, JEB is controllable using a Java or Python API. This allows users to automate some parts of the reverse engineering process.
JEB can also be run in "console-only" mode: this mode is leaner and faster than the default UI mode, and better suited for bulk analysis.