4

Rizin was forked from Radare2 several years ago, mainly due to human factors. At the time, there weren't any important differences in features between the two.

I understand that Rizin has rewritten much of the code, but that makes internal differences, not differences in features.

At this point: What features does Radare2 have that Rizin doesn't? What features does Rizin have that Radare2 doesn't? Assuming I just use the tool, and don't look at its sources, what differences, if any, will I notice?

(I'm referring to the command line tool, not the GUIs.)

3
  • 1
    I'm also interested in this and will probably also put out a bounty once yours expires. Feel free to remind me, in case I forget.
    – 0xC0000022L
    Sep 11, 2023 at 7:51
  • 1
    @0xC0000022L You are hereby reminded as asked ;-) Sep 18, 2023 at 2:46
  • Do you find the current answer acceptable (I found it quite comprehensive)? If not, please edit your question to clarify what aspects are missing and I will put out a bounty worth 100 rep. And yes, feel free to remind me again.
    – 0xC0000022L
    Sep 19, 2023 at 11:31

1 Answer 1

4

Since your questions kind of overlap, allow me to attempt to answer them in a different order. As it's been a while since I've used both tools, and topics were chosen randomly, please forgive the limited scope of my descriptions.

Q: Assuming I just use the tool, and don't look at its sources, what differences, if any, will I notice?

Any user of the two tools will almost immediately notice differences in the way the tools are used. They have simply diverged since the fork, and both went about their own ideas of what tool usage should look like.

This begins with starting up both tools. AFAIK, Radare2 still needs some argument to really start, such as "-" or "-d filename". Rizin can be started without any arguments on the command line, and will not make any assumption about being started.

Command usage has diverged a lot since the fork. You'll find there are many commands that aren't portable between the two. The Rizin project removed many commands it deemed unreliable, unfit for use, obscure, or generally misplaced. It later re-added most of the removed commands in a reviewed and restructured manner, possibly altering the semantics of their use. Looking at the help info of both tools should give an impression of this. Both projects keep books online. However, these often lag behind current developments and best serve to wake some curiosity in the reader, to experiment further.

Q: What features does Rizin have that Radare2 doesn't?

Quoting from the original blog post announcing the fork of Radare2 and creation of the Rizin project:

New Projects: we replaced the existing project functionality with a new one, developed entirely from scratch, that is based on serialization of existing objects instead of replication of commands. A blog post about this new feature will soon be published, so stay tuned if you want to know more!

Removal of less tested/stable features: As we strive to provide a stable tool that you can trust, we chose to remove some features that we believe are not widely used, are old or are not tested at all and thus do not provide any value in their current state. This includes features such as the embedded WebUI, m commands, old projects, the pdc command, T commands, and others.

New shell behavior and overall commands handling: We recently developed in radare2 a new way to parse user commands, register them and develop them.

The Rizin project has taken a different approach to the development of the tool. It appears to be driven by ideas such as maintainability of code, extensibility of features, and flexibility in usage. Cutter is the official GUI of the Rizin project, and that has had an impact on any changed done on the command line end. In general, there is now a much more reliable interface even for obscure functionality, because that is what Cutter relies on. I'm not sure that is the same with Iaito for Radare2.

RzIL vs. ESIL - Rizin attempts to replace ESIL, the Evaluable Strings Intermediate Language, with their own brand of IL, called RzIL. An Intermediate Language is a representation of the semantics of a target CPU opcode. Even while working with a architecture the user doesn't know, he can still make sense of the goings on in the disassembly this way. This can be seen, used and interpreted by the user, mostly in visual modes.

As quoted above, Rizin has a new projects feature. This can't be said enough, because historically, Radare/Radare2 projects were hit or miss (well... miss, for the most part). They finally work as expected, do not corrupt on save, include most configurations (instead of only a subset), and greatly improve working with Rizin over several sessions. The casual explorer of a binary file is less likely to need to keep a log of all commands entered to again reach the desired state of the binary.

The Rizin project as such has also become more approachable by users and interested parties. There are several ways to get in touch with the project team and contribute. Check https://rizin.re/code-of-conduct/

The Rizin Package Manager, rz-pm, is now a Go program. It's much more portable than the previous Bash based one, and the Bash dependency is likely gone.

The Rizin project builds releases for a couple platforms, but is compatible with a long list. Some lesser known platforms were removed from the list of supported ones, likely because there were either no reported use cases or there were no instances available to the CI system.

There's some extra attention to detail with some of the more recent changes. For instance, as of release 0.5.0, variables on the stack of an x86 binary are not identified by bp/sp+ anymore. This often caused misleading results for the reader, but not the machine, because it was not apparent two different expressions evaluated to the same address. Rizin now uses their address from the bottom of the stack frame in all cases. Also, from release 0.4.0 on, Rizin has a feature to help identify candidates for the real base address of a raw binary (check the new B command). I know of no such feature integrated into Radare2.

Rizin got rid of the Web UI and the embedded HTTP server. Radare2 is said to have improved on both features.

Radare2 got rid of the 'newshell' parser and improved the 'oldshell' parser instead, while Rizin did it the other way. This is an important choice, since newshell opened the path to a consistent parsing of commands, and even variable arguments (see the e command for configuration changes).

The Rizin project is aware of licensing questions. Therefore, it added SPDX info to every file and is actively trying to become compatible with LGPL, so it does a lot of rewriting of GPL'ed code. ( https://github.com/rizinorg/rizin/issues/2704 ) Depending on your situation as a user, this might have implications for you.

One last note: The Google Summer of Code gig seems to have moved from Radare project to Rizin project.

Q: What features does Radare2 have that Rizin doesn't?

Radare continues on its path of being a one stop shop for reverse engineering, for the battle hardened reverse engineer. It has a steep learning curve, and mastering just a fraction of the functionality will make many things possbile for you. By using radare2, you can learn a lot from the daily work of pancake (the original author and maintainer of radare2 to this day) and his coworkers. This will probably also give you a ton of street cred as a reverser.

They keep adding new functionality, and even rework some of the existing functionality if need be. Radare2 is working on more features related to WebAssembly being able to make use of binary blobs right there in the session (such as finding and exporting keys, images and the like). I think it was recently that they added initial support for Katakana characters in certain encodings, and greatly improved UTF16 string handling (such as for Windows binaries).

The Web UI and HTTP server still feature heavily in Radare2, if that is your kind of thing.

Radare2 is also available for many platforms. Among them are all the popular ones, and some of the more obscure: SerenityOS (sans debugger support for the time being), Vinix (which has a kernel written in V), and NetBSD on VAX (don't ask about debugging). Supported CPU architectures almost read like the character list to Game of Thrones, with new ones added each time... such as PDP11, Alpha64 and armv7.v35.

Closing remarks

I hope this kind of helps to make sense of the differences between these fantastic tools. It really helps to follow their change notes and blogs, because the documentation often can't keep up. (Yes, I'd have posted more links, but my can only post 8 right now.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.