You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These actions can be used to quickly manipulate or interact with entries in the table.
80
+
70
81
## Coverage Composition
71
82
72
83
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.
@@ -134,7 +145,7 @@ Loaded coverage data and user constructed compositions can be selected or delete
134
145
135
146
Before using Lighthouse, one will need to collect code coverage data for their target binary / application.
136
147
137
-
The examples below demonstrate how one can use [DynamoRIO](http://www.dynamorio.org) or [Intel Pin](https://software.intel.com/en-us/articles/pin-a-dynamic-binary-instrumentation-tool) to collect Lighthouse compatible coverage agaainst a target. The `.log` files produced by these instrumentation tools can be loaded directly into Lighthouse.
148
+
The examples below demonstrate how one can use [DynamoRIO](http://www.dynamorio.org), [Intel Pin](https://software.intel.com/en-us/articles/pin-a-dynamic-binary-instrumentation-tool)or [Frida](https://www.frida.re)to collect Lighthouse compatible coverage against a target. The `.log` files produced by these instrumentation tools can be loaded directly into Lighthouse.
138
149
139
150
## DynamoRIO
140
151
@@ -156,7 +167,17 @@ Example usage:
156
167
pin.exe -t CodeCoverage64.dll -- boombox.exe
157
168
```
158
169
159
-
For convenience, binaries for the Windows pintool can be found on the [releases](https://github.com/gaasedelen/lighthouse/releases/tag/v0.6.0) page. MacOS and Linux users need to compile the pintool themselves following the [instructions](coverage/pin#compilation) included with the pintool for their respective platforms.
170
+
For convenience, binaries for the Windows pintool can be found on the [releases](https://github.com/gaasedelen/lighthouse/releases/tag/v0.7.0) page. MacOS and Linux users need to compile the pintool themselves following the [instructions](coverage/pin#compilation) included with the pintool for their respective platforms.
171
+
172
+
## Frida (Experimental)
173
+
174
+
Lighthouse offers limited support for Frida based code coverage via a custom [instrumentation script](coverage/frida) contributed by [yrp](https://twitter.com/yrp604).
175
+
176
+
Example usage:
177
+
178
+
```
179
+
sudo python frida-drcov.py bb-bench
180
+
```
160
181
161
182
# Future Work
162
183
@@ -166,7 +187,7 @@ Time and motivation permitting, future work may include:
In this folder you will find the code coverage collection script `frida-drcov.py` that run ontop of the [Frida](https://www.frida.re/) DBI toolkit. This script will produce code coverage (using Frida) in a log format compatible with [Lighthouse](https://github.com/gaasedelen/lighthouse).
4
+
5
+
Frida is best supported on mobile platforms such as iOS or Android, claiming some support for Windows, MacOS, Linux, and QNX. Practically speaking, `frida-drcov.py` should only be used for collecting coverage data on mobile applications.
6
+
7
+
This script is labeled only as a prototype.
8
+
9
+
## Install
10
+
11
+
To use `frida-drcov.py`, you must have [Frida](https://www.frida.re/) installed. This can be done via python's `pip`:
12
+
13
+
```
14
+
sudo pip install frida
15
+
```
16
+
17
+
## Usage
18
+
19
+
Once frida is installed, the `frida-drcov.py` script in this repo can be used to collect coverage against a running process as demonstrated below. By default, the code coverage data will be written to the file `frida-drcov.log` at the end of execution.
20
+
21
+
```
22
+
python frida-drcov.py <process name | pid>
23
+
```
24
+
25
+
Here is an example of us instrumenting the running process `bb-bench`.
26
+
27
+
```
28
+
$ sudo python frida-drcov.py bb-bench
29
+
[+] Got module info
30
+
Starting to stalk threads...
31
+
Stalking thread 775
32
+
Done stalking threads.
33
+
[*] Now collecting info, control-D to terminate....
34
+
[*] Detaching, this might take a second... # ^d
35
+
[+] Detached. Got 320 basic blocks.
36
+
[*] Formatting coverage and saving...
37
+
[!] Done
38
+
$ ls -lh frida-cov.log # this is the file you will load into lighthouse
39
+
-rw-r--r-- 1 root staff 7.2K 21 Oct 11:58 frida-cov.log
40
+
```
41
+
42
+
Using the `-o` flag, one can specify a custom name/location for the coverage log file:
43
+
44
+
```
45
+
python frida-drcov.py -o more-coverage.log foo
46
+
```
47
+
48
+
## Module Whitelisting
49
+
50
+
One can whitelist specific modules inside the target process. Say you have binary `foo` which imports the libraries `libfoo`, `libbar`, and `libbaz`. Using the `-w` flag (whitelist) on the command line, we can explicitly target modules of interest:
51
+
52
+
```
53
+
$ python frida-drcov.py -w libfoo -w libbaz foo
54
+
```
55
+
56
+
This will reduce the amount of information collected and improve performance. If no `-w` arguments are supplied, `frida-drcov.py` will trace all loaded images.
57
+
58
+
## Thread Targeting
59
+
60
+
On multi-threaded applications, tracing all threads can impose significant overhead. For these cases you can filter coverage collection based on thread id if you only care about specific threads.
61
+
62
+
In the following example, we target thread id `543`, and `678` running in the process named `foo`.
63
+
64
+
```
65
+
python frida-drcov.py -t 543 -t 678 foo
66
+
```
67
+
68
+
Without the `-t` flag, all threads that exist in the process at the time of attach will be traced.
0 commit comments