|
| 1 | +# Project architecture |
| 2 | + |
| 3 | +The main component of this tool is the Ghidra plugin, `AngrIntegrationPlugin` (in `plugin/AngrIntegration`). This creates a |
| 4 | +Ghidra UI Component (in `AngrIntegrationProvider`), and creates an `AngrInterface` which is responsible for communicating |
| 5 | +with angr. It also aquires the `ConsoleService` for printing to the console and wraps it in it's own methods for |
| 6 | +outputting data. |
| 7 | + |
| 8 | +## `AngrInterface` |
| 9 | + |
| 10 | +Responsible for running scripts for the plugin. Stores the paths to python and keeps track of currently running worker |
| 11 | +threads. |
| 12 | + |
| 13 | +When the `AngrIntegrationProvider` tells the interface to run angr, a `Process` is created, which corresponds to an |
| 14 | +actually running instance of Python (in the venv). This is passed to a Swing `SwingWorker`, which polls the |
| 15 | +stdin/out/err every 20ms for new output. If there is new output, it will send it to either the REPL or the console, |
| 16 | +depending on if the REPL is active or not. |
| 17 | + |
| 18 | +The `AngrInterface` is also responsible for interpreteting several special commands the python process can send, which are |
| 19 | +all prefixed by a string that's unlikely to be hit normally (currently "`!<*`"). These can do things like send status |
| 20 | +updates to the UI, or cause the `AngrInterface` to create the REPL window and start sending data to that instead. |
| 21 | + |
| 22 | +If the REPL is active, it will call `checkSendInput` on the `AngrREPL` object every 20ms, which forwards updates from |
| 23 | +the user down the pipes to the angr process. |
| 24 | + |
| 25 | +## `AngrIntegrationProvider` |
| 26 | + |
| 27 | +High level component for the UI. Constructs each tab of the UI, registers event handlers, and does any other UI setup |
| 28 | +that needs doing. The tables, components that are shown or hidden by buttons, and Hook panels are delegated to other |
| 29 | +classes due to their complexity. |
| 30 | + |
| 31 | +Shows status reports from the `AngrInterface` next to the run button. Receives events from the `AngrIntegrationPlugin` |
| 32 | +when the program is changed, to allow the various components to adjust. |
| 33 | + |
| 34 | +When the run button is clicked, the `Provider` gathers all the fields from the UI into a `AngrConfiguration` object, |
| 35 | +which is serialized and written to a file in `/tmp`. Then the `AngrInterface` invokes the `angr_main` script, which |
| 36 | +reads that file and uses it to run angr! |
| 37 | + |
| 38 | +## `GoalView` and `StateView` |
| 39 | + |
| 40 | +These subclass Ghidra's `OptionalComponent` which is an abstract class that defines a component that can be shown, and also respond to events when the program is changed or readied. These are used to define the components in the UI when the corresponding button is selected for exploration goal or entry point respectively. When it's time to construct the `AngrConfiguration`, the `getConfig` function is called on them which should return the `ExplorationGoal` or `EntryPoint` that should be written to the `AngrConfiguration`. |
| 41 | + |
| 42 | +Each `_GoalView` corresponds to a `_Goal` that represents that goal in an `AngrConfiguration`, and respectively for `_StateView`. |
| 43 | + |
| 44 | +## `Table` and `TableModel` |
| 45 | + |
| 46 | +These are just specialisations of `JTable`s and `TableModel`s that configure the table to fit our needs. |
| 47 | + |
| 48 | +## `HookView` |
| 49 | + |
| 50 | +This component draws the edit panel for an individual hook. Unlike most of the UI, changes made in the UI are |
| 51 | +immediately written to an underlying array of `Hook`s, which means that only one `HookView` needs to exist. |
| 52 | + |
| 53 | +## `AngrREPL` |
| 54 | + |
| 55 | +Wraps a `InterpreterComponentProvider` in a small interface for reading and writing to it. |
| 56 | + |
| 57 | +## Python |
| 58 | + |
| 59 | +### `get_angr_version` |
| 60 | + |
| 61 | +Invoked by the plugin when loading or the venv changes, to check that the correct version of angr is loaded. |
| 62 | + |
| 63 | +### `angr_main` |
| 64 | + |
| 65 | +The main entry point to angr in the plugin. This reads a passed in data file, which should be a JSON object created from |
| 66 | +the `AngrInterface`, which defines everything that's been written into the UI. |
| 67 | + |
| 68 | +This does some setup, which includes using the `symbolic_field` module to construct symbolic variables and constraints |
| 69 | +from provided python strings, and inserting the progress reporter `ExplorationTechinique` from `progress_reporter`, |
| 70 | +which periodically writes progress reports which are picked up by the `AngrInterface` connected to stdout. It will also |
| 71 | +load the architecture definition from the provided config, which contains many hooks that can trigger across the whole |
| 72 | +process. |
| 73 | + |
| 74 | +Then it runs the main angr process, which should probably take a while! When done, it will print some cursory |
| 75 | +information about the recovered states and, if configured to do so, signal the interface to move to a REPL before |
| 76 | +starting a repl interpreter itself. |
0 commit comments