diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/PROJECTS.md | 57 | ||||
| -rw-r--r-- | docs/TEXTUAL_NOTES.md | 32 |
2 files changed, 88 insertions, 1 deletions
diff --git a/docs/PROJECTS.md b/docs/PROJECTS.md index 88ce2f6..eae860b 100644 --- a/docs/PROJECTS.md +++ b/docs/PROJECTS.md @@ -297,6 +297,63 @@ 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`. + +**Pick a 32-bit processor at load, or none of this decompiles.** Bare `arm` +gives a 64-BIT database (AArch64), and that is decided at load time and cannot be +changed afterwards — setting the bitness post-hoc makes the decompiler INTERR. +In a 64-bit database: + +* Thumb doesn't exist, so `t` sets a segment flag that means nothing; and +* Hex-Rays refuses a 32-bit function outright — *"only 64-bit functions can be + decompiled in the current database"* — so the disassembly looks right and F5 + silently produces nothing. + +So the list offers `arm:ARMv7-A` (most firmware), `arm:ARMv7-M` / `arm:ARMv6-M` +(Cortex-M, Thumb only) and `arm:ARMv5TE` alongside 64-bit `arm`. `t` warns when +it notices the database is 64-bit and points at `Ctrl+L`. + +Worth knowing: a correctly-chosen 32-bit ARM database also lets IDA's own +auto-analysis find Thumb functions — `experiments/fibonacci.bin` yields 54 +functions on load with `arm:ARMv7-A` and none with `arm`. + +### When analysis finds nothing + +Zero functions is what a raw image described wrongly looks like — right file, +wrong architecture, and IDA has no complaint to make about it. The app used to +fall through to the symbol picker, which had nothing to show, so you got empty +panes and a status reading "functions still loading…" long after loading had +finished. + +Now it opens the listing at the start of the image (the bytes are there even when +no code was recognised) and the status bar carries the diagnosis for as long as +it's true: + + seg000 @ 0x0 [listing] — no functions: wrong processor/base? Ctrl+L to reload + +`Ctrl+L` re-asks. The database IDA already built has the old processor and base +baked into it and wins over any switches, so reloading means deleting it — hence +the confirmation, which tells you what you'd lose (and, in this case, that you'd +lose nothing). + Two things worth knowing: * The options apply to the **first** open only. Afterwards the `.i64` records how diff --git a/docs/TEXTUAL_NOTES.md b/docs/TEXTUAL_NOTES.md index 4bf7fcb..c8b265c 100644 --- a/docs/TEXTUAL_NOTES.md +++ b/docs/TEXTUAL_NOTES.md @@ -15,7 +15,7 @@ Hard-won Textual behaviour and the patterns this app relies on. Pairs with isn't recomputed until layout. Apply the scroll now AND again via `call_after_refresh` with `refresh(layout=True)`; don't zero `virtual_size` on load (snaps scroll to 0 → visible flash). See `ColumnCursor._apply_scroll`, - `DisasmView._on_primed`, `DecompView.show`. + `ListingView._on_primed`, `DecompView.show`. - **Scrolling on already-laid-out content (no reload) leaves a stale frame.** A plain `scroll_to` moves `scroll_offset` but Textual only repaints on a *rounded* scroll change, and with no virtual_size/content change there's no @@ -80,3 +80,33 @@ Hard-won Textual behaviour and the patterns this app relies on. Pairs with failures. Re-run on a warm session before trusting a regression. - Edits mutate the `.i64` — revert renames (via API) for idempotency; use a PID-unique temp name to dodge collisions from a prior crashed run. + + +## A priority app binding fires even under a modal + +`Binding("tab,shift+tab", "toggle_view", priority=True)` on the App runs before +the focus chain, so Tab never reached ANY dialog — nothing in a modal could be +tabbed to, in this app, ever. It looked like a bug in one dialog (the load +options address field was unreachable) and was actually app-wide. + +The fix is in the action, not the binding: if a modal is up, hand the key back. + +```python +def action_toggle_view(self): + if self.screen is not self.screen_stack[0]: + self.screen.focus_next() + return +``` + +Related: DOM order is rarely the tab order you want. In a dialog with a filter +box, an option list and a second field, `focus_next()` stops at the list — which +is arrow-driven and has nothing to type — so text meant for the second field +lands in the filter. Override `focus_next`/`focus_previous` on the screen to +cycle the fields people actually type into. + +## A modal can outgrow the terminal and clip its own controls + +`#pal-list { max-height: 24 }` plus a 21-row list pushed the address field and +help line off the bottom of the screen. Nothing errors; the field is simply not +there, which reads to the user as "Tab does nothing". Cap the scrollable part +per-dialog so the controls below it are always visible. |