Open coderjingluo opened 4 months ago
This is a well known problem - when tracing with basic block addresses, implementations will very frequently disagree in myriad ways about what basic block boundaries are. Our attempt at working around this problem lives in https://github.com/angr/angr/blob/master/angr/exploration_techniques/tracer.py, which tries to force angr (i.e. unicorn+vex basic blocks) to follow a qemu-user trace. However, most people have given up on account of it is just too hard.
This is a well known problem - when tracing with basic block addresses, implementations will very frequently disagree in myriad ways about what basic block boundaries are. Our attempt at working around this problem lives in https://github.com/angr/angr/blob/master/angr/exploration_techniques/tracer.py, which tries to force angr (i.e. unicorn+vex basic blocks) to follow a qemu-user trace. However, most people have given up on account of it is just too hard.
This is a well known problem - when tracing with basic block addresses, implementations will very frequently disagree in myriad ways about what basic block boundaries are. Our attempt at working around this problem lives in https://github.com/angr/angr/blob/master/angr/exploration_techniques/tracer.py, which tries to force angr (i.e. unicorn+vex basic blocks) to follow a qemu-user trace. However, most people have given up on account of it is just too hard.
If qemu_runner use qemu to generate trace, let him generate more context information about the block, when the execution branch is inconsistent with the trace, fallback state and set the context information corresponding to the block in the trace to the state, can it alleviate this situation?
It can. However you will still find the horrors lurking.
Question
In practical applications, the trace returned when I use QEMURunner has inconsistent branches in simgr.step, but the input provided is the same. Why?