Cutter shows wrong CPU language in disassembly window during debug

[drsn00ker]

Running Latest Cutter appimage 2.1.2 in Kali (tried Debian as well) On a Intel core2 duo. Trying to study an ARM32EL v8 program. Debug shows the incorrect x86 code in Disassembly window (but proper ARM registers (see picture). Importantly debug does complete the execution successfully! Just wish I could see what it's doing in the code.

I will also add that the emulator even shows the X86 registers and tries to (and fails) to run the code as x86, even though it is ARM. Lastly, I hope you will add the option of command line parameters for the emulator! Thanks for all the great work!

[karliss]

Which debugging backend are you using and how you running arm executable on a x86 computer? What emulator are you using?

but proper ARM registers (see picture)

Which part of the screnshot are you referring as proper ARM registers? All I see is rax, rbx, rcx, rdx which are not ARM register names. Are the the values correct ?

[drsn00ker]

Honestly don't know about the back-end. I'm very new at this. Just hit the debug button on the top of the screen! My guess is, it is gdb (hence the x86) and not gdb-multiarch? But don't know how to verify that. From x86 linux I run: qemu-arm -g 1234 program parameters then in a second terminal gdb-multiarch

Should have said mostly ARM registers in debug. The first couple are some hybrid: rAX should just be r0 or AX.

[the-Arioch]

• AX/CX/DX/BX/BP/SP/SI/DI - original 16-bit i8086 registers
• EAX, ECX, ... - the 32-bit i80386 extension to x86 registers
• RAX, RCX, ... - the AMD64 extension to x86 registers

Clearly not ARM.

And in general Rnnn is so common a convention that it would hardly help to identify processors. I believe all DEC computers of 1960-s/1970-s had their registers as R0 till R7 for example.

In particular, R08 till R15 are normal AMD64 registers (added to the pre-AMD64 set of 8 GPRs named above), so what most probably is displayed on your screenshot is a snapshot of most often used ARM64 registers and none distinctly from other architectures.

Could you copy the DASHBOARD panel ?

Also, there can be "universal binaries" having compiled code for several platforms at once. Even if your file has ARM code inside does not always preclude having x86 code too.

Technically even Windows or OS/2 EXE/DLL are "universal", carring both 16-bit DOS code and 32/64-bit Windows code in one file. Disasm tools customarily just ignore the DOS code there as it usually is a meaningless "don't run me in DOS" stub (but the code is still there regardless).

[drsn00ker]

Sure thing. It's a tiny (18kb) executable binary pulled from a firmware. It runs fine using "qemu-arm program parameters"

[karliss]

If you simply press the debug button without any additional setup it will try to start the native debugging session. Which will result in complete nonsense. I guess there should probably be a sanity check if you are trying to start debugging an executable which isn't for current archtitecture or OS.

For debugging executables from different platforms you can use either the rizin builtin emulator or connect to remote debugger. Note that builtin rizin emulator is good enough for emulating individual functions that don't interact with OS, but if you try to emulate whole executable the result may vary.

As for remote connection in theory it should be possible to connect to your qemu somewhat similar to what you do with gdb-multiarch. Different programs implement different subset of gdb protocol, so at the moment not every tool which supports gdb protocol works well with Cutter.

[drsn00ker]

Debug does work and finishes correctly (in non-native mode) even when stepping through it. Just showing the wrong mnemonics. Let me start playing with the emulator to see if that is making more sense.