Consider to make it a plugin to Cutter

[XVilka]

Would benefit both platforms a lot. The one way is to do it directly as a plugin, another way is to separate "raster" widgets to be reusable in other projects too, like Cutter.

Radare2 is a highly-portable cross-platform reverse engineering framework and a toolkit without dependencies. It has support for analyzing binaries, disassembling code, debugging programs, attaching to remote GDB/LLDB, WinDbg servers, rich plugin system (see r2pm), and integration with various decompilers. For example, ghidra decompiler plugin - r2ghidra-dec. It is actively developed and can be easily integrated in various open source and commercial products. I believe, it will be highly beneficial to support these and provide a package for install from r2pm, see the package repository here: https://github.com/radareorg/radare2-pm

For documentation on writing plugins for radare2 see Scripting and Plugins Radare2 Book chapters.

Cutter is a crossplatform Qt/C++ GUI frontend to radare2:

For documentation on writing plugins for Cutter see the official tutorial and the curated list of various popular plugins.

See also rizinorg/cutter-plugins#3

[hello-adam]

yeah, seems like you could maybe make a cutter plugin that was a wrapper around hobbits display plugins and then you'd just get any future hobbits displays for "free"

I couldn't find a C++ plugin guide, but I'll take a look at one of their existing C++ plugins at some point. I can't say we'll be able to prioritize this, but it's good to have on the radar (and we'll certainly support anyone who is interested in making/maintaining this integration)

[karliss]

Hi, it's probably better to keep the discussion in separate issue either here or creating a new in cutter/plugins instead of rizinorg/cutter-plugins#3 .

Refreshing on every seek change is probably way too aggressive. That would mean reloading every time a user clicks within a disassembly widget or hexdump. IO access through r2 can be quite slow especially with some debug backend. It will probably better once async r2 access refactoring is done but it will take some time.

For the context - r2 operates in a 64 bit address space and files can be mapped at different points of it. Typically a PE or ELF executable will be mapped in a similar layout as it would be when it gets loaded by OS for execution.

To get the information about regions containing something you will probably have to use one of r2 commands using cmdj https://cutter.re/docs/developers-docs.html#calling-a-radare2-command . o group of commands especially oj and omj look promising. Maybe leave an option to manually specify the memory range. There are also commands for listing executable sections and segments but those don't work on raw binaries or any other file format that doesn't have such concept.

Seek would be better used as cursor within loaded memory.

I recommend looking into MemoryDockWidget . It allows user to enable or disable seek synchronization and use "show in memoryWidgetX" context menu. At the moment it requires specifying MemoryWidgetType enum value, but nothing too bad will happen if you specify whatever. In future I will adjust the API so that plugins can use MemoryWidgetType::Other.

You shouldn't reload memory when the widget is in background or closed. Take a look at RefreshDeferrer and createRefreshDeferrer.

[hello-adam]

@karliss thanks, I moved it to the plugin project: Mahlet-Inc/hobbits-cutter-plugin#1

Hobbits requirements that would facilitate this plugin and/or other integrations can be opened as new issues.