Radare2 GSoC 2017 Introduction Project Ideas Micro Tasks

Project Ideas

^

Completing Radeco

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.

Tasks

Additionally, the students are also expected to detail their architecture (in the wikis) and write tests and documentation for any features that they contribute.

Skills

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.

Difficulty

Advanced

Benefits for the student

Benefits for the project

Finally, radare2 will have its own retargetable decompiler, which will cover a wide range of architectures.

Assess requirements for midterm/final evaluation

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.

Mentors

Links/Resources

^

Ropchain generator with ragg2

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.

Task

  1. Implement a "classic" (/bin/sh for example) ropchain as a proof-of-concept, like what ROPgadget does. This can be done is almost any language, thanks to the bindings/r2pipe.
  2. Caching rop gadgets in SDB, for quicker retrieval
  3. Implement a ropchain generator that uses ragg syntax, or something like: register reg1 = 0; register reg2 = whatever; register reg3 = reg1 + reg2; system(echo reg3);

Skills

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.

Difficulty

Medium

Benefits for the student

The student will improve their skills in software exploitation and solvers.

Benefits for the project

This feature would greatly help during exploits development, and people would be able to ditch mona.py for radare2 ;)

Assess requirements for midterm/final evaluation

midterm: ROP gadgets stored in sdb, and gadget classification final evaluation: a working ropchain builder

Mentors

Links/Resources

^

Improve remote debugging with GDBServer and RAP

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.

Task

Skills

Student should know C, have some experience with socket/network programming and a general idea about how debuggers works

Difficulty

Advanced

Benefits for the student

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.

Benefits for the project

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.

Assess requirements for midterm/final evaluation

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.

Mentors

Links/Resources

^

Timeless debugging support

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.

Task

  1. Read/write memory at any moment in the debugging history
  2. Same for registers
  3. Be able to seek forward/backward in time
  4. Implement step back command (dsb)

Skills

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.

Difficulty

Advanced

Benefits for the student

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.

Benefits for the project

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.

Assess requirements for midterm/final evaluation

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.

Mentors

Links/Resources

^

Handle EXE/DLL as FAT binaries

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)

Task

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)

Skills

The student should be comfortable with the C language, and be familiar with windows binaries

Difficulty

Advanced

Benefits for the student

The student will gain a deep understanding of Microsoft's executable formats.

Benefits for the project

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.

Assess requirements for midterm/final evaluation

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.

Mentors

Links/Resources

^

Proper Windows platform support

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

Tasks

  1. Fix current features on Windows platform:
  2. Improve PDB loading support and integration with analysis subsystem
  3. Make zignatures for Windows libraries
  4. Better Support for .dll (analysis and debugger)
  5. Ability to find out WinMain automatically, parsing SEH and RTTI
  6. Improve WinDbg protocol support and integration with analysis
  7. Add support of loading all kinds of user mode minidumps and kernel dumps

Skills

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.

Difficulty

Medium. If the student is comfortable with programming for Windows, there shouldn't be major challenges except WinDbg protocol support.

Benefits for the student

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.

Benefits for the project

Since radare2 has a better support for emulation and analysis, this will help to migrate from WinDbg to radare2.

Assess requirements for midterm/final evaluation

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.

Mentors

Links/Resources

^

Web interface

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.

Tasks

  1. Implement/enhance widgets like:
  2. Make it responsive
  3. Make it more keyboard friendly (aka-olly)
  4. Better Interface for the debugger
  5. Optimize it, compress JS, reduce AJAX queries, make it usable on all devices

Skills

The student should be comfortable with modern web technologies like javascript and HTML5. They don't need to be über-comfortable with C nor assembly, since all the information is obtained directly from radare2. As a bonus point it would be interesting if they know some basic assembly. It's better if student will come with a few simple mockups what [s]he is going to do.

Difficulty

Easy. If the student if comfortable with web technologies, there shouldn't be any major challenges in complteting this task.

Benefits for the student

The student will gain experience in writing rich web applications, and domain-specific user interface. Also, the student will learn to design usable APIs, since this task will deal with interfacing C and Javascript.

Benefits for the project

Since radare2 has a steep learning curve, this task will lower the barrier for transitioning from IDA to radare2.

Assess requirements for midterm/final evaluation

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.

Mentors

Links/Resources



--radare2 @ 2017