Set analysis tree in radare2 in a vim like philosophy.

[gogo2464]

Description

Using emulicious we can debug a game boy rom and see all subfolder and files from debug information. In radare2 we currently can only see debugs infos in a single file in r2.

If you want to see how to test emulicious, fell free to download a file with all debug symbols:

on debian:

sudo apt install cmake make gcc git -y;
sudo apt install pkg-config libpng-tools libpng-dev bison -y;

git clone https://github.com/radareorg/radare2;
sh ./radare2/sys/install.sh;

git clone https://github.com/gbdev/rgbds;
cmake -S . -B rgbds/build/ -DCMAKE_BUILD_TYPE=Release rgbds/;
cmake --build rgbds/build;
sudo cmake --install rgbds/build;
sudo make install -C rgbds;

git clone https://github.com/pret/pokered;
make -C pokered/;

git clone https://github.com/MrCheeze/pokered-self-replicator;
mv pokered-self-replicator/sav.dat pokered/pokered.sav;

wget https://bgb.bircd.org/bgbw64.zip;
mkdir bgb;
unzip bgbw64.zip -d bgb;

sudo dpkg --add-architecture i386
sudo wget -nc -O /usr/share/keyrings/winehq-archive.key https://dl.winehq.org/wine-builds/winehq.key
sudo wget -nc -P /etc/apt/sources.list.d/ https://dl.winehq.org/wine-builds/debian/dists/bullseye/winehq-bullseye.sources
sudo apt update
sudo apt install --yes --install-recommends winehq-devel 

wine64 $(pwd)/bgb/bgb64.exe $(pwd)/pokered/pokered.gbc;

then download emulicious : http://emulicious.net/downloads/

file -> open file
then
tools -> debugger

and you will see that the difference is huge!!!

See

[trufae]

Can you provide a screenshot or some explanations about your proposal? I cant barely understand your explanation.

[gogo2464]

Yes sure I just updated my post.

[gogo2464]

@trufae I was referiing to the files in the left pane

[trufae]

yes i understand, but what information would you put in that tree and how that will be browsable from visual/shell/webui/qt? i mean the data is there, but im struggling to find why is that better than plain lists, to follow references that can create infinite loops so you cant circle back without a memory explosion there.

you have a tree-like view of classes->methods and functions->variables in visual (Vv), which can be always improved to show the child nodes as in a tree..

[gogo2464]

It is better because we can know where to jum to a sepecific reference like code source folders

[trufae]

But which data do you want to put in that tree?

[gogo2464]

I doubt. I hesitate between put reference to single blop or if I would like to split the signle file in several folders with the left pane.

[gogo2464]

"and how that will be browsable from visual/shell/webui/qt?"

Good question:
- visual mode: we could use shortcut like in vim IDEs to switch between panes.
- console: we do not have access on the bin but we could use the command s.
- shell: rasm could create folders.
- webui: we will need to create tags.
- qt: use qt panels.

But basically yes... I have a big big idea with no implementation details.

[trufae]

but what's the info you want? function -> calls? this is already in aflm, having it in visual should be easy, as it can be already used via ~.. or ~...

i dont understand what rasm have to do here, or what do you mean by tags in the webui for example. if you have a big idea, but you dont know how to express it, code it, please elaborate it,make a proper proposal or show an example of what you want, because from the view in the screenshot i see sources+ functions, but in r2 you dont have the concept of "source files" unless yo uhave source-lines information via dwarf/etc.. i can quickly implement whatever i think you want here, it doesnt seems much complex, but i dont understand your idea

[gogo2464]

It is not more info. It is just a way to access them by file.

[gogo2464]

I just want to split code in various files like in source code ide. Only possible when the debug infos are available.

[gogo2464]

Yes i want to add sources files.we might add it from the analysis plugin. It remains an idea.

[trufae]

Got it. I will think a bit about the idea. Seems interesting as it puts compile units to the top level and maybe handy to maybe have multiple columns with different open entries. And this kind of works in panels with aflm but a subcommand like aflms for source files as top level and an argument that picks a comma separated list of entries opened. This way it will work from the shell too

[gogo2464]

Yes. seems a good idea for at least:
- gameboy due to precise debug symbols
- android APKs because it is a single zip with several source code files in including smali (source code), and data in .xml and also .so. Sounds a challenging philosophy.