The radare project started in February of 2006 aiming to provide a free and simple command line interface for an hexadecimal editor supporting 64 bit offsets to make searches and recovering data from hard-disks.
Since then, the project has grown with the aim changed to provide a complete framework for analyzing binaries with some basic *NIX concepts in mind like everything is a file, small programs that interact together using stdin/out, and keep it simple.
Radare2 is a complete LGPL rewrite of the original project, to remove design issues of the first iteration, and to make it more modular and easier to script and maintain. It features a testsuite that aims to cover as much cases as possible in order to catch regressions.
Radare2 is composed of an hexadecimal editor as central point, with several assemblers/disassemblers, code analysis capabilities, scripting features, visualization of code and data through graphs and other means, a visual mode, easy unix integration, a diff engine, a shellcode compiler, and much more.
Last year (2014) we hosted our own Summer of Code (RSoC 2014) and you can see results here.
If you have questions or comments, visit our IRC channel #radare on Freenode.
Those people are part of the solid core of radare2, and volunteered to help you if you want to pick up a task.
Currently, all repositories are hosted on github, that is also our bugtracker. We are mostly using pads and IRC for communication.
We have a testsuite (that is also running on our Jenkins instance) to test and verify that all the features are still working and that a merge or a commit don't break anything, and to find regressions.
We encourage contributors to write test cases and documentation in order to verify the implementation and ensure that everything fits well together.
There is also a Coverity instance to catch obvious defects.
For the complex bugs and examples we're using our own asciinema installation^
Radare2 is modular: this means that it aims to make all the elements and features easily reusable from other projects. The choice of LGPL3 as a license is the minimum requirement to get code merged in r2. Contributors can choose Apache, BSD, MIT, Public Domain, or other similar licenses. The reason to exclude GPL as a valid license for the project is because we aim to support proprietary software that uses r2, while protecting our free codebase.
Radare2 has a nice web interface, but it's not currently as complete as the command line one. While the later is more powerful, it has a steep learning curve, and it not usable on every devices (Like cellphones or tablets); this is we'd like to put some efforts into an awesome and good-looking web interface.
As a bonus point it would be interesting if they know some basic assembly.
Easy. If the student if comfortable with web technologies, there shouldn't be any major challenges
Since radare2 has a steep learning curve, this task will lower the barrier for transitioning from IDA to radare2.
ESIL stands for 'Evaluable Strings Intermediate Language'. It aims to represent every opcode in an intermediary language. Those representations can be evaluated in order to provide accurate emulation. Unlike most of the modern IL/IR, ESIL is not registry-machine, it's a symbolic language, with an infinite set of variables, without restrictions on their names.
At the moment, there's an initial parser implemented that reads an esil expression and generates an SDB database, which can be easily walked to retrieve all information needed to get the AST and to perform analysis.
ESIL can be used to facilitate reverse engineering, since it's easier to emulate functions than to deploy a whole environnement in QEMU.
The student should be comfortable with the C language. Having knowledge of lexers/parsers and compilers would be a plus.
This task aims to allow dynamic analysis of non-native architectures without the need of a virtual machine.
Analyzing binaries is a complex task, and everything that could help the reverser is worth considering. While static analysis is really tricky to get right, dynamic analysis is much more straightforward. Unfortunately, setting up exotic environnements in a virtual machine like QEMU is painful. This is why we'd like to use emulation, powered by ESIL, instead. This would bring us, for example functions arguments guessing, jump destinations computation, registers values, ...
We'd like to get this kind of analysis capabilities on top of ESIL:
- Detecting switch-cases - Getting jmp destinations - Guessing function parameters - Improving (x)ref detection - Debugging entire functions without the need of a native debugger
The student should be comfortable with the C language, and have knowledge in program analysis.
The completion of this task would greatly improve radare2's analysis capabilities, making it ever more competitive with IDA Pro.
ESIL currently is not in SSA form, which means that variables get assigned more than once. A goal for the radare2 project is to include a retargetable decompiler, and having SSA form output of ESIL is a first step towards this.
The student should be comfortable with the C language, and have knowledge about compilers.
Radare2 can not only be used to debug and understand binaries, but also to attack and exploit them! Currently, it features a cross-platform ROP-gadget hunter, and some other helpers, like mitigation detection, or De-Bruijn pattern. But we're quite sure that we can go even further to speed-up exploits development.
The student should be comfortable with the C language, and familiar with assembly, shellcoding and exploitation in general.
The student will improve their skills in software exploitation, both in methodology and bug hunting, as well as learn mitigation bypass techniques.
Radare2 is starting to be used in offensive situations, like in CTF, but mainly for disassembling exotic architectures. It would be great if it was used for its offensive capabilities too.
ImmunityDBG has mona.py, there is also ROPgadget, and it's a shame that despite having ESIL, radare2 doesn't have something similar.
/bin/shfor example) ropchain as a proof-of-concept, like what ROPgadget does
register reg1 = 0;
register reg2 = whatever;
register reg3 = reg1 + reg2;
The student should be comfortable with the C language. Having some notions in different exotic architectures and parsing would be a plus.
The student will improve their skills in software exploitation and parsing.
This feature would greatly help during exploits development, and people would be able to ditch mona.py for radare2 ;)
It would be nice to have a nice-looking debugger or module, maybe a mix between PEDA and Voltron.
Your task will be to write some tests for the debugger, then to implement all kind of features for it:
The student should be comfortable with the C language, and be familiar with debuggers.
Coding a debugger is fun, combining analysis capabilities with it is even more fun. The student will improve their knowlege in both areas, as well as in user-interfaces.
Radare2 is complex to use, but with this task we hope that the barrier will be lowered for the debugger, as well as achieve feature parity with other popular debuggers.
Windows programs are like Apple's FAT binaries, they contain multiple programs inside,
and r2 should be able to list and select them when loading.
Also, it may be possible to extract them with
rabin2 -x foo.exe.
The sub-bins inside an EXE are:
This task also includes adding support for .NET in RBin, to be able to list the symbols, get the entrypoint, code metadata, etc.
The student should be comfortable with the C language, and be familiar with windows binaries
The student will gain a deep understanding of Microsoft's executable formats.
Currently, there are no up to date modern tools to deal with .Net programs in a low-level manner, when decompilers fail. With this task, we'd like to fill this gap.
Currently, radare2 uses several assemblers, and none of them is complete. It would be awesome to have a generic assembler library for a lot of architectures.
Unify assembly syntax between all supported architectures in radare2, implement this in an external library, and make it fasm-compatible.
The student should be comfortable with the C language and assembly.
The student will have the opportunity to see uncommon architectures, and to implement a simple-but-solid assembly language parser.
Radare2 is currently using Capstone to disassemble several architecture, having an equivalent library to assemble would greatly simplify the maintainance and the code base.
Radare2 implements RConsCanvas and it's own graph rendering and interactivity code, but the features required to make the graphs fully functional are not done yet.
The student should add the following improvents to radare2's graph engine
The student should be comfortable with the C language and graph theory.
The student will discover the complex is the world of the *nix terminals, ANSI escape sequences, and other control funny things. Also they will learn about providing a good international experience to the users (UTF-8 support) and general graph-related algorithms.
Radare2 will get much better interaction and visualization of code. This will simplify the analysis of big functions and produce good looking ascii-art graphs.