[angr] memory write tracking

Audrey Dutcher audrey at rhelmot.io
Sun Mar 25 04:05:56 PDT 2018


pass num_inst=1 to the step or run commands

On Sun, Mar 25, 2018 at 4:05 AM, alessandro mantovani <alk13 at hotmail.it>
wrote:

> Hi all,
>
> Ok, so, what I have to do in order to perform instructions steps (and not
> block steps)? Is it possible?
>
> Thanks,
>
> elmanto
>
> On 23/03/2018 21:57, Audrey Dutcher wrote:
>
> 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: https://docs.angr.io/
> docs/pipeline.html
>
> 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.
>
> Thanks,
> - Audrey
>
> On Fri, Mar 23, 2018 at 4:47 AM, alessandro mantovani <alk13 at hotmail.it>
> wrote:
>
>> 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/20180325/64c5425f/attachment-0001.html>


More information about the angr mailing list