Radare2 has a very flexible console interface, including command line, different visual modes and Unix-like integration with other tools. But there are still a lot of things to be done.
Student should know C and understand basics of the console graphics. Having and experience with Vim/Emacs or other similar-philosophy programs is a plus.
Medium
The student will know how the console interaction is done "under the hood", will gain the knowledge of Unicode internals and the experience of tuning the redrawing performance. It might also improve the efficiency of working inside the console programs.
Huge benefits for end users in UX and better support for localization
Radare2 is a well known for the abundance of the commands and complex syntax. At this point nearly every command performs its own parsing for the arguments and autocompletion. Some parts of the syntax are parsed in the main processing loop. The main goal of this task is to implement a generic parser for all radare2 commands, providing a simple interface with an arguments list and count for every subcommand, allowing for easy extension of the syntax and even performing real-time (as you type) syntax highlighting of the command right in radare2 REPL. We already have mpc as a parser for ragg2. So having it as a core for radare2 commands parsing seems like a good idea too.
Student should know C. And thould be familiar with writing parsers and writing performance-critical code.
Medium
Student will understand the logic behind writing different kinds of parsers, and will learn a lot about radare2 internals and the complexity of its commands' syntax.
This feature will reduce the complexity of adding new command or changing existing one, it will bring also the better syntax extensions and ability to syntax highlight the language.
Currently we have types support in radare2, including basic (low-level) ability to edit type with pf and higher-level, C-like types with t command. Currently you can parse the C type definition from C headers for example, or load from "precompiled" SDB file. The goal of this task is to integrate more types handling into the radare2 analysis loop, including automatic inference and suggestions.
Some basic type inference is already implemented as a part of aft and afc commands, and anal.types.* configuration options.
Student should know C as well as be familiar with basics of the program analysis.
Medium
Student will understand modern program analysis problems related to type inference, understand low level details on how compilers produce native code from OOP concepts, and will meet the most common reverse engineering task in its advanced incarnation.
This feature will make radare2 more usable for day-to-day reverse engineering of complex programs, and will make integration with radeco decompilator even easier.
t and pf commands.av, t, andpf commands.While instruction set defines architecture, it is common that particular CPU or SoC models implement only a subset of it or extend it with custom instructions and registers. Moreover, various SoC modifications can define peripheral devices interaction through ports (rare), registers or MMIO spaces. All this helps the reverse engineering process, because a lot of the code will make sense upon a glance once you see it accesses certain registers (if named) or peripheral devices (when MMIO area is defined).
lang-* pluginsStudent should know C and understand basics of the hardware platforms, architectures and chips.
Medium
The student will improve familiarity with reverse engineering for various architectures and platforms, along with the improving the efficiency of radare2.
Huge benefits for end users in UX and better support for extension.
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.
The student should be comfortable with the C language, and be familiar with windows binaries
Advanced
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.
Radare2 has basic support for Windows but not all tests are passing under AppVeyor, debugging has still problems, and some features of radare2 do not work properly. This task consists of some small, and some big unrelated tasks to improve the basic and advanced support of running radare2 on Windows platform
dmh for glibc)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 internals, related to debugging.
Since radare2 has a better support for emulation and analysis, this will help to migrate from WinDbg to radare2.
Radare2 has had the ability to perform binary diffing for over a decade. Nevertheless the support is quite basic and there is room for improvement. One of the most important tasks is to deepen the integration with analysis loop. Integration with the analysis loop will allow radare2 to find and highlight the difference between arguments count, local variables count, their types and other analysis metainformation. The next big task is to modernize radiff2 (and corresponding parts in RCore) in terms of performance and user interface. And of course - cover the radiff2 and radare2 diffing features with regression tests and unit tests.
Student should know C as well as be familiar with basics of the program analysis. Having an experience with other binary diffing software is a plus.
Medium
Student will understand modern program analysis problems in application to binary diffing, and how to improve the performance of patch analysis.
This feature will make radare2 usable for day-to-day patch analysis of modern software, as well as improve the automation and performance of this task.
Radare2 has been a successfull reverse engineering framework and a toolset for years. But apart from decompilation, the biggest missing feature is the lack of real time collaboration, which is important when reversing large files, or playing CTFs in a team. There are successfull examples like collabREate, YaCo and solIDArity (proprietary/$$$). When it comes to public tools, collabREate is the most complete and common, and it supports notifications (and online propagation) of those actions:
The possible architecture of the platform:
"WebUI [1] (microservice in Go) <-> Server [2] (microservice in Go) <-> C library of client [3]"
The project management (create/remove/add user in project/remove user from project) should be done in the Server [2]. The user management - too. Those functions are exported in some way for using in WebUI microservice (RPC maybe?). The file storage is a filesystem, for storing initial files (in binary format), state and differences (in text format) using Git Go library, those text differences are "r2 commands", which are sent by a C api library. Conflict resolution could be done via standard Git features - rebase/merge.
Ability to code and understand C and Go (Go can be learnt in a couple weeks though).
Medium
Student will learn about creating a distributed systems with Go and conflict resolution algorithms in real time.
It is crucial for the ability to reverse engineer complex programs in a team, allowing managing the changes history. It will also improve the undo features in radare2. This kind of work will be beneficial for team-CTF competitions as well.