angr
When the address of the trace returned by QEMURunner does not match the address executed by unicorn
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?
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?