SimEngineError raised because control flows to locations determined by the input PoV

Describe the bug.

When tracing a CGC binary using it’s PoV, control flows to invalid memory locations without any code at the location causing the tracing to stop with a SimEngineError. A cursory analysis of concrete execution of the CGC binary using the PoV in qemu reveals the crash is expected behaviour: the input somehow influences the control flow and causes the binary to crash.

Environment Information.

Platform: linux-x86_64 Python version: 3.8.5 (default, Jan 27 2021, 15:41:15) [GCC 9.3.0] ######## angr ######### Python found it in /home/dnivra/angr-dev/angr/angr Pip version angr 9.0.gitrolling Git info: Current commit 762becbf9c66d4798b8c23cfa512a7f893e2bcf9 from branch master Checked out from remote origin: https://github.com/angr/angr ######## ailment ######### Python found it in /home/dnivra/angr-dev/ailment/ailment Pip version ailment 9.0.gitrolling Git info: Current commit 4e2bba6f0299d1eda6ae570ceabd91eb8a0c72be from branch master Checked out from remote origin: https://github.com/angr/ailment ######## cle ######### Python found it in /home/dnivra/angr-dev/cle/cle Pip version cle 9.0.gitrolling Git info: Current commit 80dcd50abfaa70cbd5b2e360fe41b71406acbfb4 from branch master Checked out from remote origin: https://github.com/angr/cle ######## pyvex ######### Python found it in /home/dnivra/angr-dev/pyvex/pyvex Pip version pyvex 9.0.gitrolling Git info: Current commit 969ec1f10d3e3b15407ee986052aa4b6f2e9df05 from branch master Checked out from remote origin: https://github.com/angr/pyvex ######## claripy ######### Python found it in /home/dnivra/angr-dev/claripy/claripy Pip version claripy 9.0.gitrolling Git info: Current commit 34f31c487f7453f4666cd6fd1d529f417ff6ca08 from branch master Checked out from remote origin: https://github.com/angr/claripy ######## archinfo ######### Python found it in /home/dnivra/angr-dev/archinfo/archinfo Pip version archinfo 9.0.gitrolling Git info: Current commit 437b194538ccb0bf118b4b674613b88832b0b342 from branch master Checked out from remote origin: https://github.com/angr/archinfo ######## z3 ######### Python found it in /home/dnivra/.virtualenvs/angr-dev/lib/python3.8/site-packages/z3 Pip version z3-solver 4.8.9.0 Couldn’t find git info ######## unicorn ######### Python found it in /home/dnivra/.virtualenvs/angr-dev/lib/python3.8/site-packages/unicorn Pip version unicorn 1.0.2rc4 Couldn’t find git info ######### Native Module Info ########## angr: <CDLL ‘/home/dnivra/angr-dev/angr/angr/lib/angr_native.so’, handle 2cd33e0 at 0x7fe5c9a93220> unicorn: <CDLL ‘/home/dnivra/.virtualenvs/angr-dev/lib/python3.8/site-packages/unicorn/lib/libunicorn.so’, handle 2407f70 at 0x7fe5cf5cf1c0> pyvex: <cffi.api._make_ffi_library.<locals>.FFILibrary object at 0x7fe5d01de130> z3: <CDLL ‘/home/dnivra/.virtualenvs/angr-dev/lib/python3.8/site-packages/z3/lib/libz3.so’, handle 26679d0 at 0x7fe5cccdf340>

To Reproduce.

angr-bug-2664-error-repro-1.zip angr-bug-2664-error-repro-2.zip are two cases to reproduce this issue. In former, control ends up at 0x0(the value is read from a symbolic address). In latter, control ends up at 0xb7ffdb04(tracing this takes quite a while. Edit: ~30 mins till SimEngineError occurs) and then crashes. I’m not sure how control ends up there: I observe the same when running the binary on concrete PoV bytes in qemu.

[rhelmot]

I can reproduce your error. It looks like it’s executing input as code, which is what’s causing the discrepancy. In order to run this kind of code properly you have to create the project with self-modifying code support enabled (I added binary_project_bow.fire(project_kwargs={'support_selfmodifying_code': True}) after the creation of binary_project_bow). However this makes the trace desync much earlier. Perhaps this is because turning on support for self-modifying code force-disables IR optimization, which could cause issues when re-executing code?

In any case, I think you can put this binary on the back burner. It traces correctly up until the last two steps, which are shellcode.

[dnivra]

Sorry about the delayed follow up on this. Can someone try running the second test case I shared above to see if that works correctly? When I ran it, I got a SimEngineError and so I’m suspecting the issue in that binary is probably not yet fixed. It takes a while till it crashes with SimEngineError(~30 minutes IIRC).