This section describes miscellaneous features offered by the UI client.

Quick Search#

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 .ui.text.PreferLegacyFindDialog).

Search Filters#

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).

Example: some.thing will select rows containing "someAthing", "Some thing", but not "something".

• A regex filter can be reversed by prepending a tilde character (~).

Example: ~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.

Example: "some.thing" will select rows containing "some.thing" or "SOME.THING", but not "someXthing".

• A literal filter can also be reversed with tilde.

Example: ~"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: column_name:"filter_string"

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: flags:""
- Match rows whose Flags cells are empty and Address cells contain "ABC": flags:"" address:"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 PersistArtifactFiles).

Quick Save#

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)
• labels
• 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#

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:

Type	Description
AREA_OF_INTEREST	A generic type to signify an area of interest within a unit.
CORRUPTION	Input corruption has been detected.
DEPRECATED_FEATURE	The unit has detected features that have been deprecated.
ERROR	A generic type to signify an error in the unit.
INFO	A generic type similar to AREA_OF_INTEREST.
MALICIOUS	The intent is malicious.
POTENTIALLY_HARMFUL	This type indicates usage of a feature not recommended by guidelines due to its potential dangerousness.
UNSUPPORTED_FEATURE	Some input cannot be parsed because of a limitation within the unit itself.
WARNING	A generic type to signify a warning in the unit.

Exporting Output#

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.

Export filters#

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 Lcom/abc/.*

Project Properties#

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.

Artifact Properties#

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.

Unit Properties#

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

Listing Parsers#

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.

Adding Artifacts#

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:

Reparsing Data#

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.

JEB Assistant#

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.