From 7bdf3741c91f76bfff3f3e054a5cf41b7f476d0b Mon Sep 17 00:00:00 2001 From: blasty Date: Sun, 26 Jul 2026 14:51:07 +0200 Subject: arm: switch ARM/Thumb decoding with `t` MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `c` could not carve Thumb code. Thumb isn't a property of the bytes — it's a mode the CPU is in — so a raw image gives IDA nothing to detect: at a Thumb entry point it decodes 16-bit instructions as 32-bit ARM and produces confident nonsense. experiments/fibonacci.bin starts with `08 b5` = push {r3,lr}, which IDA reads as SVCLT 0xBF00. `t` on the listing switches the mode at the cursor and disassembles in it: Thumb @ 0x0 (segment set to 32-bit; Thumb needs ARM32) — 10 instructions 0x0 PUSH {R3,LR} 0x2 MOVS R1, #0 0x4 MOV R4, R0 0x6 BL unk_E3C Setting the T segment register is only half of it. Thumb does not exist in AArch64, and a headerless blob loaded with -parm comes up 64-bit, so T alone changes nothing and looks broken — I watched exactly that happen while probing the API. Asking for Thumb IS asking for ARM32, so set_thumb forces the segment to 32-bit and says so rather than doing it silently. It also has to del_items over the range first: the bytes are currently decoded in the old mode, and leaving that item defined pins the wrong instruction length so the new mode has nothing to apply to. Implemented as a `thumb` kind in the existing edit-item flow, so it inherits the shared reload — same cache bump, same ViewAnchor restore, same status flash. It switches AND disassembles, because flipping T and leaving the bytes undefined shows you nothing and reading the code was the point. tests: new tests/test_thumb_ui.py (8) driving the real Thumb binary — `c` alone does NOT produce the prologue, `t` does, the instructions are 16-bit wide (in ARM mode those three rows would be one 4-byte instruction), the run continues, the status explains the 32-bit forcing, and `t` toggles back. Deletes the .i64 first, because T and the segment's addressing mode are saved in it and a stale database would answer the question for us. 209/0 scenarios, 26/0 blob, 8/0 thumb. --- README.md | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'README.md') diff --git a/README.md b/README.md index 8fc59fd..6ccd65a 100644 --- a/README.md +++ b/README.md @@ -98,6 +98,10 @@ nothing: ./ida-tui fw.bin --processor arm --base 0x8000000 ``` +ARM images that use Thumb need one more thing: press `t` on the listing to switch +ARM/Thumb decoding at the cursor (it sets IDA's `T` register, and the segment to +32-bit, since Thumb doesn't exist in AArch64). + `--base` is a real address (IDA's own `-b` is in paragraphs; the conversion is done for you). In a project the options are recorded per binary, which is what a multi-image firmware wants. They apply to the first open only — after that the -- cgit v1.3.1-sl0p