radeco, a radare2 based decompiler, was a project that was started in GSoC'15, and continued in GSoC'16. Currently, radeco features a ESIL to SSA IL converter, skeleton of C emitter and a few optimisations to the IR. The task for this year is to complete the full process of the decompiler (from binary to C pseudo-code). This involves several tasks which are listed below. Note that some of these tasks are large and are listed to give students a complete view of the requirements of this project. A potential student is required to discuss these with the mentors and pick some tasks to write their proposals for GSoC'17. Being a relatively new project under the radare banner, this project also gives student an opportunity to learn, design and discuss the architectural aspects of the project.
Additionally, the students are also expected to detail their architecture (in the wikis) and write tests and documentation for any features that they contribute.
Knowledge of working of compilers and program analysis (or an interest to learn these quickly) Some knowledge of rust is an added bonus. A potential student must be willing to learn rust in order to contribute to this project. Some knowledge of common ISA such as x86, x86_64, ARM.
Finally, radare2 will have its own retargetable decompiler, which will cover a wide range of architectures.
For the midterm evaluations, the student is expected to have completed the C/pseudo code emitter and obtain the first set of results. The final evaluation requires students to have improved the quality of the generated code and have a working type inference system.
Since modern architectures are now enforcing W^X, exploiters are using ROP. (Un)fortunately, building rop chain by hand can be tedious, this is why some tools can be used to ease this construction: ImmunityDBG has mona.py, there is also ROPgadget and dropper. It's a shame that despite having ESIL, radare2 doesn't have something similar yet.
/bin/shfor example) ropchain as a proof-of-concept, like what ROPgadget does. This can be done is almost any language, thanks to the bindings/r2pipe.
register reg1 = 0; register reg2 = whatever; register reg3 = reg1 + reg2; system(reg3);
The student should be comfortable with the C language, know some assembly and a high-level language. Also, knowing a little bit of automatic binary analysis wouldn’t hurt.
The student will improve their skills in software exploitation and solvers.
This feature would greatly help during exploits development, and people would be able to ditch mona.py for radare2 ;)
midterm: ROP gadgets stored in sdb, and gadget classification final evaluation: a working ropchain builder
Having a reusable implementation of gdbserver in r2 will be useful because it means that r2 will be able to be used from IDA, GDB or LLDB as frontend. And being able to use r2 too to communicate with a remote r2 instance with better integration for remote debugging.
Also, the current r2 remote debugging is done via rap:// which is just a plain io+system protocol. it will be good to support a remote debugging via serializing r2 commands so we need a debug_rap plugin.
Student should know C, have some experience with socket/network programming and a general idea about how debuggers works
The student will understand how most of the remote debugging works "under the hood". And will have general knowledge about writing mutiplatfform debuggers, as like as bits of network programming.
The fact we have our own gdbserver implementation will help us to improve GDB protocol on both client and server sides, which will make the testing protcol parser easier. Also radare2 would not rely on the non-standard debug protcols for exotic platforms, since it would be easier to port radare2 gdbserver on that platform.
Midterm will be successfull if the simpe gdbserver, working via sockets will be able to talk with radare2 and gdb Final evaluation will require gdbserver which should work at least on x86, arm, mips and powerpc platforms, able to answer radare2, gdb, lldb and IDA Pro rquests.
We want to add support for timeless debugging in r2. This requires to design and implement a generic API that would allow to load recorded tracing sessions from tools like rr, QIRA or r2 itself. r2 can’t create tracing sessions and it should be implemented in the debugging component of our tool. We already have support for debugging snapshots, so those actions should be available as callbacks in the debugger plugins, and provide some basic commands to specify which snapshot to get or set.
Student should know C and C++ (for integration with tools like RR or Qira). And should be familiar with the ideas of reversible debugging along with the knowledge how debuggers are working.
Student will meet a relatively new approach to debug and searching errors, along with an opportunity to gather experience of optimizing algorythms to be able work with a huge amount of data, which is a definetely a case for timeless debug.
Timeless and reversible debugging will help radare2 to become an universal debug tool for quick and easy inspection of trace snapshots, based on RR or Qira sessions.
Midterm: design and implementation of the interface and commands to work with traces taken from QIRA and RR. Final: Add the plugin for timeless debugging feature inside r2.
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: 1. DOS program 2. W16 program 3. W32 program 4. MSIL program (.NET)
This task also includes adding support for .NET in RBin, to be able to list the symbols, get the entrypoint, code metadata, etc. This will require rethinking some of the commands to allow switch between parts of this FAT binary on the fly. 1. Fix current fatmach0 2. dyldcache is broken 3. PE (dos, win, .net) separation 4. Add support for iOS OTA images (see issue)
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.
Midterm: Support of FAT binaries (Win32 native + .NET) in RBin, basic one Final: Also should be working with listing symbols from both parts of the binary (e.g. .NET and native code), as long as other metadata. And show this metadata in rabin2 output as well.
Radare2 has a basic support for windows but tests are still not passing under AppVeyor, debugging has still problems, and some features of radare2 does not work properly or at all. This task consists from some small, some big unrelated tasks to improve the basic and advanced support of running radare2 on Windows platform
The student should be comfortable with programming under Windows platform. They don't need to have a reverse engineering background, since most of the missing stuff is well documented. As a bonus point it would be interesting if they know some basic assembly.
Medium. If the student is comfortable with programming for Windows, there shouldn't be major challenges except WinDbg protocol support.
The student will gain experience in writing debuggers for Windows platform. Also, the student will learn the Windows platform crucial parts' internals, related to debugging.
Since radare2 has a better support for emulation and analysis, this will help to migrate from WinDbg to radare2.
The student must finish the regression tests pass stage during the first evaluation. WinDbg protocol support improvements are the requirement to pass the 2nd evaluation. Ability to parse various versions of PDB format + regression tests for them is a final evaluation requirement.
Radare2 has a nice web interface (and not only one: /p, /m and /t), but it's not currently as complete as the command line one. While the latter 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, functional web interface.
Easy. If the student if comfortable with web technologies, there shouldn't be any major challenges in complteting this task.
Since radare2 has a steep learning curve, this task will lower the barrier for transitioning from IDA to radare2.
The student must focus on the material webui as long is the one used by default in Android and it is also the fastest one to load. Adding more visual feedback like displaying graphs for entropy, section sizes, ... and support for editing code or data, and be able to use the debugger in a more comfortable way.