B2R2.MiddleEnd.ControlFlowAnalysis Namespace
| Type/Module | Description |
|
Call edge from its callsite address to the callee's address. This is to uniquely identify call edges for abstracted vertices. We create an abstract vertex for each call instruction even though multiple call instructions may target the same callee. The callee address can be None for an indirect call. |
|
|
Per-function factory for basic blocks. Each BBL is memoized so that we do not create multiple BBLs for the same address. As this is a per-function structure, each different function has its own BBLFactory. |
|
|
Message containing the building context of a function. |
|
|
Callee's abstract information. |
|
|
What kind of callee is this? |
|
|
Our CFG reconstruction algorithm is performed by consuming actions (CFGAction). Each action has a priority, which is used to determine the order of the actions to run. |
|
|
A priority queue to store the ICFGActions. |
|
|
|
|
|
|
|
|
|
|
|
The context for building a control flow graph of a function. This exists per function, and it can include a user-defined context, too. |
|
|
|
|
|
The result obtained from recovering a CFG. |
|
|
This is a delayed request that is used to update the status of the CFG builder. This is populated only when the builder is running and is consumed after regular CFGActions are consumed. |
|
|
The builder for an external function, which is responsible storing auxiliary information about the function, such as caller information. |
|
|
|
|
|
Represents a function in a binary, which is essentially a continuous chunk of code. Functions may overlap with each other in rare cases. Function overlapping is rare because we will create a new function when there is an incoming edge in the middle of a funcion, |
|
|
Collection of recovered functions. |
|
|
Map from a function (callee) to its caller functions. This is not thread-safe, and thus should be used only by TaskManager. |
|
|
The interface for building a function. |
|
|
A strategy that defines how CFGActions are handled to build a function. This interface will be accessed in parallel by multiple threads, so every operation should be thread-safe. Note that CFGBuildingContext as well as 'FnCtx are only accessed by a single thread, though. |
|
|
Represents a function identification startegy. This is used to find candidate functions to analyze. |
|
|
Interface for summarizing a function based on the given context to abstract data. |
|
|
Interface for analyzing indirect branch instructions that use a jump table. |
|
|
Linkage information. A symbol/identifier in C can have either internal or external linkage. |
|
|
The interface for accessing the state of the TaskManager. |
|
|
The main builder for an internal function. This is responsible for building the function CFG while maintaining its internal state. By "internal", we mean that the function is defined within the target binary as opposed to external (library) functions. |
|
|
A per-function table that maintains function call information within a function, such as callsites in the function, callees, and their relationships. |
|
|
Interface for setting the priority of an action. |
|
|
Interface for resetting the state of an object. |
|
|
Jump table information. |
|
|
A note (or a recovery state) for jump table recovery. |
|
|
Global collection of jump table recovery notes. This is not thread-safe, so it should be accessed only by TaskManager. |
|
|
The result of jump table registration. |
|
|
Decision about what to do next in the jump table registration process. |
|
|
Represents the recovery targets to build. This is used for filtering the candidates to build, and it is defined as part of the strategy because some strategies may want to build only a subset of the candidates. |
|
|
Task manager for control flow analysis. |
|
|
Request messages for the task manager. |
|
|
|
|
|
Command to be consumed by task workers. |
|
|
Status of a task worker command. |
|
|
Stream of commands consumed by task workers. |
|
|
|
B2R2