updates readme and version #

This commit is contained in:
gaasedelen
2020-04-23 05:41:53 -04:00
parent 4661517cb3
commit 69a595a875
6 changed files with 144 additions and 69 deletions
+102 -68
View File
@@ -5,7 +5,7 @@
## Overview
Lighthouse is a code coverage plugin for [IDA Pro](https://www.hex-rays.com/products/ida/), and [Binary Ninja](https://binary.ninja/). The plugin makes use of interactive disassemblers to map, explore, and visualize externally collected code coverage data when symbols or source may not be available for a given binary.
Lighthouse is a powerful code coverage plugin for [IDA Pro](https://www.hex-rays.com/products/ida/) and [Binary Ninja](https://binary.ninja/). As an extension of the leading disassemblers, this plugin enables one to interactively explore code coverage data in new and innovative ways when symbols or source may not be available for a given binary.
This plugin is labeled only as a prototype & code resource for the community.
@@ -13,6 +13,7 @@ Special thanks to [@0vercl0k](https://twitter.com/0vercl0k) for the inspiration.
## Releases
* v0.9 -- Python 3 support, custom coverage formats, coverage cross-refs, theming subsystem, much more.
* v0.8 -- Binary Ninja support, HTML coverage reports, consistent styling, many tweaks, bugfixes.
* v0.7 -- Frida, C++ demangling, context menu, function prefixing, tweaks, bugfixes.
* v0.6 -- Intel pintool, cyclomatic complexity, batch load, bugfixes.
@@ -24,109 +25,54 @@ Special thanks to [@0vercl0k](https://twitter.com/0vercl0k) for the inspiration.
# Installation
Lighthouse is a cross-platform (Windows, macOS, Linux) python plugin. It takes zero third party dependencies, making the code both portable and easy to install.
Lighthouse is a cross-platform (Windows, macOS, Linux) Python 2/3 plugin. It takes zero third party dependencies, making the code both portable and easy to install.
1. From your disassembler's python console, run the following command to find its plugin directory:
- **IDA Pro**: `os.path.join(idaapi.get_user_idadir(), "plugins")`
- **Binary Ninja**: `binaryninja.user_plugin_path()`
2. Copy the contents of this repository's `/plugin/` folder to the listed directory.
This project is primarily developed and tested with IDA for Windows, so that is where we expect the best experience. Support for Binary Ninja and other disassemblers is still considered exprimental at this time.
3. Restart your disassembler.
# Usage
Lighthouse loads automatically when a database is opened, installing a handful of menu entries into the disassembler.
Once properly installed, there will be a few new menu entries available in the disassembler. These are the entry points for a user to load coverage data and start using Lighthouse.
<p align="center">
<img alt="Lighthouse Menu Entries" src="screenshots/open.gif"/>
</p>
These are the entry points for a user to load and view coverage data. To generate coverage data that can be loaded into Lighthouse, please look at the [README](https://github.com/gaasedelen/lighthouse/tree/develop/coverage) in the coverage directory of this repository.
Lighthouse is able to load a few different 'flavors' of coverage data. To generate coverage data that can be loaded into Lighthouse, please look at the [README](https://github.com/gaasedelen/lighthouse/tree/master/coverage) in the coverage directory of this repository.
## Coverage Painting
Lighthouse 'paints' the active coverage data across the three major IDA views as applicable. Specifically, the Disassembly, Graph, and Pseudocode views.
While Lighthouse is in use, it will 'paint' the active coverage data across all of the code viewers available in the disassembler. Specifically, this will apply to your linear disassembly, graph, and decompiler windows.
<p align="center">
<img alt="Lighthouse Coverage Painting" src="screenshots/painting.png"/>
</p>
In Binary Ninja, only the Disassembly and Graph views are supported.
In Binary Ninja, only the linear disassembly, graph, and IL views are supported. Support for painting decompiler output in Binary Ninja will be added to Lighthouse in the *near future* as the feature stabilizes.
## Coverage Overview
# Coverage Overview
The Coverage Overview is a dockable widget that provides a function level view of the active coverage data for the database.
The Coverage Overview is a dockable widget that will open up once coverage has been loaded into Lighthouse.
<p align="center">
<img alt="Lighthouse Coverage Overview" src="screenshots/overview.png"/>
</p>
This table can be sorted by column, and entries can be double clicked to jump to their corresponding disassembly.
This interactive widget provides a function level view of the loaded coverage data. It also houses a number of tools to manage loaded data and drive more advanced forms of coverage analysis.
## Context Menu
Right clicking the table in the Coverage Overview will produce a context menu with a few basic amenities.
Right clicking the table in the Coverage Overview will produce a context menu with a few basic amenities to extract information from the table, or manipulate the database as part of your reverse engineering process.
<p align="center">
<img alt="Lighthouse Context Menu" src="screenshots/context_menu.gif"/>
</p>
These actions can be used to quickly manipulate or interact with entries in the table.
## Coverage Composition
Building relationships between multiple sets of coverage data often distills deeper meaning than their individual parts. The shell at the bottom of the [Coverage Overview](#coverage-overview) provides an interactive means of constructing these relationships.
<p align="center">
<img alt="Lighthouse Coverage Composition" src="screenshots/shell.gif"/>
</p>
Pressing `enter` on the shell will evaluate and save a user constructed composition.
## Composition Syntax
Coverage composition, or _Composing_ as demonstrated above is achieved through a simple expression grammar and 'shorthand' coverage symbols (A to Z) on the composing shell.
### Grammar Tokens
* Logical Operators: `|, &, ^, -`
* Coverage Symbol: `A, B, C, ..., Z`
* Parenthesis: `(...)`
### Example Compositions
* `A & B`
* `(A & B) | C`
* `(C & (A - B)) | (F,H & Q)`
The evaluation of the composition may occur right to left, parenthesis are suggested for potentially ambiguous expressions.
## Hot Shell
Additionally, there is a 'Hot Shell' mode that asynchronously evaluates and caches user compositions in real-time.
<p align="center">
<img alt="Lighthouse Hot Shell" src="screenshots/hot_shell.gif"/>
</p>
The hot shell serves as a natural gateway into the unguided exploration of composed relationships.
## Search
Using the shell, one can search and filter the functions listed in the coverage table by prefixing their query with `/`.
<p align="center">
<img alt="Lighthouse Search" src="screenshots/search.gif"/>
</p>
The head of the shell will show an updated coverage % computed only from the remaining functions. This is useful when analyzing coverage for specific function families.
## Jump
Entering an address or function name into the shell can be used to jump to corresponding function entries in the table.
<p align="center">
<img alt="Lighthouse Jump" src="screenshots/jump.gif"/>
</p>
If there are any other actions that you think might be useful to add to this context menu, please file an issue and they will be considered for a future release of Lighthouse.
## Coverage ComboBox
@@ -145,6 +91,94 @@ A sample report can be seen [here](https://rawgit.com/gaasedelen/lighthouse/mast
<img alt="Lighthouse HTML Report" src="screenshots/html_report.gif"/>
</p>
# Coverage Shell
At the bottom of the coverage overview window is the coverage shell. This shell can be used to perform logic-based operations that combine or manipulate the loaded coverage sets.
<p align="center">
<img alt="Lighthouse Coverage Composition" src="screenshots/shell.gif"/>
</p>
This feature is extremely useful in exploring the relationships of program execution across multiple runs. In other words, the shell can be used to 'diff' execution between coverage sets and extract a deeper meaning that is otherwise obscured within the noise of their individual parts.
## Composition Syntax
Coverage composition, or _Composing_ as demonstrated above is achieved through a simple expression grammar and 'shorthand' coverage symbols (A to Z) on the composing shell.
### Grammar Tokens
* Logical Operators: `|, &, ^, -`
* Coverage Symbol: `A, B, C, ..., Z, *`
* Parenthesis: `(...)`
### Example Compositions
1. Executed code that is *shared* between coverage `A` and coverage `B`:
```
A & B
```
2. Executed code that is *unique* only to coverage `A`:
```
A - B
```
3. Executed code that is *unique* to `A` or `B`, but not `C`:
```
(A | B) - C
```
Expressions can be of arbitrary length or complexity, but the evaluation of the composition may occur right to left. So parenthesis are suggested for potentially ambiguous expressions.
## Hot Shell
Additionally, there is a 'Hot Shell' mode that asynchronously evaluates and caches user compositions in real-time.
<p align="center">
<img alt="Lighthouse Hot Shell" src="screenshots/hot_shell.gif"/>
</p>
The hot shell serves as a natural gateway into the unguided exploration of composed relationships.
## Search
Using the shell, you can search and filter the functions listed in the coverage table by prefixing their query with `/`.
<p align="center">
<img alt="Lighthouse Search" src="screenshots/search.gif"/>
</p>
The head of the shell will show an updated coverage % computed only from the remaining functions. This is useful when analyzing coverage for specific function families.
## Jump
Entering an address or function name into the shell can be used to jump to corresponding function entries in the table.
<p align="center">
<img alt="Lighthouse Jump" src="screenshots/jump.gif"/>
</p>
# Coverage Cross-references (Xref)
While using Lighthouse, you can right click any basic block (or instruction) and use the 'Coverage Xref' action to see which coverage sets executed the selected block. Double clicking any of the listed entries will instantly switch to that coverage set.
<p align="center">
<img alt="Lighthouse Xref" src="screenshots/xref.gif"/>
</p>
This pairs well with the 'Coverage Batch' feature, which allows you to quickly load and aggregate thousands of coverage files into Lighthouse. Cross-referencing a block and selecting a 'set' will load the 'guilty' set from disk as a new coverage set for you to explore separate from the batch.
# Themes
Lighthouse ships with two default themes -- a 'light' theme, and a 'dark' one. Depending on the colors currently used by your disassembler, Lighthouse will attempt to select the theme that seems most appropriate.
<p align="center">
<img alt="Lighthouse Themes" src="screenshots/themes.png"/>
</p>
The theme files are stored as simple JSON on disk and are highly configurable. If you are not happy with the default themes or colors, you can create your own themes and simply drop them in the user theme directory.
Lighthouse will remember your theme preference for future loads and uses.
# Future Work
Time and motivation permitting, future work may include:
@@ -159,7 +193,7 @@ Time and motivation permitting, future work may include:
* ~~Custom themes~~
* ~~Python 3 support~~
I welcome external contributions, issues, and feature requests. Please make any pull requests to the `develop` branch of this repo.
I welcome external contributions, issues, and feature requests. Please make any pull requests to the `develop` branch of this repository if you would like them to be considered for a future release.
# Authors
+41
View File
@@ -36,3 +36,44 @@ Example usage:
sudo python frida-drcov.py bb-bench
```
# Other Coverage Formats
Lighthouse is flexible as to what kind of coverage or 'trace' file formats it can load. Below is an outline of these human-readable text formats that are arguably the easiest to output from a custom tracer.
## Module + Offset (modoff)
A 'Module+Offset' coverage file / trace is a highly recommended coverage format due to its simplicity and readability:
```
boombox+3a06
boombox+3a09
boombox+3a0f
boombox+3a15
...
```
Each line of the trace represents an executed instruction or basic block in the instrumented program. The line *must* name an executed module eg `boombox.exe` and a relative offset to the executed address from the imagebase.
It is okay for hits from other modules (say, `kernel32.dll`) to exist in the trace. Lighthouse will not load coverage for them.
## Address Trace (Instruction, or Basic Block)
Perhaps the most primitive coverage format, Lighthouse can also consume an 'absolute address' style trace:
```
0x14000419c
0x1400041a0
0x1400045dc
0x1400045e1
0x1400045e2
...
```
Note that these address traces can be either instruction addresses, or basic block addresses -- it does not matter. The main caveat is that addresses in the trace *must* match the address space within the disassembler database.
If an address cannot be mapped into a function in the disassembler database, Lighthouse will simply discard it.
## Custom Trace Formats
If you are adamant to use a completely custom coverage format, you can try to subclass Lighthouse's `CoverageFile` parser interface. Once complete, simply drop your parser into the `parsers` folder.
+1 -1
View File
@@ -26,7 +26,7 @@ class LighthouseCore(object):
# Plugin Metadata
#--------------------------------------------------------------------------
PLUGIN_VERSION = "0.9.0-DEV"
PLUGIN_VERSION = "0.9.0"
AUTHORS = "Markus Gaasedelen"
DATE = "2020"
Binary file not shown.

Before

Width:  |  Height:  |  Size: 4.3 MiB

After

Width:  |  Height:  |  Size: 2.0 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 204 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 380 KiB