angr初探

# PREFACE：最近遇到需要动态模拟的题比较多，这里还是系统学一下 angr

# ps. angr 的文档还是写的比较有意思而且详细的，适合当睡前读物，点名批评某二进制分析工具的文档…

# 参考链接：

angr documentation

jakespringer/angr_ctf (github.com)

# 虚拟环境

angr 官方推荐在虚拟环境中运行，防止与外部包冲突（例如 keystone 和 keystone-engine 冲突，这里用的是 keystone-engine ）

pip install virtualenv

# 在当前目录下创建名为 angr-venv的新目录，包含干净的python环境
virtualenv angr-venv

Windows：
angr-venv\Scripts\activate

Linux/Mac：
source angr-venv/bin/activate

pip install angr

退出虚拟环境：
deactivate

# 使用样例

# 导入模块

import angr

# 命令行使用时可以导入 monkeyhex 转化为十六进制输出

import monkeyhex # this will format numerical results in hexadecimal

# project 的基础属性

proj.entry # 文件的入口点

proj.loader # 显示已加载对象，内存映射的地址范围

# 对基本块的操作

block = proj.factory.block(proj.entry) # 打印入口的基本块的汇编

# 模拟状态 SimState

state = proj.factory.entry_state() 

# 模拟管理器 Simulation Managers

simgr = proj.factory.simulation_manager(state) # 创建一个新的 SimulationManager 实例，它将负责管理程序的所有可能的执行路径，包括路径的分叉、合并和死亡

import angr

# Analyses

>>> proj.analyses.            # Press TAB here in ipython to get an autocomplete-listing of everything:

（未必准确的解释，后续慢慢验证）

import angr

# The Loader

# All loaded objects

>>> obj = proj.loader.main_object

# Symbols and Relocations

CLE 寻找符号地址

>>> strcmp = proj.loader.find_symbol('strcmp')

The Symbol object has three ways of reporting its address:

• .rebased_addr is its address in the global address space. This is what is shown in the print output.
• .linked_addr is its address relative to the prelinked base of the binary. This is the address reported in, for example, readelf(1) .
• .relative_addr is its address relative to the object base. This is known in the literature (particularly the Windows literature) as an RVA (relative virtual address).

>>> strcmp.name

>>> strcmp.is_export

# Relocations don't have a good pretty-printing, so those addresses are Python-internal, unrelated to our program

# Loading Options

If you are loading something with angr.Project and you want to pass an option to the cle.Loader instance that Project implicitly creates, you can just pass the keyword argument directly to the Project constructor, and it will be passed on to CLE. You should look at the CLE API docs. if you want to know everything that could possibly be passed in as an option, but we will go over some important and frequently used options here.

We’ve discussed auto_load_libs already - it enables or disables CLE’s attempt to automatically resolve shared library dependencies, and is on by default. Additionally, there is the opposite, except_missing_libs , which, if set to true, will cause an exception to be thrown whenever a binary has a shared library dependency that cannot be resolved.

You can pass a list of strings to force_load_libs and anything listed will be treated as an unresolved shared library dependency right out of the gate, or you can pass a list of strings to skip_libs to prevent any library of that name from being resolved as a dependency. Additionally, you can pass a list of strings (or a single string) to ld_path , which will be used as an additional search path for shared libraries, before any of the defaults: the same directory as the loaded program, the current working directory, and your system libraries.

If you want to specify some options that only apply to a specific binary object, CLE will let you do that too. The parameters main_opts and lib_opts do this by taking dictionaries of options. main_opts is a mapping from option names to option values, while lib_opts is a mapping from library name to dictionaries mapping option names to option values.

The options that you can use vary from backend to backend, but some common ones are:

• backend - which backend to use, as either a class or a name
• base_addr - a base address to use
• entry_point - an entry point to use
• arch - the name of an architecture to use

Example:

>>> angr.Project('examples/fauxware/fauxware', main_opts={'backend': 'blob', 'arch': 'i386'}, lib_opts={'libc.so.6': {'backend': 'elf'}})

# Symbolic Function Summaries

angr/angr/procedures at master · angr/angr (github.com)

# hook

The mechanism by which angr replaces library code with a Python summary is called hooking, and you can do it too! When performing simulation, at every step angr checks if the current address has been hooked, and if so, runs the hook instead of the binary code at that address. The API to let you do this is proj.hook(addr, hook), where hook is a SimProcedure instance. You can manage your project’s hooks with .is_hooked, .unhook, and .hooked_by, which should hopefully not require explanation.

stub_func = angr.SIM_PROCEDURES['stubs']['ReturnUnconstrained'] # this is a CLASS

可以尝试

import angr

然后可以进行 hook 修改寄存器等操作

import angr

# 符号样例

# Bitvectors

>>> one = state.solver.BVV(1, 64)

可以通过 ASTs 分析

>>> tree = (x + 1) / (y + 2)

# Symbolic Constraints

Performing comparison operations between any two similarly-typed ASTs will yield another AST - not a bitvector, but now a symbolic boolean.

>>> x == 1

判断

yes = one == 1

# Constraint Solving

>>> state.solver.add(x > y)

# get a fresh state without constraints

# fresh state

# Floating point numbers

# fresh state

This is nice, but sometimes we need to be able to work directly with the representation of the float as a bitvector. You can interpret bitvectors as floats and vice versa, with the methods raw_to_bv and raw_to_fp :

>>> a.raw_to_bv()

>>> a

# More Solving Methods

eval will give you one possible solution to an expression, but what if you want several? What if you want to ensure that the solution is unique? The solver provides you with several methods for common solving patterns:

• 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.

Additionally, all of these methods can take the following keyword arguments:

• extra_constraints can be passed as a tuple of constraints. These constraints will be taken into account for this evaluation, but will not be added to the state.
• cast_to can be passed a data type to cast the result to. Currently, this can only be int and bytes , which will cause the method to return the corresponding representation of the underlying data. For example, state.solver.eval(state.solver.BVV(0x41424344, 32), cast_to=bytes) will return b'ABCD' .

# Machine State - memory, registers, and so on

quick examples:

>>> import angr, claripy

这里开始使用更简单的执行方法： state.step() ，其会进行一步符号执行并且返回名为 angr.engines.successors.SimSuccessors 的对象，并且会提供若干可以被分类成不同执行路径的继承状态，关注该对象的 .successors 属性，其是一个包含所有 “normal” successors of a given step 的 list。

该 list 会包含所有 constraint 的正误状态作为新的 constraint

(这里的 example 应该是用一个 strcmp 作为 constraint)

>>> proj = angr.Project('examples/fauxware/fauxware')

可以 use state.posix.stdin.load(0, state.posix.stdin.size) to retrieve a bitvector representing all the content read from stdin so far

>>> input_data = state1.posix.stdin.load(0, state1.posix.stdin.size)

# State Presets

project.factory.

• .blank_state() constructs a “blank slate” blank state, with most of its data left uninitialized. When accessing uninitialized data, an unconstrained symbolic value will be returned.
• .entry_state() constructs a state ready to execute at the main binary’s entry point.
• .full_init_state() constructs a state that is ready to execute through any initializers that need to be run before the main binary’s entry point, for example, shared library constructors or preinitializers. When it is finished with these it will jump to the entry point.
• .call_state() constructs a state ready to execute a given function.

使用方法：

• 传入起始地址：

​ All of these constructors can take an addr argument to specify the exact address to start.

• 传入参数：

​ If you’re executing in an environment that can take command line arguments or an environment, you can pass a list of arguments through args and a dictionary of environment variables through env into entry_state and full_init_state . The values in these structures can be strings or bitvectors, and will be serialized into the state as the arguments and environment to the simulated execution. The default args is an empty list, so if the program you’re analyzing expects to find at least an argv[0] , you should always provide that!

• 可以传入符号

​ If you’d like to have argc be symbolic, you can pass a symbolic bitvector as argc to the entry_state and full_init_state constructors. Be careful, though: if you do this, you should also add a constraint to the resulting state that your value for argc cannot be larger than the number of args you passed into args .

• 传入函数参数

​ To use the call state, you should call it with .call_state(addr, arg1, arg2, ...) , where addr is the address of the function you want to call and argN is the Nth argument to that function, either as a Python integer, string, or array, or a bitvector. If you want to have memory allocated and actually pass in a pointer to an object, you should wrap it in an PointerWrapper, i.e. angr.PointerWrapper("point to me!") . The results of this API can be a little unpredictable, but we’re working on it.

​ To specify the calling convention used for a function with call_state , you can pass a SimCC instance as the cc argument.:raw-html-m2r: We try to pick a sane default, but for special cases you will need to help angr out.

# 对内存操作

对内存地址批量操作

>>> s = proj.factory.blank_state()

# 对寄存器操作

state.registers ： Intermediate Representation - angr documentation

angr/archinfo: Classes with architecture-specific information useful to other projects. (github.com)

# State Options

https://docs.angr.io/en/latest/appendix/options.html#list-of-state-options

# Example: enable lazy solves, an option that causes state satisfiability to be checked as infrequently as possible.

# Plugins

# State Plugins

implement new kinds of data storage

For example, the normal memory plugin simulates a flat memory space, but analyses can choose to enable the “abstract memory” plugin, which uses alternate data types for addresses to simulate free-floating memory mappings independent of address, to provide state.memory . Conversely, plugins can reduce code complexity: state.memory and state.registers are actually two different instances of the same plugin, since the registers are emulated with an address space as well.

# The globals plugin

state.globals is an extremely simple plugin: it implements the interface of a standard Python dict, allowing you to store arbitrary data on a state.

# The history plugin

state.history is a very important plugin storing historical data about the path a state has taken during execution. It is actually a linked list of several history nodes, each one representing a single round of execution—you can traverse this list with state.history.parent.parent etc.

To make it more convenient to work with this structure, the history also provides several efficient iterators over the history of certain values. In general, these values are stored as history.recent_NAME and the iterator over them is just history.NAME . For example, for addr in state.history.bbl_addrs: print hex(addr) will print out a basic block address trace for the binary, while state.history.recent_bbl_addrs is the list of basic blocks executed in the most recent step, state.history.parent.recent_bbl_addrs is the list of basic blocks executed in the previous step, etc. If you ever need to quickly obtain a flat list of these values, you can access .hardcopy , e.g. state.history.bbl_addrs.hardcopy . Keep in mind though, index-based accessing is implemented on the iterators.

Here is a brief listing of some of the values stored in the history:

• history.descriptions is a listing of string descriptions of each of the rounds of execution performed on the state.
• history.bbl_addrs is a listing of the basic block addresses executed by the state. There may be more than one per round of execution, and not all addresses may correspond to binary code - some may be addresses at which SimProcedures are hooked.
• history.jumpkinds is a listing of the disposition of each of the control flow transitions in the state’s history, as VEX enum strings.
• history.jump_guards is a listing of the conditions guarding each of the branches that the state has encountered.
• history.events is a semantic listing of “interesting events” which happened during execution, such as the presence of a symbolic jump condition, the program popping up a message box, or execution terminating with an exit code.
• history.actions is usually empty, but if you add the angr.options.refs options to the state, it will be populated with a log of all the memory, register, and temporary value accesses performed by the program.

# The callstack plugin

angr will track the call stack for the emulated program. On every call instruction, a frame will be added to the top of the tracked callstack, and whenever the stack pointer drops below the point where the topmost frame was called, a frame is popped. This allows angr to robustly store data local to the current emulated function.

Similar to the history, the callstack is also a linked list of nodes, but there are no provided iterators over the contents of the nodes - instead you can directly iterate over state.callstack to get the callstack frames for each of the active frames, in order from most recent to oldest. If you just want the topmost frame, this is state.callstack .

• callstack.func_addr is the address of the function currently being executed
• callstack.call_site_addr is the address of the basic block which called the current function
• callstack.stack_ptr is the value of the stack pointer from the beginning of the current function
• callstack.ret_addr is the location that the current function will return to if it returns

# I/O

Working with File System, Sockets, and Pipes

# Copying and Merging

A state supports very fast copies, so that you can explore different possibilities:

>>> proj = angr.Project('/bin/true')

States can also be merged together.

# merge will return a tuple. the first element is the merged state

# Simulation Managers

描述：

Simulation managers let you wrangle multiple states in a slick way. States are organized into “stashes”, which you can step forward, filter, merge, and move around as you wish.

# Stepping

.step() ： 前进一个 basic block

.run() ：执行到所有 deadended，并且获得所有 deadended states（例如到达 exit syscall，此时该 state 会被从 active stash 中移除并放入 deadended states ）

# Stash Management

.move() ： from_stash to_stash filter_func (optional, default:everything)

# eg. 检查所有执行路径已终止（deadended）的状态，查找其中在程序的标准输出中打印了 'Welcome' 的状态，并将这些状态移动到一个名为 'authenticated' 的新 stash，以便进一步分析或单独处理。

stash 的类型为 list，可以通过如下方式访问：

for s in simgr.deadended + simgr.authenticated:

所以 link 呢

# Stash types

Stash	Description
active	This stash contains the states that will be stepped by default, unless an alternate stash is specified.
deadended	A state goes to the deadended stash when it cannot continue the execution for some reason, including no more valid instructions, unsat state of all of its successors, or an invalid instruction pointer.
pruned	When using LAZY_SOLVES , states are not checked for satisfiability unless absolutely necessary. When a state is found to be unsat in the presence of LAZY_SOLVES , the state hierarchy is traversed to identify when, in its history, it initially became unsat. All states that are descendants of that point (which will also be unsat, since a state cannot become un-unsat) are pruned and put in this stash.
unconstrained	If the save_unconstrained option is provided to the SimulationManager constructor, states that are determined to be unconstrained (i.e., with the instruction pointer controlled by user data or some other source of symbolic data) are placed here.
unsat	If the save_unsat option is provided to the SimulationManager constructor, states that are determined to be unsatisfiable (i.e., they have constraints that are contradictory, like the input having to be both “AAAA” and “BBBB” at the same time) are placed here.
errored	If, during execution, an error is raised, then the state will be wrapped in an ErrorRecord object, which contains the state and the error it raised, and then the record will be inserted into errored . launch a debug shell at the site of the error with record.debug() .

# Exploration

.explore() ： find argument (指令的结束地址或结束地址列表，或函数根据某种标准的返回状态)

当满足后，放入 found stash，然后结束符号执行，可以同样声明 avoid condition（格式与 find 相同）

num_find 指定 return 前找到多少数量的 find （default = 1，如果所有 active stash 的 state 被全部执行则同样 return）

eg.

proj = angr.Project('examples/CSCI-4968-MBE/challenges/crackme0x00a/crackme0x00a')

其他样例：angr examples - angr documentation

# Exploration Techniques

angr ships with several pieces of canned functionality that let you customize the behavior of a simulation manager, called exploration techniques. The archetypical example of why you would want an exploration technique is to modify the pattern in which the state space of the program is explored - the default “step everything at once” strategy is effectively breadth-first search, but with an exploration technique you could implement, for example, depth-first search. However, the instrumentation power of these techniques is much more flexible than that - you can totally alter the behavior of angr’s stepping process. Writing your own exploration techniques will be covered in a later chapter.

To use an exploration technique, call simgr.use_technique(tech) , where tech is an instance of an ExplorationTechnique subclass. angr’s built-in exploration techniques can be found under angr.exploration_techniques .

Here’s a quick overview of some of the built-in ones:

• DFS: Depth first search, as mentioned earlier. Keeps only one state active at once, putting the rest in the deferred stash until it deadends or errors.
• Explorer: This technique implements the .explore() functionality, allowing you to search for and avoid addresses.
• LengthLimiter: Puts a cap on the maximum length of the path a state goes through.
• LoopSeer: Uses a reasonable approximation of loop counting to discard states that appear to be going through a loop too many times, putting them in a spinning stash and pulling them out again if we run out of otherwise viable states.
• ManualMergepoint: Marks an address in the program as a merge point, so states that reach that address will be briefly held, and any other states that reach that same point within a timeout will be merged together.
• MemoryWatcher: Monitors how much memory is free/available on the system between simgr steps and stops exploration if it gets too low.
• Oppologist: The “operation apologist” is an especially fun gadget - if this technique is enabled and angr encounters an unsupported instruction, for example a bizzare and foreign floating point SIMD op, it will concretize all the inputs to that instruction and emulate the single instruction using the unicorn engine, allowing execution to continue.
• Spiller: When there are too many states active, this technique can dump some of them to disk in order to keep memory consumption low.
• Threading: Adds thread-level parallelism to the stepping process. This doesn’t help much because of Python’s global interpreter locks, but if you have a program whose analysis spends a lot of time in angr’s native-code dependencies (unicorn, z3, libvex) you can seem some gains.
• Tracer: An exploration technique that causes execution to follow a dynamic trace recorded from some other source. The dynamic tracer repository has some tools to generate those traces.
• Veritesting: An implementation of a [CMU paper](https://users.ece.cmu.edu/~dbrumley/pdf/Avgerinos et al._2014_Enhancing Symbolic Execution with Veritesting.pdf) on automatically identifying useful merge points. This is so useful, you can enable it automatically with veritesting=True in the SimulationManager constructor! Note that it frequenly doesn’t play nice with other techniques due to the invasive way it implements static symbolic execution.

Look at the API documentation for the SimulationManager and ExplorationTechnique classes for more information.

# Simulation and Instrumentation

Attribute	Guard Condition	Instruction Pointer	Description
successors	True (can be symbolic, but constrained to True)	Can be symbolic (but 256 solutions or less; see unconstrained_successors ).	A normal, satisfiable successor state to the state processed by the engine. The instruction pointer of this state may be symbolic (i.e., a computed jump based on user input), so the state might actually represent several potential continuations of execution going forward.
unsat_successors	False (can be symbolic, but constrained to False).	Can be symbolic.	Unsatisfiable successors. These are successors whose guard conditions can only be false (i.e., jumps that cannot be taken, or the default branch of jumps that must be taken).
flat_successors	True (can be symbolic, but constrained to True).	Concrete value.	As noted above, states in the successors list can have symbolic instruction pointers. This is rather confusing, as elsewhere in the code (i.e., in SimEngineVEX.process , when it’s time to step that state forward), we make assumptions that a single program state only represents the execution of a single spot in the code. To alleviate this, when we encounter states in successors with symbolic instruction pointers, we compute all possible concrete solutions (up to an arbitrary threshold of 256) for them, and make a copy of the state for each such solution. We call this process “flattening”. These flat_successors are states, each of which has a different, concrete instruction pointer. For example, if the instruction pointer of a state in successors was X+5 , where X had constraints of X > 0x800000 and X <= 0x800010 , we would flatten it into 16 different flat_successors states, one with an instruction pointer of 0x800006 , one with 0x800007 , and so on until 0x800015 .
unconstrained_successors	True (can be symbolic, but constrained to True).	Symbolic (with more than 256 solutions).	During the flattening procedure described above, if it turns out that there are more than 256 possible solutions for the instruction pointer, we assume that the instruction pointer has been overwritten with unconstrained data (i.e., a stack overflow with user data). This assumption is not sound in general. Such states are placed in unconstrained_successors and not in successors .
all_successors	Anything	Can be symbolic.	This is successors + unsat_successors + unconstrained_successors .

# Breakpoints

>>> import angr

Event type	Event meaning
mem_read	Memory is being read.
mem_write	Memory is being written.
address_concretization	A symbolic memory access is being resolved.
reg_read	A register is being read.
reg_write	A register is being written.
tmp_read	A temp is being read.
tmp_write	A temp is being written.
expr	An expression is being created (i.e., a result of an arithmetic operation or a constant in the IR).
statement	An IR statement is being translated.
instruction	A new (native) instruction is being translated.
irsb	A new basic block is being translated.
constraints	New constraints are being added to the state.
exit	A successor is being generated from execution.
fork	A symbolic execution state has forked into multiple states.
symbolic_variable	A new symbolic variable is being created.
call	A call instruction is hit.
return	A ret instruction is hit.
simprocedure	A simprocedure (or syscall) is executed.
dirty	A dirty IR callback is executed.
syscall	A syscall is executed (called in addition to the simprocedure event).
engine_process	A SimEngine is about to process some code.

These events expose different attributes:

Event type	Attribute name	Attribute availability	Attribute meaning
mem_read	mem_read_address	BP_BEFORE or BP_AFTER	The address at which memory is being read.
mem_read	mem_read_expr	BP_AFTER	The expression at that address.
mem_read	mem_read_length	BP_BEFORE or BP_AFTER	The length of the memory read.
mem_read	mem_read_condition	BP_BEFORE or BP_AFTER	The condition of the memory read.
mem_write	mem_write_address	BP_BEFORE or BP_AFTER	The address at which memory is being written.
mem_write	mem_write_length	BP_BEFORE or BP_AFTER	The length of the memory write.
mem_write	mem_write_expr	BP_BEFORE or BP_AFTER	The expression that is being written.
mem_write	mem_write_condition	BP_BEFORE or BP_AFTER	The condition of the memory write.
reg_read	reg_read_offset	BP_BEFORE or BP_AFTER	The offset of the register being read.
reg_read	reg_read_length	BP_BEFORE or BP_AFTER	The length of the register read.
reg_read	reg_read_expr	BP_AFTER	The expression in the register.
reg_read	reg_read_condition	BP_BEFORE or BP_AFTER	The condition of the register read.
reg_write	reg_write_offset	BP_BEFORE or BP_AFTER	The offset of the register being written.
reg_write	reg_write_length	BP_BEFORE or BP_AFTER	The length of the register write.
reg_write	reg_write_expr	BP_BEFORE or BP_AFTER	The expression that is being written.
reg_write	reg_write_condition	BP_BEFORE or BP_AFTER	The condition of the register write.
tmp_read	tmp_read_num	BP_BEFORE or BP_AFTER	The number of the temp being read.
tmp_read	tmp_read_expr	BP_AFTER	The expression of the temp.
tmp_write	tmp_write_num	BP_BEFORE or BP_AFTER	The number of the temp written.
tmp_write	tmp_write_expr	BP_AFTER	The expression written to the temp.
expr	expr	BP_BEFORE or BP_AFTER	The IR expression.
expr	expr_result	BP_AFTER	The value (e.g. AST) which the expression was evaluated to.
statement	statement	BP_BEFORE or BP_AFTER	The index of the IR statement (in the IR basic block).
instruction	instruction	BP_BEFORE or BP_AFTER	The address of the native instruction.
irsb	address	BP_BEFORE or BP_AFTER	The address of the basic block.
constraints	added_constraints	BP_BEFORE or BP_AFTER	The list of constraint expressions being added.
call	function_address	BP_BEFORE or BP_AFTER	The name of the function being called.
exit	exit_target	BP_BEFORE or BP_AFTER	The expression representing the target of a SimExit.
exit	exit_guard	BP_BEFORE or BP_AFTER	The expression representing the guard of a SimExit.
exit	exit_jumpkind	BP_BEFORE or BP_AFTER	The expression representing the kind of SimExit.
symbolic_variable	symbolic_name	BP_AFTER	The name of the symbolic variable being created. The solver engine might modify this name (by appending a unique ID and length). Check the symbolic_expr for the final symbolic expression.
symbolic_variable	symbolic_size	BP_AFTER	The size of the symbolic variable being created.
symbolic_variable	symbolic_expr	BP_AFTER	The expression representing the new symbolic variable.
address_concretization	address_concretization_strategy	BP_BEFORE or BP_AFTER	The SimConcretizationStrategy being used to resolve the address. This can be modified by the breakpoint handler to change the strategy that will be applied. If your breakpoint handler sets this to None, this strategy will be skipped.
address_concretization	address_concretization_action	BP_BEFORE or BP_AFTER	The SimAction object being used to record the memory action.
address_concretization	address_concretization_memory	BP_BEFORE or BP_AFTER	The SimMemory object on which the action was taken.
address_concretization	address_concretization_expr	BP_BEFORE or BP_AFTER	The AST representing the memory index being resolved. The breakpoint handler can modify this to affect the address being resolved.
address_concretization	address_concretization_add_constraints	BP_BEFORE or BP_AFTER	Whether or not constraints should/will be added for this read.
address_concretization	address_concretization_result	BP_AFTER	The list of resolved memory addresses (integers). The breakpoint handler can overwrite these to effect a different resolution result.
syscall	syscall_name	BP_BEFORE or BP_AFTER	The name of the system call.
simprocedure	simprocedure_name	BP_BEFORE or BP_AFTER	The name of the simprocedure.
simprocedure	simprocedure_addr	BP_BEFORE or BP_AFTER	The address of the simprocedure.
simprocedure	simprocedure_result	BP_AFTER	The return value of the simprocedure. You can also override it in BP_BEFORE, which will cause the actual simprocedure to be skipped and for your return value to be used instead.
simprocedure	simprocedure	BP_BEFORE or BP_AFTER	The actual SimProcedure object.
dirty	dirty_name	BP_BEFORE or BP_AFTER	The name of the dirty call.
dirty	dirty_handler	BP_BEFORE	The function that will be run to handle the dirty call. You can override this.
dirty	dirty_args	BP_BEFORE or BP_AFTER	The address of the dirty.
dirty	dirty_result	BP_AFTER	The return value of the dirty call. You can also override it in BP_BEFORE, which will cause the actual dirty call to be skipped and for your return value to be used instead.
engine_process	sim_engine	BP_BEFORE or BP_AFTER	The SimEngine that is processing.
engine_process	successors	BP_BEFORE or BP_AFTER	The SimSuccessors object defining the result of the engine.

eg. 每当程序状态 s 执行内存读取时， angr 都会在读取完成后立即调用 track_reads ，打印出读取的值和发生读取的内存地址。

>>> def track_reads(state):

# This will break before a memory write if 0x1000 is a possible value of its target expression

声明函数作为 condition

# this is a complex condition that could do anything! In this case, it makes sure that RAX is 0x41414141 and

# Caution about mem_read breakpoint

The mem_read breakpoint gets triggered anytime there are memory reads by either the executing program or the binary analysis. If you are using breakpoint on mem_read and also using state.mem to load data from memory addresses, then know that the breakpoint will be fired as you are technically reading memory.

So if you want to load data from memory and not trigger any mem_read breakpoint you have had set up, then use state.memory.load with the keyword arguments disable_actions=True and inspect=False .

This is also true for state.find and you can use the same keyword arguments to prevent mem_read breakpoints from firing.

# Analyses

Writing Analyses - angr documentation

the idea is that all the analyses appear under project.analyses (for example, project.analyses.CFGFast() ) and can be called as functions, returning analysis result instances.

Name	Description
CFGFast	Constructs a fast Control Flow Graph of the program
CFGEmulated	Constructs an accurate Control Flow Graph of the program
VFG	Performs VSA on every function of the program, creating a Value Flow Graph and detecting stack variables
DDG	Calculates a Data Dependency Graph, allowing one to determine what statements a given value depends on
BackwardSlice	Computes a Backward Slice of a program with respect to a certain target
Identifier	Identifies common library functions in CGC binaries
More!	angr has quite a few analyses, most of which work! If you’d like to know how to use one, please submit an issue requesting documentation.

# Resilience

Analyses can be written to be resilient, and catch and log basically any error. These errors, depending on how they’re caught, are logged to the errors or named_errors attribute of the analysis. However, you might want to run an analysis in “fail fast” mode, so that errors are not handled. To do this, the argument fail_fast=True can be passed into the analysis constructor.

# Symbolic Execution

# 为什么这里是 todo…

Symbolic Execution - angr documentation

# angr_ctf

# 官方给的样例，文档里还有很多真实 ctf 比赛的例题 orz，初探就做到这里吧

# 环境配置

添加环境变量：

export C_INCLUDE_PATH=/usr/include/x86_64-linux-gnu

支持编译 32 位程序包：

sudo apt-get install libc6-dev-i386

生成可执行程序

python3 generate.py [seed] [output_file]

# 00_angr_find

直接找对应标准输出的输入即可

import angr

# 01_angr_avoid

main 函数的节点过多

可以看到 avoid_me 函数被大量调用

这里需要让 angr 走到 avoid_me 函数后就剪枝

可以使用函数传入所有需要 avoid 的状态

import angr

# 02_angr_find_condition

和上面一样

import angr

# 03_angr_symbolic_registers

和上面一样可以打通

import angr

不过官方 exp 是打算让分段打（yysy，看起来没啥用，也就是省去了初始化的一些时间，不会优化太多）：

# Angr doesn't currently support reading multiple things with scanf (Ex: 

# 04_angr_symbolic_stack

老 exp 还是可以打通… 不过官方 exp 是要求把栈模拟一下的，贴一下先

# This challenge will be more challenging than the previous challenges that you

分析一下：

主要是这里：

实际上就是找到栈上的参数，用于做初始化状态，再进行符号执行

# 05_angr_symbolic_memory

对应到全局变量的方法

import angr

# 06_angr_symbolic_dynamic_memory

最早的仍旧能打通

不过这题主要还是教你把堆模拟（分配未分配过的内存即可）

fake_heap_address0 = 0x4444444

# 07_angr_symbolic_file

最早的仍旧能打通，而且官方的反而打不通 ee

还是贴一个官方的吧，其实就是教怎么模拟文件

# This challenge could, in theory, be solved in multiple ways. However, for the

ps. 找到 issue 了：

Scaffold and solution challenge 07 are not working with latest angr, because SimFile class changed.

This is working code with latest version of angr for the filesystem part:

  filename = "OJKSQYDP.txt"  # :string
  symbolic_file_size_bytes = 64

  password = claripy.BVS('password', symbolic_file_size_bytes * 8)
  password_file = angr.storage.SimFile(filename, content=password, size=symbolic_file_size_bytes)

  initial_state.fs.insert(filename, password_file)
  simulation = project.factory.simgr(initial_state)

TODO：改了 issue 仍旧打不通

# 08_angr_constraints

老 exp 打不通了，好耶（什）

原理：

# While you, as a human, can easily determine that this function is equivalent
# to simply comparing the strings, the computer cannot. Instead the computer 
# would need to branch every time the if statement in the loop was called (16 
# times), resulting in 2^16 = 65,536 branches, which will take too long of a 
# time to evaluate for our needs.

TODO：这里尝试过在 check 的 jnz 地址处对 zf 寄存器状态做剪枝，也跑不出来，后续看看为啥

官方给的解法是手动获取模拟比较（设置终止状态在真正的 check 之前，然后手动设置比较），将其转化为 constraint，约束求解得到最终结果，贴一个吧先：

import angr

# 09_angr_hooks

他说要 hook，但是我强行给他分段打通楽（什）

一开始写的 exp（注意给 password 初始值写上，开始的时候忘了）可以打通

import angr

然后看看官方怎么 hook 的

结论是这么写将中间那个过不去的函数转化为手动的 check，那比上一个的做法还简洁点点

主要就是这里：

直接贴一个：

# This level performs the following computations:

# 10_angr_simprocedures

将 check 部分的 basic block 拆了很多很多，看源码是加了不透明谓词和分发块：

ida 做了的伪代码做了代码优化，看起来其实和前面两个题差不多

但是下面这种写法不行，不知道是为啥不能这样 hook，这样 hook 的话约束不出来解：

（先 hook 找输入的地址，然后手写 check，但是约束不出来，跑出来空解）

import angr

看看官方的吧：

import angr

定义一个类，遇到 check 函数后直接 hook 并且跳过

简写偷一个，方便看：

import angr

所以为啥我的跑不通

# 11_angr_sim_scanf

看起来比上个还过分一点

看起来是很多 scanf 了

这个从源程序看起来可以直接手动 check 秒掉，还是小写一个

（然后其实 check 也是不必要的，就这样 hook 就行）

import angr

来看看这题想考怎么个事

# This time, the solution involves simply replacing scanf with our own version,
# since Angr does not support requesting multiple parameters with scanf.

结果

import angr

其实可以打通的，结论是 angr 在不断进步～～，楽～～

不过这题还是想跟你说说 hook 系统函数的方法，其实也就是 hook 一下符号

# This time, the solution involves simply replacing scanf with our own version,

# 12_angr_veritesting

？？？为什么又 hook 不成功了（这里因为代码又变了，想做一些新的尝试）

↓失败的代码

import angr

这里进行一点 debug 看看…

修改代码如下：

import angr

打印的内容如下：

T W W Z Z Z Z C C C C C C C C F F F F F F F F F F F F F F F F I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I I L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L L

实际上，这里去重之后就是正确答案了，说明这里出现了路径爆炸，在某个地方被分化，stash 内路径数量翻倍了，导致每次 bfs 路径都幂指数上升了

猜测是因为输入的不确定，在赋值的时候就需要 hook 掉，把这段补上（打印 stash 的长度看眼）：

@project.hook(0x80492B5)

看一下目前 hook 后剩下的代码（ida 中 patch 替代）

晚上睡前想着，会不会是循环的时候 jle 给分化出来了 stash，但是早起看了眼前面的程序，也是循环应该没有问题的

加上上面又 hook 的代码，输出大约如下：

len : 9
T len : 9
len : 9
W W len : 9
len : 9
len : 9
len : 9
Z Z Z Z len : 9
len : 9
len : 9
len : 9
len : 9
len : 9
len : 9
len : 9
C C C C C C C C len : 9
len : 9
len : 9
len : 9
len : 9
len : 9
len : 9
len : 9
len : 9
len : 9
len : 9
len : 9
len : 9
len : 9
len : 9
len : 9
F F F F F F F F F F F F F F F F len : 9

结果 stash 长度并没有变化，但是仍旧有路径分化的现象，这就有些闹鬼了

打在上面看看：

import angr

结论是 stash 还是 9，为啥 9 啊，整个程序才 9 个 basic block ，结束地址前面已经不存在分支了

这里直接从 scanf 后面开始 init blank_state 也是一样的结果，说明不是 scanf 或者环境变量传入的问题

问了 r1mao 学长，发现这里对 stash 和 state 的理解有点问题了：

state 会分在不同 types 的 stash，如果这里打印 simulation.active 的话，得到的就是当前的 state 数量，和执行的重复数量结果是一致的

active len : 32
stashLen : 9

打印一下 stash 和 state 的结构
实际上是这样子的

stash:
----------------------------------------------------------------------------------------
active              |              kill              |              etc.          
   |							    |							     |
   ----> active state               ----> killed state				 ----> else state

所以应该这样子用：

simulation.stashes['active']

检查一下是不是 jle 惹的锅

@project.hook(0x80492E9)

不是，那还好：
len before jle 1
len after jle 1
len before jle 2
len before jle 2
len after jle 2
len after jle 2

同理，只剩一个地方了…

这下赛博鬼抓到了…hook 以后机器指令没跳过去…

ok，找到了，语法错误，也没报…

exp：

import angr

还是看看官方吧，虽然被折磨了一把…

这里是想教你用 veritesting ，这样子 veritesting=True 即可

import angr

# 13_angr_static_binary

可以看到原本的 strcmp 函数被分解成了很复杂的样子，会导致 angr 陷进去出不来了，其他库函数也一样

这里是编译时加了静态链接的参数导致的

把系统函数 hook 掉换成 libc 和 glibc 里的标准符号即可

import angr

# 14_angr_shared_library

坏了，这题目编译不明白了开始

直接 gh 上拿了… 懒得研究了…

从 so 里面导入的 check：

直接看官方 exp 吧（也就是做了个模拟，不过这个挺经典的感觉，后面单独模拟函数会很用得上）：

# The shared library has the function validate, which takes a string and returns

---

莫名其妙的下面变成 pwn 题了…

# -pwn-

# 15_angr_arbitrary_read

乍看一下就很怪了，只得翻 exp，发现是用 pwn…

那这里到了期待已久的 auto pwn 环节哩