Radare2 GSoC 2016 Introduction Project Ideas Micro Tasks

Project Ideas

^

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

^

Completing Radeco

radeco, a radare2 based decompiler, was a project that was started in GSoC'15. Currently, radeco features a ESIL to SSA IL converter and a few optimisations to the IR. The task for this year is to complete the first iteration of the decompiler. 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'16. 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

^

Better support for UNICORN debugging

Current support of UNICORN in r2 is more or less a proof of concept. We need to support more architectures, better handle syscall tracing, share memory and initialize/store/restore debugging states from core files, etc. All those features should be a laa par of using ESIL for emulation, which is currently working way better than UNICORN, but having more backends also benefits the overall interface and internal apis.

Tasks

  1. Support more architectures in the unicorn plugins
  2. Share memory changes in realtime between r2 io and unicorn process

Skills

C

Difficulty

Medium

Benefits for the student

The student will learn about the differences between multiple architectures and find a way to properly structure this to integrate it with radare2 with a multi-architecture debugging backend plugin.

Benefits for the project

Unicorn is a project with a growing community and inherits the power from QEMU, supporting many architectures and with many real use cases. Having better support for it implies that r2 will be able to verify the ESIL implementation against more backends and gain the ability to emulate code in more architectures.

Assess requirements for midterm/final evaluation

At least two architectures should be supported in the unicorn plugin and the memory should be mirrored in realtime between unicorn and r2.

Mentors

Links/Resources

^

Function argument detection

Radare2 doesn’t deal very well with argument and variable and function definition. The student will have to combine several concepts/modules within radare2 to be able to complete this tasks: - Radare’s type system - SDB, the internal database format - pf, the structure module - The analysis engine

How it looks

Task

Skills

The student should be comfortable with the C language, know the basics of assembly and have knowledge in program analysis.

Difficulty

Medium

Benefits for the student

General idea about various platforms ABI

Benefits for the project

The completion of this task would greatly improve radare2's analysis capabilities, making it ever more competitive with IDA Pro.

Assess requirements for midterm/final evaluation

At the midterm student should have a working argument with types display.

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

^

Improve assembly syntax

Currently, radare2 uses several assemblers, and none of them is complete. It would be awesome to have a generic assembler syntax with structures and macroses for a lot of architectures.

Task

Unify assembly syntax among all supported architectures in radare2, implement this in an external library, and make it fasm-compatible. This backend will perform the preprocessing assembly listings, then passing it to the frontend. It should be the one library for all available architectures.

It should support:

macro <name> <args> { <body> }

struc Unit a,b,type { .offs_l dw a & 0xFFFF .cntr db 0 .dtype db type .offs_h dw ((b >> 16) & 0xFFFF) .size = $ - .offs_l }

``` pd PStruct

; For accessing structure fields based on some register virtual at edi edi.d PStruct end virtual mov eax, [edi.d.Call] ```

Skills

The student should be comfortable with the C language and assembly.

Difficulty

Medium

Benefits for the student

The student will have the opportunity to see uncommon architectures, and to implement a simple-but-solid assembly language parser.

Benefits for the project

Having a better assembler syntax will allow r2 and its users to have a multiarch assembler with syntax as handier as the one from nasm or fasm.

Assess requirements for midterm/final evaluation

Midterm will require working universal assembly library for at least 4 architectures: x86, arm, mips and avr. It could be a separate library at this point. And at the final evaluation we’ll expect it integrated into the radare2 framework and completely covered by regression tests for each specific keyword or syntax construction.

Mentors

Links/Resources

^

Coredump loading/creating support (ELF/MACH0)

A core represents the state of a process at a point in time. It contains all the information that needed to inspect the process and its state. This information includes thread information, mapped memory, register state and more. After implementing a support of loading coredump files into the radare2 debugger, it will be possible to inspect the state of the process as if they had attached a debugger to the process at the time when the core file was generated. Moreover, generating coredump files from the remote systems, connected via gdb:// protocol can increase speed of debugging via slow links.

Currently radare2 can dump and restore memory, register states to disk, in order to have snapshots of the execution, but the dump is not done in Core format.

Tasks

  1. parse mach0/elf coredump images and load them in r2
  2. implement coredump generation from debugger memory/regs
  3. support linux and osx/linux
  4. ability to generate coredump from remote target connected via gdb:// protocol

Skills

C

Difficulty

Medium

Benefits for the student

Learn and understanding the ELF/MACH0 internals as well as which information is important to be able to reproduce a specific state of execution to understand, for example: why a crash has happened.

Benefits for the project

Missed support for loading coredump was the only major difference between radare2 and gdb, so after implementing it and improving DWARF support will help broader usages of radare2 as a source-level debugger.

Assess requirements for midterm/final evaluation

At the midterm evaluation student should provide working support fo loading coredump from file. After the final evaluation radare2 should have support for creating coredump files for process on linux systems.

Mentors

Links/Resources

^

Kernel support for r2

There have been many attempts to bring r2 into the kernel and boot land, but none of them stick enough time or get enough support to survive. We should be able to allow r2 to talk with the kernel by exposing a new device to read/write kernel memory, and extend the functionality to expose more internal information from the kernel to r2.

Maybe the best way to talk with r2 is via rap:// we should evaluate the communication protocol in order to simplify as much as possible the problem and avoid adding vulnerabilities.

This kind of r2kernel integration has been used in the past for manually hooking syscalls by patching the kernel memory inline or patching some instructions to disable some protections for testing and better understanding of the priviledged procedures of modern operating systems.

Tasks

Skills

C, Kernel

Difficulty

Medium

Benefits for the student

Learn about how all major kernels expose interfaces to the user and their limitations. Understanding the differences in memory protection and address space found in user and kernel land.

Benefits for the project

Being able to talk with kernel from r2 will unleash a lot of power for exploiters, researchers and kernel developers, providing easy to use tools for analyzing code and patching without having to reboot or reload kernel modules.

Assess requirements for midterm/final evaluation

At least one operating system should be supported, and it should be possible to read and write memory. Bonus points include the ability to enumerate symbols or set flags to different points of interest.

Mentors

pancake

Links/Resources



--radare2 @ 2016