| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The idalib worker is now the sole backend for opening a binary, so remove the
ida-pro-mcp code paths from the hot path:
* app.py: IdaTui.__init__ drops url/db/ensure_server/backend (now just
open_path/keepalive/rpc_path/ttl); _connect calls _open_worker_client directly;
_open_mcp_client deleted; _reconnect respawns the worker only; self.client and
_after_reconnect typed WorkerClient. No more IDAClient import.
* launch.py: rewritten worker-only -- validate the binary, sweep stale locks,
spawn the TUI (which starts the private worker behind its overlay). The whole
supervisor dance (_ensure_server/_start_supervisor/_open_binary/
_existing_session) is gone; `ida-tui foo.elf` is the one usage.
* tests/test_scenarios.py: pilot is worker-only (run(binary); binary via
positional/--worker/--binary, defaults to targets/echo).
Verified: app + launch + pilot import and construct; pilot lists 31 scenarios.
The mcp modules (client.py/pane.py/tui.py/spawn.sh) still exist as dead code and
are deleted in the next commit. Worker pilot (134/2-known-flakes) still the gate.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Opening a binary now defaults to our own idalib worker; the ida-pro-mcp HTTP
supervisor path is deprecated (kept only for --db/attach and --backend mcp).
* launch.py: --backend default resolves to worker for a fresh binary open, mcp
for the attach modes (--db / bare `ida-tui`, which have no worker equivalent);
explicit --backend or IDATUI_BACKEND still wins. Logs a deprecation notice when
the mcp path is used.
* Deprecation markers on client.py and server/patch_server.py; the ida-tui shell
header and README now describe the worker as primary and note
$IDATUI_WORKER_PYTHON. TODO tracks the removal checklist.
No code deleted yet — the mcp fallback stays until the worker is proven on a box
where idalib can spawn (pilot against --backend worker is the gate). Backend
resolution matrix verified: `ida-tui bash`->worker, bare/`--db`->mcp, explicit
flag/env honored.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
step 3)
Wires WorkerClient into the app as a selectable backend, so you can launch:
ida-tui --backend worker /path/to/binary # or IDATUI_BACKEND=worker
* IdaTui gains a `backend` param. _connect is refactored into _open_mcp_client()
(the existing ida-pro-mcp path, unchanged) and _open_worker_client() (spawns a
private idalib worker via WorkerClient that opens+analyzes THIS binary and
streams progress into the loading overlay). The common tail (health, keepalive,
Program, load_functions) is shared, so domain.py and every view are untouched.
* _reconnect branches the same way: a dropped worker (segfault → closed socket)
respawns a fresh WorkerClient — the connection-loss recovery already built
works verbatim for the worker.
* launch.py adds --backend (env IDATUI_BACKEND); the worker path skips all the
supervisor/server plumbing (it owns a private worker) and just sweeps stale
locks + requires a binary. keepalive is a no-op for the worker (it never idles
out). mcp remains the default — nothing changes unless you opt in.
Verified without idalib: all four files parse; --backend is in --help; IdaTui
constructs for both backends with both openers present; WorkerClient covers the
full client surface. The idalib E2E (experiments/worker_smoke.py, and actually
launching --backend worker) still can't run in this sandbox — it now reaps every
idalib spawn before a byte is written — but the mcp default is untouched and the
worker path reuses proven pieces (the unix protocol benched at ~50us/call; the
worker dispatches the same tool functions the HTTP path does).
To validate on a real box: ida-tui --backend worker targets/echo (or run
experiments/worker_smoke.py for the headless read-path check).
|
| |
|
|
|
|
|
|
| |
The "auto-analyzing…" note crammed the "first open of a big binary can take a
while" caveat onto one line that overflowed the fixed-width splash box (it showed
truncated as "…first open of a big binary can"). Move the caveat to the splash's
static help line, keep the dynamic note short, and (in app.py, already committed)
widen the box to 72 and let the note/help wrap (height: auto) as a safety net.
|
| |
|
|
|
|
|
|
|
|
|
| |
The supervisor opens + auto-analyzes its seed binary BEFORE it binds the port
(idalib_supervisor.main), so the whole "starting analysis server" wait is really
IDA running initial auto-analysis. Relabel the overlay notes to say so:
"starting IDA — initial auto-analysis of <bin>…" then
"auto-analyzing <bin>… (Ns) first open of a big binary can take a while".
Message-only change in _ensure_server (with the progress callback); no behavior
change. Verified the emitted notes with a mocked server-up poll.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The remaining "long wait with no feedback" was the launcher's _ensure_server: it
started the supervisor and blocked ~10s polling for the port BEFORE the TUI (and
its overlay) existed. Only a one-line stderr message covered it.
Move that wait behind the overlay. The launcher now only does instant checks
(sweep stale locks if the server is down, honor --no-server) and hands the binary
straight to the TUI with ensure_server=True. The TUI's _connect starts the
server itself and narrates it in the loading overlay ("starting analysis
server… (Ns)") before opening/analyzing the binary. idb_open is idempotent, so an
already-open session is still adopted instantly (the launcher no longer needs to
probe sessions).
_ensure_server gained a progress callback so it reports to the overlay instead of
stderr (which would corrupt the TUI screen).
Verified with the server DOWN: chrome + overlay appear within ~0.5s, notes go
"starting analysis server… (0s)" -> "opening echo — analyzing…" ->
"echo — 128 functions…" -> land on main. Pilot suite (db/ensure_server=False path)
green: startup/palette/view_toggle/disasm_nav/search/rename/follow_xrefs/
decomp_nav/mouse/listing_view/continuous_view/func_banners.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A binary whose worker was hard-killed mid-analysis leaves unpacked .id0/.id1/
.id2/.nam/.til files (no .i64). The supervisor is seeded with the target and
opens it on startup, so a wedged DB there crash-loops the whole supervisor
("Failed to open initial binary: Remote end closed connection") and the launcher
reports "supervisor exited during startup" -- before the TUI's own open-time
recovery can ever run.
When the launcher is about to start a fresh supervisor (server is down, so
nothing can hold the DB), proactively sweep the target's stale unpacked lock
files first (never the packed .i64). Safe because no server == no live session.
Verified: after clearing bash's stale locks the supervisor starts and stays up
20/20 checks over 20s with no crash loop and a clean log.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two parts:
1) A LoadingScreen modal is pushed on mount and dismissed once we land on a
function (or the symbol picker). Its note line mirrors _status, so you see
"opening… analyzing", then "N functions…", instead of staring at empty panes.
Esc hides it if you'd rather watch the status bar.
2) The real fix for the dead air BEFORE the TUI drew anything: the launcher used
to block on idb_open (full analysis of a big binary) *before* starting the
TUI, so the overlay only flashed after the wait was already over. Now the
launcher only adopts an already-open session (instant); otherwise it defers
the open to the TUI via open_path, and _connect does idb_open (with the
crashed-worker lock-sweep + retry moved here) while the chrome + overlay are
on screen. Added a ttl arg to IdaTui for the deferred open.
Verified: overlay pushed on mount, present through open+function-load, dismissed
on landing; TUI-driven open (open_path, db=None) opens echo and lands on main
with notes "opening echo — analyzing…" -> "echo — 128 functions…"; startup/
palette/view_toggle/disasm_nav/search/rename/follow_xrefs/decomp_nav/mouse/
listing_view/continuous_view/func_banners green.
|
|
|
A caveman entry point so you don't hand-craft the plumbing every time. It:
* ensures the ida-pro-mcp supervisor is up — starts spawn.sh detached
(start_new_session, tmux-free) and waits for the port if it's down;
* recovers a binary wedged by a hard-killed worker — sweeps the stale
unpacked .id0/.id1/.id2/.nam/.til next to the .i64 and retries (the packed
.i64 is never touched);
* adopts an already-open session for the same binary (idempotent), else
idb_opens it with a sane idle-TTL;
* launches the TUI attached to that session with keepalive on.
./ida-tui /path/to/binary # open a binary and drive it
./ida-tui # attach to the sole session
./ida-tui --db <id> # attach to a specific session
Pieces: idatui/launch.py (logic, reuses pane.py's server probe), a repo-root
`ida-tui` sh wrapper (resolves ~/ida-venv python, keeps idatui importable from
any cwd), and an `ida-tui` console-script in pyproject. --help works without
textual (app imported late). README documents both the one-liner and the
manual recovery. gitignore bin/ (binary targets, like targets/).
Verified live: ensure_server up-detection, open, adopt (same session id), and
lock-sweep all work against a running supervisor.
|
