simuvex
, which was responsible for analyzing the effects of a single piece of code (whether a basic block or a SimProcedure) on a program state, and angr
, which aggregated analyses of these basic blocks into program-level analysis such as control-flow recovery, symbolic execution, and so forth. In theory, this would encourage for the encapsulation of block-level analyses, and allow other program analysis frameworks to build upon simuvex
for their needs. In practice, no one (to our knowledge) used simuvex
without angr
, and the separation introduced frustrating limitations (such as not being able to reference the history of a state from a SimInspect breakpoint) and duplication of code (such as the need to synchronize data from state.scratch
into path.history
).simuvex.SimProcedures
has been renamed to angr.SIM_PROCEDURES
, since it is a global variable and not a class. There have been some other changes to its semantics, see the section on SimProcedures for details.state.history
. Since the path would now simply point to the state, we got rid of it. The mapping of concepts is roughly as follows:path.actions
and path.recent_actions
- actions are no longer tracked by default. If you would like them to be tracked again, please add angr.options.refs
to your state.project.factory.simulation_manager(...)
.errored
stash of a path group. Now, error resilience is handled at the simulation manager level, and any state that throws an error during stepping will be wrapped in an ErrorRecord object, which is not a subclass of SimState, and put into the errored
list attribute of the simulation manager, which is not a stash..state
(the initial state that caused the error), .error
(the error that was thrown), and .traceback
(the traceback from the error). To debug these errors you can call .debug()
.SimProcedures['libc.so.6']
has been split up between SIM_PROCEDURES['libc']
, SIM_PROCEDURES['posix']
, and SIM_PROCEDURES['glibc']
, depending on what specifications each function conforms to. This allows us to reuse the libc
catalog in msvcrt.dll
and the MUSL libc, for example.angr.procedures.definitions
. Each SimLibrary object stores information about a single shared library, and can contain SimProcedure implementations, calling convention information, and type information. SimLibraries are scraped from the filesystem at import time, just like SimProcedures, and placed into angr.SIM_LIBRARIES
.SimProcedures
dict in order to change which SimProcedures would be used to hook over library functions by default, this will no longer work. Instead of SimProcedures[lib][func_name] = proc
, you now need to say SIM_LIBRARIES[lib].add(func_name, proc)
. But really you should just be using hook_symbol
anyway.Hook
class is gone. Instead, we now can hook with individual instances of SimProcedure objects, as opposed to just the classes. A shallow copy of the SimProcedure will be made at runtime to preserve thread safety.project.hook(addr, Hook(proc, ...))
or project.hook(addr, proc)
, you can now do project.hook(addr, proc(...))
. In order to use simple functions as hooks, you can either say project.hook(addr, func)
or decorate the declaration of your function with @project.hook(addr)
.self.call(...)
SimProcedure continuation system. It is no longer required to set IS_FUNCTION = True
if you intend to use self.call()
while writing a SimProcedure, and each call-return target you use will have a unique address associated with it. These addresses will be allocated lazily, which does have the side effect of making address allocation nondeterministic, sometimes based on dictionary-iteration order.hook_symbol
method will no longer attempt to redo relocations for the given symbol, instead just hooking directly over the address of the symbol in whatever library it comes from. This speeds up loading substancially and ensures more consistent behavior for when mixing and matching native library code and SimProcedure summaries.project._extern_obj
loader.extern_object
project._syscall_obj
loader.kernel_object
loader.whats_at()
loader.describe_addr
loader.addr_belongs_to_object()
loader.find_object_containing()
loader.find_symbol_name()
loader.find_symbol().name
loader.find_symbol(name or addr)
loader.find_module_name()
loader.find_object_containing().provides
loader.find_symbol_got_entry()
loader.find_relevant_relocations()
loader.main_bin
loader.main_object
anything.get_min_addr()
anything.min_addr
symbol.addr
symbol.linked_addr
state.solver
(if you're still referring to it as state.se
you should stop) and simplified it into a cleaner interface:solver.eval(expression)
will give you one possible solution to the given expression.solver.eval_one(expression)
will give you the solution to the given expression, or throw an error if more than one solution is possible.solver.eval_upto(expression, n)
will give you up to n solutions to the given expression, returning fewer than n if fewer than n are possible.solver.eval_atleast(expression, n)
will give you n solutions to the given expression, throwing an error if fewer than n are possible.solver.eval_exact(expression, n)
will give you n solutions to the given expression, throwing an error if fewer or more than are possible.solver.min(expression)
will give you the minimum possible solution to the given expression.solver.max(expression)
will give you the maximum possible solution to the given expression.extra_constraints
can be passed as a tuple of constraints.cast_to
can be passed a data type to cast the result to.str
, which will cause the method to return the byte representation of the underlying data.state.solver.eval(state.solver.BVV(0x41424344, 32, cast_to=str)
will return "ABCD"
.