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. --- docs/PROJECTS.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) (limited to 'docs/PROJECTS.md') diff --git a/docs/PROJECTS.md b/docs/PROJECTS.md index 10274ab..38d3262 100644 --- a/docs/PROJECTS.md +++ b/docs/PROJECTS.md @@ -297,6 +297,26 @@ conversion happens in `BinaryRef.load_args`, and a base that isn't 16-byte aligned is rejected rather than silently landing somewhere else. `ida_args` passes anything else through untouched. +### ARM/Thumb + +Thumb is not 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: `push {r3,lr}` +(`08 b5`) reads as `SVCLT 0xBF00`, and `c` either refuses or carves garbage. + +`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 + +It sets IDA's `T` segment register, and forces the segment to 32-bit when +turning Thumb on. That second part isn't optional: Thumb doesn't exist in +AArch64, and a headerless blob loaded with `-parm` comes up 64-bit, so setting +`T` alone changes nothing and looks broken. Asking for Thumb *is* asking for +ARM32. + +`t` again toggles back — the mode is a guess, and guesses get revised. Both +states are saved in the `.i64`. + ### When analysis finds nothing Zero functions is what a raw image described wrongly looks like — right file, -- cgit v1.3.1-sl0p