This section describes miscellaneous features offered by the UI client.
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, 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 PNF Software modules support persistence.
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:
|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.|
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.
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.