stage0
rizin
stage0 | rizin | |
---|---|---|
22 | 46 | |
888 | 2,436 | |
- | 2.0% | |
3.9 | 9.8 | |
3 months ago | 6 days ago | |
Assembly | C | |
GNU General Public License v3.0 only | 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.
stage0
- Running the "Reflections on Trusting Trust" Compiler
- Stage0: A minimal bootstrapping path to a C compiler capable of compiling GCC
- Goodbye to the C++ Implementation of Zig
- Stage0 – A set of minimal dependency bootstrap binaries
-
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.
[0]:https://github.com/oriansj/stage0
-
"Do you believe that every upstream project... is examined by an expert who can accurately identify whether said project contains malware...?"
https://www.bootstrappable.org/ has some good info. Reading the source of https://github.com/oriansj/stage0 is also very enlightening. It's set its goal to be understandable by 70% of programmers.
- Stage0 - A set of minimal dependency bootstrap binaries
-
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.
-
How To Build an Evil Compiler
One countermeasure not mentioned here is bootstrapping a compiler with a program small enough to be manually verified. The stage0 project is under 1KB (small enough that the binary can be, and has been, manually checked against the hand written assembly), and GNU Guix (a system for reproducible, isolated builds) is currently working on moving it's bootstrap speed to stage0. That means that, fairly soon, there will be a large set of software that doesn't have a connection to an original C compiler.
- A minimal C compiler in x86 assembly
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
[2] https://github.com/rizinorg/rizin/releases/tag/v0.7.0
- 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].
[1] https://rizin.re/
[2] https://binaryanalysisplatform.github.io/bap/api/master/bap-...
[3] https://github.com/rizinorg/rizin/blob/dev/doc/rzil.md
-
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
[2] https://github.com/rizinorg/rizin
[3] https://cutter.re
[4] https://github.com/rizinorg/cutter
- Rizin – Free and Open Source Reverse Engineering Framework
-
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
[2] https://github.com/rizinorg/rizin
[3] https://github.com/rizinorg/rizin/labels/RzDebug
- Rizin release 0.6.2
-
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.
- Rizin release v0.6.1
-
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/
[2] https://rizin.re/posts/gsoc-2022-rz-bindgen/
[3] https://github.com/rizinorg/rizin/blob/dev/doc/rzil.md
What are some alternatives?
arocc - A C compiler written in Zig.
radare2 - UNIX-like reverse engineering framework and command-line toolset
chibicc - A small C compiler
ghidra - Ghidra is a software reverse engineering (SRE) framework
libcperciva - BSD-licensed C99/POSIX library code shared between tarsnap, scrypt, kivaloo, spiped, and bsdiff.
cutter - Free and Open Source Reverse Engineering Platform powered by rizin
bug - Scala 2 bug reports only. Please, no questions — proper bug reports only.
r2ghidra - Native Ghidra Decompiler for r2
c4 - C in four functions
Kaitai Struct - Kaitai Struct: declarative language to generate binary data parsers in C++ / C# / Go / Java / JavaScript / Lua / Nim / Perl / PHP / Python / Ruby
pkgconf - package compiler and linker metadata toolkit
rz-ghidra - Deep ghidra decompiler and sleigh disassembler integration for rizin