## 1. Project Overview & Quickstart (rizinorg/docker) # docker Docker official jenkins repo ### Repository Details - **Repository:** [rizinorg/docker](https://github.com/rizinorg/docker) - **GitHub Stars:** ⭐ 7,595 - **Primary Language:** PowerShell *Note: High-volume repository documentation is actively indexed and synchronized by YakaAI.* ## 2. Official Technical Reference & Guides (rizinorg/website) ## File: README.md # Rizin Website ## Local Installation 1. Install or download the **Extended** version of [Hugo](https://gohugo.io/getting-started/installing/) - Newer version of Hugo might not work. The version used here is [v0.111.3](https://github.com/gohugoio/hugo/releases/tag/v0.111.3) 2. Clone this repository and its submodules: ``` $ git clone --recurse-submodules https://github.com/rizinorg/website ``` 3. Enter the cloned repository and "serve" the website using Hugo ```bash $ cd website # Check hugo version $ hugo version hugo v0.111.3-5d4eb5154e1fed125ca8e9b5a0315c4180dab192+extended linux/amd64 BuildDate=2023-03-12T11:40:50Z VendorInfo=gohugoio $ hugo serve ``` ## File tree description ``` . ├── assets │ └── css │ └── custom │ └── rizin.css <--- Edit CSS here ├── config.yml <--- Hugo Config for the website ├── content <--- Markdown files for single pages │ ├── archives.md │ ├── code-of-conduct.md │ ├── organization.md │ ├── posts <--- Markdown blog posts │ │ └── example │ │ └── index.md │ └── teams <--- Special folder for team pages │ ├── community.md │ ├── core.md │ ├── Distributions and Packaging.md │ ├── package-manager-and-plugins.md │ └── . . . ├── data │ └── teams.json <--- JSON with teams data and descriptions ├── layouts <--- Special layouts │ ├── _default │ │ ├── organization.html │ │ └── team.html │ ├── index.html <--- Main page │ └── partials <--- override theme or introduce new partials │ ├── extend_head.html │ ├── header.html │ └── main-page.html ├── static │ └── images │ └── rizin.svg | | └── themes <--- The base theme. Don't touch files in here └── hugo-PaperMod ``` ## Demo GIF When showing Rizin demos the GIF are generated with [Terminalizer](https://www.terminalizer.com/) by using this [config file](https://github.com/rizinorg/website/blob/main/.terminalizer-config). --- ## File: content/gsoc/2021.md --- title: "GSoC 2021" layout: "single" ShowToc: true TocOpen: false ShowReadingTime: false date: "2021-02-18" --- **TL;DR** Jump to the [Ideas list](#project-ideas). # Introduction Each year since 2015, we have participated in Google Summer of Code as the Radare2 project and accomplished many goals. This year we participate as a fork - Rizin, but effectively continuing the same process and the same mentors. ## Mentors Members of the Rizin and Cutter core teams have volunteered to guide students for GSoC’21. They were already guiding the students for the GSoC and RSoC in past years as part of the Radare2 project. Please feel free to reach out to any of them in case you need any help in selecting a project. - **Anton Kochkov** Mattermost: xvilka -- [@akochkov](https://twitter.com/akochkov) - **Riccardo Shirone** Mattermost: ret2libc - **Florian Märkl** Mattermost/Telegram: @thestr4ng3r -- [@thestr4ng3r](https://twitter.com/thestr4ng3r) - **Antide Petit** IRC/Telegram: xarkes -- [@xarkes\_](https://twitter.com/xarkes_) - **Itay Cohen** Mattermost/Telegram: @Megabeets [@Megabeets\_](https://twitter.com/Megabeets_) - **Giovanni Dante Grazioli** Mattermost/Telegram: @deroad [@der0ad](https://twitter.com/der0ad) - **Yossi Zapesochini** Mattermost/Telegram: @yossizap - And many others ## Development methodology Currently, all repositories are hosted on GitHub [main](https://github.com/rizinorg/) organization account, bugs are tracked on GitHub [issues](https://github.com/rizinorg/rizin/issues) too. We are mostly using [our own Mattermost instance](https://im.rizin.re), IRC, and [Telegram](https://t.me/rizinorg)) for communication. We have a [testsuite](https://github.com/rizinorg/rizin/tree/dev/test) (that is running on GitHub Actions, [Travis CI](https://travis-ci.com/rizinorg/rizin), [AppVeyor](https://ci.appveyor.com/project/rizinorg/rizin) and SourceHut) to test and verify that all the features are still working and that a pull requests or commits don't break anything, to ensure the support of different operating systems (Linux, MacOS, Windows, FreeBSD, OpenBSD), different architectures (x86/x86_64, ARM64, PowerPC, SystemZ), 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. For complex bugs and examples we're using [ASCIInema](http://asciinema.org/) for recording the sessions. See also our guides for corresponding projects: - Rizin [Contributing Guide](https://github.com/rizinorg/rizin/blob/dev/CONTRIBUTING.md) and [Developers Intro](https://github.com/rizinorg/rizin/blob/dev/DEVELOPERS.md) - Cutter [Contributing Guide](https://github.com/rizinorg/cutter/blob/master/CONTRIBUTING.md) and [Developers Intro](https://cutter.re/docs/code.html) For those who want to get introduced to the Rizin codebase and practices, we recommend to pick one of the easy issues for [Rizin](https://github.com/rizinorg/rizin/labels/good%20first%20issue) or [Cutter](https://github.com/rizinorg/cutter/labels/good%20first%20issue) to start with. ## License Rizin is modular: this means that it aims to make all the elements and features easily reusable from other projects. The choice of [LGPL3](https://www.gnu.org/licenses/lgpl.html) as a license is the minimum requirement to get code merged in Rizin. 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 Rizin, while protecting our free codebase. ## Instructions for students It is a requirement that students who want to apply to the Rizin project for the Google Summer of Code 2021 should submit a small pull request accomplishing one of the [microtasks](#microtasks) (see below) as part of their application. Though you can also choose any of the GitHub issues for Rizin if they are big enough to be a qualification task, and still small enough to be finished no more than in a couple of weeks. ## Programming languages Most of Rizin is written in C (conforming C99 standard) and hence we expect students to be familiar with C programming language. For some of our tasks or microtasks, such as collaborative RE or [rz-pm](https://github.com/rizinorg/rz-pm), students should know the Go programming language. For the [Cutter tasks](#cutter), students should know C++ and Qt framework basics. ## Recommended steps 1. Read Google's instructions for participating 2. Grab any of the project from list of ideas that you're interested in (or propose your own). 3. Write a first draft proposal using Google Docs and [our template](https://docs.google.com/document/d/1kDPGgr_D5tQuYLQi_gEGlkuQ-DlU8GH5kDBqZbVSC7I/edit?usp=sharing) and ask one of the mentors or administrators to review it with you. 4. Submit it using Google's web interface. ## Student proposal guidelines 1. Keep it simple enough to fit in no more than a couple of pages. Try to be clear and concise in your writing. 2. Try to split GSoC period into tasks, and each task into subtasks. It helps us to understand how you plan to accomplish your goals, but more importantly, it'll help you to understand the task deep enough before starting, and prioritize important things to do first. 3. Please, note, how much time a day/week you are able to spend on this project. 4. Specify your timezone, since so we can assign you a mentor in the same one, to ease communication. 5. Submit your proposal early, not in the last minute! 6. Be sure to choose a “backup” idea (the second task you want to do), so that conflicts (two students for one task) can be resolved. # Project Ideas ## Rizin ## Type Analysis Improvements Currently we have types support in Rizin, including basic (low-level) ability to edit type with `pf` and higher-level, C-like types with `t` command. It is possible to parse the C type definition from C headers for example, or load from "precompiled" SDB file. However, despite such features being present, many of them still lack the right structures and connections between them to make complex automated and manual analysis of code using types convenient. The goal of this task is to build upon the currently available features and re-think or re-design some of them to fit into the bigger picture of the entire framework. The overall plan for this project is tracked at [https://github.com/rizinorg/rizin/projects/3](https://github.com/rizinorg/rizin/projects/3). There are certain dependencies between some of the subtasks, but as long as these are respected, subtasks to be taken for GSoC can be picked by preference. ### Task (proposal) 1. Bundle all types functionality in a new module `RzTypes` [#369](https://github.com/rizinorg/rizin/issues/369) 2. Refactor some base type accesses to use the RzAnalysisBaseType API [#368](https://github.com/rizinorg/rizin/issues/368) 3. Replace the current TCC-based C types parser by a Tree-sitter based one [#275](https://github.com/rizinorg/rizin/issues/275) ### Skills Student should know C as well as be familiar with basics of the program analysis. They should also be passionate about software architecture. ### Difficulty Hard ### Benefits for the student Student will understand modern program analysis problems related to type analysis, as well as gain skills in the field of software architecture of a large, modular C project with complex dependencies between modules. ### Assess requirements for midterm/final evaluation - 1st term: `RzTypes` module exists and contains all relevant code. - Final term: Tree-sitter based C parser is implemented and integrated into the analysis framework. ### Mentors - xvilka - thestr4ng3r ### Links/Resources - [Type Analysis Improvements Project](https://github.com/rizinorg/rizin/projects/3) - [C++ grammar for tree-sitter](https://github.com/tree-sitter/tree-sitter-cpp) ## CPU/Platform profiles 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). A common example is [SVD loading](https://github.com/leveldown-security/SVD-Loader-Ghidra) for ARM architecture. A good example how CPU profile should look like: - `asm.cpu` to be dynamically populated by listing the available CPU dedicated plaintext/sdb files - Add `RAM_SIZE` info in the CPU files and remove hardcoding from .h and .c files - Add `ROM_SIZE` info in the CPU files and remove hardcoding from .h and .c files - Add `INTERRUPT_VECTOR_SIZE` info in the CPU files and remove hardcoding from .h and .c files - Add `IO_REGISTERS`, `EXTENDED_IO_REGISTER`, `MMIO_REGISTER`, coprocessor register info in the CPU files and remove hardcoding from .h and .c files ### Task 1. Implement support for CPU profiles 2. Implement support for platform profiles 3. Add support for register and MMIO specific setups 4. Integrate these in analysis loop, handling register and memory accesses. 5. Implement tests and documentation in Rizin book 6. Provide an API for setting these values from rz-pipe and `lang-*` plugins ### Skills Student should know C and understand basics of the hardware platforms, architectures and chips. ### Difficulty Medium ### Benefits for the student The student will improve familiarity with reverse engineering for various architectures and platforms, along with the improving the efficiency of Rizin. ### Benefits for the project Huge benefits for end users in UX and better support for extension. ### Assess requirements for evaluations - 1st term: CPU and platform profiles, some most common profiles, integration with the analysis loop - Final term: Support for more platforms, regression and unit tests, documentation (including Rizin book). ### Mentors - xvilka - deroad ### Links/Resources - [Issue #103](https://github.com/rizinorg/rizin/issues/103) - [SVD loader for Ghidra](https://github.com/leveldown-security/SVD-Loader-Ghidra) - [How to use SVD loader with Ghidra](https://leveldown.de/blog/svd-loader/) - [SVD parser in Rust](https://github.com/rust-embedded/svd) - [CMSIS-SVD repository](https://github.com/posborne/cmsis-svd) ## Rz-diff improvements Rizin 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 Rizin 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 rz-diff (and corresponding parts in RCore) in terms of performance and user interface. And of course - cover the rz-diff and rizin diffing features with regression tests and unit tests. ### Tasks - Support diffing of the different parts of the same buffer/file - Split view for [hexadecimal view](https://github.com/rizinorg/rizin/issues/126) and disassembly diffing mode - Improve the integration with analysis (variables and types differences) - Integrate ESIL and decompilation ([rz-ghidra](https://github.com/rizinorg/rz-ghidra), [jsdec](https://github.com/rizinorg/jsdec)) pseudocode as an options for binary diffing - Implement the most important diffing strategies from Diaphora - Write the test cases for Rizin regression tests and improve the results. ### Skills 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. ### Difficulty Medium ### Benefits for the student Student will understand modern program analysis problems in application to binary diffing, and how to improve the performance of patch analysis. ### Benefits for the project This feature will make Rizin usable for day-to-day patch analysis of modern software, as well as improve the automation and performance of this task. ### Assess requirements for midterm/final evaluation - 1st term: rz-diff/rizin should support highlighting types, arguments, and variables differences between functions. - Fina term: Implement split-view for hex, disassembly, and graph modes. Their interface and performance improvements. Write the regression tests for all implemented features, add the documentation in Rizin book. ### Mentors - xvilka - Megabeets ### Links/Resources - [rz-diff-labeled issues](https://github.com/rizinorg/rizin/labels/rz_diff) - [Signature-labeled issues](https://github.com/rizinorg/rizin/labels/zignatures) - Cutter: Diffing interface feature request [#1104](https://github.com/rizinorg/cutter/issues/1104) - [PatchDiff2](https://github.com/filcab/patchdiff2) - [BinDiff](https://www.zynamics.com/bindiff.html) - [Diaphora](https://github.com/joxeankoret/diaphora) - [SimHash](https://github.com/googleprojectzero/functionsimsearch) ## Exploitation capabilities improvements Since modern architectures are now enforcing [W^X](https://en.wikipedia.org/wiki/W%5EX), exploiters are using [ROP](https://en.wikipedia.org/wiki/Return-oriented_programming). (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](https://www.corelan.be/index.php/2012/12/31/jingle-bofs-jingle-rops-sploiting-all-the-things-with-mona-v2/), there is also [ROPgadget](http://www.shell-storm.org/project/ROPgadget/) and [dropper](https://github.com/rizlik/dropper).There exist even tools that can generate ROP chains automatically, for example [exrop](https://github.com/d4em0n/exrop). It's a shame that despite having [ESIL](https://book.rizin.re/disassembling/esil.html), Rizin doesn't have something similar yet. One of the possible solutions would be to build an external plugin or tool which will reuse power of librz and rz-gg. Moreover it makes sense to think about SROP, COOP and BROP support. The `rz-gg` tool while has the ability to create a custom shellcode has the outdated database of the shellcodes, so [updating them](https://github.com/rizinorg/rizin/issues/154) is crucial for the tool to be relevant. ### Task 1. Update the shellcodes database, imrove `rz-gg` features and documentation 2. Implement a ropchain syntax parser that uses `rz-gg` or a custom DSL, something like: ``` register reg1 = 0; register reg2 = whatever; register reg3 = reg1 + reg2; system(reg3); ``` 3. Write a compiler which uses SMT solver (like Z3 for example) to produce the ropchain. 4. Support main architectures - x86, ARM, MIPS, PowerPC ### 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 Advanced ### 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 Rizin ;) ### Assess requirements for evaluation - 1st term: Creating the language for defining the ROP chain semantics and integrating it with SMT solver - Final term: Working ropchain compiler, covered by tests and documented in the Rizin book. ### Mentors - xvilka - ret2libc ### Links/Resources - [ROPGadget](http://shell-storm.org/project/ROPgadget/) - [Ropper](https://github.com/sashs/Ropper) - [Angrop](https://github.com/salls/angrop) - [ROPC](https://github.com/pakt/ropc) - [exrop](https://github.com/d4em0n/exrop) - [roper2](https://github.com/oblivia-simplex/roper2) - [mona.py](https://www.corelan.be/index.php/2012/12/31/jingle-bofs-jingle-rops-sploiting-all-the-things-with-mona-v2/) from corelan - [Hunting for ROP Gadgets in Style](https://media.blackhat.com/us-13/US-13-Quynh-OptiROP-Hunting-for-ROP-Gadgets-in-Style-WP.pdf) (2012) - [dropper](https://github.com/rizlik/dropper) a BARF-based rop chain generator - [Materials](http://dustri.org/b/files/hacklu2014_r2_exploitation.tar.xz) about the exloitation workshop at Hack.lu 2014 - [Slides](https://github.com/XVilka/hacklu) for the exploitation part of workshop at Hack.lu 2015 - [RzEgg related bugs](https://github.com/rizinorg/rizin/labels/RzEgg) ## Bindings for languages other than C/C++ Rizin offers a convenient scripting interface through the rz-pipe APIs, which build upon its command-based interface. While this reduced interface is beneficial and well-suited for many scripting tasks, building more complex applications generally requires direct access to the public C api that Rizin offers. Using this API is directly possible in C and C++, as it is done in Cutter for example, but for other languages no generic bindings exist so far. The goal of this task is to use a bindings generator such as SWIG to expose Rizin's C API to languages such as Python, Java or OCaml. ### Task - Integrate SWIG-generated bindings into Rizin's build system - Write SWIG interfaces for all mature parts of Rizin's C API - Integrate the Python bindings into Cutter's Python support ### Skills The student should be comfortable with the C and Python languages, as well as have a deep understanding of common memory management patterns such as ownership and reference counting. ### Difficulty Advanced ### Benefits for the student The student will gain an experience of exposing a C-based API with manual memory management to high-level, object-oriented languages with automatic memory management. ### Assess requirements for midterm/final evaluation - 1st term: Bindings can be generated as part of the standard Rizin build system and small parts of the core API are already usable. - Final term: All relevant parts of the API can be used through bindings and also from within Cutter's Python interpreter. ### Mentors - thestr4ng3r - xvilka ### Links/Resources - [SWIG Website](http://www.swig.org/) - [SWIG 4.0 Documentation](http://www.swig.org/Doc4.0/SWIGDocumentation.html) - [Small PoC of bindings generated in Rizin's build system](https://github.com/rizinorg/rizin/pull/285) - [Article about Rizin's build system design](https://rizin.re/posts/why-meson/) # Cutter ## Plugins and Python High Level API We currently don't have API almost for plugin authors to use. We need to improve a lot of things about our Plugins support and take it few steps ahead. This task is only about improving the Python interface in Cutter, specifically its graphical user interface components. For a task about exposing Rizin's API for disassembly, analysis and other purposes, see the Rizin bindings task above. ### Task - Expose everything Cutter can offer for plugins authors. This includes high level API, integration of the plugin management etc. - Accessing everything from Python (like Blender) - see [issue #1662](https://github.com/rizinorg/cutter/issues/1662) - Python integration and IPython console. ### Skills The student should be comfortable with the C++ and Python languages, and be familiar with Qt framework ### Difficulty Advanced ### Benefits for the student The student will gain an experience of creating a suitable API for scripting graphical interface programs. ### Benefits for the project It will greatly improve the scripting experience, will make API more consistent and will ease creating Cutter plugins by the community. Moreover, it will simplify testing of the Cutter features. ### Assess requirements for midterm/final evaluation - 1st term: Design of the high level API and required Rizin changes. Review and implement all missing API functions that are accessible as interface controls. - Final term: Implement the way to show the API when hovered over some interface control, create documentation. ### Mentors - thestr4ng3r - Megabeets ### Links/Resources - [SDB Module/API for Cutter Python/Jupyter integration](https://github.com/rizinorg/cutter/issues/1778) - [Jupyter plugin for Cutter](https://github.com/rizinorg/cutter-jupyter) ## Multi-Tasking and Event-driven architecture Cutter is a reverse engineering framework that is powered by Rizin. The information it gets about functions, strings, imports, and the analysis are all performed in Rizin and displayed in Cutter. Currently, Cutter is pulling information from Rizin only on demand. This is problematic because sometimes the user performs changes (via plugins, the console widget, and more) that are affecting the information from Rizin, but Cutter doesn't know about these changes to apply the to the UI. For example, if a user will define a new function in a Python script or via the console widget by using the Rizin command `af @ `, Cutter will now show this new function in the Functions widget until the user will refresh the interface manually (edit -> Refresh Contents). In addition, this task will also handle the analysis in the background feature, to allow the analysis performed by Rizin to happen while the interface is active. ### Tasks The overall implementation of this task should start from Rizin by adding events to many of the functions. This can be done using `rz_events`. For example, add an event for function creating, for section creation, for flag deletion, for name changed, and more - Add events to all the relevant functions inside Rizin - Add support for these events in Cutter and refresh and update the relevant widgets per each event - Support analysis in the background and allow the user to start its session while Rizin is analyzing (see [#1856](https://github.com/rizinorg/cutter/issues/1856), [#1574](https://github.com/rizinorg/cutter/issues/1574)) ### Skills The student should be comfortable with the C++ for Cutter and C for Rizin. The student should be familiar with Qt framework. ### Difficulty Advanced ### Benefits for the student The student will gain an experience of creating complex event-driven software in both C and C++ languages. ### Benefits for the project It will allow to work on big files effortlessly in Cutter, will improve analysis quality as well. ### Assess requirements for midterm/final evaluation - 1st term: Implement events everywhere in the relevant places across Rizin code and event-driven interaction with Cutter. - Final term: Add support for the Cutter interface refresh based on the events from Rizin, implement analysis in background. ### Mentors - thestr4ng3r - Karliss ## Heap viewer We already have a nice heap (and memory map) parser and visualizer in Rizin (`dm` and `dmh` commands). After debugging becomes a first-class citizen in cutterland it would be awesome to have memory map and heap visualizations. ### Task - Expose Rizin API/commands for Cutter to use for visualization - Design and implement heap navigation and inspection widgets - Provide the integration with current debugging mode in Cutter - Make the implementation work with both local (native) and remote debugging modes ### Skills The student should be comfortable with the C++, and be familiar with Qt framework ### Difficulty Medium ### Benefits for the student The student will gain the understanding on how modern runtimes provide the heap for various programs, which will be beneficial for the binary exploitation skills. ### Benefits for the project It will greatly improve the debugging and reverse engineering experience for complex programs, also provides the way to design the exploitation techniques with the help of Rizin/Cutter. ### Assess requirements for midterm/final evaluation - 1st term: Design and implement heap visualization widgets, add Rizin test and fixes - Final term: Various bugfixes related to the heap inspection support on various platforms and allocators, tests and documentation. ### Mentors - xvilka - Megabeets ### Links/Resources - [Issue #1041](https://github.com/rizinorg/cutter/issues/1041) - [Heap Viewer plugin for IDA Pro](https://github.com/danigargu/heap-viewer) - [Heap parsing for MacOS, tmalloc, jmalloc](https://github.com/rizinorg/rizin/issues/208) - [Dynamic Allocator Detection](https://github.com/rizinorg/rizin/issues/157) - ["heap"-marked Rizin issues](https://github.com/rizinorg/rizin/labels/heap) ## Diffing mode Binary diffing is one of the most common tasks for the reverse engineer. There are many various tools available, but most of them are either detached from the main RE toolbox or poorly integrated. Rizin provides basic diffing features out of the box with `rz-diff` tool, but Cutter has no interface to represent similar functionality. ### Task - Expose basic `rz-diff` features in the Cutter - Create the interface to choose two files for diffing - Create the way to show the differences in all main widgets: - Hexadecimal view - Disassembly view - Graph view - Pseudocode view ### Skills The student should be comfortable with the C++ language, and be familiar with Qt framework ### Difficulty Advanced ### Benefits for the student The student will gain an experience of creating efficient graphical interfaces. ### Benefits for the project It will greatly benefit the project since Cutter will be the only FOSS RE tool to provide this feature out of the box. ### Assess requirements for midterm/final evaluation - 1st term: Expose the `rz-diff` features in the Cutter core and create the interface for opening files for diffing. Implement the diff modes for hexadecimal and disassembly views. - Final term: Implement the diff modes for graph and pseudocode views, create the documentation. ### Mentors - xvilka - Megabeets ### Links/Resources - [Issue #1104](https://github.com/rizinorg/cutter/issues/1104) - [BinDiff](https://www.zynamics.com/bindiff.html) - [Diaphora](https://github.com/joxeankoret/diaphora) # Microtasks When taking any of microtasks please be sure someone isn't already working on them, and let us know if you are going to work on a particular one. ## File formats Implementing the support for any new file format counts as a microtask. See [New File-Format](https://github.com/rizinorg/ideas/labels/New%20File%20Format) label for pending issues. ## Disassemblers and assemblers Implementing the support for any new architectire counts as a microtask. See [New-Architecture](https://github.com/rizinorg/ideas/labels/New%20Architecture) label for pending issues. ## ELF binary parsing. Rizin parses a lot of information about the ELF but doesn't print everything. Thus, the improving the output of `i*` commands and `rz-bin` tool is important to match up with `readelf` ([Add file offset and memory alignment for segments information (`iSS` command)](https://github.com/rizinorg/rizin/issues/403)) Moreover, some information about [PLT stubs not being resolved correctly](https://github.com/rizinorg/rizin/issues/13). ## Analysis The current code analysis has many caveats and issues which need addressing. Fixing them and writing more tests is important to stabilize and enhance rizin's analysis engine. [See these issues](https://github.com/rizinorg/rizin/labels/RzAnalysis) or the ["Analysis" project](https://github.com/rizinorg/rizin/projects/4) on our GitHub dashboard. ### Basefind [#413](https://github.com/rizinorg/rizin/issues/413) There are plenty of external scripts and plugins for finding the most probable base for raw firmware images. Opening raw firmwares with rizin is a common use case, so it makes sense to implement it as a part of rizin core. ### Heap analysis [#157](https://github.com/rizinorg/rizin/issues/157) Currently Rizin has support for heap exploration and analysis, but the feature is still basic and can be improved. Additionally, [other allocators can be added](https://github.com/rizinorg/rizin/issues/208) (MacOS, tmalloc, etc.), but this should be done after a proper refactoring, because heap analysis shouldn't depend on the debugger backend, and we may be able to use different heap tools. ## Class analysis for C++/ObjectiveC/Swift/Dlang/Java [#416](https://github.com/rizinorg/rizin/issues/416) Analysis classes, accessible under the `ac` command, is a relatively new feature of rizin. They provide a way to both manually and automatically manage and use information about classes in the binary. ### Devirtualize method calls using class vtables [#414](https://github.com/rizinorg/rizin/issues/414) Consider the following call: `call dword [eax + 0x6c]` Let's assume eax is the base pointer of a vtable we have saved in class analysis and we want to find out the actual address of the called method. So there should be a command that takes the offset (in this case 0x6c) and looks up the actual destination. It should be possible to call this command with a specific class, so it only looks into its vtable, or without a class, so it gives a list of possible destinations for all vtables that are not too small for the offset. When that is implemented, one could also add a command that does the same thing, but automatically takes the offset from the opcode at the current seek. ### Add classes list to `Vb` `Vb` already supports browsing bin classes. The same thing should be implemented for classes from analysis. ## Signatures Rizin has a good support for loading and creating signatures, but it is not yet complete, thus some problems remain, for example: [#272](https://github.com/rizinorg/rizin/issues/272). As Rizin supports FLIRT signatures loading from IDA Pro, [not all of them are supported yet - e.g. version 5 compression](https://github.com/rizinorg/rizin/issues/417). ## Refactoring ### Use "newshell" instead of old switch/case handling Rizin is in the middle of the switch from the old style switch/case manual parsing of every command to the centralized [Tree-Sitter](https://tree-sitter.github.io/tree-sitter/)-based parser, providing every command handler `argc`/`argv` arguments. Best candidates for the initial switch are: - `librz/core/cmd_egg.c` - `librz/core/cmd_hash.c` - `librz/core/cmd_plugins.c` A good example of transition is in these pull requests for `t` (types) command conversion: - [Migrating Types to the Newshell (1)](https://github.com/rizinorg/rizin/pull/700) - [Migrating Types to the Newshell (2)](https://github.com/rizinorg/rizin/pull/728) - [Migrating Types to the Newshell (3)](https://github.com/rizinorg/rizin/pull/739) - [Adding autocompletion for types commands](https://github.com/rizinorg/rizin/pull/785) ### Use internal API instead of commands Currently, Rizin's source code is rife with calls to `rz_core_cmd()`-like functions that run the Rizin command. While it is a useful shortcut for developer, it makes a good source of the potential bugs in case of the command syntax or behavior change. If these changes happen they are invisible to the compiler, so it cannot warn on the changed syntax. It isn't the case of changed function arguments count or type. Thus, all these calls eventually should be substituted with direct calls to the corresponding API functions. If there is no corresponding API function, then one should be created. Good examples of such cases are: - [Refactor Graph processing from commands to the API use](https://github.com/rizinorg/rizin/issues/397) - [Refactor Visual mode from commands to the API use](https://github.com/rizinorg/rizin/issues/382) - [Refactor Panels mode from commands to the API use](https://github.com/rizinorg/rizin/issues/383) In general you can just search for `rz_core_cmd` pattern in any place inside `librz/`. ### Improving the uplifting of the code to IL Rizin has its own intermediate language - ESIL, but not yet support it for all architectures. So the task is to add ESIL support to any architecture, which doesn't has it yet. ## Miscellaneous ### Shell (dietline) improvements Currently Rizin uses its own readline-compatible implementation of the input handling in the embedded shell that is compact and portable between all supported platforms. It supports both Emacs and Vi modes, but not all bindings and features are supported. Some are omitted by choice, but some were simply not implemented. See the ["dietline"-labeled issues](https://github.com/rizinorg/rizin/labels/dietline). ### Improving regression suite and testing It is required to solve [numerous issues](https://github.com/rizinorg/rizin/labels/rz-test), along with improving parallel execution and performance. Good example is to allow better filtering of the test types to run, for example to [ignore debug tests](https://github.com/rizinorg/rizin/issues/336). The next interesting idea is to setup and reuse Godbolt compilation engine for generating tests for different compilers and compilation options. There is even a command line tool for interacting with Godbolt - [cce](https://github.com/ethanhs/cce). Another important part of the improving test suite is to cover more different formats and cases with expanding it. See the [#114 issue](https://github.com/rizinorg/rizin/issues/114) with more details on how it can be done. ## RzGhidra There are many small issues in the decompiler output: - [String detection problem](https://github.com/rizinorg/rz-ghidra/issues/85) and [one more](https://github.com/rizinorg/rz-ghidra/issues/73). - [Show function arguments in calls](https://github.com/rizinorg/rz-ghidra/issues/74) - [`pdgsd` commands showing incorrect P-code](https://github.com/rizinorg/rz-ghidra/issues/172) - [Prioritize keeping vars with lower addresses](https://github.com/rizinorg/rz-ghidra/issues/167) - [Minor improvements for the SLEIGH plugin](https://github.com/rizinorg/rz-ghidra/issues/133) Some of these issues might be related on how Rizin and RzGhidra integrate and might require changes in the Rizin side. Also note that most of these issues should be paired with the test to verify it will not break in the future. --- ## File: content/gsoc/2022.md --- title: "GSoC 2022" layout: "single" ShowToc: true TocOpen: false ShowReadingTime: false date: "2022-02-11" --- **TL;DR** Jump to the [Ideas list](#project-ideas). # Introduction This year is the second time we participate as a fork - Rizin, effectively continuing the tradition since the year 2015 (as the radare2 project). ## Mentors Members of the Rizin and Cutter core teams have volunteered to guide participants for GSoC’22. They were already guiding the participants for the GSoC and RSoC in past years. Please feel free to reach out to any of them in case you need any help in selecting a project. - **Anton Kochkov** Mattermost: xvilka -- [@akochkov](https://twitter.com/akochkov) - **Riccardo Schirone** Mattermost: ret2libc - **Florian Märkl** Mattermost/Telegram: @thestr4ng3r -- [@thestr4ng3r](https://twitter.com/thestr4ng3r) - **Itay Cohen** Mattermost/Telegram: @Megabeets [@Megabeets\_](https://twitter.com/Megabeets_) - **Giovanni Dante Grazioli** Mattermost/Telegram: @deroad [@der0ad](https://twitter.com/der0ad) - **Yossi Zapesochini** Mattermost/Telegram: @yossizap - And many others ## Development methodology Currently, all repositories are hosted on GitHub [main](https://github.com/rizinorg/) organization account, bugs are tracked on GitHub [issues](https://github.com/rizinorg/rizin/issues) too. We are mostly using [our own Mattermost instance](https://im.rizin.re), IRC, and [Telegram](https://t.me/rizinorg)) for communication. We have a [testsuite](https://github.com/rizinorg/rizin/tree/dev/test) (which is running on GitHub Actions, [Travis CI](https://travis-ci.com/rizinorg/rizin), [AppVeyor](https://ci.appveyor.com/project/rizinorg/rizin) and SourceHut) to test and verify that all the features are still working and that a pull requests or commits don't break anything, to ensure the support of different operating systems (Linux, MacOS, Windows, FreeBSD, OpenBSD), different architectures (x86/x86_64, ARM64, PowerPC, SystemZ), 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. For complex bugs and examples we're using [ASCIInema](http://asciinema.org/) for recording the sessions. See also our guides for corresponding projects: - Rizin [Contributing Guide](https://github.com/rizinorg/rizin/blob/dev/CONTRIBUTING.md) and [Developers Intro](https://github.com/rizinorg/rizin/blob/dev/DEVELOPERS.md) - Cutter [Contributing Guide](https://github.com/rizinorg/cutter/blob/master/CONTRIBUTING.md) and [Developers Intro](https://cutter.re/docs/code.html) For those who want to get introduced to the Rizin codebase and practices, we recommend to pick one of the easy issues for [Rizin](https://github.com/rizinorg/rizin/labels/good%20first%20issue) or [Cutter](https://github.com/rizinorg/cutter/labels/good%20first%20issue) to start with. ## License Rizin is modular: this means that it aims to make all the elements and features easily reusable from other projects. The choice of [LGPL3](https://www.gnu.org/licenses/lgpl.html) as a license is the minimum requirement to get code merged in Rizin. 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 Rizin, while protecting our free codebase. ## Instructions for participants It is a requirement that participants who want to apply to the Rizin project for the Google Summer of Code 2022 should submit a small pull request accomplishing one of the [microtasks](#microtasks) (see below) as part of their application. Though you can also choose any of the GitHub issues for Rizin if they are big enough to be a qualification task, and still small enough to be finished no more than in a couple of weeks. To help participants to understand how to contribute to the project there are issues marked as **"good first issue"** for both [Rizin](https://github.com/rizinorg/rizin/labels/good%20first%20issue) and [Cutter](https://github.com/rizinorg/cutter/labels/good%20first%20issue). ## Programming languages Most of Rizin is written in C (conforming C99 standard) and hence we expect participants to be familiar with C programming language. For some of our tasks or microtasks, such as [rz-pm](https://github.com/rizinorg/rz-pm), they should know the Go programming language. For the [Cutter tasks](#cutter), it is a requirement to know C++ and Qt framework basics. ## Recommended steps 1. Read Google's instructions for participating 2. Grab any of the project from the list of ideas that you're interested in (or propose your own). 3. Write a first draft proposal using Google Docs and [our template](https://docs.google.com/document/d/1kDPGgr_D5tQuYLQi_gEGlkuQ-DlU8GH5kDBqZbVSC7I/edit?usp=sharing) and ask one of the mentors or administrators to review it with you. 4. Submit it using Google's web interface. ## Participant proposal guidelines 1. Keep it simple enough to fit in no more than a couple of pages. Try to be clear and concise in your writing. 2. Try to split the entire GSoC period into tasks, and each task into subtasks. It helps us to understand how you plan to accomplish your goals, but more importantly, it'll help you to understand the task deep enough before starting, and prioritize important things to do first. 3. Please note how much time a day/week you are able to spend on this project. 4. Please specify which category you apply for - medium task or extended deadline one. 5. Specify your timezone, since so we can assign you a mentor in the same one, to ease communication. 6. Submit your proposal early, not in the last minute! 7. Be sure to choose a “backup” idea (the second task you want to do), so that conflicts (two participants for one task) can be resolved. # Project Ideas ## Rizin ## RzIL uplifting migration (350 hour project) Rizin has had an intermediate language for over a decade. Major architectures are supporting uplifting to ESIL. During the RSoC 2021, the initial version of the [new intermediate language](https://github.com/rizinorg/rizin/blob/dev/doc/rzil.md), which is based on the BAP's Core Theory was implemented. In the following months it was improved and some of the architectures were ported to use RZIL instead of ESIL. The main goal of this project is to finish the migration of one or more existing architectures that still use ESIL or add a RzIL support for the architectures that hadn't any uplifting at all. ### Tasks - Implement a RZIL uplifting for any non-trivial architecture, preferably that is supported by ESIL already - Improve the integration with analysis (variables and types differences) for the chosen architecture - Write the test cases for Rizin regression tests and improve the results. - Update and use [rz-tracetest](https://github.com/rizinorg/rz-tracetest) for the chosen architectures - Implement necessary commands and APIs in Rizin for visual representation of the IL tree - Implement standard and graph views in Cutter for the IL output (optional) Due to the sensivity of uplifting to the precision, it's important to follow these steps: - For every single lifted opcode, have at the very least one asm test in `test/db/asm/...` containing the IL to detect changes when the code is changed and have it type-checked. This should produce 100% coverage on the lifter C code (except e.g. `malloc()` error handling). - Run `rz-tracetest` on real traces. It's also possible to write custom assembly programs that execute specific obscure instructions where it's hard to be sure that they were implemented correctly on many random inputs and then feed these executions into `rz-tracetest`. - Few `rz-test` command tests that emulate some code snippets in rizin. For example a simple decryption loop to check the overall integration in rizin, or for specific edge cases (like running a division by zero). ### Skills The participant should know C and bits of C++ as well as be familiar with basics of the program analysis. Having an experience with other intermediate language, SAT/SMT, and mathematical logic is a plus. ### Difficulty Medium ### Benefits for the participant The participant will understand the state of the art of intermediate languages research, it's relation to the mathematical logic, SMT, and program analysis. Moreover, the participant will become familiar with the both symbolic and concrete emulation during the implementation process. ### Benefits for the project Migrating most architectures will help to deprecate and remove outdated ESIL and will help improving the analysis precision. Adding uplifting for new architectures that weren't even supported by ESIL will imrove the analysis to even greater degree. ### Assess requirements for midterm/final evaluation - 1st term: finish the RZIL uplifting for the chosen architecture with basic instruction-level tests - Final term: implement all changes in the analysis code, added more complex integration tests with types analysis ### Mentors - xvilka - thestr4ng3r ### Links/Resources - [RZIL-labeled issues](https://github.com/rizinorg/rizin/labels/RZIL) - [ESIL-labeled issues](https://github.com/rizinorg/rizin/labels/RZIL) - [ESIL to RZIL conversion tracking issue](https://github.com/rizinorg/rizin/issues/2080) - [Cutter: IL output and graph visual representation](https://github.com/rizinorg/rizin/issues/1133) ## Debug information handling improvements (175 hour project) Rizin already supports most of the DWARF and PDB features, including cross-platform parsing of both. However information are usually just printed to aid the reverse engineering process, but they are not actually used at their best. For example, you can't use them to configure a breakpoint, nor they can be used to access variables within a function during debugging. Moreover, it is becoming more and more common to store DWARF information in separate files, either shipped as separate file or downloaded on the fly with `debuginfod`. Rizin does not support these kind of DWARF files yet. Your task would be to improve the parsing support of both by fixing smaller bugs, add support for separate DWARF files and `debuginfod` and enhance breakpoint integration and variable/structure printing in debugging mode with the source information gathered from DWARF/PDB. ### Task 1. Support loading DWARF information from separate files and `debuginfod` 2. Unify source lines/types information access for DWARF, PDB, dSYM and refactor/fix parsing code as necessary 3. Integrate source line and types/variables information with the analysis (optional) 4. Integrate source line and types/variables with printing with `p` commands in the debug mode 5. Integrate source line and types/variables with breakpoint commands and APIs 6. Parsing performance improvements ### Skills * Good knowledge of the C language * Some experience in debugging with GDB or LLDB * Basic knowledge of at least one of the following formats: ELF, DWARF, PDB, PE ### Difficulty Hard ### Benefits for the participant Participant will understand how high-level features of debuggers work as well as gain skills in the field of software architecture of a large, modular C project. ### Assess requirements for midterm/final evaluation - 1st term: `debuginfod` and source line information refactoring are implemented - Final term: Integration of variable information with the debug and printing commands is implemented ### Mentors - xvilka - thestr4ng3r - ret2libc ### Links/Resources - [Loading debug information from `debuginfod`](https://github.com/rizinorg/rizin/issues/1285) - [Unify code of source information access for DWARF, PDB, dSYM](https://github.com/rizinorg/rizin/issues/907) - [Ghidra issue: support DWARF in MinGW PE binaries](https://github.com/NationalSecurityAgency/ghidra/issues/1267) - [Debuginfod](https://sourceware.org/elfutils/Debuginfod) - [Debian Debuginfod](https://wiki.debian.org/Debuginfod) - [Fedora Debuginfod](https://fedoraproject.org/wiki/Debuginfod) - [DWARF-labeled issues](https://github.com/rizinorg/rizin/labels/DWARF) - [PDB-labaled issues](https://github.com/rizinorg/rizin/labels/PDB) ## Thread-safety and multithreading (175 hour project) Currently Rizin is not thread safe completely internally and as a library for a multithreaded application. The goal of this project is to eliminate global states and use contexts, eliminate singletons, e.g. RzCons, and use thread-safe external functions and dependencies. ### Task 1. Migrate from thread-unsafe system and external dependencies 2. Eliminate global state inside RzCons and use of the singleton 3. Make RzBin thread-safe 4. Make RzAnalysis thread-safe 5. Make RzCore thread-safe 6. Add tests for using multiple RzCore and RzAnalysis instances 7. Parallelize some of the RzAnalysis function using the threading API ### Skills Participant should know C as well as have the experience of developing multithreaded applications. ### Difficulty Hard ### Benefits for the participant Participant will understand the hurdles of multithreaded programming, data synchronization, locks and debugging of such code. ### Assess requirements for midterm/final evaluation - 1st term: Eliminate thread-unsafe dependencies and remove global state from RzCons and RzBin - Final term: Make RzAnalysis and RzCore (optionally) thread-safe ### Mentors - xvilka - thestr4ng3r - wargio ### Links/Resources - [Migrate from `wcstombs()` function since it's not thread-safe](https://github.com/rizinorg/rizin/issues/1058) ## Rewriting GPL-only code (175 hour project) Currently some of the Rizin main features rely on the GPL-only code copied from binutils or GCC. The goal is to rewrite all this code from GPL-only to LGPL or any other less restrictive license. It is quite important for better adoption of Rizin as a library in other FOSS and commercial projects. ## Tasks 1. Rewrite C++ demangler to and remove the GPL code 2. Rewrite some of the mainstream architectures that still rely on binutils without using GPL-only code Good example of such architectures are: - SPARC (there is already capstone-based RzAsm and RzAnalysis plugin but it's less complete than binutils-based one) - Xtensa - Tricore - SH - HPPA (PA-RISC) ### Skills Participant should know C and basics of C++ for understanding the mangling scheme ### Difficulty Medium ### Benefits for the participant Participant will understand how C++ type information is stored in the name of the methods and classes. ### Assess requirements for midterm/final evaluation - 1st term: Basic demangling for C++ is rewritten under less restrictive license. - Final term: At least one binutils-based architecture is reimplemented with more permissive license. ### Mentors - xvilka - thestr4ng3r - wargio ### Links/Resources - [rz-libdemangle: rewrite/remove GPL-only code](https://github.com/rizinorg/rz-libdemangle/issues/3) - [Update binutils code to latest](https://github.com/rizinorg/rizin/issues/814) ## Exploitation capabilities improvements (175 hour project) Since modern architectures are now enforcing [W^X](https://en.wikipedia.org/wiki/W%5EX), exploiters are using [ROP](https://en.wikipedia.org/wiki/Return-oriented_programming). (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](https://www.corelan.be/index.php/2012/12/31/jingle-bofs-jingle-rops-sploiting-all-the-things-with-mona-v2/), there is also [ROPgadget](http://www.shell-storm.org/project/ROPgadget/) and [dropper](https://github.com/rizlik/dropper).There exist even tools that can generate ROP chains automatically, for example [exrop](https://github.com/d4em0n/exrop). It's a shame that despite having [ESIL](https://book.rizin.re/disassembling/esil.html), Rizin doesn't have something similar yet. One of the possible solutions would be to build an external plugin or tool which will reuse power of librz and rz-gg. Moreover it makes sense to think about SROP, COOP and BROP support. The `rz-gg` tool while has the ability to create a custom shellcode has the outdated database of the shellcodes, so [updating them](https://github.com/rizinorg/rizin/issues/154) is crucial for the tool to be relevant. ### Task 1. Update the shellcodes database, imrove `rz-gg` features and documentation 2. Implement a ropchain syntax parser that uses `rz-gg` or a custom DSL, something like: ``` register reg1 = 0; register reg2 = whatever; register reg3 = reg1 + reg2; system(reg3); ``` 3. Write a compiler which uses SMT solver (like Z3 for example) to produce the ropchain. 4. Support main architectures - x86, ARM, MIPS, PowerPC ### Skills The participant 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 Advanced ### Benefits for the participant The participant 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 Rizin ;) ### Assess requirements for evaluation - 1st term: Creating the language for defining the ROP chain semantics and integrating it with SMT solver - Final term: Working ropchain compiler, covered by tests and documented in the Rizin book. ### Mentors - xvilka - ret2libc ### Links/Resources - [ROPGadget](http://shell-storm.org/project/ROPgadget/) - [Ropper](https://github.com/sashs/Ropper) - [Angrop](https://github.com/salls/angrop) - [ROPC](https://github.com/pakt/ropc) - [exrop](https://github.com/d4em0n/exrop) - [roper2](https://github.com/oblivia-simplex/roper2) - [mona.py](https://www.corelan.be/index.php/2012/12/31/jingle-bofs-jingle-rops-sploiting-all-the-things-with-mona-v2/) from corelan - [Hunting for ROP Gadgets in Style](https://media.blackhat.com/us-13/US-13-Quynh-OptiROP-Hunting-for-ROP-Gadgets-in-Style-WP.pdf) (2012) - [dropper](https://github.com/rizlik/dropper) a BARF-based rop chain generator - [Materials](http://dustri.org/b/files/hacklu2014_r2_exploitation.tar.xz) about the exloitation workshop at Hack.lu 2014 - [Slides](https://github.com/XVilka/hacklu) for the exploitation part of workshop at Hack.lu 2015 - [RzEgg related bugs](https://github.com/rizinorg/rizin/labels/RzEgg) ## Bindings for languages other than C/C++ (175 hour project) Rizin offers a convenient scripting interface through the rz-pipe APIs, which build upon its command-based interface. While this reduced interface is beneficial and well-suited for many scripting tasks, building more complex applications generally requires direct access to the public C api that Rizin offers. Using this API is directly possible in C and C++, as it is done in Cutter for example, but for other languages no generic bindings exist so far. The goal of this task is to use a bindings generator such as SWIG to expose Rizin's C API to languages such as Python, Java or OCaml. ### Task - Integrate SWIG-generated bindings into Rizin's build system - Write SWIG interfaces for all mature parts of Rizin's C API - Integrate the Python bindings into Cutter's Python support ### Skills The participant should be comfortable with the C and Python languages, as well as have a deep understanding of common memory management patterns such as ownership and reference counting. ### Difficulty Advanced ### Benefits for the participant The participant will gain an experience of exposing a C-based API with manual memory management to high-level, object-oriented languages with automatic memory management. ### Assess requirements for midterm/final evaluation - 1st term: Bindings can be generated as part of the standard Rizin build system and small parts of the core API are already usable. - Final term: All relevant parts of the API can be used through bindings and also from within Cutter's Python interpreter. ### Mentors - thestr4ng3r - xvilka ### Links/Resources - [SWIG Website](http://www.swig.org/) - [SWIG 4.0 Documentation](http://www.swig.org/Doc4.0/SWIGDocumentation.html) - [Small PoC of bindings generated in Rizin's build system](https://github.com/rizinorg/rizin/pull/285) - [Article about Rizin's build system design](https://rizin.re/posts/why-meson/) # Cutter ## Plugins and Python High Level API (175 hour project) Our current public API to be used by plugin authors is somewhat limited. We need to improve a lot of things about our Plugins support and take it few steps ahead. This task is only about improving the public C++ and Python interface of Cutter, specifically its graphical user interface components. For a task about exposing Rizin's API for disassembly, analysis and other purposes, see the Rizin bindings task above. ### Task - Expose everything Cutter can offer for plugins authors. This includes high level API, integration of the plugin management etc. - Accessing everything from Python (like Blender) - see [issue #1662](https://github.com/rizinorg/cutter/issues/1662) - Python integration and IPython console. ### Skills The participant should be comfortable with the C++ and Python languages, and be familiar with Qt framework ### Difficulty Advanced ### Benefits for the participant The participant will gain an experience of creating a suitable API for scripting graphical interface programs. ### Benefits for the project It will greatly improve the scripting experience, will make API more consistent and will ease creating Cutter plugins by the community. Moreover, it will simplify testing of the Cutter features. ### Assess requirements for midterm/final evaluation - 1st term: Design of the high level API and required Rizin changes. Review and implement all missing API functions that are accessible as interface controls. - Final term: Implement the way to show the API when hovered over some interface control, create documentation. ### Mentors - thestr4ng3r - Megabeets ### Links/Resources - [SDB Module/API for Cutter Python/Jupyter integration](https://github.com/rizinorg/cutter/issues/1778) - [Jupyter plugin for Cutter](https://github.com/rizinorg/cutter-jupyter) ## Multi-Tasking and Event-driven architecture (350 hour project) The information Cutter gets about functions, strings, imports, and the analysis are all performed in Rizin and only displayed in Cutter. Currently, it is pulling most information from Rizin only on demand. This is problematic because sometimes the user performs changes (via plugins, the console widget, and more) that are affecting the information from Rizin, but Cutter doesn't know about these changes to apply the to the UI. For example, if a user will define a new function in a Python script or via the console widget by using the Rizin command `af @ `, Cutter will not show this new function in the Functions widget until the user will refresh the interface manually (Edit -> Refresh Contents). The goal of this task is to use an event-driven architecture to overcome this limitation. In addition, this task will also handle the analysis in the background feature, to allow the analysis performed by Rizin to happen while the interface is active. ### Tasks The overall implementation of this task should start from Rizin by adding events to many of the functions. This can be done using `rz_events`. For example, add an event for function creating, for section creation, for flag deletion, for name changed, and more - Add events to all the relevant functions inside Rizin - Add support for these events in Cutter and refresh and update the relevant widgets per each event - Support analysis in the background and allow the user to start its session while Rizin is analyzing (see [#1856](https://github.com/rizinorg/cutter/issues/1856), [#1574](https://github.com/rizinorg/cutter/issues/1574)) ### Skills The participant should be comfortable with the C++ for Cutter and C for Rizin. They should also be familiar with Qt framework. Experience in GUI code architecture, for example using functional reactive programming or Elm-like approaches is a plus. ### Difficulty Advanced ### Benefits for the participant The participant will gain an experience of creating complex event-driven software in both C and C++ languages. ### Benefits for the project It will allow to work on big files effortlessly in Cutter, will improve analysis quality as well. ### Assess requirements for midterm/final evaluation - 1st term: Implement events everywhere in the relevant places across Rizin code and event-driven interaction with Cutter. - Final term: Add support for the Cutter interface refresh based on the events from Rizin, implement analysis in background. ### Mentors - thestr4ng3r ## Heap viewer completion (175 hour project) Thanks to the work that was done in the previous GSoC, Cutter and Rizin have nice visualizations of the heap and memory maps. We would like to expand on this feature with performance improvements to the heap parsers and support more memory allocators. ### Task - Complete Cutter's implementation of the windows heap widget #[2723](https://github.com/rizinorg/cutter/pull/2723) - Improve the performance of the Windows heap parser - Fix Windows heap parsing errors - Make the implementation work with remote debugging modes ### Skills The participant should be comfortable with the C++, and be familiar with Qt framework ### Difficulty Medium ### Benefits for the participant The participant will gain the understanding on how modern runtimes provide the heap for various programs, which will be beneficial for the binary exploitation skills. ### Benefits for the project It will greatly improve the debugging and reverse engineering experience for complex programs, also provides the way to design the exploitation techniques with the help of Rizin/Cutter. ### Assess requirements for midterm/final evaluation - 1st term: Design and implement heap visualization widgets, add Rizin test and fixes - Final term: Various bugfixes related to the heap inspection support on various platforms and allocators, tests and documentation. ### Mentors - xvilka - Megabeets - yossizap ### Links/Resources - [Issue #1041](https://github.com/rizinorg/cutter/issues/1041) - [Heap Viewer plugin for IDA Pro](https://github.com/danigargu/heap-viewer) - [Heap parsing for MacOS, tmalloc, jmalloc](https://github.com/rizinorg/rizin/issues/208) - [Dynamic Allocator Detection](https://github.com/rizinorg/rizin/issues/157) - ["heap"-marked Rizin issues](https://github.com/rizinorg/rizin/labels/heap) ## Diffing mode (175 hour project) Binary diffing is one of the most common tasks for the reverse engineer. There are many tools available, but most of them are either detached from the main RE toolbox or poorly integrated. Rizin provides basic diffing features out of the box with `rz-diff` tool, but Cutter has no interface to represent similar functionality. ### Task - Expose basic `rz-diff` features in the Cutter - Create the interface to choose two files for diffing - Create the way to show the differences in all main widgets: - Hexadecimal view - Disassembly view - Graph view - Pseudocode view ### Skills The participant should be comfortable with the C++ language, and be familiar with Qt framework ### Difficulty Medium ### Benefits for the participant The participant will gain an experience of creating efficient graphical interfaces. ### Benefits for the project It will greatly benefit the project since Cutter will be the only FOSS RE tool to provide this feature out of the box. ### Assess requirements for midterm/final evaluation - 1st term: Expose the `rz-diff` features in the Cutter core and create the interface for opening files for diffing. Implement the diff modes for hexadecimal and disassembly views. - Final term: Implement the diff modes for graph and pseudocode views, create the documentation. ### Mentors - xvilka - Megabeets ### Links/Resources - [Issue #1104](https://github.com/rizinorg/cutter/issues/1104) - [BinDiff](https://www.zynamics.com/bindiff.html) - [Diaphora](https://github.com/joxeankoret/diaphora) # Microtasks When taking any of microtasks please be sure someone isn't already working on them, and let us know if you are going to work on a particular one. ## File formats Implementing the support for any new file format counts as a microtask. See [New File-Format](https://github.com/rizinorg/ideas/labels/New%20File%20Format) label for pending issues. ## Disassemblers and assemblers Implementing the support for any new architecture counts as a microtask. See [New-Architecture](https://github.com/rizinorg/ideas/labels/New%20Architecture) label for pending issues. ## ELF binary parsing. Rizin parses a lot of information about the ELF but doesn't print everything. Moreover, some information about [PLT stubs not being resolved correctly](https://github.com/rizinorg/rizin/issues/13). ## Analysis The current code analysis has many caveats and issues which need addressing. Fixing them and writing more tests is important to stabilize and enhance rizin's analysis engine. [See these issues](https://github.com/rizinorg/rizin/labels/RzAnalysis) or the ["Analysis" project](https://github.com/rizinorg/rizin/projects/4) on our GitHub dashboard. ### Heap analysis [#157](https://github.com/rizinorg/rizin/issues/157) Currently Rizin has support for heap exploration and analysis, but the feature is still basic and can be improved. Additionally, [other allocators can be added](https://github.com/rizinorg/rizin/issues/208) (MacOS, tmalloc, etc.), but this should be done after a proper refactoring, because heap analysis shouldn't depend on the debugger backend, and we may be able to use different heap tools. ## Class analysis for C++/ObjectiveC/Swift/Dlang/Java [#416](https://github.com/rizinorg/rizin/issues/416) Analysis classes, accessible under the `ac` command, is a relatively new feature of rizin. They provide a way to both manually and automatically manage and use information about classes in the binary. ### Devirtualize method calls using class vtables [#414](https://github.com/rizinorg/rizin/issues/414) Consider the following call: `call dword [eax + 0x6c]` Let's assume eax is the base pointer of a vtable we have saved in class analysis and we want to find out the actual address of the called method. So there should be a command that takes the offset (in this case 0x6c) and looks up the actual destination. It should be possible to call this command with a specific class, so it only looks into its vtable, or without a class, so it gives a list of possible destinations for all vtables that are not too small for the offset. When that is implemented, one could also add a command that does the same thing, but automatically takes the offset from the opcode at the current seek. ### Add classes list to `Vb` `Vb` already supports browsing bin classes. The same thing should be implemented for classes from analysis. ## Refactoring ### Use internal API instead of commands Currently, Rizin's source code is rife with calls to `rz_core_cmd()`-like functions that run the Rizin command. While it is a useful shortcut for developer, it makes a good source of the potential bugs in case of the command syntax or behavior change. If these changes happen they are invisible to the compiler, so it cannot warn on the changed syntax. It isn't the case of changed function arguments count or type. Thus, all these calls eventually should be substituted with direct calls to the corresponding API functions. If there is no corresponding API function, then one should be created. Good examples of such cases are: - [Refactor Graph processing from commands to the API use](https://github.com/rizinorg/rizin/issues/397) - [Refactor Visual mode from commands to the API use](https://github.com/rizinorg/rizin/issues/382) - [Refactor Panels mode from commands to the API use](https://github.com/rizinorg/rizin/issues/383) In general you can just search for `rz_core_cmd` pattern in any place inside `librz/`. ## Miscellaneous ### Shell (dietline) improvements Currently Rizin uses its own readline-compatible implementation of the input handling in the embedded shell that is compact and portable between all supported platforms. It supports both Emacs and Vi modes, but not all bindings and features are supported. Some are omitted by choice, but some were simply not implemented. See the ["dietline"-labeled issues](https://github.com/rizinorg/rizin/labels/dietline). ### Improving regression suite and testing It is required to solve [numerous issues](https://github.com/rizinorg/rizin/labels/rz-test), along with improving parallel execution and performance. Good example is to allow better filtering of the test types to run, for example to [ignore debug tests](https://github.com/rizinorg/rizin/issues/336). The next interesting idea is to setup and reuse Godbolt compilation engine for generating tests for different compilers and compilation options. There is even a command line tool for interacting with Godbolt - [cce](https://github.com/ethanhs/cce). Another important part of the improving test suite is to cover more different formats and cases with expanding it. See the [#114 issue](https://github.com/rizinorg/rizin/issues/114) with more details on how it can be done. ### Unbreaking broken tests Almost one thousand of tests marked as "broken" in our testsuite. The task is to take any of those, investigate why it fails, if the test makes sense now or already irrelevant today. Then to try to fix some of the broken tests. ## Better portability Due to the mistakes in handling data for big-endian platforms in Rizin code a lot of tests still don't pass on our System Z CI worker. Most of the broken test are related to parsing the formats, in particular reading the integers in portable way. See [#297](https://github.com/rizinorg/rizin/issues/297) for details on these formats. In most cases the solution would be to use `rz_read_*()` API functions: [Developers Guide: Manage Endianess](https://github.com/rizinorg/rizin/blob/dev/DEVELOPERS.md#manage-endianness). ## RzGhidra There are many small issues in the decompiler output: - [`pdgsd` commands showing incorrect P-code](https://github.com/rizinorg/rz-ghidra/issues/172) - [Improvements in recovering jump tables](https://github.com/rizinorg/rz-ghidra/issues/236) - [rz-ghidra can't detect string](https://github.com/rizinorg/rz-ghidra/issues/85) - [Ghidra Decompiler Error: Could not finish collapsing block structure](https://github.com/rizinorg/rz-ghidra/issues/203) - [Mishandled tail jump with relocation inside the jump function](https://github.com/rizinorg/rz-ghidra/issues/202) - [Prioritize keeping vars with lower addresses](https://github.com/rizinorg/rz-ghidra/issues/167) - [Minor improvements for the SLEIGH plugin](https://github.com/rizinorg/rz-ghidra/issues/133) Some of these issues might be related on how Rizin and RzGhidra integrate and might require changes in the Rizin side. Also note that most of these issues should be paired with the test to verify it will not break in the future. --- ## File: content/gsoc/2023.md --- title: "GSoC 2023" layout: "single" ShowToc: true TocOpen: false ShowReadingTime: false date: "2023-01-24" --- **TL;DR** Jump to the [Ideas list](#project-ideas). # Introduction This year is the third time we participate as Rizin, effectively continuing the tradition since the year 2015. ## Mentors Members of the Rizin and Cutter core teams have volunteered to guide participants for GSoC’23. They were already guiding the participants for the GSoC and RSoC in past years. Please feel free to reach out to any of them in case you need any help in selecting a project. - **Anton Kochkov** Mattermost: xvilka -- [@akochkov](https://twitter.com/akochkov) - **Riccardo Schirone** Mattermost: ret2libc [@RickySkiro](https://twitter.com/RickySkiro) - **Florian Märkl** Mattermost/Telegram: @thestr4ng3r -- [@thestr4ng3r](https://muenchen.social/@thestr4ng3r) - **Itay Cohen** Mattermost/Telegram: @Megabeets [@Megabeets\_](https://twitter.com/Megabeets_) - **Giovanni Dante Grazioli** Mattermost/Telegram: @deroad [@der0ad](https://twitter.com/der0ad) - And many others ## Development methodology Currently, all repositories are hosted on GitHub [main](https://github.com/rizinorg/) organization account, bugs are tracked on GitHub [issues](https://github.com/rizinorg/rizin/issues) too. We are mostly using [our own Mattermost instance](https://im.rizin.re), IRC, and [Telegram](https://t.me/rizinorg)) for communication. We have a [testsuite](https://github.com/rizinorg/rizin/tree/dev/test) (which is running on GitHub Actions, [Travis CI](https://travis-ci.com/rizinorg/rizin), [AppVeyor](https://ci.appveyor.com/project/rizinorg/rizin) and SourceHut) to test and verify that all the features are still working and that a pull requests or commits don't break anything, to ensure the support of different operating systems (Linux, MacOS, Windows, FreeBSD, OpenBSD), different architectures (x86/x86_64, ARM64, PowerPC, SystemZ), 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. For complex bugs and examples we're using [ASCIInema](http://asciinema.org/) for recording the sessions. See also our guides for corresponding projects: - Rizin [Contributing Guide](https://github.com/rizinorg/rizin/blob/dev/CONTRIBUTING.md) and [Developers Intro](https://github.com/rizinorg/rizin/blob/dev/DEVELOPERS.md) - Cutter [Contributing Guide](https://github.com/rizinorg/cutter/blob/master/CONTRIBUTING.md) and [Developers Intro](https://cutter.re/docs/code.html) For those who want to get introduced to the Rizin codebase and practices, we recommend to pick one of the easy issues for [Rizin](https://github.com/rizinorg/rizin/labels/good%20first%20issue) or [Cutter](https://github.com/rizinorg/cutter/labels/good%20first%20issue) to start with. ## License Rizin is modular: this means that it aims to make all the elements and features easily reusable from other projects. The choice of [LGPL3](https://www.gnu.org/licenses/lgpl.html) as a license is the minimum requirement to get code merged in Rizin. 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 Rizin, while protecting our free codebase. ## Instructions for participants It is a requirement that participants who want to apply to the Rizin project for the Google Summer of Code 2023 should submit a small pull request accomplishing one of the [microtasks](#microtasks) (see below) as part of their application. Though you can also choose any of the GitHub issues for Rizin if they are big enough to be a qualification task, and still small enough to be finished no more than in a couple of weeks. To help participants to understand how to contribute to the project there are issues marked as **"good first issue"** for both [Rizin](https://github.com/rizinorg/rizin/labels/good%20first%20issue) and [Cutter](https://github.com/rizinorg/cutter/labels/good%20first%20issue). ## Programming languages Most of Rizin is written in C (conforming C99 standard) and hence we expect participants to be familiar with C programming language. For some of our tasks or microtasks, such as [rz-pm](https://github.com/rizinorg/rz-pm), they should know the Go programming language. For the [Cutter tasks](#cutter), it is a requirement to know C++ and Qt framework basics. ## Recommended steps 1. Read Google's instructions for participating 2. Grab any of the project from the list of ideas that you're interested in (or propose your own). 3. Write a first draft proposal using Google Docs and [our template](https://docs.google.com/document/d/1kDPGgr_D5tQuYLQi_gEGlkuQ-DlU8GH5kDBqZbVSC7I/edit?usp=sharing) and ask one of the mentors or administrators to review it with you. 4. Submit it using Google's web interface. ## Participant proposal guidelines 1. Keep it simple enough to fit in no more than a couple of pages. Try to be clear and concise in your writing. 2. Try to split the entire GSoC period into tasks, and each task into subtasks. It helps us to understand how you plan to accomplish your goals, but more importantly, it'll help you to understand the task deep enough before starting, and prioritize important things to do first. 3. Please note how much time a day/week you are able to spend on this project. 4. Please specify which category you apply for - medium task or extended deadline one. 5. Specify your timezone, since so we can assign you a mentor in the same one, to ease communication. 6. Submit your proposal early, not in the last minute! 7. Be sure to choose a “backup” idea (the second task you want to do), so that conflicts (two participants for one task) can be resolved. # Project Ideas # Cutter ## Improving usability and user experience (175 hour project) The Cutter's backend provides a lot of features that are not exposed or exposed in Cutter efficiently. The goal of this task would be to figure out the biggest pain points of the users and address them by improving or reworking the interface. Some of the issues are already in our GitHub, while other might be figured during the cross-comparison with other tools. ### Task - Add a scrollbar to the disassembly and hexdump widgets - Better syntax highlight and theming - Managing window/widget overlays - Add information about status of the analysis, signature searching, and other operations - Address various small UI problems that make user's life harder than necessary ### Skills The participant should be comfortable with the C++ and be familiar with Qt framework. Basics of the design/UX would be a plus. ### Difficulty Advanced ### Benefits for the participant The participant will gain an experience of creating comfortable and efficient user interface with C++/Qt. ### Benefits for the project It will make interface and user experience more consistent, on par with Rizin itself, and other tools. ### Assess requirements for midterm/final evaluation - 1st term: Add scrollbar to necessary widget, improve theming and syntax highlight - Final term: Managing widgets layouts, docking; provide action status information ### Mentors - thestr4ng3r - xvilka - Megabeets ### Links/Resources - [User Experience project for Cutter](https://github.com/orgs/rizinorg/project/4/views/1) - [User Experience project for Rizin](https://github.com/rizinorg/rizin/projects/1) ## Plugins and Python High Level API (175 hour project) Our current public API to be used by plugin authors is somewhat limited. We need to improve a lot of things about our Plugins support and take it few steps ahead. This task is only about improving the public C++ and Python interface of Cutter, specifically its graphical user interface components. For a task about exposing Rizin's API for disassembly, analysis and other purposes, see the Rizin bindings task above. ### Task - Expose everything Cutter can offer for plugins authors. This includes high level API, integration of the plugin management etc. - Accessing everything from Python (like Blender) - see [issue #1662](https://github.com/rizinorg/cutter/issues/1662) - Python integration and IPython console. ### Skills The participant should be comfortable with the C++ and Python languages, and be familiar with Qt framework ### Difficulty Advanced ### Benefits for the participant The participant will gain an experience of creating a suitable API for scripting graphical interface programs. ### Benefits for the project It will greatly improve the scripting experience, will make API more consistent and will ease creating Cutter plugins by the community. Moreover, it will simplify testing of the Cutter features. ### Assess requirements for midterm/final evaluation - 1st term: Design of the high level API and required Rizin changes. Review and implement all missing API functions that are accessible as interface controls. - Final term: Implement the way to show the API when hovered over some interface control, create documentation. ### Mentors - thestr4ng3r - Megabeets ### Links/Resources - [SDB Module/API for Cutter Python/Jupyter integration](https://github.com/rizinorg/cutter/issues/1778) - [Jupyter plugin for Cutter](https://github.com/rizinorg/cutter-jupyter) ## Multi-Tasking and Event-driven architecture (350 hour project) The information Cutter gets about functions, strings, imports, and the analysis are all performed in Rizin and only displayed in Cutter. Currently, it is pulling most information from Rizin only on demand. This is problematic because sometimes the user performs changes (via plugins, the console widget, and more) that are affecting the information from Rizin, but Cutter doesn't know about these changes to apply the to the UI. For example, if a user will define a new function in a Python script or via the console widget by using the Rizin command `af @ `, Cutter will not show this new function in the Functions widget until the user will refresh the interface manually (Edit -> Refresh Contents). The goal of this task is to use an event-driven architecture to overcome this limitation. In addition, this task will also handle the analysis in the background feature, to allow the analysis performed by Rizin to happen while the interface is active. ### Tasks The overall implementation of this task should start from Rizin by adding events to many of the functions. This can be done using `rz_events`. For example, add an event for function creating, for section creation, for flag deletion, for name changed, and more - Add events to all the relevant functions inside Rizin - Add support for these events in Cutter and refresh and update the relevant widgets per each event - Support analysis in the background and allow the user to start its session while Rizin is analyzing (see [#1856](https://github.com/rizinorg/cutter/issues/1856), [#1574](https://github.com/rizinorg/cutter/issues/1574)) ### Skills The participant should be comfortable with the C++ for Cutter and C for Rizin. They should also be familiar with Qt framework. Experience in GUI code architecture, for example using functional reactive programming or Elm-like approaches is a plus. ### Difficulty Advanced ### Benefits for the participant The participant will gain an experience of creating complex event-driven software in both C and C++ languages. ### Benefits for the project It will allow to work on big files effortlessly in Cutter, will improve analysis quality as well. ### Assess requirements for midterm/final evaluation - 1st term: Implement events everywhere in the relevant places across Rizin code and event-driven interaction with Cutter. - Final term: Add support for the Cutter interface refresh based on the events from Rizin, implement analysis in background. ### Mentors - thestr4ng3r ## Heap viewer completion (175 hour project) Thanks to the work that was done in the previous GSoC, Cutter and Rizin have nice visualizations of the heap and memory maps. We would like to expand on this feature with performance improvements to the heap parsers and support more memory allocators. ### Task - Complete Cutter's implementation of the windows heap widget #[2723](https://github.com/rizinorg/cutter/pull/2723) - Improve the performance of the Windows heap parser - Fix Windows heap parsing errors - Make the implementation work with remote debugging modes ### Skills The participant should be comfortable with the C++, and be familiar with Qt framework ### Difficulty Medium ### Benefits for the participant The participant will gain the understanding on how modern runtimes provide the heap for various programs, which will be beneficial for the binary exploitation skills. ### Benefits for the project It will greatly improve the debugging and reverse engineering experience for complex programs, also provides the way to design the exploitation techniques with the help of Rizin/Cutter. ### Assess requirements for midterm/final evaluation - 1st term: Design and implement heap visualization widgets, add Rizin test and fixes - Final term: Various bugfixes related to the heap inspection support on various platforms and allocators, tests and documentation. ### Mentors - xvilka - Megabeets ### Links/Resources - [Issue #1041](https://github.com/rizinorg/cutter/issues/1041) - [Heap Viewer plugin for IDA Pro](https://github.com/danigargu/heap-viewer) - [Heap parsing for MacOS, tmalloc, jmalloc](https://github.com/rizinorg/rizin/issues/208) - [Dynamic Allocator Detection](https://github.com/rizinorg/rizin/issues/157) - ["heap"-marked Rizin issues](https://github.com/rizinorg/rizin/labels/heap) ## Diffing mode (175 hour project) Binary diffing is one of the most common tasks for the reverse engineer. There are many tools available, but most of them are either detached from the main RE toolbox or poorly integrated. Rizin provides basic diffing features out of the box with `rz-diff` tool, but Cutter has no interface to represent similar functionality. ### Task - Expose basic `rz-diff` features in the Cutter - Create the interface to choose two files for diffing - Create the way to show the differences in all main widgets: - Hexadecimal view - Disassembly view - Graph view - Pseudocode view ### Skills The participant should be comfortable with the C++ language, and be familiar with Qt framework ### Difficulty Medium ### Benefits for the participant The participant will gain an experience of creating efficient graphical interfaces. ### Benefits for the project It will greatly benefit the project since Cutter will be the only FOSS RE tool to provide this feature out of the box. ### Assess requirements for midterm/final evaluation - 1st term: Expose the `rz-diff` features in the Cutter core and create the interface for opening files for diffing. Implement the diff modes for hexadecimal and disassembly views. - Final term: Implement the diff modes for graph and pseudocode views, create the documentation. ### Mentors - xvilka - deroad ### Links/Resources - [Issue #1104](https://github.com/rizinorg/cutter/issues/1104) - [BinDiff](https://www.zynamics.com/bindiff.html) - [Diaphora](https://github.com/joxeankoret/diaphora) # Rizin ## RzIL uplifting migration (350 hour project) Rizin has had an intermediate language for over a decade. Major architectures are supporting uplifting to ESIL. During the RSoC 2021, the initial version of the [new intermediate language](https://github.com/rizinorg/rizin/blob/dev/doc/rzil.md), which is based on the BAP's Core Theory was implemented. In the following years it was improved and some of the architectures were ported to use RZIL instead of ESIL. The main goal of this project is to finish the migration of one or more existing architectures that still use ESIL or add a RzIL support for the architectures that hadn't any uplifting at all. ### Tasks - Implement a RZIL uplifting for any non-trivial architecture, preferably that is supported by ESIL already - Improve the integration with analysis (variables and types differences) for the chosen architecture - Write the test cases for Rizin regression tests and improve the results. - Update and use [rz-tracetest](https://github.com/rizinorg/rz-tracetest) for the chosen architectures - Implement necessary commands and APIs in Rizin for visual representation of the IL tree - Implement standard and graph views in Cutter for the IL output (optional) Due to the sensivity of uplifting to the precision, it's important to follow these steps: - For every single lifted opcode, have at the very least one asm test in `test/db/asm/...` containing the IL to detect changes when the code is changed and have it type-checked. This should produce 100% coverage on the lifter C code (except e.g. `malloc()` error handling). - Run `rz-tracetest` on real traces. It's also possible to write custom assembly programs that execute specific obscure instructions where it's hard to be sure that they were implemented correctly on many random inputs and then feed these executions into `rz-tracetest`. - Few `rz-test` command tests that emulate some code snippets in rizin. For example a simple decryption loop to check the overall integration in rizin, or for specific edge cases (like running a division by zero). ### Skills The participant should know C and bits of C++ as well as be familiar with basics of the program analysis. Having an experience with other intermediate language, SAT/SMT, and mathematical logic is a plus. ### Difficulty Medium ### Benefits for the participant The participant will understand the state of the art of intermediate languages research, it's relation to the mathematical logic, SMT, and program analysis. Moreover, the participant will become familiar with the both symbolic and concrete emulation during the implementation process. ### Benefits for the project Migrating most architectures will help to deprecate and remove outdated ESIL and will help improving the analysis precision. Adding uplifting for new architectures that weren't even supported by ESIL will improve the analysis to even greater degree. ### Assess requirements for midterm/final evaluation - 1st term: finish the RZIL uplifting for the chosen architecture with basic instruction-level tests - Final term: implement all changes in the analysis code, added more complex integration tests with types analysis ### Mentors - xvilka - thestr4ng3r ### Links/Resources - [RZIL-labeled issues](https://github.com/rizinorg/rizin/labels/RZIL) - [ESIL-labeled issues](https://github.com/rizinorg/rizin/labels/RZIL) - [ESIL to RZIL conversion tracking issue](https://github.com/rizinorg/rizin/issues/2080) - [Cutter: IL output and graph visual representation](https://github.com/rizinorg/rizin/issues/1133) ## Debug information handling improvements (175 hour project) Rizin already supports most of the DWARF and PDB features, including cross-platform parsing of both. However information are usually just printed to aid the reverse engineering process, but they are not actually used at their best. For example, you can't use them to configure a breakpoint, nor they can be used to access variables within a function during debugging. Moreover, it is becoming more and more common to store DWARF information in separate files, either shipped as separate file or downloaded on the fly with `debuginfod`. Rizin does not support these kind of DWARF files yet. Your task would be to improve the parsing support of both by fixing smaller bugs, add support for separate DWARF files and `debuginfod` and enhance breakpoint integration and variable/structure printing in debugging mode with the source information gathered from DWARF/PDB. ### Task 1. Support loading DWARF information from separate files and `debuginfod` 2. Unify source lines/types information access for DWARF, PDB, dSYM and refactor/fix parsing code as necessary 3. Integrate source line and types/variables information with the analysis (optional) 4. Integrate source line and types/variables with printing with `p` commands in the debug mode 5. Integrate source line and types/variables with breakpoint commands and APIs 6. Parsing performance improvements ### Skills * Good knowledge of the C language * Some experience in debugging with GDB or LLDB * Basic knowledge of at least one of the following formats: ELF, DWARF, PDB, PE ### Difficulty Hard ### Benefits for the participant Participant will understand how high-level features of debuggers work as well as gain skills in the field of software architecture of a large, modular C project. ### Assess requirements for midterm/final evaluation - 1st term: `debuginfod` and source line information refactoring are implemented - Final term: Integration of variable information with the debug and printing commands is implemented ### Mentors - xvilka - thestr4ng3r - ret2libc ### Links/Resources - [Loading debug information from `debuginfod`](https://github.com/rizinorg/rizin/issues/1285) - [Unify code of source information access for DWARF, PDB, dSYM](https://github.com/rizinorg/rizin/issues/907) - [Ghidra issue: support DWARF in MinGW PE binaries](https://github.com/NationalSecurityAgency/ghidra/issues/1267) - [Debuginfod](https://sourceware.org/elfutils/Debuginfod) - [Debian Debuginfod](https://wiki.debian.org/Debuginfod) - [Fedora Debuginfod](https://fedoraproject.org/wiki/Debuginfod) - [DWARF-labeled issues](https://github.com/rizinorg/rizin/labels/DWARF) - [PDB-labaled issues](https://github.com/rizinorg/rizin/labels/PDB) ## Debugger improvements and portability (175 hour project) Rizin debugger already supports most of the platforms, including native and remote debugging. Nevertheless, for most platforms it's limited mostly to the x86/x86_64 and ARMv8, often lacking the tests. The task would be to add missing architectures to the native debugger, e.g. MIPS to the Linux Native, ARMv7/ARMv8 to the FreeBSD, System Z debugger for Linux, HPPA debugger for Linux, VAX debugger for NetBSD, and so on. With the help of emulators like QEMU and SIMH we could extend our CI to automatically test these debuggers. ### Task 1. Support for missing architectures that are supported by Rizin statically in the Linux native debugger 2. Support for missing architectures that are supported by Rizin statically in the BSD native debugger 3. Cover more platforms supported by the debugger with automated tests, with CI whenever it's possible 4. Fix the bugs in debuggers, minor refactorings of the code ### Skills * Good knowledge of the C language * Some experience in debugging with GDB or LLDB ### Difficulty Hard ### Benefits for the participant Participant will understand how debugging works on the low level, and will gain experience with variety of different platforms and operating systems. ### Assess requirements for midterm/final evaluation - 1st term: `SystemZ, MIPS, HPPA support in Linux native, remote GDB debuggers - Final term: ARM and SPARC support in *BSD debuggers, VAX support in NetBSD ### Mentors - xvilka - thestr4ng3r - ret2libc ### Links/Resources - [Debug-labeled issues](https://github.com/rizinorg/rizin/labels/Debug) - [RzDebug-labaled issues](https://github.com/rizinorg/rizin/labels/RzDebug) - [New Platform support](https://github.com/rizinorg/ideas/labels/New%20Platform) - [New Architecture support](https://github.com/rizinorg/ideas/labels/New%20Architecture) ## Thread-safety and multithreading (175 hour project) Currently Rizin is not thread safe completely internally and as a library for a multithreaded application. The goal of this project is to eliminate global states and use contexts, eliminate singletons, e.g. RzCons, and use thread-safe external functions and dependencies. ### Task 1. Migrate from thread-unsafe system and external dependencies 2. Eliminate global state inside RzCons and use of the singleton 3. Make RzBin thread-safe 4. Make RzAnalysis thread-safe 5. Make RzCore thread-safe 6. Add tests for using multiple RzCore and RzAnalysis instances 7. Parallelize some of the RzAnalysis function using the threading API ### Skills Participant should know C as well as have the experience of developing multithreaded applications. ### Difficulty Hard ### Benefits for the participant Participant will understand the hurdles of multithreaded programming, data synchronization, locks and debugging of such code. ### Assess requirements for midterm/final evaluation - 1st term: Eliminate thread-unsafe dependencies and remove global state from RzCons and RzBin - Final term: Make RzAnalysis and RzCore (optionally) thread-safe ### Mentors - xvilka - thestr4ng3r - wargio ### Links/Resources - [Migrate from `wcstombs()` function since it's not thread-safe](https://github.com/rizinorg/rizin/issues/1058) ## Rewriting GPL-only code (175 hour project) Currently some of the Rizin main features rely on the GPL-only code copied from binutils or GCC. The goal is to rewrite all this code from GPL-only to LGPL or any other less restrictive license. It is quite important for better adoption of Rizin as a library in other FOSS and commercial projects. ## Tasks 1. Rewrite C++ demangler to and remove the GPL code 2. Rewrite some of the mainstream architectures that still rely on binutils without using GPL-only code Good example of such architectures are: - SPARC (there is already capstone-based RzAsm and RzAnalysis plugin but it's less complete than binutils-based one) - Xtensa - ARC - HPPA (PA-RISC) ### Skills Participant should know C and basics of C++ for understanding the mangling scheme ### Difficulty Medium ### Benefits for the participant Participant will understand how C++ type information is stored in the name of the methods and classes. ### Assess requirements for midterm/final evaluation - 1st term: Basic demangling for C++ is rewritten under less restrictive license. - Final term: At least one binutils-based architecture is reimplemented with more permissive license. ### Mentors - xvilka - thestr4ng3r - wargio ### Links/Resources - [rz-libdemangle: rewrite/remove GPL-only code](https://github.com/rizinorg/rz-libdemangle/issues/3) - [Update binutils code to latest](https://github.com/rizinorg/rizin/issues/814) ## Exploitation capabilities improvements (175 hour project) Since modern architectures are now enforcing [W^X](https://en.wikipedia.org/wiki/W%5EX), exploiters are using [ROP](https://en.wikipedia.org/wiki/Return-oriented_programming). (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](https://www.corelan.be/index.php/2012/12/31/jingle-bofs-jingle-rops-sploiting-all-the-things-with-mona-v2/), there is also [ROPgadget](http://www.shell-storm.org/project/ROPgadget/) and [dropper](https://github.com/rizlik/dropper).There exist even tools that can generate ROP chains automatically, for example [exrop](https://github.com/d4em0n/exrop). It's a shame that despite having [ESIL](https://book.rizin.re/disassembling/esil.html), Rizin doesn't have something similar yet. One of the possible solutions would be to build an external plugin or tool which will reuse power of librz and rz-gg. Moreover it makes sense to think about SROP, COOP and BROP support. The `rz-gg` tool while has the ability to create a custom shellcode has the outdated database of the shellcodes, so [updating them](https://github.com/rizinorg/rizin/issues/154) is crucial for the tool to be relevant. ### Task 1. Update the shellcodes database, imrove `rz-gg` features and documentation 2. Implement a ropchain syntax parser that uses `rz-gg` or a custom DSL, something like: ``` register reg1 = 0; register reg2 = whatever; register reg3 = reg1 + reg2; system(reg3); ``` 3. Write a compiler which uses SMT solver (like Z3 for example) to produce the ropchain. 4. Support main architectures - x86, ARM, MIPS, PowerPC ### Skills The participant 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 Advanced ### Benefits for the participant The participant 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 Rizin ;) ### Assess requirements for evaluation - 1st term: Creating the language for defining the ROP chain semantics and integrating it with SMT solver - Final term: Working ropchain compiler, covered by tests and documented in the Rizin book. ### Mentors - xvilka - ret2libc ### Links/Resources - [ROPGadget](http://shell-storm.org/project/ROPgadget/) - [Ropper](https://github.com/sashs/Ropper) - [Angrop](https://github.com/salls/angrop) - [ROPC](https://github.com/pakt/ropc) - [exrop](https://github.com/d4em0n/exrop) - [roper2](https://github.com/oblivia-simplex/roper2) - [mona.py](https://www.corelan.be/index.php/2012/12/31/jingle-bofs-jingle-rops-sploiting-all-the-things-with-mona-v2/) from corelan - [Hunting for ROP Gadgets in Style](https://media.blackhat.com/us-13/US-13-Quynh-OptiROP-Hunting-for-ROP-Gadgets-in-Style-WP.pdf) (2012) - [dropper](https://github.com/rizlik/dropper) a BARF-based rop chain generator - [Materials](http://dustri.org/b/files/hacklu2014_r2_exploitation.tar.xz) about the exloitation workshop at Hack.lu 2014 - [Slides](https://github.com/XVilka/hacklu) for the exploitation part of workshop at Hack.lu 2015 - [RzEgg related bugs](https://github.com/rizinorg/rizin/labels/RzEgg) # Microtasks When taking any of microtasks please be sure someone isn't already working on them, and let us know if you are going to work on a particular one. ## File formats Implementing the support for any new file format counts as a microtask. See [New File-Format](https://github.com/rizinorg/ideas/labels/New%20File%20Format) label for pending issues. ## Disassemblers and assemblers Implementing the support for any new architecture counts as a microtask. See [New-Architecture](https://github.com/rizinorg/ideas/labels/New%20Architecture) label for pending issues. ## Analysis The current code analysis has many caveats and issues which need addressing. Fixing them and writing more tests is important to stabilize and enhance rizin's analysis engine. [See these issues](https://github.com/rizinorg/rizin/labels/RzAnalysis) on our GitHub dashboard. ### Heap analysis [#157](https://github.com/rizinorg/rizin/issues/157) Currently Rizin has support for heap exploration and analysis, but the feature is still basic and can be improved. Additionally, [other allocators can be added](https://github.com/rizinorg/rizin/issues/208) (MacOS, tmalloc, etc.), but this should be done after a proper refactoring, because heap analysis shouldn't depend on the debugger backend, and we may be able to use different heap tools. ## Class analysis for C++/ObjectiveC/Swift/Dlang/Java [#416](https://github.com/rizinorg/rizin/issues/416) Analysis classes, accessible under the `ac` command, is a relatively new feature of rizin. They provide a way to both manually and automatically manage and use information about classes in the binary. ### Devirtualize method calls using class vtables [#414](https://github.com/rizinorg/rizin/issues/414) Consider the following call: `call dword [eax + 0x6c]` Let's assume eax is the base pointer of a vtable we have saved in class analysis and we want to find out the actual address of the called method. So there should be a command that takes the offset (in this case 0x6c) and looks up the actual destination. It should be possible to call this command with a specific class, so it only looks into its vtable, or without a class, so it gives a list of possible destinations for all vtables that are not too small for the offset. When that is implemented, one could also add a command that does the same thing, but automatically takes the offset from the opcode at the current seek. ### Add classes list to `Vb` `Vb` already supports browsing bin classes. The same thing should be implemented for classes from analysis. ## Refactoring ### Use internal API instead of commands Currently, Rizin's source code is rife with calls to `rz_core_cmd()`-like functions that run the Rizin command. While it is a useful shortcut for developer, it makes a good source of the potential bugs in case of the command syntax or behavior change. If these changes happen they are invisible to the compiler, so it cannot warn on the changed syntax. It isn't the case of changed function arguments count or type. Thus, all these calls eventually should be substituted with direct calls to the corresponding API functions. If there is no corresponding API function, then one should be created. Good examples of such cases are: - [Refactor Graph processing from commands to the API use](https://github.com/rizinorg/rizin/issues/397) - [Refactor Visual mode from commands to the API use](https://github.com/rizinorg/rizin/issues/382) - [Refactor Panels mode from commands to the API use](https://github.com/rizinorg/rizin/issues/383) In general you can just search for `rz_core_cmd` pattern in any place inside `librz/`. ## Miscellaneous ### Shell (dietline) improvements Currently Rizin uses its own readline-compatible implementation of the input handling in the embedded shell that is compact and portable between all supported platforms. It supports both Emacs and Vi modes, but not all bindings and features are supported. Some are omitted by choice, but some were simply not implemented. See the ["dietline"-labeled issues](https://github.com/rizinorg/rizin/labels/dietline). ### Improving regression suite and testing It is required to solve [numerous issues](https://github.com/rizinorg/rizin/labels/rz-test), along with improving parallel execution and performance. The next interesting idea is to setup and reuse Godbolt compilation engine for generating tests for different compilers and compilation options. There is even a command line tool for interacting with Godbolt - [cce](https://github.com/ethanhs/cce). ### Unbreaking broken tests Almost one thousand of tests marked as "broken" in our testsuite. The task is to take any of those, investigate why it fails, if the test makes sense now or already irrelevant today. Then to try to fix some of the broken tests. ## RzGhidra There are many small issues in the decompiler output: - [`pdgsd` commands showing incorrect P-code](https://github.com/rizinorg/rz-ghidra/issues/172) - [Improvements in recovering jump tables](https://github.com/rizinorg/rz-ghidra/issues/236) - [rz-ghidra can't detect string](https://github.com/rizinorg/rz-ghidra/issues/85) - [Ghidra Decompiler Error: Could not finish collapsing block structure](https://github.com/rizinorg/rz-ghidra/issues/203) - [Mishandled tail jump with relocation inside the jump function](https://github.com/rizinorg/rz-ghidra/issues/202) - [Prioritize keeping vars with lower addresses](https://github.com/rizinorg/rz-ghidra/issues/167) - [Minor improvements for the SLEIGH plugin](https://github.com/rizinorg/rz-ghidra/issues/133) Some of these issues might be related on how Rizin and RzGhidra integrate and might require changes in the Rizin side. Also note that most of these issues should be paired with the test to verify it will not break in the future. --- ## File: content/gsoc/2024.md --- title: "GSoC 2024" layout: "single" ShowToc: true TocOpen: false ShowReadingTime: false date: "2024-01-23" --- **TL;DR** Jump to the [Ideas list](#project-ideas). # Introduction This year, we participate again, effectively continuing the tradition since 2015. ## Mentors Members of the Rizin and Cutter core teams have volunteered to guide participants for GSoC’24. They have already been guiding the participants for the GSoC and RSoC in past years. Please feel free to reach out to any of them if you need any help in selecting a project. - **Anton Kochkov** Mattermost: xvilka -- [@akochkov](https://twitter.com/akochkov) - **Riccardo Schirone** Mattermost: ret2libc [@RickySkiro](https://twitter.com/RickySkiro) - **Florian Märkl** Mattermost/Telegram: @thestr4ng3r -- [@thestr4ng3r](https://muenchen.social/@thestr4ng3r) - **Itay Cohen** Mattermost/Telegram: @Megabeets [@Megabeets\_](https://twitter.com/Megabeets_) - **Giovanni Dante Grazioli** Mattermost/Telegram: @deroad [@der0ad](https://twitter.com/der0ad) - And many others ## Development methodology Currently, all repositories are hosted on GitHub [main](https://github.com/rizinorg/) organization account and bugs are tracked on GitHub [issues](https://github.com/rizinorg/rizin/issues) too. We are primarily using [our own Mattermost instance](https://im.rizin.re), IRC, and [Telegram](https://t.me/rizinorg)) for communication. We have a [testsuite](https://github.com/rizinorg/rizin/tree/dev/test) (which is running on GitHub Actions, [Travis CI](https://travis-ci.com/rizinorg/rizin), [AppVeyor](https://ci.appveyor.com/project/rizinorg/rizin) and SourceHut) to test and verify that all the features are still working and that a pull requests or commits don't break anything, to ensure the support of different operating systems (Linux, MacOS, Windows, FreeBSD, OpenBSD), different architectures (x86/x86_64, ARM64, PowerPC, SystemZ), 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. For complex bugs and examples, we're using [ASCIInema](http://asciinema.org/) to record the sessions. See also our guides for corresponding projects: - Rizin [Contributing Guide](https://github.com/rizinorg/rizin/blob/dev/CONTRIBUTING.md) and [Developers Intro](https://github.com/rizinorg/rizin/blob/dev/DEVELOPERS.md) - Cutter [Contributing Guide](https://github.com/rizinorg/cutter/blob/master/CONTRIBUTING.md) and [Developers Intro](https://cutter.re/docs/code.html) For those who want to get introduced to the Rizin codebase and practices, we recommend to pick one of the easy issues for [Rizin](https://github.com/rizinorg/rizin/labels/good%20first%20issue) or [Cutter](https://github.com/rizinorg/cutter/labels/good%20first%20issue) to start with. ## License Rizin is modular: this means that it aims to make all the elements and features easily reusable from other projects. The choice of [LGPL3](https://www.gnu.org/licenses/lgpl.html) as a license is the minimum requirement to get code merged in Rizin. 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 Rizin while protecting our free codebase. ## Instructions for participants Participants who want to apply to the Rizin project for the Google Summer of Code 2024 are required to submit a small pull request accomplishing one of the [microtasks](#microtasks) (see below) as part of their application. You can also choose any of the GitHub issues for Rizin if they are big enough to be a qualification task and still small enough to be finished in no more than a couple of weeks. To help participants understand how to contribute to the project, there are issues marked as **"good first issue"** for both [Rizin](https://github.com/rizinorg/rizin/labels/good%20first%20issue) and [Cutter](https://github.com/rizinorg/cutter/labels/good%20first%20issue). ## Programming languages Most of Rizin is written in C (conforming to the C99 standard), and hence, we expect participants to be familiar with C programming language. For some of our tasks or microtasks, such as [rz-pm](https://github.com/rizinorg/rz-pm), they should know the Go programming language. For the [Cutter tasks](#cutter), it is a requirement to know C++ and Qt framework basics. ## Recommended steps 1. Read Google's instructions for participating 2. Grab any of the projects from the list of ideas that you're interested in (or propose your own). 3. Write a first draft proposal using Google Docs and [our template](https://docs.google.com/document/d/1kDPGgr_D5tQuYLQi_gEGlkuQ-DlU8GH5kDBqZbVSC7I/edit?usp=sharing) and ask one of the mentors or administrators to review it with you. 4. Submit it using Google's web interface. ## Participant proposal guidelines 1. Keep it simple enough to fit in no more than a couple of pages. Try to be clear and concise in your writing. 2. Try to split the entire GSoC period into tasks and each task into subtasks. It helps us understand how you plan to accomplish your goals, but more importantly, it'll help you understand the task deep enough before starting and prioritize important things to do first. 3. Please note how much time a day/week you can spend on this project. 4. Please specify which category you apply for - medium task or extended deadline one. 5. Specify your timezone so we can assign you a mentor in the same one to ease communication. 6. Submit your proposal early, not at the last minute! 7. Be sure to choose a “backup” idea (the second task you want to do) so that conflicts (two participants for one task) can be resolved. # Project Ideas # Cutter ## Improving usability and user experience (175 hour project) The Cutter's backend provides many features that are not exposed or exposed in Cutter efficiently. The goal of this task would be to figure out the users' biggest pain points and address them by improving or reworking the interface. Some of the issues are already in our GitHub, while others might be figured during the cross-comparison with other tools. ### Task - Add a scrollbar to the disassembly and hexdump widgets - Better syntax highlight and theming - Managing window/widget overlays - Add information about status of the analysis, signature searching, and other operations - Address various small UI problems that make user's life harder than necessary ### Skills The participant should be comfortable with the C++ and be familiar with Qt framework. Basics of the design/UX would be a plus. ### Difficulty Advanced ### Benefits for the participant The participant will gain an experience of creating comfortable and efficient user interface with C++/Qt. ### Benefits for the project It will make interface and user experience more consistent, on par with Rizin itself, and other tools. ### Assess requirements for midterm/final evaluation - 1st term: Add scrollbar to necessary widget, improve theming and syntax highlight - Final term: Managing widgets layouts, docking; provide action status information ### Mentors - thestr4ng3r - xvilka - Megabeets ### Links/Resources - [User Experience project for Cutter](https://github.com/orgs/rizinorg/project/4/views/1) - [User Experience project for Rizin](https://github.com/rizinorg/rizin/projects/1) ## Plugins and Python High Level API (175 hour project) Our current public API to be used by plugin authors is somewhat limited. We need to improve a lot of things about our Plugins support and take it few steps ahead. This task is only about improving the public C++ and Python interface of Cutter, specifically its graphical user interface components. For a task about exposing Rizin's API for disassembly, analysis and other purposes, see the Rizin bindings task above. ### Task - Expose everything Cutter can offer for plugin authors. This includes high level API, integration of the plugin management etc. - Accessing everything from Python (like Blender) - see [issue #1662](https://github.com/rizinorg/cutter/issues/1662) - Python integration and IPython console. ### Skills The participant should be comfortable with the C++ and Python languages, and be familiar with Qt framework ### Difficulty Advanced ### Benefits for the participant The participant will gain an experience of creating a suitable API for scripting graphical interface programs. ### Benefits for the project It will greatly improve the scripting experience, will make API more consistent and will ease creating Cutter plugins by the community. Moreover, it will simplify testing of the Cutter features. ### Assess requirements for midterm/final evaluation - 1st term: Design of the high level API and required Rizin changes. Review and implement all missing API functions that are accessible as interface controls. - Final term: Implement the way to show the API when hovered over some interface control, create documentation. ### Mentors - thestr4ng3r - Megabeets ### Links/Resources - [SDB Module/API for Cutter Python/Jupyter integration](https://github.com/rizinorg/cutter/issues/1778) - [Jupyter plugin for Cutter](https://github.com/rizinorg/cutter-jupyter) ## Multi-Tasking and Event-driven architecture (350 hour project) The information Cutter gets about functions, strings, imports, and the analysis are all performed in Rizin and only displayed in Cutter. Currently, it is pulling most information from Rizin only on demand. This is problematic because sometimes the user performs changes (via plugins, the console widget, and more) that are affecting the information from Rizin, but Cutter doesn't know about these changes to apply the to the UI. For example, if a user will define a new function in a Python script or via the console widget by using the Rizin command `af @ `, Cutter will not show this new function in the Functions widget until the user will refresh the interface manually (Edit -> Refresh Contents). The goal of this task is to use an event-driven architecture to overcome this limitation. In addition, this task will also handle the analysis in the background feature, to allow the analysis performed by Rizin to happen while the interface is active. ### Tasks The overall implementation of this task should start from Rizin by adding events to many of the functions. This can be done using `rz_events`. For example, add an event for function creating, for section creation, for flag deletion, for name changed, and more - Add events to all the relevant functions inside Rizin - Add support for these events in Cutter and refresh and update the relevant widgets per each event - Support analysis in the background and allow the user to start its session while Rizin is analyzing (see [#1856](https://github.com/rizinorg/cutter/issues/1856), [#1574](https://github.com/rizinorg/cutter/issues/1574)) ### Skills The participant should be comfortable with the C++ for Cutter and C for Rizin. They should also be familiar with Qt framework. Experience in GUI code architecture, for example using functional reactive programming or Elm-like approaches is a plus. ### Difficulty Advanced ### Benefits for the participant The participant will gain an experience of creating complex event-driven software in both C and C++ languages. ### Benefits for the project It will allow to work on big files effortlessly in Cutter, will improve analysis quality as well. ### Assess requirements for midterm/final evaluation - 1st term: Implement events everywhere in the relevant places across Rizin code and event-driven interaction with Cutter. - Final term: Add support for the Cutter interface refresh based on the events from Rizin, implement analysis in background. ### Mentors - thestr4ng3r ## Heap viewer completion (175 hour project) Thanks to the work that was done in the previous GSoC, Cutter and Rizin have nice visualizations of the heap and memory maps. We would like to expand on this feature with performance improvements to the heap parsers and support more memory allocators. ### Task - Complete Cutter's implementation of the windows heap widget #[2723](https://github.com/rizinorg/cutter/pull/2723) - Improve the performance of the Windows heap parser - Fix Windows heap parsing errors - Make the implementation work with remote debugging modes ### Skills The participant should be comfortable with the C++, and be familiar with Qt framework ### Difficulty Medium ### Benefits for the participant The participant will gain the understanding on how modern runtimes provide the heap for various programs, which will be beneficial for the binary exploitation skills. ### Benefits for the project It will greatly improve the debugging and reverse engineering experience for complex programs, also provides the way to design the exploitation techniques with the help of Rizin/Cutter. ### Assess requirements for midterm/final evaluation - 1st term: Design and implement heap visualization widgets, add Rizin test and fixes - Final term: Various bugfixes related to the heap inspection support on various platforms and allocators, tests and documentation. ### Mentors - xvilka - Megabeets ### Links/Resources - [Issue #1041](https://github.com/rizinorg/cutter/issues/1041) - [Heap Viewer plugin for IDA Pro](https://github.com/danigargu/heap-viewer) - [Heap parsing for MacOS, tmalloc, jmalloc](https://github.com/rizinorg/rizin/issues/208) - [Dynamic Allocator Detection](https://github.com/rizinorg/rizin/issues/157) - ["heap"-marked Rizin issues](https://github.com/rizinorg/rizin/labels/heap) ## Diffing mode (175 hour project) Binary diffing is one of the most common tasks for the reverse engineer. There are many tools available, but most of them are either detached from the main RE toolbox or poorly integrated. Rizin provides basic diffing features out of the box with `rz-diff` tool, but Cutter has no interface to represent similar functionality. ### Task - Expose basic `rz-diff` features in the Cutter - Create the interface to choose two files for diffing - Create the way to show the differences in all main widgets: - Hexadecimal view - Disassembly view - Graph view - Pseudocode view ### Skills The participant should be comfortable with the C++ language, and be familiar with Qt framework ### Difficulty Medium ### Benefits for the participant The participant will gain an experience of creating efficient graphical interfaces. ### Benefits for the project It will greatly benefit the project since Cutter will be the only FOSS RE tool to provide this feature out of the box. ### Assess requirements for midterm/final evaluation - 1st term: Expose the `rz-diff` features in the Cutter core and create the interface for opening files for diffing. Implement the diff modes for hexadecimal and disassembly views. - Final term: Implement the diff modes for graph and pseudocode views, create the documentation. ### Mentors - xvilka - deroad ### Links/Resources - [Issue #1104](https://github.com/rizinorg/cutter/issues/1104) - [BinDiff](https://www.zynamics.com/bindiff.html) - [Diaphora](https://github.com/joxeankoret/diaphora) # Rizin ## RzIL uplifting migration (350 hour project) Rizin has had an intermediate language for over a decade. Major architectures are supporting uplifting to ESIL. During the RSoC 2021, the initial version of the [new intermediate language](https://github.com/rizinorg/rizin/blob/dev/doc/rzil.md), which is based on the BAP's Core Theory was implemented. In the following years it was improved and some of the architectures were ported to use RZIL instead of ESIL. The main goal of this project is to finish the migration of one or more existing architectures that still use ESIL or add a RzIL support for the architectures that hadn't any uplifting at all. ### Tasks - Implement a RZIL uplifting for any non-trivial architecture, preferably that is supported by ESIL already - Improve the integration with analysis (variables and types differences) for the chosen architecture - Write the test cases for Rizin regression tests and improve the results. - Update and use [rz-tracetest](https://github.com/rizinorg/rz-tracetest) for the chosen architectures - Implement necessary commands and APIs in Rizin for visual representation of the IL tree - Implement standard and graph views in Cutter for the IL output (optional) Due to the sensivity of uplifting to the precision, it's important to follow these steps: - For every single lifted opcode, have at the very least one asm test in `test/db/asm/...` containing the IL to detect changes when the code is changed and have it type-checked. This should produce 100% coverage on the lifter C code (except e.g. `malloc()` error handling). - Run `rz-tracetest` on real traces. It's also possible to write custom assembly programs that execute specific obscure instructions where it's hard to be sure that they were implemented correctly on many random inputs and then feed these executions into `rz-tracetest`. - Few `rz-test` command tests that emulate some code snippets in rizin. For example a simple decryption loop to check the overall integration in rizin, or for specific edge cases (like running a division by zero). ### Skills The participant should know C and bits of C++ as well as be familiar with basics of the program analysis. Having an experience with other intermediate language, SAT/SMT, and mathematical logic is a plus. ### Difficulty Medium ### Benefits for the participant The participant will understand the state of the art of intermediate languages research, it's relation to the mathematical logic, SMT, and program analysis. Moreover, the participant will become familiar with the both symbolic and concrete emulation during the implementation process. ### Benefits for the project Migrating most architectures will help to deprecate and remove outdated ESIL and will help improving the analysis precision. Adding uplifting for new architectures that weren't even supported by ESIL will improve the analysis to even greater degree. ### Assess requirements for midterm/final evaluation - 1st term: finish the RZIL uplifting for the chosen architecture with basic instruction-level tests - Final term: implement all changes in the analysis code, added more complex integration tests with types analysis ### Mentors - xvilka - thestr4ng3r ### Links/Resources - [RZIL-labeled issues](https://github.com/rizinorg/rizin/labels/RZIL) - [ESIL-labeled issues](https://github.com/rizinorg/rizin/labels/RZIL) - [ESIL to RZIL conversion tracking issue](https://github.com/rizinorg/rizin/issues/2080) - [Cutter: IL output and graph visual representation](https://github.com/rizinorg/rizin/issues/1133) ## Debugger improvements and portability (175 hour project) Rizin debugger already supports most of the platforms, including native and remote debugging. Nevertheless, for most platforms it's limited mostly to the x86/x86_64 and ARMv8, often lacking the tests. The task would be to add missing architectures to the native debugger, e.g. MIPS to the Linux Native, ARMv7/ARMv8 to the FreeBSD, System Z debugger for Linux, HPPA debugger for Linux, VAX debugger for NetBSD, and so on. Moreover, some information isn't available during the debugging mode, e.g. source-level breakpoints or names, it would be necessary to make sure debug commands understand those. With the help of emulators like QEMU and OpenSIMH we could extend our CI to automatically test these debuggers. ### Task 1. Integrated source-level information loaded from DWARF or PDB into debug commands and print `p` commands 2. Support for missing architectures that are supported by Rizin statically in the Linux native debugger 3. Support for missing architectures that are supported by Rizin statically in the BSD native debugger 4. Cover more platforms supported by the debugger with automated tests, with CI whenever it's possible 5. Fix the bugs in debuggers, minor refactorings of the code ### Skills * Good knowledge of the C language * Some experience in debugging with GDB or LLDB ### Difficulty Hard ### Benefits for the participant Participant will understand how debugging works on the low level, and will gain experience with variety of different platforms and operating systems. ### Assess requirements for midterm/final evaluation - 1st term: `SystemZ, MIPS, HPPA support in Linux native, remote GDB debuggers - Final term: ARM and SPARC support in *BSD debuggers, VAX support in NetBSD ### Mentors - xvilka - thestr4ng3r - ret2libc ### Links/Resources - [Debug-labeled issues](https://github.com/rizinorg/rizin/labels/Debug) - [RzDebug-labaled issues](https://github.com/rizinorg/rizin/labels/RzDebug) - [New Platform support](https://github.com/rizinorg/ideas/labels/New%20Platform) - [New Architecture support](https://github.com/rizinorg/ideas/labels/New%20Architecture) ## FRIDA integration (175 hour project) [FRIDA](https://frida.re) is the famous dynamic instrumentation toolkit that is immensely popular among mobile device researches. Rizin could be easily integrated with Frida by creating a plugin that will allow to connect to the Frida instance, receive traces, set breakpoints, get information and events from it. ### Task 1. Create the basic plugin that allows attaching, spwaning, launching processes within Frida loco ally 2. Support remote connection 3. Add feature to receive information from the Frida instanced 4. Add breakpoints and run/step/continue feature's 5. Support calling functions and scripts in the context of the instrumented process ### Skills Participant should know C as well as have the experience of working with debuggers. ### Difficulty Hard ### Benefits for the participant Participant will understand and learn how to use Frida toolkit, also the internals of the debugging and instrumentation processes. ### Assess requirements for midterm/final evaluation - 1st term: Implement core of the FRIDA plugin, allowing local and remote debugging features - Final term: Add support for extended features like calling functions or scripts within the context ### Mentors - xvilka - thestr4ng3r - wargio ### Links/Resources - [FRIDA](https://frida.re) - [FRIDA (GitHub)](https://github.com/frida/frida) - [r2frida](https://github.com/nowsecure/r2frida) ## Rewriting GPL-only code (175 hour project) Currently some of the Rizin main features rely on the GPL-only code copied from binutils or GCC. The goal is to rewrite all this code from GPL-only to LGPL or any other less restrictive license. It is quite important for better adoption of Rizin as a library in other FOSS and commercial projects. ## Tasks 1. Rewrite C++ demangler to and remove the GPL code 2. Rewrite some of the mainstream architectures that still rely on binutils without using GPL-only code Good example of such architectures are: - SPARC (there is already capstone-based RzAsm and RzAnalysis plugin but it's less complete than binutils-based one, capstone update is also required) - Xtensa (It's better to implement/update it in Capstone) - ARC (Same, better to implement/update it in Capstone) - Lanai - CRIS - VAX ### Skills Participant should know C and basics of C++ for understanding the mangling scheme ### Difficulty Medium ### Benefits for the participant Participant will understand how C++ type information is stored in the name of the methods and classes. ### Assess requirements for midterm/final evaluation - 1st term: Basic demangling for C++ is rewritten under less restrictive license. - Final term: At least one binutils-based architecture is reimplemented with more permissive license. ### Mentors - xvilka - thestr4ng3r - wargio ### Links/Resources - [rizin: rewrite/remove GPL-only code](https://github.com/rizinorg/rizin/issues/2704) - [rz-libdemangle: rewrite/remove GPL-only code](https://github.com/rizinorg/rz-libdemangle/issues/3) - [Update binutils code to latest](https://github.com/rizinorg/rizin/issues/814) ## Exploitation capabilities improvements (175 hour project) Since modern architectures are now enforcing [W^X](https://en.wikipedia.org/wiki/W%5EX), exploiters are using [ROP](https://en.wikipedia.org/wiki/Return-oriented_programming). (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](https://www.corelan.be/index.php/2012/12/31/jingle-bofs-jingle-rops-sploiting-all-the-things-with-mona-v2/), there is also [ROPgadget](http://www.shell-storm.org/project/ROPgadget/) and [dropper](https://github.com/rizlik/dropper).There exist even tools that can generate ROP chains automatically, for example [exrop](https://github.com/d4em0n/exrop). It's a shame that despite having [RzIL](https://github.com/rizinorg/rizin/blob/dev/doc/rzil.md), Rizin doesn't have something similar yet. One of the possible solutions would be to build an external plugin or tool which will reuse power of librz and rz-gg. Moreover it makes sense to think about SROP, COOP and BROP support. The `rz-gg` tool while has the ability to create a custom shellcode has the outdated database of the shellcodes, so [updating them](https://github.com/rizinorg/rizin/issues/154) is crucial for the tool to be relevant. ### Task 1. Update the shellcodes database, improve `rz-gg` features and documentation 2. Implement a ropchain syntax parser that uses `rz-gg` or a custom DSL, something like: ``` register reg1 = 0; register reg2 = whatever; register reg3 = reg1 + reg2; system(reg3); ``` 3. Write a compiler which uses SMT solver (like Z3 for example) to produce the ropchain. 4. Support main architectures - x86, ARM, MIPS, PowerPC ### Skills The participant 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 Advanced ### Benefits for the participant The participant 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 Rizin ;) ### Assess requirements for evaluation - 1st term: Creating the language for defining the ROP chain semantics and integrating it with SMT solver - Final term: Working ropchain compiler, covered by tests and documented in the Rizin book. ### Mentors - xvilka - ret2libc ### Links/Resources - [ROPGadget](http://shell-storm.org/project/ROPgadget/) - [Ropper](https://github.com/sashs/Ropper) - [Angrop](https://github.com/salls/angrop) - [ROPC](https://github.com/pakt/ropc) - [exrop](https://github.com/d4em0n/exrop) - [roper2](https://github.com/oblivia-simplex/roper2) - [mona.py](https://www.corelan.be/index.php/2012/12/31/jingle-bofs-jingle-rops-sploiting-all-the-things-with-mona-v2/) from corelan - [Hunting for ROP Gadgets in Style](https://media.blackhat.com/us-13/US-13-Quynh-OptiROP-Hunting-for-ROP-Gadgets-in-Style-WP.pdf) (2012) - [dropper](https://github.com/rizlik/dropper) a BARF-based rop chain generator - [Materials](http://dustri.org/b/files/hacklu2014_r2_exploitation.tar.xz) about the exloitation workshop at Hack.lu 2014 - [Slides](https://github.com/XVilka/hacklu) for the exploitation part of workshop at Hack.lu 2015 - [RzEgg related bugs](https://github.com/rizinorg/rizin/labels/RzEgg) # Microtasks When taking any of microtasks please be sure someone isn't already working on them, and let us know if you are going to work on a particular one. ## Cutter UX improvements There are many small issues and missing features that when implemented will improve the user experience significantly: - [Allow adding new flags from hexdump](https://github.com/rizinorg/cutter/issues/2932) - [Scrollbar inside disasssembly windows](https://github.com/rizinorg/cutter/issues/2907) - [Variables and values popup widgets on mouse hover](https://github.com/rizinorg/cutter/issues/2532) - [Allow to set RzRun profiles from the GUI during debugging](https://github.com/rizinorg/cutter/issues/3199) - [Double-click on the type in Disasm and Graph widgets should switch to the Types windows and show the selected type](https://github.com/rizinorg/cutter/issues/2780) - [Set breakpoint inside X-Refs window](https://github.com/rizinorg/cutter/issues/2658) - [Unified dialogue to set debug symbols servers](https://github.com/rizinorg/cutter/issues/3202) See full list at our [User Experience](https://github.com/orgs/rizinorg/projects/4/views/1) project covering all parts of RizinOrg: Rizin, Cutter, RzGhidra, rz-pm. ## File formats Implementing the support for any new file format counts as a microtask. See [New File-Format](https://github.com/rizinorg/ideas/labels/New%20File%20Format) label for pending issues. ## Disassemblers and assemblers Implementing the support for any new architecture counts as a microtask. See [New-Architecture](https://github.com/rizinorg/ideas/labels/New%20Architecture) label for pending issues. Two notable examples are updating existing bytecode plugins to support newer versions of the respective languages: - [Support for the Lua 5.2 language changes](https://github.com/rizinorg/rizin/issues/3914) - [Support for the Python 3.11 and 3.12 language changes](https://github.com/rizinorg/rizin/issues/3130) ## Analysis The current code analysis has many caveats and issues which need addressing. Fixing them and writing more tests is important to stabilize and enhance rizin's analysis engine. [See these issues](https://github.com/rizinorg/rizin/labels/RzAnalysis) on our GitHub dashboard. ### Heap analysis [#157](https://github.com/rizinorg/rizin/issues/157) Currently Rizin has support for heap exploration and analysis, but the feature is still basic and can be improved. Additionally, [other allocators can be added](https://github.com/rizinorg/rizin/issues/208) (MacOS, tmalloc, etc.), but this should be done after a proper refactoring, because heap analysis shouldn't depend on the debugger backend, and we may be able to use different heap tools. ## Class analysis for C++/ObjectiveC/Swift/Dlang/Java [#416](https://github.com/rizinorg/rizin/issues/416) Analysis classes, accessible under the `ac` command, is a relatively new feature of rizin. They provide a way to both manually and automatically manage and use information about classes in the binary. ### Devirtualize method calls using class vtables [#414](https://github.com/rizinorg/rizin/issues/414) Consider the following call: `call dword [eax + 0x6c]` Let's assume eax is the base pointer of a vtable we have saved in class analysis and we want to find out the actual address of the called method. So there should be a command that takes the offset (in this case 0x6c) and looks up the actual destination. It should be possible to call this command with a specific class, so it only looks into its vtable, or without a class, so it gives a list of possible destinations for all vtables that are not too small for the offset. When that is implemented, one could also add a command that does the same thing, but automatically takes the offset from the opcode at the current seek. ### Add classes list to `Vb` `Vb` already supports browsing bin classes. The same thing should be implemented for classes from analysis. ## Rizin legacy code refactoring ### Use internal API instead of commands Currently, Rizin's source code is rife with calls to `rz_core_cmd()`-like functions that run the Rizin command. While it is a useful shortcut for developer, it makes a good source of the potential bugs in case of the command syntax or behavior change. If these changes happen they are invisible to the compiler, so it cannot warn on the changed syntax. It isn't the case of changed function arguments count or type. Thus, all these calls eventually should be substituted with direct calls to the corresponding API functions. If there is no corresponding API function, then one should be created. Good examples of such cases are: - [Refactor Graph processing from commands to the API use](https://github.com/rizinorg/rizin/issues/397) - [Refactor Visual mode from commands to the API use](https://github.com/rizinorg/rizin/issues/382) - [Refactor Panels mode from commands to the API use](https://github.com/rizinorg/rizin/issues/383) In general you can just search for `rz_core_cmd` pattern in any place inside `librz/`. ## Miscellaneous ### Shell (dietline) improvements Currently Rizin uses its own readline-compatible implementation of the input handling in the embedded shell that is compact and portable between all supported platforms. It supports both Emacs and Vi modes, but not all bindings and features are supported. Some are omitted by choice, but some were simply not implemented. See the ["dietline"-labeled issues](https://github.com/rizinorg/rizin/labels/dietline). ### Improving regression suite and testing It is required to solve [numerous issues](https://github.com/rizinorg/rizin/labels/rz-test), along with improving parallel execution and performance. The next interesting idea is to setup and reuse Godbolt compilation engine for generating tests for different compilers and compilation options. There is even a command line tool for interacting with Godbolt - [cce](https://github.com/ethanhs/cce). ### Unbreaking broken tests Almost one thousand of tests marked as "broken" in our testsuite. The task is to take any of those, investigate why it fails, if the test makes sense now or already irrelevant today. Then to try to fix some of the broken tests. ## RzGhidra There are many small issues in the decompiler output: - [`pdgsd` commands showing incorrect P-code](https://github.com/rizinorg/rz-ghidra/issues/172) - [Improvements in recovering jump tables](https://github.com/rizinorg/rz-ghidra/issues/236) - [rz-ghidra can't detect string](https://github.com/rizinorg/rz-ghidra/issues/85) - [Ghidra Decompiler Error: Could not finish collapsing block structure](https://github.com/rizinorg/rz-ghidra/issues/203) - [Mishandled tail jump with relocation inside the jump function](https://github.com/rizinorg/rz-ghidra/issues/202) - [Prioritize keeping vars with lower addresses](https://github.com/rizinorg/rz-ghidra/issues/167) - [Minor improvements for the SLEIGH plugin](https://github.com/rizinorg/rz-ghidra/issues/133) Some of these issues might be related on how Rizin and RzGhidra integrate and might require changes in the Rizin side. Also note that most of these issues should be paired with the test to verify it will not break in the future. --- ## File: content/gsoc/2025.md --- title: "GSoC 2025" layout: "single" ShowToc: true TocOpen: false ShowReadingTime: false date: "2025-01-26" --- **TL;DR** Jump to the [Ideas list](#project-ideas). # Introduction This year, we participate again, effectively continuing the tradition since 2015. ## Mentors Members of the Rizin and Cutter core teams have volunteered to guide participants for GSoC’25. They have already been guiding the participants for the GSoC and RSoC in past years. Please feel free to reach out to any of them if you need any help in selecting a project. - **Anton Kochkov** Mattermost: xvilka -- [@akochkov](https://twitter.com/akochkov) - **Florian Märkl** Mattermost/Telegram: @thestr4ng3r -- [@thestr4ng3r](https://muenchen.social/@thestr4ng3r) - **Giovanni Dante Grazioli** Mattermost/Telegram: @deroad [@der0ad](https://twitter.com/der0ad) - And many others ## Development methodology Currently, all repositories are hosted on GitHub [main](https://github.com/rizinorg/) organization account and bugs are tracked on GitHub [issues](https://github.com/rizinorg/rizin/issues) too. We are primarily using [our own Mattermost instance](https://im.rizin.re), IRC, and [Telegram](https://t.me/rizinorg)) for communication. We have a [testsuite](https://github.com/rizinorg/rizin/tree/dev/test) (which is running on GitHub Actions, [Travis CI](https://travis-ci.com/rizinorg/rizin), [AppVeyor](https://ci.appveyor.com/project/rizinorg/rizin) and SourceHut) to test and verify that all the features are still working and that a pull requests or commits don't break anything, to ensure the support of different operating systems (Linux, MacOS, Windows, FreeBSD, OpenBSD), different architectures (x86/x86_64, ARM64, PowerPC, SystemZ), 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. For complex bugs and examples, we're using [ASCIInema](http://asciinema.org/) to record the sessions. See also our guides for corresponding projects: - Rizin [Contributing Guide](https://github.com/rizinorg/rizin/blob/dev/CONTRIBUTING.md) and [Developers Intro](https://github.com/rizinorg/rizin/blob/dev/DEVELOPERS.md) - Cutter [Contributing Guide](https://github.com/rizinorg/cutter/blob/master/CONTRIBUTING.md) and [Developers Intro](https://cutter.re/docs/code.html) For those who want to get introduced to the Rizin codebase and practices, we recommend to pick one of the easy issues for [Rizin](https://github.com/rizinorg/rizin/labels/good%20first%20issue) or [Cutter](https://github.com/rizinorg/cutter/labels/good%20first%20issue) to start with. ## License Rizin is modular: this means that it aims to make all the elements and features easily reusable from other projects. The choice of [LGPL3](https://www.gnu.org/licenses/lgpl.html) as a license is the minimum requirement to get code merged in Rizin. 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 Rizin while protecting our free codebase. ## Instructions for participants Participants who want to apply to the Rizin project for the Google Summer of Code 2025 are required to submit a small pull request accomplishing one of the [microtasks](#microtasks) (see below) as part of their application. You can also choose any of the GitHub issues for Rizin if they are big enough to be a qualification task and still small enough to be finished in no more than a couple of weeks. To help participants understand how to contribute to the project, there are issues marked as **"good first issue"** for both [Rizin](https://github.com/rizinorg/rizin/labels/good%20first%20issue) and [Cutter](https://github.com/rizinorg/cutter/labels/good%20first%20issue). ## Programming languages Most of Rizin is written in C (conforming to the C99 standard), and hence, we expect participants to be familiar with C programming language. For some of our tasks or microtasks, such as [rz-pm](https://github.com/rizinorg/rz-pm), they should know the Go programming language. For the [Cutter tasks](#cutter), it is a requirement to know C++ and Qt framework basics. ## Recommended steps 1. Read Google's instructions for participating 2. Grab any of the projects from the list of ideas that you're interested in (or propose your own). 3. Write a first draft proposal using Google Docs and [our template](https://docs.google.com/document/d/1kDPGgr_D5tQuYLQi_gEGlkuQ-DlU8GH5kDBqZbVSC7I/edit?usp=sharing) and ask one of the mentors or administrators to review it with you. 4. Submit it using Google's web interface. ## Participant proposal guidelines 1. Keep it simple enough to fit in no more than a couple of pages. Try to be clear and concise in your writing. 2. Try to split the entire GSoC period into tasks and each task into subtasks. It helps us understand how you plan to accomplish your goals, but more importantly, it'll help you understand the task deep enough before starting and prioritize important things to do first. 3. Please note how much time a day/week you can spend on this project. 4. Please specify which category you apply for - medium task or extended deadline one. 5. Specify your timezone so we can assign you a mentor in the same one to ease communication. 6. Submit your proposal early, not at the last minute! 7. Be sure to choose a “backup” idea (the second task you want to do) so that conflicts (two participants for one task) can be resolved. # Project Ideas # Cutter ## Improving usability and user experience (175 hour project) The Cutter's backend provides many features that are not exposed or exposed in Cutter efficiently. The goal of this task would be to figure out the users' biggest pain points and address them by improving or reworking the interface. Some of the issues are already in our GitHub, while others might be figured during the cross-comparison with other tools. ### Task - Add a scrollbar to the disassembly and hexdump widgets - Better syntax highlight and theming - Managing window/widget overlays - Add information about status of the analysis, signature searching, and other operations - Address various small UI problems that make user's life harder than necessary ### Skills The participant should be comfortable with the C++ and be familiar with Qt framework. Basics of the design/UX would be a plus. ### Difficulty Advanced ### Benefits for the participant The participant will gain an experience of creating comfortable and efficient user interface with C++/Qt. ### Benefits for the project It will make interface and user experience more consistent, on par with Rizin itself, and other tools. ### Assess requirements for midterm/final evaluation - 1st term: Add scrollbar to necessary widget, improve theming and syntax highlight - Final term: Managing widgets layouts, docking; provide action status information ### Mentors - thestr4ng3r - xvilka - Megabeets ### Links/Resources - [User Experience project for Cutter](https://github.com/orgs/rizinorg/project/4/views/1) - [User Experience project for Rizin](https://github.com/rizinorg/rizin/projects/1) ## Plugins and Python High Level API (175 hour project) Our current public API to be used by plugin authors is somewhat limited. We need to improve a lot of things about our Plugins support and take it few steps ahead. This task is only about improving the public C++ and Python interface of Cutter, specifically its graphical user interface components. For a task about exposing Rizin's API for disassembly, analysis and other purposes, see the Rizin bindings task above. ### Task - Expose everything Cutter can offer for plugin authors. This includes high level API, integration of the plugin management etc. - Accessing everything from Python (like Blender) - see [issue #1662](https://github.com/rizinorg/cutter/issues/1662) - Python integration and IPython console. ### Skills The participant should be comfortable with the C++ and Python languages, and be familiar with Qt framework ### Difficulty Advanced ### Benefits for the participant The participant will gain an experience of creating a suitable API for scripting graphical interface programs. ### Benefits for the project It will greatly improve the scripting experience, will make API more consistent and will ease creating Cutter plugins by the community. Moreover, it will simplify testing of the Cutter features. ### Assess requirements for midterm/final evaluation - 1st term: Design of the high level API and required Rizin changes. Review and implement all missing API functions that are accessible as interface controls. - Final term: Implement the way to show the API when hovered over some interface control, create documentation. ### Mentors - thestr4ng3r - Megabeets ### Links/Resources - [SDB Module/API for Cutter Python/Jupyter integration](https://github.com/rizinorg/cutter/issues/1778) - [Jupyter plugin for Cutter](https://github.com/rizinorg/cutter-jupyter) ## Multi-Tasking and Event-driven architecture (350 hour project) The information Cutter gets about functions, strings, imports, and the analysis are all performed in Rizin and only displayed in Cutter. Currently, it is pulling most information from Rizin only on demand. This is problematic because sometimes the user performs changes (via plugins, the console widget, and more) that are affecting the information from Rizin, but Cutter doesn't know about these changes to apply the to the UI. For example, if a user will define a new function in a Python script or via the console widget by using the Rizin command `af @ `, Cutter will not show this new function in the Functions widget until the user will refresh the interface manually (Edit -> Refresh Contents). The goal of this task is to use an event-driven architecture to overcome this limitation. In addition, this task will also handle the analysis in the background feature, to allow the analysis performed by Rizin to happen while the interface is active. ### Tasks The overall implementation of this task should start from Rizin by adding events to many of the functions. This can be done using `rz_events`. For example, add an event for function creating, for section creation, for flag deletion, for name changed, and more - Add events to all the relevant functions inside Rizin - Add support for these events in Cutter and refresh and update the relevant widgets per each event - Support analysis in the background and allow the user to start its session while Rizin is analyzing (see [#1856](https://github.com/rizinorg/cutter/issues/1856), [#1574](https://github.com/rizinorg/cutter/issues/1574)) ### Skills The participant should be comfortable with the C++ for Cutter and C for Rizin. They should also be familiar with Qt framework. Experience in GUI code architecture, for example using functional reactive programming or Elm-like approaches is a plus. ### Difficulty Advanced ### Benefits for the participant The participant will gain an experience of creating complex event-driven software in both C and C++ languages. ### Benefits for the project It will allow to work on big files effortlessly in Cutter, will improve analysis quality as well. ### Assess requirements for midterm/final evaluation - 1st term: Implement events everywhere in the relevant places across Rizin code and event-driven interaction with Cutter. - Final term: Add support for the Cutter interface refresh based on the events from Rizin, implement analysis in background. ### Mentors - thestr4ng3r ## Heap viewer completion (175 hour project) Thanks to the work that was done in the previous GSoC, Cutter and Rizin have nice visualizations of the heap and memory maps. We would like to expand on this feature with performance improvements to the heap parsers and support more memory allocators. ### Task - Complete Cutter's implementation of the windows heap widget #[2723](https://github.com/rizinorg/cutter/pull/2723) - Improve the performance of the Windows heap parser - Fix Windows heap parsing errors - Make the implementation work with remote debugging modes ### Skills The participant should be comfortable with the C++, and be familiar with Qt framework ### Difficulty Medium ### Benefits for the participant The participant will gain the understanding on how modern runtimes provide the heap for various programs, which will be beneficial for the binary exploitation skills. ### Benefits for the project It will greatly improve the debugging and reverse engineering experience for complex programs, also provides the way to design the exploitation techniques with the help of Rizin/Cutter. ### Assess requirements for midterm/final evaluation - 1st term: Design and implement heap visualization widgets, add Rizin test and fixes - Final term: Various bugfixes related to the heap inspection support on various platforms and allocators, tests and documentation. ### Mentors - xvilka - Megabeets ### Links/Resources - [Issue #1041](https://github.com/rizinorg/cutter/issues/1041) - [Heap Viewer plugin for IDA Pro](https://github.com/danigargu/heap-viewer) - [Heap parsing for MacOS, tmalloc, jmalloc](https://github.com/rizinorg/rizin/issues/208) - [Dynamic Allocator Detection](https://github.com/rizinorg/rizin/issues/157) - ["heap"-marked Rizin issues](https://github.com/rizinorg/rizin/labels/heap) ## Diffing mode (175 hour project) Binary diffing is one of the most common tasks for the reverse engineer. There are many tools available, but most of them are either detached from the main RE toolbox or poorly integrated. Rizin provides basic diffing features out of the box with `rz-diff` tool, but Cutter has no interface to represent similar functionality. ### Task - Expose basic `rz-diff` features in the Cutter - Create the interface to choose two files for diffing - Create the way to show the differences in all main widgets: - Hexadecimal view - Disassembly view - Graph view - Pseudocode view ### Skills The participant should be comfortable with the C++ language, and be familiar with Qt framework ### Difficulty Medium ### Benefits for the participant The participant will gain an experience of creating efficient graphical interfaces. ### Benefits for the project It will greatly benefit the project since Cutter will be the only FOSS RE tool to provide this feature out of the box. ### Assess requirements for midterm/final evaluation - 1st term: Expose the `rz-diff` features in the Cutter core and create the interface for opening files for diffing. Implement the diff modes for hexadecimal and disassembly views. - Final term: Implement the diff modes for graph and pseudocode views, create the documentation. ### Mentors - xvilka - deroad ### Links/Resources - [Issue #1104](https://github.com/rizinorg/cutter/issues/1104) - [BinDiff](https://www.zynamics.com/bindiff.html) - [Diaphora](https://github.com/joxeankoret/diaphora) # Rizin ## Classes analysis for C++/ObjectiveC/Swift/Dlang/Java (350 hour project) Analysis classes, accessible under the `ac` command, is a relatively new feature of rizin. They provide a way to both manually and automatically manage and use information about classes in the binary. But their support is only bare bones, without supporting various analysis integration, as well as display in the disassembly output. Consider the following call: `call dword [eax + 0x6c]` Let's assume eax is the base pointer of a vtable we have saved in class analysis and we want to find out the actual address of the called method. So there should be a command that takes the offset (in this case 0x6c) and looks up the actual destination. It should be possible to call this command with a specific class, so it only looks into its vtable, or without a class, so it gives a list of possible destinations for all vtables that are not too small for the offset. When that is implemented, one could also add a command that does the same thing, but automatically takes the offset from the opcode at the current seek. ### Task - Connecting classes with their methods - Class inheritance - nesting data structs - Constructors and destructors autorecognition - `try`/`catch`/`finally` recognition and marking - arguments recognition - ASCII/graphviz graph of class inheritance/structure inheritance - Tests with sources for C++, FreePascal, D language, ObjC and Swift, for rizin-testbins - Classes list via `Vb`. It already supports browsing bin classes. The same thing should be implemented for classes from analysis. ### Skills * Good knowledge of the C language * Good knowledge of the C++ language (other languages, like ObjC, Swift, D, etc are a plus) ### Difficulty Hard ### Benefits for the participant Participant will understand how OOP languages work under the hood, and will master technique of detecting various high level (classes, methods) abstractions in the binary code. ### Benefits for the project It will greatly benefit the project to allow efficient reverse engineering of the programs written in C++ and other OOP languages. ### Assess requirements for midterm/final evaluation - 1st term: implement classes integration into the analysis, type inference; detect constructors and destructors, `try`/`catch` blocks. - Final term: Class inheritance recognition, virtual methods detection, building class inheritance graphs, visual mode to inspect classes and methods relationships. ### Mentors - xvilka - deroad ### Links and resources - [Improve vtable detection for C++, ObjectiveC, Dlang and Swift binaries - issue #416](https://github.com/rizinorg/rizin/issues/416) - [Devirtualize method calls using class vtables - issue #414](https://github.com/rizinorg/rizin/issues/414) ## Debugger improvements and portability (175 hour project) Rizin debugger already supports most of the platforms, including native and remote debugging. Nevertheless, for most platforms it's limited mostly to the x86/x86_64 and ARMv8, often lacking the tests. The task would be to add missing architectures to the native debugger, e.g. MIPS to the Linux Native, ARMv7/ARMv8 to the FreeBSD, System Z debugger for Linux, HPPA debugger for Linux, VAX debugger for NetBSD, and so on. Moreover, some information isn't available during the debugging mode, e.g. source-level breakpoints or names, it would be necessary to make sure debug commands understand those. With the help of emulators like QEMU and OpenSIMH we could extend our CI to automatically test these debuggers. ### Task 1. Integrated source-level information loaded from DWARF or PDB into debug commands and print `p` commands 2. Support for missing architectures that are supported by Rizin statically in the Linux native debugger 3. Support for missing architectures that are supported by Rizin statically in the BSD native debugger 4. Cover more platforms supported by the debugger with automated tests, with CI whenever it's possible 5. Fix the bugs in debuggers, minor refactorings of the code ### Skills * Good knowledge of the C language * Some experience in debugging with GDB or LLDB ### Difficulty Hard ### Benefits for the participant Participant will understand how debugging works on the low level, and will gain experience with variety of different platforms and operating systems. ### Benefits for the project It will allow efficient low-level debugging on various supported platforms, not only the mainstream ones, greatly improving Rizin's usefulness in reversing some domain-specific software. ### Assess requirements for midterm/final evaluation - 1st term: `SystemZ, MIPS, HPPA support in Linux native, remote GDB debuggers - Final term: ARM and SPARC support in *BSD debuggers, VAX support in NetBSD ### Mentors - xvilka - thestr4ng3r - ret2libc ### Links/Resources - [Debug-labeled issues](https://github.com/rizinorg/rizin/labels/Debug) - [RzDebug-labaled issues](https://github.com/rizinorg/rizin/labels/RzDebug) - [New Platform support](https://github.com/rizinorg/ideas/labels/New%20Platform) - [New Architecture support](https://github.com/rizinorg/ideas/labels/New%20Architecture) ## FRIDA integration (175 hour project) [FRIDA](https://frida.re) is the famous dynamic instrumentation toolkit that is immensely popular among mobile device researches. Rizin could be easily integrated with Frida by creating a plugin that will allow to connect to the Frida instance, receive traces, set breakpoints, get information and events from it. ### Task 1. Create the basic plugin that allows attaching, spwaning, launching processes within Frida loco ally 2. Support remote connection 3. Add feature to receive information from the Frida instanced 4. Add breakpoints and run/step/continue feature's 5. Support calling functions and scripts in the context of the instrumented process ### Skills Participant should know C as well as have the experience of working with debuggers. ### Difficulty Hard ### Benefits for the participant Participant will understand and learn how to use Frida toolkit, also the internals of the debugging and instrumentation processes. ### Benefits for the project It will allow easy dynamic code instrumentation right from the Rizin or Cutter session, allowing tracing and code inspection. ### Assess requirements for midterm/final evaluation - 1st term: Implement core of the FRIDA plugin, allowing local and remote debugging features - Final term: Add support for extended features like calling functions or scripts within the context ### Mentors - xvilka - thestr4ng3r - wargio ### Links/Resources - [FRIDA](https://frida.re) - [FRIDA (GitHub)](https://github.com/frida/frida) - [r2frida](https://github.com/nowsecure/r2frida) ## Exploitation capabilities improvements (175 hour project) Since modern architectures are now enforcing [W^X](https://en.wikipedia.org/wiki/W%5EX), exploiters are using [ROP](https://en.wikipedia.org/wiki/Return-oriented_programming). (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](https://www.corelan.be/index.php/2012/12/31/jingle-bofs-jingle-rops-sploiting-all-the-things-with-mona-v2/), there is also [ROPgadget](http://www.shell-storm.org/project/ROPgadget/) and [dropper](https://github.com/rizlik/dropper).There exist even tools that can generate ROP chains automatically, for example [exrop](https://github.com/d4em0n/exrop). It's a shame that despite having [RzIL](https://github.com/rizinorg/rizin/blob/dev/doc/rzil.md), Rizin doesn't have something similar yet. One of the possible solutions would be to build an external plugin or tool which will reuse power of librz and rz-gg. Moreover it makes sense to think about SROP, COOP and BROP support. The last year (GSoC'24) one of our participants started implementing this feature, but it wasn't finished. You could check the [rz-solver](https://github.com/rizinorg/rz-solver) repository for more details. Also, the `rz-gg` tool while has the ability to create a custom shellcode but there is still [a lot of work](https://github.com/rizinorg/rizin/issues?q=is%3Aissue+is%3Aopen+label%3Arz-gg) required. ### Task 1. Fix `rz-gg` issues 2. Write a compiler which uses SMT solver (like Z3 for example) to produce the ropchain: [#4563](https://github.com/rizinorg/rizin/issues/4563). 4. Support main architectures - x86, ARM, MIPS, PowerPC at the very least ### Skills The participant 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 Advanced ### Benefits for the participant The participant 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 Rizin ;) ### Assess requirements for evaluation - 1st term: Creating the language for defining the ROP chain semantics and integrating it with SMT solver - Final term: Working ropchain compiler, covered by tests and documented in the Rizin book. ### Mentors - xvilka - ret2libc ### Links/Resources - [ROPGadget](http://shell-storm.org/project/ROPgadget/) - [Ropper](https://github.com/sashs/Ropper) - [Angrop](https://github.com/salls/angrop) - [ROPC](https://github.com/pakt/ropc) - [exrop](https://github.com/d4em0n/exrop) - [roper2](https://github.com/oblivia-simplex/roper2) - [mona.py](https://www.corelan.be/index.php/2012/12/31/jingle-bofs-jingle-rops-sploiting-all-the-things-with-mona-v2/) from corelan - [Hunting for ROP Gadgets in Style](https://media.blackhat.com/us-13/US-13-Quynh-OptiROP-Hunting-for-ROP-Gadgets-in-Style-WP.pdf) (2012) - [dropper](https://github.com/rizlik/dropper) a BARF-based rop chain generator - [Materials](http://dustri.org/b/files/hacklu2014_r2_exploitation.tar.xz) about the exloitation workshop at Hack.lu 2014 - [Slides](https://github.com/XVilka/hacklu) for the exploitation part of workshop at Hack.lu 2015 - [RzEgg related bugs](https://github.com/rizinorg/rizin/labels/RzEgg) ## Binary case reduce tool (175 hours project) Similar to [Csmith/Creduce](https://github.com/csmith-project/creduce) but operating on the binary files, to reduce the size of the test and to avoid sharing proprietary/classified files. It can perform these operations: - cut bytes - shift - zero/0xFF/mask bytes - remove section Since it requires some knowledge of the file format, existing libraries like [LIEF](https://lief.re/) could be used. ### Task 1. Make a tool to reduce the size of ELF using specified operations 2. Extend it to other formats - PE, MachO 3. Create tests for this tool 4. Research the possibility of minimizing some testcases that are already in the Rizin repository. ### Skills The participant should be comfortable with the C language, as well as the high-level language of a choice (Python or Rust). ### Difficulty Advanced ### Benefits for the participant The participant will improve their understanding in file formats and their mutation. ### Benefits for the project This feature would greatly help in minimizing and anonimizing testcases for the Rizin and any other binary analysis tool. ### Assess requirements for evaluation - 1st term: Create the simple tool to reduce the ELF size - Final term: Extend it to other formats, improve the "compression" rate, cover with tests. ### Mentors - xvilka - deroad ### Links/Resources - https://github.com/rizinorg/ideas/issues/52 # Microtasks When taking any of microtasks please be sure someone isn't already working on them, and let us know if you are going to work on a particular one. ## Cutter UX improvements There are many small issues and missing features that when implemented will improve the user experience significantly: - [Allow adding new flags from hexdump](https://github.com/rizinorg/cutter/issues/2932) - [Scrollbar inside disasssembly windows](https://github.com/rizinorg/cutter/issues/2907) - [Variables and values popup widgets on mouse hover](https://github.com/rizinorg/cutter/issues/2532) - [Allow to set RzRun profiles from the GUI during debugging](https://github.com/rizinorg/cutter/issues/3199) - [Double-click on the type in Disasm and Graph widgets should switch to the Types windows and show the selected type](https://github.com/rizinorg/cutter/issues/2780) - [Set breakpoint inside X-Refs window](https://github.com/rizinorg/cutter/issues/2658) - [Unified dialogue to set debug symbols servers](https://github.com/rizinorg/cutter/issues/3202) See full list at our [User Experience](https://github.com/orgs/rizinorg/projects/4/views/1) project covering all parts of RizinOrg: Rizin, Cutter, RzGhidra, rz-pm. ## File formats Implementing the support for any new file format counts as a microtask. See [New File-Format](https://github.com/rizinorg/ideas/labels/New%20File%20Format) label for pending issues. ## Disassemblers and assemblers Implementing the support for any new architecture counts as a microtask. See [New-Architecture](https://github.com/rizinorg/ideas/labels/New%20Architecture) label for pending issues. Two notable examples are updating existing bytecode plugins to support newer versions of the respective languages: - [Support for the Lua 5.2 language changes](https://github.com/rizinorg/rizin/issues/3914) - [Support for the Python 3.11 and 3.12 language changes](https://github.com/rizinorg/rizin/issues/3130) ## Analysis The current code analysis has many caveats and issues which need addressing. Fixing them and writing more tests is important to stabilize and enhance rizin's analysis engine. [See these issues](https://github.com/rizinorg/rizin/labels/RzAnalysis) on our GitHub dashboard. ### Heap analysis [#157](https://github.com/rizinorg/rizin/issues/157) Currently Rizin has support for heap exploration and analysis, but the feature is still basic and can be improved. Additionally, [other allocators can be added](https://github.com/rizinorg/rizin/issues/208) (MacOS, tmalloc, etc.), but this should be done after a proper refactoring, because heap analysis shouldn't depend on the debugger backend, and we may be able to use different heap tools. ## Rizin legacy code refactoring ## Miscellaneous ### `rz-ar` - code archives unpacking tool https://github.com/rizinorg/rizin/issues/4866 ### Improving regression suite and testing It is required to solve [numerous issues](https://github.com/rizinorg/rizin/labels/rz-test), along with improving parallel execution and performance. The next interesting idea is to setup and reuse Godbolt compilation engine for generating tests for different compilers and compilation options. There is even a command line tool for interacting with Godbolt - [cce](https://github.com/ethanhs/cce). ### Unbreaking broken tests Almost one thousand of tests marked as "broken" in our testsuite. The task is to take any of those, investigate why it fails, if the test makes sense now or already irrelevant today. Then to try to fix some of the broken tests. ## RzGhidra There are many small issues in the decompiler output: - [`pdgsd` commands showing incorrect P-code](https://github.com/rizinorg/rz-ghidra/issues/172) - [Improvements in recovering jump tables](https://github.com/rizinorg/rz-ghidra/issues/236) - [rz-ghidra can't detect string](https://github.com/rizinorg/rz-ghidra/issues/85) - [Ghidra Decompiler Error: Could not finish collapsing block structure](https://github.com/rizinorg/rz-ghidra/issues/203) - [Prioritize keeping vars with lower addresses](https://github.com/rizinorg/rz-ghidra/issues/167) - [Minor improvements for the SLEIGH plugin](https://github.com/rizinorg/rz-ghidra/issues/133) Some of these issues might be related on how Rizin and RzGhidra integrate and might require changes in the Rizin side. Also note that most of these issues should be paired with the test to verify it will not break in the future. --- ## File: content/gsoc/2026.md --- title: "GSoC 2026" layout: "single" ShowToc: true TocOpen: false ShowReadingTime: false date: "2026-01-18" --- **TL;DR** Jump to the [Ideas list](#project-ideas). # Introduction This year, we participate again, effectively continuing the tradition since 2015. ## Mentors Members of the Rizin and Cutter core teams have volunteered to guide participants for GSoC’26. They have already been guiding the participants for the GSoC and RSoC in past years. Please feel free to reach out to any of them if you need any help in selecting a project. - **Anton Kochkov** Mattermost: xvilka -- [@akochkov](https://twitter.com/akochkov) - **Giovanni Dante Grazioli** Mattermost/Telegram: @deroad [@der0ad](https://twitter.com/der0ad) - And many others ## Development methodology Currently, all repositories are hosted on GitHub [main](https://github.com/rizinorg/) organization account and bugs are tracked on GitHub [issues](https://github.com/rizinorg/rizin/issues) too. We are primarily using [our own Mattermost instance](https://im.rizin.re), IRC, and [Telegram](https://t.me/rizinorg)) for communication. We have a [testsuite](https://github.com/rizinorg/rizin/tree/dev/test) (which is running on GitHub Actions, [Travis CI](https://travis-ci.com/rizinorg/rizin), [AppVeyor](https://ci.appveyor.com/project/rizinorg/rizin) and SourceHut) to test and verify that all the features are still working and that a pull requests or commits don't break anything, to ensure the support of different operating systems (Linux, MacOS, Windows, FreeBSD, OpenBSD), different architectures (x86/x86_64, ARM64, PowerPC, SystemZ), 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. For complex bugs and examples, we're using [ASCIInema](http://asciinema.org/) to record the sessions. See also our guides for corresponding projects: - Rizin [Contributing Guide](https://github.com/rizinorg/rizin/blob/dev/CONTRIBUTING.md) and [Developers Intro](https://github.com/rizinorg/rizin/blob/dev/DEVELOPERS.md) - Cutter [Contributing Guide](https://github.com/rizinorg/cutter/blob/master/CONTRIBUTING.md) and [Developers Intro](https://cutter.re/docs/code.html) For those who want to get introduced to the Rizin codebase and practices, we recommend to pick one of the easy issues for [Rizin](https://github.com/rizinorg/rizin/labels/good%20first%20issue) or [Cutter](https://github.com/rizinorg/cutter/labels/good%20first%20issue) to start with. Due to concerns about the quality of code generated by AI agents, we strongly discourage applicants who solely rely on them, from applying to our Google Summer of Code program. We require all the GSoC participants to demonstrate understanding of the code they submit to our repositories, and therefore reserve the right at any moment of time, to request the prompts sent to their AI tools to assess actual skills and comprehension of the person. ## License Rizin is modular: this means that it aims to make all the elements and features easily reusable from other projects. The choice of [LGPL3](https://www.gnu.org/licenses/lgpl.html) as a license is the minimum requirement to get code merged in Rizin. 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 Rizin while protecting our free codebase. ## Instructions for participants Participants who want to apply to the Rizin project for the Google Summer of Code 2026 are required to submit a small pull request accomplishing one of the [microtasks](#microtasks) (see below) as part of their application. You can also choose any of the GitHub issues for Rizin if they are big enough to be a qualification task and still small enough to be finished in no more than a couple of weeks. To help participants understand how to contribute to the project, there are issues marked as **"good first issue"** for both [Rizin](https://github.com/rizinorg/rizin/labels/good%20first%20issue) and [Cutter](https://github.com/rizinorg/cutter/labels/good%20first%20issue). > **IMPORTANT** > AI tools must not be used to fix GitHub issues labelled `good first issue`. > These issues are generally not urgent, and are intended to be learning > opportunities for new contributors to get familiar with the codebase. > Whether you are a newcomer or not, fully automating the process > of fixing this issue squanders the learning opportunity and doesn't add much > value to the project. > **Using AI tools to fix issues labelled as `good first issues` is forbidden**. ## Programming languages Most of Rizin is written in C (conforming to the C99 standard), and hence, we expect participants to be familiar with C programming language. For some of our tasks or microtasks, such as [rz-pm](https://github.com/rizinorg/rz-pm), they should know the Go programming language. For the [Cutter tasks](#cutter), it is a requirement to know C++ and Qt framework basics. ## Recommended steps 1. Read Google's instructions for participating 2. Grab any of the projects from the list of ideas that you're interested in (or propose your own). 3. Write a first draft proposal using Google Docs and [our template](https://docs.google.com/document/d/1kDPGgr_D5tQuYLQi_gEGlkuQ-DlU8GH5kDBqZbVSC7I/edit?usp=sharing) and ask one of the mentors or administrators to review it with you. 4. Submit it using Google's web interface. ## Participant proposal guidelines 1. Keep it simple enough to fit in no more than a couple of pages. Try to be clear and concise in your writing. 2. Try to split the entire GSoC period into tasks and each task into subtasks. It helps us understand how you plan to accomplish your goals, but more importantly, it'll help you understand the task deep enough before starting and prioritize important things to do first. 3. Please note how much time a day/week you can spend on this project. 4. Please specify which category you apply for - medium task or extended deadline one. 5. Specify your timezone so we can assign you a mentor in the same one to ease communication. 6. Submit your proposal early, not at the last minute! 7. Be sure to choose a “backup” idea (the second task you want to do) so that conflicts (two participants for one task) can be resolved. # Project Ideas # Cutter ## Improving usability and user experience (175 hour project) This project focuses on making Cutter's interface more flexible and maintainable. The goal is to address significant user pain points by updating UI behaviors and styling systems to match the flexibility of modern reverse engineering tools. ### Task - Make docking optional rather than enforced, allowing users to move and float windows freely [#3095](https://github.com/rizinorg/cutter/issues/3095) - Implement the ability to minimize and maximize individual widgets within the interface [#3060](https://github.com/rizinorg/cutter/issues/3060) - Fully specify color palettes for existing themes and replace explicit colors in stylesheets with palette roles [#2138](https://github.com/rizinorg/cutter/issues/2138) ### Skills The participant should be comfortable with the C++ and be familiar with Qt framework. Basics of the design/UX would be a plus. ### Difficulty Advanced ### Benefits for the participant The participant will learn to build flexible desktop layouts and manage professional UI design systems using C++ and Qt. ### Benefits for the project It will make interface and user experience more consistent, on par with Rizin itself, and other tools. ### Assess requirements for midterm/final evaluation - 1st term: Implement optional docking logic and widget minimize/maximize functionality. - Final term: Complete the theme palettization and replace explicit colors with palette roles to deduplicate stylesheets. ### Mentors - xvilka - Megabeets ### Links/Resources - [Window moving - docking should be optional](https://github.com/rizinorg/cutter/issues/3095) - [Allow minimize / maximize widgets](https://github.com/rizinorg/cutter/issues/3060) - [Paletize the Cutter color themes](https://github.com/rizinorg/cutter/issues/2138) ## Plugins and Python High Level API (175 hour project) Our current public API to be used by plugin authors is somewhat limited. We need to improve a lot of things about our Plugins support and take it few steps ahead. This task is only about improving the public C++ and Python interface of Cutter, specifically its graphical user interface components. For a task about exposing Rizin's API for disassembly, analysis and other purposes, see the Rizin bindings task above. ### Task - Expose everything Cutter can offer for plugin authors. This includes high level API, integration of the plugin management etc. - Accessing everything from Python (like Blender) - see [issue #1662](https://github.com/rizinorg/cutter/issues/1662) - Python integration and IPython console. ### Skills The participant should be comfortable with the C++ and Python languages, and be familiar with Qt framework ### Difficulty Advanced ### Benefits for the participant The participant will gain an experience of creating a suitable API for scripting graphical interface programs. ### Benefits for the project It will greatly improve the scripting experience, will make API more consistent and will ease creating Cutter plugins by the community. Moreover, it will simplify testing of the Cutter features. ### Assess requirements for midterm/final evaluation - 1st term: Design of the high level API and required Rizin changes. Review and implement all missing API functions that are accessible as interface controls. - Final term: Implement the way to show the API when hovered over some interface control, create documentation. ### Mentors - xvilka - deroad ### Links/Resources - [SDB Module/API for Cutter Python/Jupyter integration](https://github.com/rizinorg/cutter/issues/1778) - [Jupyter plugin for Cutter](https://github.com/rizinorg/cutter-jupyter) ## Multi-Tasking and Event-driven architecture (350 hour project) The information Cutter gets about functions, strings, imports, and the analysis are all performed in Rizin and only displayed in Cutter. Currently, it is pulling most information from Rizin only on demand. This is problematic because sometimes the user performs changes (via plugins, the console widget, and more) that are affecting the information from Rizin, but Cutter doesn't know about these changes to apply the to the UI. For example, if a user will define a new function in a Python script or via the console widget by using the Rizin command `af @ `, Cutter will not show this new function in the Functions widget until the user will refresh the interface manually (Edit -> Refresh Contents). The goal of this task is to use an event-driven architecture to overcome this limitation. In addition, this task will also handle the analysis in the background feature, to allow the analysis performed by Rizin to happen while the interface is active. ### Tasks The overall implementation of this task should start from Rizin by adding events to many of the functions. This can be done using `rz_events`. For example, add an event for function creating, for section creation, for flag deletion, for name changed, and more - Add events to all the relevant functions inside Rizin - Add support for these events in Cutter and refresh and update the relevant widgets per each event - Support analysis in the background and allow the user to start its session while Rizin is analyzing (see [#1856](https://github.com/rizinorg/cutter/issues/1856), [#1574](https://github.com/rizinorg/cutter/issues/1574)) ### Skills The participant should be comfortable with the C++ for Cutter and C for Rizin. They should also be familiar with Qt framework. Experience in GUI code architecture, for example using functional reactive programming or Elm-like approaches is a plus. ### Difficulty Advanced ### Benefits for the participant The participant will gain an experience of creating complex event-driven software in both C and C++ languages. ### Benefits for the project It will allow to work on big files effortlessly in Cutter, will improve analysis quality as well. ### Assess requirements for midterm/final evaluation - 1st term: Implement events everywhere in the relevant places across Rizin code and event-driven interaction with Cutter. - Final term: Add support for the Cutter interface refresh based on the events from Rizin, implement analysis in background. ### Mentors - xvilka ## Heap viewer completion (175 hour project) Thanks to the work that was done in the previous GSoC, Cutter and Rizin have nice visualizations of the heap and memory maps. We would like to expand on this feature with performance improvements to the heap parsers and support more memory allocators. ### Task - Complete Cutter's implementation of the windows heap widget #[2723](https://github.com/rizinorg/cutter/pull/2723) - Improve the performance of the Windows heap parser - Fix Windows heap parsing errors - Make the implementation work with remote debugging modes ### Skills The participant should be comfortable with the C++, and be familiar with Qt framework ### Difficulty Medium ### Benefits for the participant The participant will gain the understanding on how modern runtimes provide the heap for various programs, which will be beneficial for the binary exploitation skills. ### Benefits for the project It will greatly improve the debugging and reverse engineering experience for complex programs, also provides the way to design the exploitation techniques with the help of Rizin/Cutter. ### Assess requirements for midterm/final evaluation - 1st term: Design and implement heap visualization widgets, add Rizin test and fixes - Final term: Various bugfixes related to the heap inspection support on various platforms and allocators, tests and documentation. ### Mentors - xvilka - Megabeets ### Links/Resources - [Issue #1041](https://github.com/rizinorg/cutter/issues/1041) - [Heap Viewer plugin for IDA Pro](https://github.com/danigargu/heap-viewer) - [Heap parsing for MacOS, tmalloc, jmalloc](https://github.com/rizinorg/rizin/issues/208) - [Dynamic Allocator Detection](https://github.com/rizinorg/rizin/issues/157) - ["heap"-marked Rizin issues](https://github.com/rizinorg/rizin/labels/heap) ## Diffing mode (175 hour project) Binary diffing is one of the most common tasks for the reverse engineer. There are many tools available, but most of them are either detached from the main RE toolbox or poorly integrated. Rizin provides basic diffing features out of the box with `rz-diff` tool, but Cutter has no interface to represent similar functionality. ### Task - Expose basic `rz-diff` features in the Cutter - Create the interface to choose two files for diffing - Create the way to show the differences in all main widgets: - Hexadecimal view - Disassembly view - Graph view - Pseudocode view ### Skills The participant should be comfortable with the C++ language, and be familiar with Qt framework ### Difficulty Medium ### Benefits for the participant The participant will gain an experience of creating efficient graphical interfaces. ### Benefits for the project It will greatly benefit the project since Cutter will be the only FOSS RE tool to provide this feature out of the box. ### Assess requirements for midterm/final evaluation - 1st term: Expose the `rz-diff` features in the Cutter core and create the interface for opening files for diffing. Implement the diff modes for hexadecimal and disassembly views. - Final term: Implement the diff modes for graph and pseudocode views, create the documentation. ### Mentors - xvilka - deroad ### Links/Resources - [Issue #1104](https://github.com/rizinorg/cutter/issues/1104) - [BinDiff](https://www.zynamics.com/bindiff.html) - [Diaphora](https://github.com/joxeankoret/diaphora) # Rizin ## Classes analysis for C++/ObjectiveC/Swift/Dlang/Java (350 hour project) Analysis classes, accessible under the `ac` command, is a relatively new feature of rizin. They provide a way to both manually and automatically manage and use information about classes in the binary. But their support is only bare bones, without supporting various analysis integration, as well as display in the disassembly output. In GSoC 2025 initial work on this task had been done, but a bulk of the task still needs to be completed. For example, [the #5415 PR - ObjectiveC inheritance](https://github.com/rizinorg/rizin/pull/5415) needs to be updated, finished, and merged. Apart from that, parsing additional information like SEH is sometimes helpful for reconstructing C++ (and other languages) classes: [#2271](https://github.com/rizinorg/rizin/issues/2271) and [#2247](https://github.com/rizinorg/rizin/issues/2247). Consider the following call: `call dword [eax + 0x6c]` Let's assume eax is the base pointer of a vtable we have saved in class analysis and we want to find out the actual address of the called method. So there should be a command that takes the offset (in this case 0x6c) and looks up the actual destination. It should be possible to call this command with a specific class, so it only looks into its vtable, or without a class, so it gives a list of possible destinations for all vtables that are not too small for the offset. When that is implemented, one could also add a command that does the same thing, but automatically takes the offset from the opcode at the current seek. ### Task - Connecting classes with their methods - Class inheritance - nesting data structs - Constructors and destructors autorecognition - `try`/`catch`/`finally` recognition and marking - arguments recognition - ASCII/graphviz graph of class inheritance/structure inheritance - Tests with sources for C++, FreePascal, D language, ObjC and Swift, for rizin-testbins - Classes list via `Vb`. It already supports browsing bin classes. The same thing should be implemented for classes from analysis. ### Skills * Good knowledge of the C language * Good knowledge of the C++ language (other languages, like ObjC, Swift, D, etc are a plus) ### Difficulty Hard ### Benefits for the participant Participant will understand how OOP languages work under the hood, and will master technique of detecting various high level (classes, methods) abstractions in the binary code. ### Benefits for the project It will greatly benefit the project to allow efficient reverse engineering of the programs written in C++ and other OOP languages. ### Assess requirements for midterm/final evaluation - 1st term: implement classes integration into the analysis, type inference; detect constructors and destructors, `try`/`catch` blocks. - Final term: Class inheritance recognition, virtual methods detection, building class inheritance graphs, visual mode to inspect classes and methods relationships. ### Mentors - xvilka - deroad ### Links and resources - [Improve vtable detection for C++, ObjectiveC, Dlang and Swift binaries - issue #416](https://github.com/rizinorg/rizin/issues/416) - [Devirtualize method calls using class vtables - issue #414](https://github.com/rizinorg/rizin/issues/414) ## FRIDA integration (175 hour project) [FRIDA](https://frida.re) is the famous dynamic instrumentation toolkit that is immensely popular among mobile device researches. Rizin could be easily integrated with Frida by creating a plugin that will allow to connect to the Frida instance, receive traces, set breakpoints, get information and events from it. ### Task 1. Create the basic plugin that allows attaching, spwaning, launching processes within Frida loco ally 2. Support remote connection 3. Add feature to receive information from the Frida instanced 4. Add breakpoints and run/step/continue feature's 5. Support calling functions and scripts in the context of the instrumented process ### Skills Participant should know C as well as have the experience of working with debuggers. ### Difficulty Hard ### Benefits for the participant Participant will understand and learn how to use Frida toolkit, also the internals of the debugging and instrumentation processes. ### Benefits for the project It will allow easy dynamic code instrumentation right from the Rizin or Cutter session, allowing tracing and code inspection. ### Assess requirements for midterm/final evaluation - 1st term: Implement core of the FRIDA plugin, allowing local and remote debugging features - Final term: Add support for extended features like calling functions or scripts within the context ### Mentors - xvilka - deroad ### Links/Resources - [FRIDA](https://frida.re) - [FRIDA (GitHub)](https://github.com/frida/frida) - [r2frida](https://github.com/nowsecure/r2frida) ## Exploitation capabilities improvements (175 hour project) Since modern architectures are now enforcing [W^X](https://en.wikipedia.org/wiki/W%5EX), exploiters are using [ROP](https://en.wikipedia.org/wiki/Return-oriented_programming). (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](https://www.corelan.be/index.php/2012/12/31/jingle-bofs-jingle-rops-sploiting-all-the-things-with-mona-v2/), there is also [ROPgadget](http://www.shell-storm.org/project/ROPgadget/) and [dropper](https://github.com/rizlik/dropper). There exist even tools that can generate ROP chains automatically, for example [exrop](https://github.com/d4em0n/exrop). It's a shame that despite having [RzIL](https://github.com/rizinorg/rizin/blob/dev/doc/rzil.md), Rizin doesn't have something similar yet. One of the possible solutions would be to build an external plugin or tool which will reuse power of librz and rz-gg. Moreover it makes sense to think about SROP, COOP and BROP support. The last year (GSoC'24) one of our participants started implementing this feature, but it wasn't finished. You could check the [rz-solver](https://github.com/rizinorg/rz-solver) repository for more details. Also, the `rz-gg` tool while has the ability to create a custom shellcode but there is still [a lot of work](https://github.com/rizinorg/rizin/issues?q=is%3Aissue+is%3Aopen+label%3Arz-gg) required. ### Task 1. Fix `rz-gg` issues 2. Write a compiler which uses SMT solver (like Z3 for example) to produce the ropchain: [#4563](https://github.com/rizinorg/rizin/issues/4563). 4. Support main architectures - x86, ARM, MIPS, PowerPC at the very least ### Skills The participant 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 Advanced ### Benefits for the participant The participant 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 Rizin ;) ### Assess requirements for evaluation - 1st term: Creating the language for defining the ROP chain semantics and integrating it with SMT solver - Final term: Working ropchain compiler, covered by tests and documented in the Rizin book. ### Mentors - xvilka - Rot127 ### Links/Resources - [ROPGadget](http://shell-storm.org/project/ROPgadget/) - [Ropper](https://github.com/sashs/Ropper) - [Angrop](https://github.com/salls/angrop) - [ROPC](https://github.com/pakt/ropc) - [exrop](https://github.com/d4em0n/exrop) - [roper2](https://github.com/oblivia-simplex/roper2) - [mona.py](https://www.corelan.be/index.php/2012/12/31/jingle-bofs-jingle-rops-sploiting-all-the-things-with-mona-v2/) from corelan - [Hunting for ROP Gadgets in Style](https://media.blackhat.com/us-13/US-13-Quynh-OptiROP-Hunting-for-ROP-Gadgets-in-Style-WP.pdf) (2012) - [dropper](https://github.com/rizlik/dropper) a BARF-based rop chain generator - [Materials](http://dustri.org/b/files/hacklu2014_r2_exploitation.tar.xz) about the exloitation workshop at Hack.lu 2014 - [Slides](https://github.com/XVilka/hacklu) for the exploitation part of workshop at Hack.lu 2015 - [RzEgg related bugs](https://github.com/rizinorg/rizin/labels/RzEgg) ## Binary case reduce tool (175 hours project) Similar to [Csmith/Creduce](https://github.com/csmith-project/creduce) but operating on the binary files, to reduce the size of the test and to avoid sharing proprietary/classified files. It can perform these operations: - cut bytes - shift - zero/0xFF/mask bytes - remove section Since it requires some knowledge of the file format, existing libraries like [LIEF](https://lief.re/) could be used. ### Task 1. Make a tool to reduce the size of ELF using specified operations 2. Extend it to other formats - PE, MachO 3. Create tests for this tool 4. Research the possibility of minimizing some testcases that are already in the Rizin repository. ### Skills The participant should be comfortable with the C language, as well as the high-level language of a choice (Python or Rust). ### Difficulty Advanced ### Benefits for the participant The participant will improve their understanding in file formats and their mutation. ### Benefits for the project This feature would greatly help in minimizing and anonimizing testcases for the Rizin and any other binary analysis tool. ### Assess requirements for evaluation - 1st term: Create the simple tool to reduce the ELF size - Final term: Extend it to other formats, improve the "compression" rate, cover with tests. ### Mentors - xvilka - deroad ### Links/Resources - https://github.com/rizinorg/ideas/issues/52 ## Function prelude detection plugin (175 hours project) A common problem in binary analysis is function detection. One method is searching for function preludes. Preludes are a sequence of instructions commonly found at the beginning of a function. These preludes perform tasks like setting up the stack, or initializing registers to values as defined in the architecture's ABI. It is very common to hard-code these prelude patters and match instructions against them. These patterns get outdated, are tedious to update, and have to be written for each architecture. Instead an algorithm to detect function preludes, based on bytes from known functions, should be implemented. ### Task The student implements the prelude detection algorithm in form of a plugin. The plugin collects bytes found at call targets, compares their similarity and generates possible prelude patterns from byte sequences with a high similarity. Lastly, a stand-alone version of the algorithm should be implemented, by writing a simple wrapper around the plugin. ### Skills The participant should be comfortable with the C language. Being strong in statistics is a plus. ### Difficulty Beginner/Advanced ### Benefits for the participant The participant will improve their understanding in basic binary analysis and algorithm design. ### Benefits for the project This feature would greatly help in detecting functions independent of the binary's architecture and give a ready to be used tool to the reverse engineering community. ### Assess requirements for evaluation - Design the matching algorithm and implement in a plugin. ### Mentors - xvilka - deroad - Rot127 # Microtasks When taking any of microtasks please be sure someone isn't already working on them, and let us know if you are going to work on a particular one. ## Cutter UX improvements There are many small issues and missing features that when implemented will improve the user experience significantly: - [Variables and values popup widgets on mouse hover](https://github.com/rizinorg/cutter/issues/2532) - [Unified dialogue to set debug symbols servers](https://github.com/rizinorg/cutter/issues/3202) - [X-Refs Widget Improvements: lack of filtering & sorting in refs lists](https://github.com/rizinorg/cutter/issues/1366) - [Make sure all the filter-supported widgets are searching with case insensitivity](https://github.com/rizinorg/cutter/issues/2230) See full list at our [User Experience](https://github.com/orgs/rizinorg/projects/4/views/1) project covering all parts of RizinOrg: Rizin, Cutter, RzGhidra, rz-pm. ## File formats Implementing the support for any new file format counts as a microtask. See [New File-Format](https://github.com/rizinorg/ideas/labels/New%20File%20Format) label for pending issues. Notable good task is extending OMF file format to support more of its variations: [OMF51 and OMF96](https://github.com/rizinorg/rizin/issues/5418). One more format that is COFF-based and is good to have in Rizin is [TI-COFF](https://github.com/rizinorg/rizin/issues/4299). Another important improvement of the existing format is [parsing `__cstring` section of Mach-O files](https://github.com/rizinorg/rizin/issues/5409). ## Disassemblers and assemblers Implementing the support for any new architecture counts as a microtask. See [New-Architecture](https://github.com/rizinorg/ideas/labels/New%20Architecture) label for pending issues. Notable example is the [BPF dissembly and analysis support](https://github.com/rizinorg/rizin/issues/4757). ## Analysis The current code analysis has many caveats and issues which need addressing. Fixing them and writing more tests is important to stabilize and enhance rizin's analysis engine. [See these issues](https://github.com/rizinorg/rizin/labels/RzAnalysis) on our GitHub dashboard. ### Heap analysis Currently Rizin has support for heap exploration and analysis, but the feature is still basic and can be improved. Additionally, [other allocators can be added](https://github.com/rizinorg/rizin/issues/208) (MacOS, tmalloc, etc.), [musl](https://github.com/rizinorg/rizin/issues/5238), [uClibc](https://github.com/rizinorg/rizin/issues/5239). ## Debugging - [Haiku OS native debugger](https://github.com/rizinorg/rizin/issues/5150) ## Miscellaneous ### `rz-find` multiple directories support Simply allow `rz-find` [searching among multiple paths](https://github.com/rizinorg/rizin/issues/5253), just like coreutils `find` tool. ### `rz-ar` - code archives unpacking tool https://github.com/rizinorg/rizin/issues/4866 ### Improving regression suite and testing It is required to solve [numerous issues](https://github.com/rizinorg/rizin/labels/rz-test), along with improving parallel execution and performance. The next interesting idea is to setup and reuse Godbolt compilation engine for generating tests for different compilers and compilation options. There is even a command line tool for interacting with Godbolt - [cce](https://github.com/ethanhs/cce). ### Unbreaking broken tests Almost one thousand of tests marked as "broken" in our testsuite. The task is to take any of those, investigate why it fails, if the test makes sense now or already irrelevant today. Then to try to fix some of the broken tests. ## RzGhidra There are many small issues in the decompiler output: - [`pdgsd` commands showing incorrect P-code](https://github.com/rizinorg/rz-ghidra/issues/172) - [Improvements in recovering jump tables](https://github.com/rizinorg/rz-ghidra/issues/236) - [rz-ghidra can't detect string](https://github.com/rizinorg/rz-ghidra/issues/85) - [Ghidra Decompiler Error: Could not finish collapsing block structure](https://github.com/rizinorg/rz-ghidra/issues/203) - [Prioritize keeping vars with lower addresses](https://github.com/rizinorg/rz-ghidra/issues/167) - [Minor improvements for the SLEIGH plugin](https://github.com/rizinorg/rz-ghidra/issues/133) Some of these issues might be related on how Rizin and RzGhidra integrate and might require changes in the Rizin side. Also note that most of these issues should be paired with the test to verify it will not break in the future. --- ## File: content/posts/year-2025-summary/index.md --- author: "xvilka" title: "2025 Year Summary" date: "2026-02-01" summary: "An overview of the work done in 2025" tags: ["rizin", "cutter", "capstone", "rzil"] ShowToc: false weight: 2 --- # 2025 summary This year we focused on completing the RzIL migration of the most used architectures (the work still continues in 2026) and the backbone of the Rizin subsystem ## Team A new member joined the Rizin Core team - [billow](https://github.com/b1llow). ## Releases - Rizin versions 0.8.x and Cutter 2.4.x - 60% of work is done for Rizin 0.9.0 ## Capstone Just like the last year, we worked on some important improvements in Capstone that are necessary for Rizin: - Updated SPARC support for the latest by rot127 - Updated and greatly extended RISC-V support (with extensions) by moste00 - Various fixes in existing architectures ## Rizin - SPARC RzIL uplifting was implemented by Rot127 - H8/300 RzIL uplifting was implemented by billow - MIPS RzIL uplifting was implemented by deroad - RzSearch and search commands were rewritten from scratch and covered by tests - Various UI/UX improvements in Rizin commands - colorization, clearer output - MIPS support was greatly improved by rewriting analysis plugin and ELF, PE, COFF handling - C++ demangler was rewritten from scratch to support both v2 and v3 mangling schemes in one code: [PR #77](https://github.com/rizinorg/rz-libdemangle/pull/77), not yet merged - x86 plugin was migrated from Capstone to Zydis - Lua support was rewritten and upgraded to support all Lua versions from 5.0 to 5.5: [PR #5555](https://github.com/rizinorg/rizin/pull/5555), not yet merged - Python bytecode support was extended to handle also 3.11-3.14 versions - H8/500 support by billow - Infineon C166 support: [PR #5309](https://github.com/rizinorg/rizin/pull/5309), not yet merged - RISC-V plugin switched to Capstone: [PR #5482](https://github.com/rizinorg/rizin/pull/5482), not yet merged - Search of cryptographic was rewritten to support more algorithms - Native debugger was refactored and covered by tests for all architectures and platforms we have on our CI [(Link to GSoC report)](https://rizin.re/posts/gsoc-2025-summary-1/#taksh-refactoring-rizins-native-debug-plugin--my-gsoc-2025-journey) - Better handling of relocations, implement missing relocations (not yet complete, work still continues in 2026) - More globals and statics were removed [(Link to GSoC report)](https://rizin.re/posts/gsoc-2025-summary-1/#ahmed-kamal-thread-safety-improvement) - Improved C++ class analysis (not yet complete, more work is needed) - ROP search was greatly improved and covered by tests ## Cutter This year was the focus of improving user interface and user experience: - Improve stability (fix various crashes) - RzMark APIs (a new feature allowing selecting data and code ranges in both Rizin and Cutter) - Keybindings search [shortcuts-pr](https://github.com/user-attachments/assets/e43d36ee-07a0-4e2a-a7ba-6f3ad5181caa) - Add a scrollbar to the disassembly window - Update disassembly color theme by "lightness" - Use the new string search API from rizin - Remember IO mode for recent files - Fixed various translation issues ## Miscellaneous [Google Summer of Code 2025](https://summerofcode.withgoogle.com/programs/2025/organizations/rizin) --- ## File: content/posts/year-2024-summary/index.md --- author: "xvilka" title: "2024 Year Summary" date: "2025-01-02" summary: "An overview of the work done in 2024" tags: ["rizin", "cutter", "capstone", "rzil"] ShowToc: false weight: 2 --- This year we focused mainly on the "backbone" of the Rizin framework and all related tools, including Cutter. This will become a foundation of the future work we plan to finish in 2025. The major goal is to release 0.8.0 in upcoming months. As for the longer term you can see [our roadmap](https://rizin.re/roadmap/) for details. ## Releases - Rizin versions 0.7.x and Cutter 2.3.3-2.3.4 - 80% of work is done for [Rizin 0.8.0](https://github.com/rizinorg/rizin/milestone/18) ## Capstone A bulk of our effort was spent towards Capstone improvements as it is the core dependency and the main disassembly engine for many architectures supported by Rizin. A long-going project called Auto-Sync was finally merged and largely completed. You could read more details in our [corresponding article](https://rizin.re/posts/auto-sync/). - Updated PPC, ARM, AArch64 and SystemZ to LLVM 18. - Tricore support by billow - HPPA by r3v0lt - Alpha by r3v0lt - ARC PR by r3v0lt (not yet merged: [#2570](https://github.com/capstone-engine/capstone/pull/2570)) - MIPS, microMIPS, and nanoMIPS support by deroad - Xtensa by billow ## Rizin - Started merging RzAsm and RzAnalysis for the future RzArch - MIPS update to a Capstone-based plugin by deroad - Basic LoongArch support by deroad - PIC MCU family RzIL uplifting by billow - MSP430 RzIL uplifting by moste00 - Xtensa RzIL uplifting by billow - Hexagon RzIL uplifting by Rot127 - Finished (almost, with one PR still not yet merged) conversion to the rzshell - Rewritten text representation of ELF, PE, NE relocations by Roeegg2 - Added initial support for the Alpha architecture - Many bugfixes, refactorings, and performance optimizations ## Cutter - Switch to the Qt6 by default, including for forming releases - Updated Rizin ## Other projects - rz-ghidra: add support for PIC architectures - rz-ghidra: add support for Tricore architecture ## Miscellaneous - [Google Summer of Code 2024](https://summerofcode.withgoogle.com/programs/2024/organizations/rizin) - [FOSSAsia 2024 conference](https://eventyay.com/e/55d2a466/session/9017)