Sunset angr-targets #5147
Sunset angr-targets #5147
Conversation
|
I came across angr-targets, in looking for ways to have angr analyze binaries that have large pre-main procedures, and it is possible 1000x faster to have that code executed in GDB, instead of in angr. The best workaround I have found so far is to load a coredump, but it seems some properties such as memory regions and the program stack are not successfully recovered by the coredump. With angr-targets being sunset, are coredumps the intended way to mix concrete and symbolic execution, or is there something else? |
|
That is one option. Another option could be to try out the unicorn or icicle engines in angr, which can do concrete execution much faster than angr can execute vex by itself. A third option, depending on the nature of the pre-main procedure, is to model some of the code as a SimProcedure, executing that in place of emulating the pre-main procedure. If you could post a sample script and binary demonstrating what you are trying to do, I would be happy to try to help see what optimizations could be done. |
|
Please, if you remove a feature from the code, remove it from documentation as well. I have spent a whole day trying to setup cross-architecture GDB runner only to discover the functionality was sunset. There is still |
|
Noted, I am removing those now: #5649 |
|
Could you please also add a note to the angr-targets repo that it's not supported by upstream angr anymore. I just tried to get it working until I realized that the feature was removed. You may merge this if you like: https://github.com/nbars/angr-targets Also, adding a note here https://angr.io/blog/angr_symbion/ would probably save some people a lot of time. Thanks :) |
|
It looks like Symbion or something like Symbion are still being used by users and attracting interest from the community. Can someone please elaborate on the exact use cases? This will help us decide if we want to implement a new feature that complements the missing piece(s). |
|
Same as @konchunas, I wanted to use angr for a heavy target (V8) to perform some localized symbolic execution, which the gdb approach seemed to be quite suitable for. Using unicorn unfortunately fails with some Can I build a memory proxy as a plugin that resolves memory access dynamically, such that I can return concrete values (retrieved from the target) the first time they occur? So basically the way symbion did but far less features and without changes to the |
|
Yes it should be possible to write a memory mixin that can retrieve values from a device as you describe. Another potential option is that I have recently implemented an Icicle emulator based engine in angr intended for fast concrete execution. I would be interested to know if it could potentially be useful here. It should be faster than unicorn and any errors during execution I would be happy to take a look at to see if they can be corrected. |
|
Just tested it using the snippet below: I am getting complaints about missing registers, which is kind of odd, at least for Even though it seems to terminate, I can not get the output of the target. Do I need some other flags?: I guess I should create a separate issue when I get some time to look into whether anything actually happened and, if not, why. Thanks! |
|
The debug warnings are as expected, vex tends to have a lot of "extra" registers it uses for its own purposes, or aliases to another register. The segment registers (cs, ds, es) are unused in x86-64, and are not implemented in the sleigh specs which is why you see those errors. Regarding the output, I am unsure. We have a test in CI that ensures posix stdout works on our test binary. A separate issue with instructions to reproduce the issue would be great. |
I would like to sunset angr-targets, removing this code from angr and archiving the angr-targets repo, removing it from CI. The code has not been developed in many years, and is largely untested. Further, the way it works isn't really aligned anymore with how angr is used to do analysis on embedded systems binaries, such that it likely doesn't have a future. This decision could always be reversed some day if this becomes an active research topic again.
This is motivated by my interest in refactoring the engine interface to improve type correctness and remove kwargs; and removing unmaintained engines should make that process less difficult.