[angr] memory write tracking

Audrey Dutcher audrey at rhelmot.io
Tue Mar 27 15:29:29 PDT 2018


"while len(simgr.active) == 0" will result in you doing no stepping
whatsoever...

The technique to debug missed branches is to find the first address you
expect to see but don't and then figure out why angr thinks the condition
is unsatisfiable.

On Tue, Mar 27, 2018 at 5:07 AM, alessandro mantovani <alk13 at hotmail.it>
wrote:

> Hi all,
>
> I tried by passing num_instr=1. Now only single instructions are
> considered (and not blocks of instructions), and this is perfect. But for
> some reasons the script doesn't explore all the possible states.
>
> As before, I collected the values of the different eip for each step of
> execution and the list containing these values has a reduced size. Is it
> possible that angr doesn't explore some states in order to avoid state
> explosion? Another question: I used the statement "while(len(simgr.active)
> == 0" just to explore all the possible states. Is this method correct?
>
> Thank you and sorry for the stress,
>
> elmanto
>
> On 25/03/2018 13:05, Audrey Dutcher wrote:
>
> 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 snum_inst=1num_inst=1teps,
>> 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/20180327/d582a2f4/attachment.html>


More information about the angr mailing list