-
Notifications
You must be signed in to change notification settings - Fork 310
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
Snowman should use a more sophisticated disassembly technique than linear #10
Comments
I agree. I would try something like:
The traversal I have already implemented once, although never got to actually using it: 7f1e836. The traversal constructs control-flow graph on the fly and uses DataflowAnalyzer to perform abstract interpretation, so, it should be able to tell you the jump destinations, in particular, switches from/to THUMB mode. One can take the above code as a starting point and do some experiments with it. |
Well couldnt this already piggyback on IDA? However a purely free ARM decompiler is welcomed. |
IDA already knows the ranges of addresses belonging to a function. Not sure, although, if it includes data into these ranges. If it does not, the IDA plug-in should not have problems with interpreting data as code. If it does, maybe we need to find where the instructions exactly are (IDA has getFlags() function for this), and update IdaFrontend::functionAddresses() to report only ranges of addresses containing executable code. But this does not dismiss the need in a better discovery of the code. |
Can you provide an example? |
are you speaking about stuff like ROP gadget ? |
Related: #14 (comment) |
Related: #51 |
Moreover #59 is an actual way to achieve this. |
No, it's not. |
ARM decompilation currently seems to suffer quite a bit from confusing code and data and this should help there.
There are lots of options for a better technique
The text was updated successfully, but these errors were encountered: