[angr] Angr and program traces
zardus at gmail.com
Thu Oct 27 08:05:49 PDT 2016
The statements and actions do, indeed, map to VEX IR statements. However,
one of the VEX IR statements is the IMark statement, which marks the
beginning of a native instruction. If you are looking at a VEX IRSB, any
given non-IMark statement "belongs" to the preceeding IMark statement.
Once you have the instructions delineated, you can do two things: recover
the operands by analyzing the actions of the corresponding statements to
understand what was read and written by each instruction, or disassemble
the instruction and analyze the disassembly to understand what the operands
are. It sounds like you already know how to do the former, and that's what
you'd need to do to recover the actual values read and written. If you're
just interested in the operand definitions, you can get the disassembly
(through capstone) for the latter method by doing:
Finally, you can do a step-by-step execution by passing extra arguments
into path_group.step. These extra arguments end up getting passed into
`project.factory.block`. Specifically, `path_group.step(num_inst=1)` will
execute a single instruction.
PS. From a philosophical perspective, we've tried to avoid primarily
designing angr toward any single technique. In general, if you find it
difficult to do anything and it seems like the functionality that you're
trying to use was designed for something else, we'd really appreciate
hearing about it (as in this case) so that we can try to find a way to
support what you're trying to do!
PPS. If you're at CCS, you should come say hi!
On Thu, Oct 27, 2016 at 4:31 PM, Mike (Mihai) Enescu <mihai.enescu at inria.fr>
> We've been trying to use angr to perform some dynamic analysis, in
> particular analysis of program traces. We understand that angr is
> primarily(?) designed for symbolic execution, and we've found it to be
> excellent for that, but we also need to be able to deal with traces and
> we're having some trouble on that front.
> One thing we'd really like to do is to execute a binary and trace the
> instructions (the instructions in the original architecture).
> Specifically, let's say the original binary is x86. We'd like to be able
> to step through the binary with angr acting as a debugger, and trace the
> exact x86 instructions that get executed. So far, we've somewhat been able
> to see corresponding VEX IR instructions if we get SIRSB's, statements,
> actions, etc from the higher level (project, path, pathgroup, state)
> interfaces. However, the angr docs advise against directly
> using/manipulating Simuvex objects and the lower-level interfaces, instead
> suggesting that almost everything can be done from its higher-level
> structures (paths, pathgroups and so forth). Even if we go to that depth,
> we're not quite sure how to map statements/actions (which I believe
> correspond to VEX-IR instructions?) to instructions in the original
> architecture (and I imagine it would be somewhat difficult even with angr
> optimizations turned off that might make this even harder)
> Is there a simple way to execute code step-by-step (where by step I mean a
> single instruction in x86, rather than basic blocks, or VEX-IR
> instructions) and extract (1) what the instruction is (pushl, addl, and so
> forth), and (2) any operand values to the instruction as it executes? Is
> angr the right tool for such analysis, or do you recommend using it more
> for symbolic execution rather than in the way we describe?
> Apologies if the answer is obvious but we just simply haven't found it or
> read the docs to enough depth.
> - Mike
> angr mailing list
> angr at lists.cs.ucsb.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the angr