Android Security and The Tools I Use – JEB

There are quite a few tools readily known to the Android reversing community. The primary one is most likely smali/baksmali. It’s an open source tool which will decompile/compile an android dex format which is used by dalvik the native Android VM, into a format known as smali, which is very similar to an assembly language. A lot of people even like dex2jar, which further enhances the experience and takes a broken down apk, and pulls out the compiled dex classes. With dex2jar you can further that and attempt to get some readable jar files. If you wanted to make it even simpler you continue with that jar and use something like JD-GUI to read those jars back into native java code and be off running. For the lazy, there’s also the apktool which does most of the above for you in a simple one-stop-shop.

These are all great tools, but what else is out there? That’s what I’ll be covering in the next few articles. Today I’d like to point your attention to JEB (http://www.android-decompiler.com/). I discovered this back in February when it made its first public release. At the time, I was knee deep in doing Android Application Security Assessments as part of our IPA process. I was still primarily using the tools mentioned above, so it was nice not only to find something different (it doesn’t use the open source smali as the decompiler), and it’s a nice all-in-one solution for exploring the code, as well as analyzing it.

Some of the main features include the following, which I’ll go into more depth and why they add more benefit to this tool. The first is the Dalvik decompiler. From day one, I was immediately able to notice a difference between it and the smali decompiler. It uses some of the built-in properties and metadata of the DEX file and uses that to help interpret some of the code. I’ve also seen this change over the past couple months as they’ve improved it, or made other changes. It’s been optimized quite a few times. For me the code decompiled for JEB was broken down further and easier to read, even as a java programmer I’d prefer code to be in the simplest form when trying to analyze it, especially when dealing with unknown classes or libraries, not to mention any obfuscated code.

JEB has a few built in features which make analysis great as well allowing you to examine cross-references, rename methods, fields, classes and packages, navigate between code and data, add comments anywhere and even a notes tab. Putting this into practice is quite easy as well. I’d give a few examples but JEB’s video does a great job itself.

JEB not only gives you assembly and decompiled java views, it breaks down the entire apk, giving you access to all the assets, manifests, string lists and constants as well. Again, the other tools are capable of this, but you’re simply left with the basic file directories, in JEB you get a tab for each item listed out.

JEB also listens to its users with frequent updates, and added features or changes coming directly from the community. The JEB team listens and is active in development.

I think the only things I’ve noticed that I don’t like about JEB are mostly personal and nit-picky. First is because it’s much like an IDE in its layout, there’s no easy way to change the styling of the code views. Yes you can change it, within the options, but you have to go through every item individually and change them separately (comments, keyword, string, etc.). I did this once, but then accidentally overwrote those settings when I did an update. Which brings me to the second item; the update system requires you to download the latest version, which is archived with a password specific to you, you then unpack it, and do what you want from there. JEB does a check on load to tell you if there’s an update or not, but you still have to update it manually. I’ve spoken to the developers and this is something they’re working on but it’s not a priority. Lastly the decompiler omits any try/catch statements. It will leave a comment saying where they were, but it doesn’t actually leave any information that might have been needed. Specifically if an application spits out an error message in a catch block, that string isn’t there. Sometimes that string is useful for pinpointing certain items.

Otherwise JEB has been a great additional to my toolset; it’s one of the first things I go to if I need quick analysis of an APK. I’m just scratching the surface on this introduction to JEB, and will be doing a follow-up comparing it more deeply with some of its competitors and other tools I’ll be listing in these articles as well. Stay tuned!