JEB is an interactive Android app disassembler and decompiler. It can handle APK or DEX files. Analysis can be saved to JDB files. JEB comes in two flavors: JEB Full (GUI + Automation) and JEB Automation (Automation only). Most of this manual applies to the UI aspects of JEB Full. The sections Scripts & Automation and beyond apply to both JEB Full and JEB Automation.

$ jeb --help
JEB full debug v1.3.201309040 (c) PNF Software, 2013
Usage:
  JEB [options] [inputpath] [-- scriptarg1 [scriptarg2 [...]]]
Arguments:
  inputpath                DEX/APK/JDB file
  scriptargX               script arguments
Options:
  --help                   Print this message and exit
  --license                Display license information
  --automation             Automation mode (default: UI, unless the license is automation-only)
  --script=<scriptpath>    Execute a script at startup (default: no input script)
  --config=<configpath>    Set alternate config file (default: jeb-config.txt in JEB directory)

Workspace

The workspace of JEB UI is divided into four areas, as seen on the picture below:

1 - The menu and toolbar, at the top.
2 - The console window and status bar, at the bottom.
3 - The class hierarchy browser.
4 - A tab folder consisting of many important subviews.



Views

Within a workspace, views representing portions of the analyzed file are contained within the tab folder (4). The views can be closed and re-opened via the Window menu. Here's a list of common views:

The Assembly view. This view contains the disassembly code of all classes contained in the DEX file. This view is interactive. The assembly can be exact Smali or simplified Dalvik assembly for improved clarity.
This view also contains the navigation bar. More information on the navigation bar and how to use it efficiently can be found on our blog. Related post: JEB 1.3: How to Sign and Match Third-Party Library Code.
The Decompiled view. This view contains the decompiled bytecode of a class, in Java. Switching back and forth with the assembly view can be done by pressing the Tab key, while the caret is positioned on a class.
The Strings view. This view contains the list of strings present in the DEX file. Double-clicking on a string switches back to the assembly view and positions the caret on the first occurence where the string is being used.
The Constants view. This view contains the list of numerical constants present in the DEX file. Double-clicking on a constant switches back to the assembly view and positions the caret on the first occurence where the constant is being used.
The Manifest view. This view represents the decompressed manifest of the application.
The Resources view. This tree view allows the user to explore the application's decompressed resources.
The Assets view. This view is very similar to the Resources view, and is used to browse an assets files.
The Certificates view. This view offers a human-readable representation of the certificates used to sign the APK.
The External Classes/Methods/Fields view. These views list the external (outside the DEX file) classes, methods and fields referenced and used within the DEX file.
The Notes view. This view is a placeholder for analysis notes.

The class hierarchy view (3) contains the entire list of classes present in the DEX file. Classes are organized by package.
Clicking or double-clicking on a class name will bring up the Assembly view and position the caret on the chosen class.
For the sake of clarity, the user may decide to temporarliy mask inner classes by ticking the appropriate checkbox at the bottom of tree. (Note: classes can be masqueraded as inner classes; keep that in mind when you analyze a file.)
The currently on-caret class is highlighted in red.


Code views

The assembly and decompiled code views are the most crucial views when it comes to analyzing an app. These code views are interactive and work hand-in-hand. (The XML views are also interactive, but are not considered code views.)

These views contain interactive items: they can be classes, fields, methods, opcodes, instructions, comments, etc.

The user can take actions on these views via the Action menu, toolbar or keyboard shortcuts. Mastering the (fairly small set of) keyboard shortcuts is essential if you want to work efficiently within JEB.

For instance, when the user sets the focus on either one of these views, they can:

Rename items (N): classs, fields and methods can be renamed. Changes are reflected in the other view. In the decompiled view, variables and parameters can also be renamed. External items (those not defined in the DEX file) cannot be renamed.
Insert comments (C): comments may be specific to a class, a field, a method or a specific method instruction. Comments can be text, audio or both. Audio comments are denoted by a bang character (!) prepended to the optional text comment, as can be seen on the example screenhsot.
Examine visual cross references (X): most interactive items can be cross-referenced to see where they are used. The cross-references are listed by order of appearance in the code. Double-click a cross-reference to jump to its location.
Examine real cross references (Ctrl+X or Cmd+X): these references are useful only when in the decompiled view. Since the view is limited to the currently analyzed class, visual cross-references are limited to that class. The real (code) cross-references come into play: although not as exhaustive as the visual xrefs in the assembly view, they show a list of global references throughout the file.
Navigate (Enter): a user can 'follow' items. In in this context, it means jumping to the definition of that item. For instance, following a method call to foo() means jumping to the location where foo() is defined.
More: refer to the Action menu.
Even more: a user can add their own "custom actions" to the Action menu.

Within the assembly view, the user can decide to decompile a class by pressing Tab. The current view will switch to the decompiled view for the target class, and the caret will be positioned on the closest high-level Java item that matches the source bytecode instruction. Reciprocally, when positioning the caret on a high-level Java item and switching back to the assembly view, JEB tries to position the caret on the low-level bytecode instruction that most closely matches the source Java statement.

The Assembly view contains the navigation bar. As mentioned above, more information on the navigation bar and how to use it efficiently can be found on JEB's blog. Refer to the following post: JEB 1.3: How to Sign and Match Third-Party Library Code.

Custom actions

The Action menu can be customized by a user. Custom actions can be inserted in the "Custom Actions" sub-menu. Custom actions (or plugins) are backed by JEB scripts. Simply put, a plugin is a script that:

is dropped in the "plugins" directory. The default plugins directory is %JEBDIR%/plugins. That directory can be configured via the Options menu.
has an optional plugin line information, that is, a single-line comment starting with '?'. Example:
#? name=My Sample Plugin, shortcut=Ctrl+Shift+T, help=This Python script is a JEB plugin
The shortcut modifiers allowed are Ctrl, Shift, Alt, and Command. The keys allowed are all alphanumeric characters, as well as the F1 to F12 functions keys

Scripting

Scripts can be used to automate tasks, such as looking for methods, renaming classes, decompiling classes, etc. Refer to the API documentation. (Although the documentation pages look like Java docfiles, the currently supported language is Python.)

Scripts can be called within the UI (via "File/Run Script") or from the command-line (with the --script= flag)

Sample scripts can be found in the Resources area.

Style options

Style options include font selection (which affect various views) and color styles.

The default font is set to a standard fixed font, usually Courier New. This may vary from system to system. Recent versions of Courier New have a good amount of Unicode glyphs. However, yours may not have the CJK glyphs, which are essential when dealing with asian locale apps. Should that happen, other fonts may be used, such as FangSong on Windows, or Sans on Ubuntu. These fonts offer a good BMP support, including CJK, Russian, Thai and Arabic.

Note: on MacOS systems, it seems the default fixed font presents a rendering issue within the class hierarchy tree: the underscore is rendered as a space. One solution to fix this issue is to use a different fixed font, for instance Consolas or Monaco.

The "Style manager" button allows a user to customize colors and aspects of various interactive items. This affects the code views as well as the XML views used to render the manifest and other XML resources. Foreground and background colors as well as font attributes for interactive items can be customized.

[/b]

[b] Only for V.I.P

Warning! You are not allowed to view this text.