ghidra
rizin
Our great sponsors
ghidra | rizin | |
---|---|---|
126 | 46 | |
47,446 | 2,413 | |
2.2% | 3.6% | |
10.0 | 9.8 | |
1 day ago | 5 days ago | |
Java | C | |
Apache License 2.0 | GNU Lesser General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
ghidra
-
Dogbolt Decompiler Explorer
Binary Ninja likewise is empty and keeps up just fine as well. It's not a coincidence that the two commercial products that are funding it are both confident enough to put their stuff online like this.
And it's no conspiracy theory or intentional sandbagging, you can see the implementation: https://github.com/decompiler-explorer/decompiler-explorer
and if anyone can improve the other tools performance we'd be happy to accept it. We reached out to the Ghidra devs: https://github.com/NationalSecurityAgency/ghidra/issues/5228 but they didn't have any silver bullets for us either.
-
Show HN: Ghidra Plays Mario
> I’m not clear on if the bugs you are finding are in Ghidra’s processor model or in the emulator? (Though I think it’s the latter?)
The project README includes a link to a commit fixing bugs in Ghidra's processor model, here is the author's PR submitting those fixes upstream: https://github.com/NationalSecurityAgency/ghidra/pull/5740
Nice, I'll give it a closer look. My only concern so far is memory hooking (still needed for hardware registers), which on Java side was called by FilteredMemoryState [1]. In memstate.cc it looks like just the simpler MemoryState is implemented [2], and there's no equivalent to MemoryAccessFilter. But it might not be that complicated to add...
[1]: https://github.com/NationalSecurityAgency/ghidra/blob/4561e8...
[2]: https://github.com/NationalSecurityAgency/ghidra/blob/4561e8...
- Debugger Ghidra Class
- Ask HN: What's the best open source alternative to IDA Pro?
- Ghidra 10.3 released (with Dark Mode).
-
Ask HN: Most interesting tech you built for just yourself?
I tried to upstream some of my refactorings/modifications to support this, but it was rejected by upstream [1]. I don't blame the Ghidra project for this decision ; my modifications are fairly intrusive (modifying the relocation table after the initial load, extensive refactoring of the ELF support code...) and my workflow is essentially unproved in public.
By that I mean I have no documentation, no series of technical articles describing this process and no public, non-trivial project to demonstrate it in real life. I do have a currently private decompilation project that uses this successfully [2], but it's not currently public and it's nowhere near finished.
Also, I only wrote a relocation synthesizer for statically-linked, 32-bit, little endian MIPS ELF. That's a fairly obscure platform, I'd expect most people care about mainstream instruction sets like x86_64 or ARM64.
If you can suggest a forum where people would be interested in this, I can drop a message there and answer more in-depth questions if you want. So far I've worked on this all on my own and I'm kinda out of the loop from the rest of the reverse-engineering community.
[1] https://github.com/NationalSecurityAgency/ghidra/pull/5010#i...
-
NSA Ghidra software reverse engineering framework
https://github.com/NationalSecurityAgency/ghidra/issues/382
3. Airgaps may be broken by ultrasound side channels; communication to compromised devices like smartphones is possible (see: speaker-to-gyroscope communication https://ieeexplore.ieee.org/abstract/document/9647842/ ; speaker-to-speaker communication https://arxiv.org/pdf/1803.03422.pdf)
4. Low bitrate data leaks, like "ghidra is running in this org, decompiling files named....." may be accumulated by the NSA
This is just zero-day warehousing and passive signals collection with embedded zerodays. It would be hard for security researchers to detect this. I'd happily change my mind if you showed me an audit that looks for beacons and other side channels.
II. The audits
Here is the one audit I could find
https://github.com/NationalSecurityAgency/ghidra/issues/382
This audit tells us that the code is janky, but doesn't tell us if it's secure. It's just a dump of thousands upon thousands of static analysis errors.
There's no threat anaylsis in this audit. All it suggests is that the code has so many defects that a serious security audit will very expensive to perform.
III. Change my mind with evidence
Please link me to the "heavy audits" of the code that you think should exist. I couldn't find them. Surely you were not bullshitting me. Surely not?!
tldr;; I think this code is less heavily audited than you can support.
> RE'd ghidra
What, like, read the source code [1] or reverse engineered a binary? Would be easy(ish) to tell if the code in the binary was different from the source, probably.
rizin
-
Refix: Fast, Debuggable, Reproducible Builds
Just for the record, for nicer inspection of files with such debug information, including compressed sections, and debuginfod support, Rizin[1] can be used, since starting from the 0.7.0 release[2] all of those were added.
[1] https://rizin.re
- LLM4Decompile: Decompiling Binary Code with LLM
-
Revng translates (i386, x86-64, MIPS, ARM, AArch64, s390x) binaries to LLVM IR
Rizin[1] is also able to uplift native code to the new RzIL, which is based on the BAP Core Theory[2] and is essentially an extension of SMT theories of bitvectors, bitvector-indexed arrays of bitvectors and effects[3].
[2] https://binaryanalysisplatform.github.io/bap/api/master/bap-...
-
The Hiew Hex Editor
Everything Hiew can do, Rizin[1] can do too, and is completely free and open source[2] under LGPL3 license. Moreover, it supports more architectures, platforms, and file formats, as well as GUI in Qt - Cutter[3][4]. If something is missing in Rizin but presented in Hiew, please let us know by opening the issue with details.
[1] https://rizin.re
-
Show HN: I spent 6 months building a new C debugger as a 17-year-old
This is precisely what we are trying to do at Rizin[1][2]. Though the primary goal of the tool/framework is static analysis. All that portability across OSes, their versions, platforms and architectures, etc is definitely hard. If anyone is interested in these subjects, all contributions are welcome. For example, check out our "RzDebug" label, marking debugging issues[3].
[1] https://rizin.re
-
If you're interested in eye-tracking, I'm interested in funding you
Okay, so, your comment about a "Dasher + Guitar Hero music theory/improvisation practice program" just sent me down a huge rabbit hole...
Well, rabbit hole(s) plural, I guess, most not directly related. :D
Largely because I made the "mistake" of looking at your HN profile & discovering you're also in NZ & we seem to have somewhat overlapping interests (and an affinity for "bacon" in account names, apparently), so, some thoughts[0]... :)
# Topic 1: Nissan Leaf VSP hacking
After reading your recent posts (https://ianrrees.github.io//2023/07/03/vsp-hacking.html & https://ianrrees.github.io//2023/08/05/voltage-glitch-inject...) on this topic & noting your remark about wanting to try reverse engineering a firmware image, I found the following thesis PDF (via a brief google search for `"reverse engineer" "firmware" "Renesas"`):
* "AUTOMOTIVE FIRMWARE EXTRACTION AND ANALYSIS TECHNIQUES" by Jan Van den Herrewegen https://etheses.bham.ac.uk/id/eprint/11516/1/VandenHerrewege...
Not really what I was anticipating finding but seems relevant to your interests--I don't think it was already in your resource list.
While the thesis addresses the Renesas 78K0 rather than the Renesas 78K0R, from a brief look at the "Flash Protection" PDF Application Note in your resource list it seems there's a large overlap.
Perhaps most significantly the author presents "novel methods" that combine bootloader binary analysis with constraint-based power glitching in an effort to improve on the results described in "Shaping the Glitch".
While I haven't read the entire 186 pages :D they theorize that using their approach extracting 8kB firmware might only take ~10 hours.
And, most helpfully, they even published their source code under the GPL here: https://github.com/janvdherrewegen/bootl-attacks
So, an interesting adjacent read even if it turns out not to be directly applicable to your situation.
Given I have an interest in & a little experience with firmware reversing my original thought was to maybe provide some hopefully helpful references that more generically related to firmware reversing but more specific is good too, I guess. :)
In terms of reverse engineering tooling, I've used Rizin/Cutter/radare2 previously: https://rizin.re https://cutter.re
On the CAN tooling/info front, you might be interested in taking a look at my "Adequate CAN" list which I originally wrote-up for a client a couple years ago: https://gitlab.com/RancidBacon/adequate-can
Some other probably outdated reverse engineering tooling links of mine: https://web.archive.org/web/20200119074540/http://www.labrad...
In terms of how to approach RE, other than just "getting started & digging in" & learning by doing, I've sometimes found it informative to read other people's firmware reverse engineering write-ups to learn about potentially useful approaches/tools.
Anyway, hopefully some of this is helpful!
[0] I have a tendency to be a little... "verbose" and/or "thorough" (depending on one's POV :) ) so I'll probably split this over a couple of comments, in case I run out of steam while writing and for topic separation.
-
Veles – A new age tool for binary analysis
See our FAQ[1] on why we forked. As three years passed and both projects are actively developed, the divergence has grown a lot since. We aim for exposing the proper API instead of relying just commands, see e.g. our new Python bindings and rz-bindgen[2]. We have completely different concept of projects, new intermediate language - RzIL[3], and many other things. And under the new organization Cutter is a first-class citizen, not an afterthought as before.
[1] https://rizin.re/posts/faq/
-
Diaphora, the most advanced Free and Open Source program diffing tool
Rizin[1][2] provides basic diffing capabilities out of the box with the `rz-diff` tool. We plan to expose it in our GUI, Cutter, too, in the near future.
[1] https://rizin.re
-
Debugger Ghidra Class
There are many different technical differences that accumulated over time - we save projects as a state snapshot, not a sequence of commands[1], we save types as semantically connected structures in a database that is guaranteed to be consistent[2], use better stack tracking for arguments and variables[3], not SP/BP/whatever, slowly migrate to a new generation of IL - RzIL instead of ESIL[4], provide standard libraries signatures out of the box in the FLIRT format[5], switched to a new way of parsing and processing commands[6], provide basefind, and many other small differences.
[1] https://rizin.re/posts/introducing-projects/
[2] https://github.com/rizinorg/rizin/tree/dev/librz/type
[3] https://github.com/rizinorg/rizin/releases/tag/v0.5.0
[4] https://github.com/rizinorg/rizin/blob/dev/doc/rzil.md
-
Fq: Jq for Binary Formats
For this kind of task, using low-level debugger tools is probably better. Rizin[1][2]/Cutter[3][4] could help. We also have GSoC participant this year who works hard on improving debuginfo and debugging support[5]. I personally also like Binary Ninja, they recently made their debugger stable enough[6].
[2] https://github.com/rizinorg/rizin
[4] https://github.com/rizinorg/cutter
[5] https://rizin.re/posts/gsoc-2023-announcement/
[5] https://binary.ninja/2023/05/03/3.4-finally-freed.html#debug...
What are some alternatives?
radare2 - UNIX-like reverse engineering framework and command-line toolset
x64dbg - An open-source user mode debugger for Windows. Optimized for reverse engineering and malware analysis.
cutter - Free and Open Source Reverse Engineering Platform powered by rizin
r2ghidra - Native Ghidra Decompiler for r2
ret-sync - ret-sync is a set of plugins that helps to synchronize a debugging session (WinDbg/GDB/LLDB/OllyDbg2/x64dbg) with IDA/Ghidra/Binary Ninja disassemblers.
Kaitai Struct - Kaitai Struct: declarative language to generate binary data parsers in C++ / C# / Go / Java / JavaScript / Lua / Nim / Perl / PHP / Python / Ruby
ghidra-dark - Dark theme installer for Ghidra
Ghidra-Cpp-Class-Analyzer - Ghidra C++ Class and Run Time Type Information Analyzer
efiSeek - Ghidra analyzer for UEFI firmware.
rz-ghidra - Deep ghidra decompiler and sleigh disassembler integration for rizin