-
Notifications
You must be signed in to change notification settings - Fork 162
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
basic block tracing broken #68
Comments
The issue of how to synchronize qemu and angr's differing notions of basic blocks is a perpetual headache for tracer. Tracer was refactored recently in order to make it less of a pile of spaghetti code and more extensible, and it looks like we lost track of whatever trick we were using beforehand to solve this particular edge case. The tracer refactor mostly tried to make explicit each edge case that would need to be synchronized. If you look into |
Inside The jumpkind gets detected as Would a |
I'm having similar issue. I'm using the shellphish/mechaphish docker image and very simple example compiled with gcc. The code is executed with
Any Idea what the issue can be? |
I already asked for help on this topic before in the slack help
channel. Then I
tried to use driller for Linux ELF binaries. Now I am running it against the
CGC challenge and also documented the process a lot more verbose.
The official driller example looks
similar to the code snipped I used. In order to test different binaries the
path to the target binary has to be changed accordingly.
Everything works nice when I use the
CADET_00001
challenge binary taken from the angr-doc repo.
Now. This is not true for
CADET_00001.2018-12-03
(see attached).This binary was built using the cgc-linux-dev box from darpa cgc repo.
After I added some extra debug output it looks like this.
rhelmot wrote "if the constraint is False it means it was a false comparison
between two concrete values, which is very scary".
A False constraint appears before we even enter the main function.
In the
CADET_00001.2018-12-03
binary the main function is not at the entrypoint, but there is some init function before it. For the testcase binary
CADET_00001
the entrypoint points sits right on it's main function.I patched
CADET_00001.2018-12-03
entrypoint from 0x080485fc to 0x08048601(now refered to as
CADET_00001.2018-12-03.fix
). This will skip the initfunction and go right into the main.
Driller seems to work fine on
CADET_00001.2018-12-03.fix
.All the init stub does is:
To my understanding only the lowest address of a basic block should be in the
trace. The last non-False entry in the log points at 0x08048731, this area does not
look like the beginning or end of a basic block.
The qemu trace logs 0x08048731.
When the
push eax; popfd
get nopped out everything works fine.If we leave the binary untouched but remove the address 0x08048731 from the
qemu_runner
trace it works too.So I guess driller/angr/vex/... don't like it when they get fed basic blocks
that aren't basic blocks? Where would I have to look next in order to fix this issue or
get it fixed?
Environment
I am using angr-dev, so the version of driller and its dependencies should be
fairly recent. The OS is Ubuntu 18.04 on amd64.
Files
zip contains all the mentioned CADET binaries
CADET_00001.zip
The text was updated successfully, but these errors were encountered: