This section describes miscellaneous features offered by the UI client.
An interactive quick search widget can be brought up and focused by pressing the keyboard shortcut CTRL+Q.
Interactive search is a convenient way to perform fast searches in text documents generated by all the units of your project (e.g. in disassembly, decompiled sources, resource files, etc.).
Quick search is also the new default for most text document searches (replacing the legacy find/find-next method). The search pop-up can be enabled with the default Edit,Find handler (CTRL+F / COMMAND+F on macOS). Users that prefer to keep the traditional find/find-next mechanism associated with Edit,Find may choose so as well in the Options (see
Search filters can be applied to filter results in table or tree views.
All filters are case-insensitive.
A simple filter string is a regular expression. JEB uses Java-style regular expressions, not PCRE, Boost, or other type of regex. Although the differences are minimal and subtle, complex regular expressions need to be carefully crafted and abide by the Java Pattern standard (refer to the "Comparison to Perl 5" section specifically).
some.thing will select rows containing "someAthing", "Some thing", but not "something".
- A regex filter can be reversed by prepending a tilde character (~).
~some.thing will not select rows containing "someAthing", however "foobar" or "something" would pass the filter.
- To search for literal strings, enclose your filter string with double-quotes.
"some.thing" will select rows containing "some.thing" or "SOME.THING", but not "someXthing".
- A literal filter can also be reversed with tilde.
~"some.thing" will select all rows but those containing "some.thing".
- When filtering on tables with multiple named columns, additional filters can be applied on specific columns. Those filters are literal strings, and the syntax is:
Example: assume a table with the 5 columns Address, Name, Comment, Flags, Value.
- Match rows whose Address cells contain "ABC":
address:"abc" (the filters are case-insensitive)
- Match rows whose Flags cells are empty:
- Match rows whose Flags cells are empty and Address cells contain "ABC":
- A general filter on the row itself can also be added to further filter the remaining results: for instance, to match rows whose Flags cells are empty and Address cells contain "ABC" and rows match the regex "some[d-y]thing", use
flags:"" address:"ABC" some[d-y]thing
Saving and Loading#
A JEB project can be persisted to a file on disk called a JEB Database file. They have a .jdb2 extension.
JDB2 files can be shared among users, within or outside one's organization, and reloaded at a later time. They can grow significantly larger than the original artifact(s), as they contain the analysis results for all - or most of all, see below - units in your project. They are encrypted and compressed.
Each JEB plugin/module is responsible for providing persistence of their result units. All standard modules support persistence.
By default, the artifact files are included in a JDB2, to permit reanalysis if the JDB2 gets corrupted. Users can disable this behavior in the options (see the engines option
JDB2 and PII
JEB avoids storing PII such as usernames and file paths in JDB2. However, since they contain all analysis results, it is partly up to the user to not add sensitive information to the analysis results (e.g. data auto-added by custom plugins and persisted in JDB2 should not contain sensitive information, etc.)
JDB2 and JEB version
Make sure to load a JDB2 with a version of JEB equal or newer than the one that generated that JDB2.
The analysis of large artifacts, yielding potentially hundreds or thousands of units, can translate into very large JDB2.
For such projects, the UI client may offer the user to "quick-save" instead of performing a regular "full-save". Quick saves are almost instantaneous, and generate lean JDB2 files. However, not all data is persisted in QuickSave'd JDB2. At the time of writing, QuickSave is supported for APK/DEX units and Native Code analysis units.
The data items saved in a QuickSave JDB2 are:
- comments (primary inline, primary pre)
- renamed items (packages, classes, methods, fields, etc.)
- identifier names
- project properties
Note: currently, the GUI client auto-suggests Quick-save for APK having a size of 10+ Mb.
See the back-end property
.project.PersistenceStrategy to customize whether quick-save should be always used, never used, or used on-demand.
Notifications are generated by modules when they encounter areas of interest during analysis of their input data. The menu entry File, Notifications allows the user to view notifications for all units produced in the currently opened project.
In the example below, the Android DEX plugin has generated a notification indicating that the Android app contained multiple DEX files, and that those were merged successfully:
Notifications are generated at the discretion of the analysis modules. They can be classified in one of nine levels:
|A generic type to signify an area of interest within a unit.
|Input corruption has been detected.
|The unit has detected features that have been deprecated.
|A generic type to signify an error in the unit.
|A generic type similar to AREA_OF_INTEREST.
|The intent is malicious.
|This type indicates usage of a feature not recommended by guidelines due to its potential dangerousness.
|Some input cannot be parsed because of a limitation within the unit itself.
|A generic type to signify a warning in the unit.
See this reference page for additional details on notification types.
Users may export analyzed data via one the sub-commands in the File, Export menu entries:
- Export some or all decompilations.
- Export all binary units to multiple files on disk
- Export the active fragment to raw text or html (with coloration similar to JEB's text views). Make sure to focus a code view or a decompiled code view before attempting to run this command.
This command is accessible via the File, Export menu entry.
To export only a subset of code, a filter may be provided. The filter is a regular expression on the internal address scheme used for the code being analyzed. For example, for Android code: to export all classes in the package and sub-packages com.abc.**, the filter would be
The properties of a project can be examined by right-clicking the project node in the Project Explorer view, via the File menu, or by using the Alt+Enter key combo when the project node is selected.
- The name is customizable. The default name is always derived from the primary artifact, with a JDB2 extension. This extension stands for "JEB Database Version 2", and represent a serialized version of your project which users can save and load on their JEB version 2 software.
- The creation and modification timestamps are read-only.
- The user-notes are writable and saved with the JDB2.
Similarly to Project properties, the properties of an artifact can be examined by right-clicking the artifact node in the Project Explorer view, via the File menu, or by using the Alt+Enter key combo when the artifact node is selected.
Similar to Project and Artifact properties, the properties of a unit can be examined by right-clicking the corresponding unit node in the Project Explorer view, via the File menu, or by using the Alt+Enter key combo when the unit node is selected.
- The unit name is customizable, however, we recommend users to not change unit names.
- The unit type corresponds to the module type that created the unit (in this example, 'apk')
- The creation timestamp is the time at which the unit was created from its parent artifact or unit
- The status field indicates potential problems: N/A means the unit was processed properly, and its contents can be examined; other string messages can be reported by modules to indicate processing error, or simply, lack of processing in the case of lazy processing.
- If the unit is backed by bytes, on a file or in memory, the size is also specified
The full list of input processor plugins (whose term was simplified to parsers in the UI) loaded within your JEB instance context can be seen by running the File, Plugins, Parsers command.
Parsers can be selectively disabled if needed. For example, if you would like JEB to not process Zip files as such (i.e., treat them as plain binary files), you may disable the zip parser.
Commonly, most projects will contain a single artifact file, such as a binary executable or an application file. However, you may add as many artifacts as you want to a project
Select the menu entry File, Add an Artifact to add an artifact to an existing project. The newly added artifact will be processed, and added to the current project tree:
This advanced feature is available by right-clicking a unit in the Project Explorer view, and selecting Parse at...:
Reparsing allows users to (re)parse a unit or parts of a unit by specifying explicitly what the input data should be parsed as.
For instance, you may have input data identified as XML data, and initially parsed as such - therefore yielding an XML unit. However, you may discover that this XML data contains bytes that would correspond to a Zip file (eg, starting with
PK...). By reparsing the XML data at the given Zip header offset using the Zip module, you ask JEB to process that data as Zip and create a zip unit from it:
Reparsing can be helpful when dealing with complicated, obfuscated, or multi-layered files.
The Assistant can be used to infer names for decompiled methods and method parameters. The Assistant is available in decompiled text fragments in the GUI via a button located on the top-right hand corner of the fragment.
More information about how to use the Assistant can be found on this blog post.