Views
To visualize a unit, double-click on its node in the Project Explorer panel, or right-click and select Open, View.
Views#
The view for a unit is a placeholder for one or more fragments, representing unit documents. For example, a Dex unit (which is the analysis result of an Android Dex file by the Dex plugin) is rendered by multiple fragments, including:
- A Description static text view
- A Hex Dump view
- An Assembly interactive text view (as well as its associated Graph view)
- A Strings interactive table view
- A Code Hierarchy interactive tree view
- etc.
Addressing#
Some types of documents provide addressing support. Addressing support is a necessary requirement to enable interactive actions such as navigation and cross-referencing.
View auto-replacement#
By default, if a unit U1 of type T has a view opened, requesting to view another unit U2 of the same type T will swap the view of U1 by U2's.
Example: a decompiled piece of code is being viewed; another decompilation (e.g. another method) is being opened; the previous view will be replaced. This is the default behavior to avoid rapidly cluttering the workspace with tens or hundreds of views. However, if this does not suit your workflow habits, 'view replacement' can be disabled in the Options (.ui.DoNotReplaceViews) or via the Navigation menu.
Documents#
The following sub-sections provide examples of common fragments and views encountered when analyzing binary files:
Description Documents#
The Description document is a standard buffer of text provided by all units. It contains a small body of text presenting various characteristics of the unit, including whether or not it contains children units.
Hex Dump Documents#
The Hex Dump document is a hexadecimal representation of the input artifact. This document can efficiently represent artifacts of a size up to 2^63 bytes.
Helper widgets are provided for easy visualization of unpacked byte sequences.
Text Documents#
Units commonly provide interactive text documents to represent their contents. Text documents are addressable. Those views can efficiently represent arbitrarily large bodies of text - up to billions of lines if necessary.
The navigation bar, vertically positioned on the right-hand side of the document by default, allows navigating the document.
Examples include: assembly documents, xml documents, decompiled code documents, etc.
Navigation bar#
By default, the navigation bar of a text document is a vertical bar located on the right side. It can be positioned horizontally as well, refer to this Client setting.
- The green line represents the location of your viewport within the document, i.e., the first line on screen.
- The yellow arrow represents the caret position. In the example above, the caret is located well outside the viewport.
- The orange line is mostly of use to plugin developers: it indicates which portion of the document is currently loaded in memory.
The bar can be zoomed in and out using mouse scrolling. Hovering over an area of the bar will roughly indicate what text is located at that position: click to navigate there.
The bar above was zoomed in. The vertical line in red indicates what portion of the document is now represented by the entire bar. It allows for finer fast navigation in long disassembly listings.
Finally, and most importantly, the bar can receive visual contributions from units and documents. It is for example used by code library recognition plugins to highlight parts of the document which contain library code. Below, an example of the bar (set horizontally for clarity) when analyzing a ShadowHammer malware sample with Visual Studio 2010 signatures on:
In this case, the cyan color represents library code.
Table Documents#
Units may provide table documents to represent their contents. Table documents are addressable.
Tree Documents#
Units may provide tree documents to represent their contents. Tree documents are addressable.
Interactive Trees#
Code hierarchies are interactive trees that allow navigation to code items, such as methods or routines.
Static Table Trees#
Parsed certificate can be represented as static table tree documents. For example, the APK module produces such documents.
Another example of a table tree (for which each node is a row within a table) is the global structure of a PDF document produced by the PDF plugin.
Mime-typed Documents#
A unit may issue mime-typed documents. It is up to front-end clients to implement rendering engines for some of those types. For example, the official UI client render various image types.
Custom Documents#
Specialized units, such as debugger or native code units, offer access to specific data that does not fit in standard document categories. It is up to the front-end to render whatever is deemed necessary.
For example, the UI client produces many specialized views to represent debugger units (such as breakpoints, threads, locals, memory, ..).
Those views are described in sections dealing with specialized units, e.g. debuggers or native disassemblers.