-
Notifications
You must be signed in to change notification settings - Fork 124
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
Unable to analyze ARM64 / ARM bare metal image #294
Comments
My standard test file for bare-metal analyses still works and it is also an ARM binary. So I will need more information to debug this. Can you share the bare-metal-config file that you used? Ideally, can you also share a binary where the error occurs? Although I know that it is often not possible to share binaries. |
If this is the same test from bare_metal_samples dir, it is a bin file (probably a raw memory dump). I am trying to execute with ELF. Anyway here is the json file I tried with (though as I pointed above the results were the same when the config file was not supplied) : { |
Hmm, your config file seems fine. Yes, the bare-metal-config option is meant for raw memory dumps and the like. But you should not use it for ELF files (where it is unnecessary anyway). But if you have the same problem in any combination then it does not seem to be related to the bare-metal-config option anyway. Since I cannot reproduce your problem on my end, I can only guess that something is wrong with either your installation of Ghidra or the cwe_checker. You could try to cleanly remove both (use |
Hi, yes, I tried to run without the bare metal option with the exact same
result. Please note though that ELF is a standalone embedded device image
rather than a Linux compiled application. And yes, unfortunately I can't
share it.
But I can try to produce more meaningful logs if you tell me how. I tried
the verbose option, it didn't gave any additional info.
I am working with latest wsl2 under windows 11. Cwe checker works fine for
Linux compiled applications, but so far I wasn't able to run it on neither
of the embedded ELF images I have.
I tried to run with docker (latest) and also directly on wsl2 with latest
main and latest freshly installed Ghidra. The results are the same. Ghidra
itself is working fine if run directory with GUI option.
Perhaps I can first try to run Ghidra in headless mode to produce that IR
representation your program uses and make sure it works properly. Can you
explain me how to do this the exact same way cwe checker does?
Thanks in advance
…On Fri, Mar 4, 2022, 08:21 Enkelmann ***@***.***> wrote:
Hmm, your config file seems fine.
Yes, the bare-metal-config option is meant for raw memory dumps and the
like. But you should not use it for ELF files (where it is unnecessary
anyway). But if you have the same problem in any combination then it does
not seem to be related to the bare-metal-config option anyway. Since I
cannot reproduce your problem on my end, I can only guess that something is
wrong with either your installation of Ghidra or the cwe_checker. You could
try to cleanly remove both (use make uninstall for the cwe_checker) and
then reinstall them. And maybe make sure that you use the newest master
branch of the cwe_checker. The other possible reason I can think of could
be an unsupported system on which you are running the cwe_checker. What OS
are you using?
—
Reply to this email directly, view it on GitHub
<#294 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AL5WPHVSC7VYAHQ3ZHZ3BFTU6GTYHANCNFSM5P2QWR4Q>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
So the file format you mean is not the Executable and Linkable Format? Regardless, the cwe_checker should not crash when using the bare-metal-option on any file format, so it is still a bug in the cwe_checker. Ok, your environment seems to be fine, the cwe_checker works for other files... So I have to guess again that it is a bug related to the particular files you try it with. |
So the file format you mean is not the Executable and Linkable Format? Regardless, the cwe_checker should not crash when using the bare-metal-option on any file format, so it is still a bug in the cwe_checker. The file format is ELF, I only said that it is not a Linux application but rather standalone image compiled for the embedded target. Also, we already agreed that "bare-metal" is not an issue here, since same result occurs regardless whether this option is used. I've added some prints into main.rs, just before Ghidra headless execution and immediately after. Here are the results : andrey@andrey-n1 ~/R/p/cwe_checker_test [1]> cwe_checker security.abs The output was: INFO Using log config file: jar:file:/home/andrey/Reverse/ghidra_10.1.2_PUBLIC/Ghidra/Framework/Generic/lib/Generic.jar!/generic.log4j.xml (LoggingInitialization)
|
Ok, it seems that the crash is due to a varnode in Ghidra P-Code that is marked as a register but has no name. The next step in debugging this would be to find out for which assembly instruction this happened and look at the raw P-Code generated for that instruction. For this one could add some debug printing to the By the way, the reason why the cwe_checker crashes for all your examples is probably that they all contain the same specific assembly instruction that our P-Code-extractor cannot handle yet. As another side note: When you have bare-metal samples in the ELF file format you do not need the |
No worries, we will debug this together :) I've added the following print to createDefTerm just before the call to createVariable : Here is the log : DEBUG: looking at instruction (register, 0x4048, 8) COPY (unique, 0x11f80, 8) So the issue is with Could it be that this is a unique combination of parameters not currently supported ? |
Thank you very much, this should be enough information for me to develop a fix! I do not know yet whether I can solve this with a quick fix or whether this needs some larger code refactoring to be properly solved, so no promises on how long it will take me to fix it. The thing that is not supported by the cwe_checker is It would be interesting to know what instruction caused this P-Code to be generated. Normally I would expect an |
Ghidra process is terminated while analyzing AARCH64 bare metal image (same result for ARM as well) :
Execution of Ghidra plugin failed: Process was terminated.
INFO REPORT: Save succeeded for file: /security.abs (HeadlessAnalyzer)
INFO REPORT: Post-analysis succeeded for file: /input/security.abs (HeadlessAnalyzer)
The text was updated successfully, but these errors were encountered: