loading: say how to read a headerless blob (processor, base)

A raw firmware dump has no format to detect, so IDA fell back to x86 at address
0. It doesn't fail — it opens, analyses, and finds nothing. An AArch64 image
loaded this way gave 0 functions; told the truth it gives 35.

    ida-tui fw.bin --processor arm --base 0x8000000

and per binary in a project, which is what a multi-image firmware actually
needs:

    {"path": "app.bin", "processor": "arm", "base": "0x8000000"}

idapro.open_database() already accepted IDA command-line switches; nothing was
passing any. Plumbed BinaryRef -> WorkerPool -> WorkerClient -> worker argv, plus
a load_args for the single-binary path that has no project ref.

base is written the way people say it (0x8000000, int or string, any base).
IDA's -b is in PARAGRAPHS — -b1000 loads at 0x10000 — so BinaryRef.load_args
converts, and a base that isn't 16-byte aligned is refused rather than silently
landing 16x off. ida_args passes anything else through.

Two bugs found by testing the whole path rather than the happy one:

* Project.load() whitelisted path/label when normalising entries, so the load
  options were dropped the first time a project was reopened — set a processor,
  come back tomorrow, it's gone.
* Re-passing the switches to an EXISTING database makes IDA refuse the open
  (rc != 0, no functions). The .i64 already records how the image was loaded, so
  the worker skips them once a database exists. My first guard checked
  splitext(path) + ".i64" and never fired, because IDA names it "<file>.i64" —
  keeping the extension. It checks both spellings now.

Verified on a real AArch64 blob: fresh load 35 functions based at 0x8002440,
reopen 35 again, and the CLI rejects an unaligned or non-numeric --base.

tests: +6 project (options recorded, paragraph conversion, file round-trip,
add() takes them, an ELF passes nothing, hex-string base). 39/0 project, 195/0
scenarios, 30/0 project UI, 36/0 index, 27/0 pool.

1 files changed, 34 insertions, 7 deletions

diff --git a/idatui/worker.py b/idatui/worker.py
index bfefa4a..26f0816 100644
--- a/idatui/worker.py
+++ b/idatui/worker.py
@@ -78,13 +78,39 @@ def _ensure_tools_injected() -> None:
         sys.stderr.write(f"idatui: tool injection skipped: {e}\n")
 
 
-def _open_and_register(binpath: str):
+def _has_database(binpath: str) -> bool:
+    """Whether IDA already has a database for ``binpath``.
+
+    IDA names it ``<file>.i64`` (keeping the extension), but a database made
+    from ``foo.bin`` can also appear as ``foo.i64`` depending on how it was
+    created — check both, because guessing wrong here means re-passing load
+    switches to an existing database, which fails the open.
+    """
+    return (os.path.exists(binpath + ".i64")
+            or os.path.exists(os.path.splitext(binpath)[0] + ".i64"))
+
+
+def _open_and_register(binpath: str, load_args: str = ""):
     """Open the DB (main thread) then import ida-pro-mcp so every @tool registers
-    against this live database. Returns (tools_dict, module_name, save_fn)."""
+    against this live database. Returns (tools_dict, module_name, save_fn).
+
+    ``load_args`` is passed to IDA as command-line switches, which is the only
+    way to tell it how to read a headerless blob: a raw firmware image has no
+    format to detect, so without ``-p<processor>`` it loads as metapc at 0 and
+    finds nothing. Ignored once a database exists — the .i64 already records how
+    it was loaded, and re-passing conflicting switches is how you corrupt one.
+    """
     _ensure_tools_injected()  # before any ida_pro_mcp import
     import idapro
     idapro.enable_console_messages(False)
-    if idapro.open_database(binpath, run_auto_analysis=True):  # nonzero == failure
+    args = load_args or None
+    if args and _has_database(binpath):
+        # The .i64 already records how this image was loaded. Passing the
+        # switches again on reopen makes IDA fail outright (rc != 0) — the load
+        # options belong to the FIRST open only.
+        args = None
+    if idapro.open_database(binpath, run_auto_analysis=True,
+                            args=args):  # nonzero == failure
         raise RuntimeError(
             f"failed to open {binpath}: the .i64 is likely held by a running "
             f"ida-mcp worker (try: pkill -f idalib) or wedged from a crash "
@@ -109,8 +135,8 @@ def _open_and_register(binpath: str):
     return MCP_SERVER.tools.methods, module, save
 
 
-def serve(sockpath: str, binpath: str) -> None:
-    tools, module, save = _open_and_register(binpath)
+def serve(sockpath: str, binpath: str, load_args: str = "") -> None:
+    tools, module, save = _open_and_register(binpath, load_args)
     sid = uuid.uuid4().hex[:8]
 
     def dispatch(name: str, args: dict):
@@ -179,10 +205,11 @@ def serve(sockpath: str, binpath: str) -> None:
 def main(argv=None) -> None:
     argv = argv if argv is not None else sys.argv[1:]
     if len(argv) < 2:
-        sys.stderr.write("usage: python -m idatui.worker <sock> <binary>\n")
+        sys.stderr.write(
+            "usage: python -m idatui.worker <sock> <binary> [ida-load-args]\n")
         raise SystemExit(2)
     try:
-        serve(argv[0], argv[1])
+        serve(argv[0], argv[1], argv[2] if len(argv) > 2 else "")
     except SystemExit:
         raise
     except BaseException as e:  # noqa: BLE001 -- surface a clean cause + code 1