From a0cb1a1a6f8aca7a64c102dba388e899267d5bc1 Mon Sep 17 00:00:00 2001 From: blasty Date: Sun, 26 Jul 2026 08:58:31 +0200 Subject: loading: a blob that analyses to nothing is still openable MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Pick a random .bin, say ARM at 0x4000, and you got two empty panes and "functions still loading…" — which was a lie; loading had finished. _auto_land falls back to the symbol picker when there's no entry function, and the picker answers an empty index with that message. Nothing ever opened. Zero functions is not a corner case. It's exactly what a real firmware image looks like when it's described wrongly, and IDA has no complaint of its own to make about it, so this was the last silent-wrong-answer in the blob path. Now: * Land in the listing at the start of the image. The bytes exist even when no code was recognised, so there is always something to show. * Say so, in the status bar, for as long as it stays true — an image with no functions is a property of the database, not an event, and writing it once meant the next status write erased it (the same clobber that bit the split view's "decompiling…"). * Ctrl+L re-asks. The .i64 has the old processor and base baked in and takes precedence over any switches, so reloading means deleting it; the confirmation says what that costs, and when there are no functions it says nothing is lost. Verified with real keys on a random 64K blob: ARM @ 0x4000 lands showing "db 65536 dup(?)" with the hint in the status; Ctrl+L -> confirm -> dialog -> metapc reloads at 0. The hint survives scrolling. tests: new tests/test_blob_ui.py (11) driving a real random blob end to end — lands, has rows, right base, honest status, hint survives navigation, Ctrl+L offers the reload and declining leaves the binary open. 202/0 scenarios, 30/0 project UI. (Harness note for future me: tmux send-keys reads "0x4000" as a hex KEY CODE and sends U+4000. Use send-keys -l for literal text.) --- docs/PROJECTS.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'docs') diff --git a/docs/PROJECTS.md b/docs/PROJECTS.md index 88ce2f6..10274ab 100644 --- a/docs/PROJECTS.md +++ b/docs/PROJECTS.md @@ -297,6 +297,25 @@ 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. +### 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 -- cgit v1.3.1-sl0p