rizin
stage0
Our great sponsors
rizin | stage0 | |
---|---|---|
44 | 22 | |
2,376 | 869 | |
3.6% | - | |
9.8 | 3.9 | |
6 days ago | about 2 months ago | |
C | Assembly | |
GNU Lesser General Public License v3.0 only | GNU 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.
rizin
- 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...
-
Short Guide to Loading Legacy U-Boot Images in Ghidra (How to Determine CONFIG_SYS_BASE_ADDR)
This command has been available since rizin 0.4.0 (https://github.com/rizinorg/rizin/releases/)
stage0
- Running the "Reflections on Trusting Trust" Compiler
- Goodbye to the C++ Implementation of Zig
-
Nixpacks takes a source directory and produces an OCI compliant image
Somewhat tangential, but I'm curious how big the bootstrap seed for Nix is. That is, if you wanted to build the entire world, what's a minimum set of binaries you'd need?
Guix has put quite a bit of work into this, AFAIU, and it's getting close to being bootstrappable all the way from stage0 [0]. Curious if some group is also working on similar things for Nix.
-
Common libraries and data structures for C
Even if they aren't, people absolutely should be able to bootstrap new platforms from scratch. It's important to have confidence in our tools, in our ability to rebuild from scratch, and to be safe against the "trusting trust" attack among other things.
Lately I've been catching up on the state of the art in bootstrapping. Check out the live-bootstrap project. stage0 starts with a seed "compiler" of a couple hundred bytes that basically turns hex codes into bytes while stripping comments. A series of such text files per architecture work their way up to a full macro assembler, which is then used to write a mostly architecture-independent minimal C compiler, which then builds a larger compiler written in this subset of C. This then bootstraps a Scheme in which a full C compiler (mescc) is written, which then builds TinyCC, which then builds GCC 4, which works its way up to modern GCC for C++... It's a fascinating read:
https://github.com/oriansj/stage0
https://github.com/fosslinux/live-bootstrap/blob/master/part...
Even if no one is "using" this it should still be a primary motivator for keeping C simple.
- A minimal C compiler in x86 assembly
- My boundaries as an open source developer
-
Bitcoin v22.0 and Guix; Stronger defense against the "Trusting Trust Attack"
Stage0 Project
- Trojan Source: Invisible Vulnerabilities
-
Trustworthy Computing in 2021
It's great to see that more people are still working on this and that people have an interest.
If you are interested in this kind of thing, then you'll also want to check out LibreBoot[1] and Bootstrappable Builds[2]. The latter is working with stage0 [3] and mes [4] to bootstrap Guix (among other projects.) All of that is further down the chain, but we'll need it if we want to build trustworthy systems.
2. https://www.bootstrappable.org
-
[Rust advocates] demean software that's not memory safe the way that politicians use their words to sow anger. C has won, and Rust blew it's shot aiming at C++ instead.
Bootstrap compiler != PL compiler. See also stage0. Compiler can be cross-compiled to architectures, whereas a bootstrap compiler can not. For other differences see the stage0 repository.
What are some alternatives?
radare2 - UNIX-like reverse engineering framework and command-line toolset
ghidra - Ghidra is a software reverse engineering (SRE) framework
cutter - Free and Open Source Reverse Engineering Platform powered by rizin
r2ghidra - Native Ghidra Decompiler for r2
Kaitai Struct - Kaitai Struct: declarative language to generate binary data parsers in C++ / C# / Go / Java / JavaScript / Lua / Nim / Perl / PHP / Python / Ruby
rz-ghidra - Deep ghidra decompiler and sleigh disassembler integration for rizin
efiSeek - Ghidra analyzer for UEFI firmware.
cgdb - Console front-end to the GNU debugger
unfuck - Python 2.7 bytecode d̶e̶o̶b̶f̶u̶s̶c̶a̶t̶o̶r unfucker
arocc - A C compiler written in Zig.
elfcat - ELF visualizer. Generates HTML files from ELF binaries.
chibicc - A small C compiler