[angr] memory write tracking

Audrey Dutcher audrey at rhelmot.io
Fri Mar 23 13:57:22 PDT 2018

comparison with `is` will work, since ASTs are designed to have object
identity. You could also say claripy.is_true(x == y) for each of the
elements of the list, since the error is thrown by python's evaluation of
the result of x==y for truthiness, not the evaluation in the first place.

There's very little difference between step and run. run just calls step
many times. Take a look at this document to understand what's happening
under the hood in simulation manager:

Keep also in mind that steps are basic block steps, not instruction steps,
so you're seeing a list of block addresses, not instruction addresses.

- Audrey

On Fri, Mar 23, 2018 at 4:47 AM, alessandro mantovani <alk13 at hotmail.it>

> Hi all,
> Sorry for the inaccuracy. I think that there are some problems:
> 1) w.r.t. the script I attached, the list named "list_of_write" contains
> <BV32> objects. For each step, the eip also contains <BV32> objects. If I
> try to compare them with "==" an exception is thrown which says:
> "ClaripyOperationError('testing Expressions for truthiness does not do
> what you want, as these expressions can be symbolic')". I replaced "=="
> with "is" (i.e. I use "if eip is write:") but I don't know if this is the
> correct way to compare two <BV32> objects. What is the correct way?
> 2) I used the "while(len(simgr.active) !=0)" as method to run the symbolic
> execution of the binary (as alternative to the run() method), so that I can
> handle the eip for each step (and for each state). Just to check if this
> works correctly I collected all the different eip in a list named
> "list_of_eip". When the execution ends, the "list_of_eip" contains only few
> <BV32> objects (only 46 values of eip, too few in my opinion). So probably
> I'm not exploring all the states of the binary, I suppose. Are there other
> methods (differently from run()) to execute the binary step by step?
> I think that the main problem is that eip doesn't explore all the possible
> space. Obviously I tested the script with different binaries which use
> packer (i.e. firstly they write to memory and secondly they execute the
> written memory) but in no case the expected behaviour is met.
> Thanks,
> elmanto
> On 22/03/2018 17:09, Yan wrote:
> Hello,
> Can you elaborate? "It doesn't work" doesn't give us enough information to
> go on, and we don't have time to investigate.
> From a quick look at your script, I would start by looking at what the
> values are in your list, and what your eip is.
> - Yan
> On Thu, Mar 22, 2018 at 6:42 AM, alessandro mantovani <alk13 at hotmail.it>
> wrote:
>> Hi all,
>> I'm implementing a script to detect all the memory write operations which
>> modify an address which is then executed (i.e. the mechanism behind the
>> packers). The code I wrote works as follows:
>> 1) I set a breakpoint for each 'mem_write' with an action func which
>> stores the attribute 'mem_write_address' (through
>> 'state.inspect.mem_write_address') into a list
>> 2) I continue execution. For each step() , I check that the current ip
>> matches with an address contained in the list (i.e. if the current ip is an
>> address which has been written before)
>> Unfortunately it doesn't work and I think that it could be a problem
>> related to the symbolic representation of the state. I attach a script so
>> that you can see the code I just explained.
>> Thanks,
>> elmanto
>> _______________________________________________
>> angr mailing list
>> angr at lists.cs.ucsb.edu
>> https://lists.cs.ucsb.edu/mailman/listinfo/angr
> _______________________________________________
> angr mailing list
> angr at lists.cs.ucsb.edu
> https://lists.cs.ucsb.edu/mailman/listinfo/angr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cs.ucsb.edu/pipermail/angr/attachments/20180323/4d780019/attachment.html>

More information about the angr mailing list