-
Notifications
You must be signed in to change notification settings - Fork 104
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
Running ThumbsUp on raw firmware binaries #41
Comments
Thanks for the detailed issue report. Will start working on it right away. |
I couldn't reproduce the error with struct.unpack("L") expecting 8 bytes instead of 4 bytes. I guess it comes from the type "long" which varies in size, but Python's documentation (in all version) specify this format is being fixed 4 bytes. Instead of just changing it to "I" (int) I'm trying to check this and hopefully notify Python that they need to update their docs. Could you elaborate on your exact setup and versions:
|
NVM, their documentation was just not clear enough. "L" indeed stands for "long" which is used as "sizeof(long)", hence varies in size. |
The firmware is ARM v7 little endian and mostly (only?) Thumb mode. A few examples are available here: https://github.com/seemoo-lab/polypyus/tree/master/examples/history I used IDA 64bit but with 32bit analysis. |
sark was pinpointed to 2.0 when moved to Python3. As sark is now more developed, we can use the latest version withouta Python issues. Solves one of the cases in issue CheckPointSW#41.
Although python's documentation says otherwise, the "L" format stands for long, and could be 4/8 bytes, depending on the compilation. Changed it to use "I" (int) so the size will be 4 bytes fixed. Fixes a bug reported in issue CheckPointSW#41.
Fixes the main bug in issue CheckPointSW#41. When there was only 1 active code type (THUMB) and we were scanning a line from the other code type (ARM) we triggered an exception. Scanned the code to make sure no prediction will be made on code types which are not active at the moment of the decision.
Bug fix for issue CheckPointSW#41 in upstream repository
This pull request fixed all the bugs listed in this issue, at least on my setup. If any of the bugs persist, please feel free to re-open this issue. |
Thank you very much for this fast fix :) The initial error is gone. But it still breaks on the Thumbs Up stage #4 with this message, on both
|
Sorry for the late response, I saw the notification just now. The code already supported predicting only the single-supported code type, so that this exception will be avoided. The bug is that I accidentally checked the cpu's supported types list instead of the active supported list. I'm now testing the patch to check that nothing breaks, and hopefully it will be committed very soon. |
It would be great if I could add your sample to my test suite. If this is indeed a file from https://github.com/seemoo-lab/polypyus/tree/master/examples/history, could you please share the *.idb / mapping instructions to IDA + list of code segments and data segments as printed out by Thumbs Up? |
Used the wrong function when handled a single active code type. Fixes issue CheckPointSW#41.
Yay, it's working now :D Two hours before the deadline, should still work. I'll send you the results, detailed setup, etc. later :) |
Hi,
I encountered the a few issues when running the Thumbs Up script with the following configuration:
The requirement sark==2.0 could not be installed, so I replaced it in the install script and just took the most recent one from GitHub, which was 7.8. This might already be the source of my subsequent errors ;)
Fixed this by replacing line 68 with
numpy.random.seed(1337)
and it worked.Console output in IDA continues as follows:
Got the following error displayed in IDA:
IDA still continues automatic analysis afterward. Not sure if it worked or didn't. The results are definitely better than after just running a linear analysis on the ROM :)
The text was updated successfully, but these errors were encountered: