The Ghidra pass on Wispr Flow's helper

What Ghidra did in this project, why it did not run at the start, what it proved, and what it changed. Wispr Flow 1.6.1102 on Windows 11. 2026-10-11. Home · Teardown section 7 · Development journey

1. Project status

• Repository: github.com/az9713/wispr-flow-rea-teardown, branch main.
• Ghidra commit: 0f18137 "Redo the helper teardown with Ghidra; apply its paste rules to flowlite". It changed 30 files: 2,872 lines added and 22 removed.
• Live pages: az9713.github.io/wispr-flow-rea-teardown. Section 7 of the teardown shows the Ghidra results.
• Contents: the teardown report, the development journey (17 sections), the index page with run steps and limits, flowlite/, ghidra/ (21 pseudocode files and evidence.tsv), and tools/.
• State: the Ghidra pass is complete. The open items are in section 10.

2. Why Ghidra did not run at the start

Wispr Flow is a Windows app, but most of it is not machine code. It is an Electron app: 133 MB of JavaScript in app.asar. Only one 20,228,632-byte file, Wispr Flow Helper.exe, is machine code. Speech capture, the server connection and transcription are all in the JavaScript. So the first pass answered most of the brief without a disassembler. Only the helper's paste rules needed one.

Ghidra did not run on the helper in the first pass for five reasons. Three are REA design rules. One is the harness, and one is my error.

Reason 1 (REA design): REA never installs Ghidra or Java

REA's own documentation states this in three places:

"REA does not install or upgrade Ghidra, Java, Python, npm, Node.js, Hopper, or a compiler." (docs/windows-ghidra-p0.md)

"Setup never installs Ghidra, Java, or Python." … "writes only after approval, and never downloads, installs, upgrades, or modifies Ghidra or Java." (docs/installation.md, Ghidra section)

"Extract Ghidra and install the JDK outside REA, then export absolute paths". (docs/installation.md)

The REA skill that I followed gives the same rule to the agent: "REA setup never installs or upgrades Node.js, npm, Homebrew, Java, Ghidra, IDA, JADX, Binwalk, or Unblob. Use existing prerequisites". The documentation does not give the reason for this rule. INFERRED Ghidra is third-party software: the download is 569,649,598 bytes, and it needs its own JDK. An install of that size changes the PC outside REA's own files.

Reason 2 (REA design): REA does not search the disk for Ghidra

REA finds Ghidra only through the environment variable GHIDRA_INSTALL_DIR. rea doctor reported missing_analysis_engine with the message GHIDRA_INSTALL_DIR is not set. But a Ghidra 12.1.4 copy was already on this PC, in the user's tools folder. A different session had put it there on 2026-10-10. REA could not see it, because the variable was not set.

Reason 3 (REA design): the other two engines were not usable here

• Hopper is the only engine that REA setup can install, and only after approval. REA's documentation says: "Hopper installation remains unavailable on Windows."
• IDA is commercial software. REA uses it only through an existing ida-pro-mcp registration. rea doctor reported IDA MCP registration is not configured.
• Ghidra on Windows is an "experimental Windows x64 P0" boundary. It is read-only: 25 inventory and analysis operations, and no renames or comments in the Ghidra database.

Reason 4 (harness): the MCP calls stopped on a timeout

In the first pass, the REA MCP calls ran for a long time with no progress, and Claude Code stopped them on its MCP idle timeout:

• analyze_javascript_application on the 133 MB ASAR: no progress for 3,385 s.
• inspect_managed_artifact on the helper: no progress for 3,666 s.

This is a limit of the harness (Claude Code), not of the model or of REA. Even with a configured Ghidra, a long Ghidra run through Claude Code's MCP connection would have met the same limit. The second pass did not use Claude Code's MCP connection for this reason (see section 4).

Reason 5 (my error): I used the wrong tool and did not check the engines

• The REA skill routes a ".NET NativeAOT PE/ELF" file to "native Ghidra analysis". I first sent the helper to inspect_managed_artifact, which reads managed .NET files. The helper has no CLR header (the header directory is 0 0), so that tool did not apply.
• I did not run rea doctor to check the engines in the first pass.
• My first report gave the timeouts as the reason the helper was not decompiled. That was incomplete. The missing engine was the real blocker. The teardown and the journey now say this.
• The rule from the skill, "use existing prerequisites", meant that an install of Ghidra needed your request. You asked for it in the second pass ("do all these steps and use Ghidra to redo the teardown and rebuild the app").

Rule learned: "Check that the engine exists before you blame the timeout."

3. The role of Ghidra

What Ghidra did

• Engine behind REA. REA started Ghidra in headless mode (no window) and sent it requests. REA set REA_ANALYSIS_PROVIDER=ghidra. REA gave each result an Evidence ID.
• Disassembly and analysis. Ghidra turned the 20 MB helper into 56,803 functions and found 14,969 strings. Evidence: ev_63ff9ab0f8afa4dfd337adbc0aea57e776623c5a8e10cf35790ae26bea871bab.
• Cross-references. Ghidra listed which code uses which address. This was how I found the paste code (see section 5).
• Pseudocode. Ghidra's decompiler turned 21 functions into readable C-like code. This is a reconstruction of the machine code, not the original source.

What Ghidra did not do

• No function names. NativeAOT removes the .NET names. Ghidra calls each function FUN_ plus its address. I gave the names, such as "SimulatePaste", from the log messages inside each function.
• No saved names in Ghidra. Windows Ghidra in REA is read-only, so my names are only in the files in ghidra/.
• No NativeAOT type recovery. REA has an optional adapter for this (ghidra-nativeaot). Its documentation lists only targets "analyzed on Linux x64", .NET runtime 8.0.22, and a JAR that you build yourself. I did not use it.
• No runtime observation. Ghidra reads the file. It does not run the helper. So it cannot show which branch runs on your PC.
• No work on the JavaScript. Speech capture, the gRPC stream and transcription stay as REA's JavaScript analyzer found them.

4. Setup and run

1. Java. JDK 23.0.2 was already installed at C:\Program Files\Java\jdk-23, with javac. Ghidra 12.1 needs JDK 21 or newer.
2. Download. ghidra_12.1.4_PUBLIC_20260921.zip, 569,649,598 bytes. Its SHA-256 matched the release note: ddac49f903da9d5bac833e5cc79395098b9c33cfd3279be5f31bd00387d2d4db.
3. Unzip. I used C:\Windows\System32\tar.exe. It printed many Can't unlink already-existing object: Permission denied lines. The folder already held the copy from 2026-10-10, and a Ghidra process from that session still held its files open. I compared the folder with the zip: 5,219 files, 0 missing, 0 size differences. I did not stop that process, because I had not started it.
4. Environment. I set GHIDRA_INSTALL_DIR as a permanent user variable. Claude Code's REA MCP server had started before that, so it still cannot see Ghidra. A restart of Claude Code fixes this.
5. First run failed. rea analyze ... --provider ghidra stopped after 340 s with "code": "provider_timeout", "operation": "list_documents", "timeout_ms": 330000. REA's default startup limit is 330,000 ms (5.5 minutes).
6. Time limit raised. REA's documentation names the fix, REA_GHIDRA_STARTUP_TIMEOUT_MS. I set it to 10,800,000 ms (3 hours).
7. One session for all queries. Each REA CLI command imports and analyzes the file again, because REA's Ghidra project is temporary. So I wrote tools/rea_session.mjs. It starts rea --mcp as a child process, keeps one Ghidra session open, and runs requests from a folder queue. It does not go through Claude Code's MCP connection, so the idle timeout does not apply.
8. Analysis time. open_binary returned in 0.2 s. The first deep request, binary_overview, waited for Ghidra's analysis. Ghidra's log said Total Time 1310 secs, then Analysis succeeded. 1,310 s is about 22 minutes, about 4 times REA's default limit.
9. Close. I closed the session with close_binary and saved a snapshot of the results: 796,889 bytes, 79 Evidence records. I stopped my driver by its task ID. Its REA server and Ghidra process ended.

Other errors on the way, with their fixes:

• SyntaxError: Bad escaped character in JSON at position 41: printf had changed the backslashes in a Windows path in a queue file. Fix: write queue files from Node, and skip a bad file instead of a crash.
• UnicodeEncodeError: 'charmap' codec can't encode character '\u9810' in tools/strs.py, when a pointer was not a real string. Fix: keep only ASCII text.

5. Method: finding code without names

1. The usual method is to search for the Windows functions that paste: SendInput, SetClipboardData, SetWindowsHookExW. REA's find_xrefs_to_name returned name_not_found for all three. The helper does not import them by name in its import table.
2. The helper writes log messages, such as "Pasted successfully using delayed clipboard manager". Ghidra found these as strings. But a search for code that uses the string's address returned an empty list ([]).
3. The reason: in NativeAOT, a string is a .NET object. The object has an 8-byte type pointer and a 4-byte length, then the characters. The code points at the start of the object, which is 12 bytes (0xC) before the characters.
4. So I asked REA for references to string address − 12. That found the function behind each log message. Example: the reference at 0x1403256d8 for "Pasted successfully using delayed clipboard manager".
5. I read each function as pseudocode and followed its calls to the next function.
6. tools/strs.py writes the string text next to each PTR_DAT_ reference in the pseudocode, so the files can be read without Ghidra.

Rule learned: "A NativeAOT string reference points 12 bytes before the text."

6. What Ghidra proved

PROVEN These rules come from the pseudocode, its constants and its log strings.

1. Two paste paths.
   • Delayed-render path (first try). The helper registers the text on the clipboard without copying it, then presses the paste keys. When the target app reads the clipboard, Windows sends the helper message 0x305. The helper then supplies the text as format 13, format 1 or the HTML format, and logs "Clipboard read detected! Rendering delayed data...". This is how the helper knows that the paste reached the app.
   • Regular path (fallback). The helper uses it if the delayed-render path fails, or if the text has {{TAB}} or {{BREAK}} markers. It saves the clipboard, writes the text, presses the keys, then restores the clipboard.
2. Formats written. Text, and also HTML Format when htmlText is not empty.
3. Paste keys. Ctrl+V is the key array 0x560011 (key code 0x11 Ctrl, 0x56 V). Shift+Insert is 0x2d0010 (0x10 Shift, 0x2D Insert). The helper uses Shift+Insert only when the flag shift-insert is on and the focused process is Cursor, Windsurf or Code. Otherwise it uses Ctrl+V.
4. Key timing. It sends all key-downs in one SendInput call, waits 50 ms (Sleep(0x32)), then sends all key-ups. It tries a failed key-up again once.
5. Waits. 50 ms after the keys ("Pasted text in window, now sleeping for 50 ms for paste to complete"). In marked text: 150 ms before a Tab key, and 50 ms between sections. On the regular path: 500 ms, then the restore.
6. Restore delay for each app (delayed-render path). The helper compares the start of the process name, upper and lower case equal (comparison mode 5):

   Apps (process name starts with)	Restore delay	Time limit for the app to read the clipboard
   vncviewer, tvnviewer, mstsc, msrdc, wfica32, vmware-view, rdcman, anydesk, teamviewer (remote-desktop apps)	5,000 ms	3,000 ms
   OUTLOOK, olk, WINWORD, WhatsApp	3,000 ms	3,000 ms
   All other apps	500 ms	1,000 ms

   If the app does not read the clipboard in that time, the helper logs "Clipboard not read within timeout -- paste likely failed" and reports a failure.
7. No restore when the clipboard changed after the paste ("Clipboard changed since paste, skipping restoration"), or when the flag disable-clipboard-restore is on.
8. What is saved and restored. FormatsToRestore: Text, UnicodeText, HTML Format, the bitmap and image formats, and the Windows clipboard-history markers (CanIncludeInClipboardHistory, CanUploadToCloudClipboard, ExcludeClipboardContentFromMonitorProcessing, Clipboard Viewer Ignore). FormatsToIgnore: FileDrop, Rich Text Format, Portable Document Format, WaveAudio, Csv and others. Any other format is logged as "Found unknown clipboard format".
9. Safety checks.
   • If a modifier key is held, the helper reports failure cause 2.
   • When the flag windows-key-up-simulation is on, it releases a held Alt (key codes 0x12, 0xA4, 0xA5) or Windows key (0x5B, 0x5C) with a "masking sequence" that uses Ctrl (0x11).
   • If the target window runs at a higher privilege level (for example, as administrator), the paste fails with cause 4, UIPI_RESTRICTIONS.
   • If the keys were already sent, it does not paste again on the regular path, so the text cannot appear twice.
10. Threading. The regular path runs on an STA thread. If the caller is not on one, the helper starts a new STA thread and waits for it.

7. Inferred and still hidden

INFERRED

• The function names in section 11. Each name comes from the log strings inside that function, not from a symbol.
• The Windows names of the numbers: 0x305/0x306 = WM_RENDERFORMAT/WM_RENDERALLFORMATS, and formats 13/1 = CF_UNICODETEXT/CF_TEXT. The numbers are in the code. The names come from my knowledge of Win32, not from the binary.
• Comparison mode 5 = OrdinalIgnoreCase (.NET knowledge, not in the binary).
• The purpose of a third list in the format setup function. It names the apps Cursor, slack, GitHubDesktop, Discord, Spotify, chrome, brave, Arc, msedge, Opera, MozillaFirefox, Notepad, Windsurf, and the sites chatgpt.com, github.com, google.com, claude.ai, gemini.google.com, replit.com, v0.dev. I did not trace where the helper uses these lists.

STILL HIDDEN

• The live values of the flags shift-insert, disable-clipboard-restore and windows-key-up-simulation. The code has both branches. The server sends the flags.
• The keyboard-hook procedure. Only "Failed to create keyboard hook" and MultiKeybindService were found. Not decompiled.
• The privilege check FUN_140322010, the HTML conversion FUN_1403274e0, and the UI Automation text reading. Not decompiled.
• Second references to the clipboard-history markers, at 0x140329848 and 0x140329884. Not read.

8. Consequences of the Ghidra pass

8.1 On the findings

In the same pass, I checked the teardown again and fixed two errors. Ghidra did not find these; a new count and a new read of the bundles found them:

• The number of database migrations is 169. The report said "~190".
• The report named the gRPC library as @grpc/grpc-js. It now says "a grpc-node client (library not named…)", because the bundle does not name the library.

8.2 On flowlite

One difference: Wispr uses Shift+Insert only when its shift-insert flag is on. flowlite has no flags, so it always uses Shift+Insert in those three editors.

Not copied, to keep flowlite small: the delayed-render clipboard, the HTML Format copy, the snapshot of every clipboard format, and the {{TAB}} and {{BREAK}} markers. So flowlite cannot know if a paste reached the app, and it restores only clipboard text. An image on the clipboard is lost.

8.3 Costs

• Download: 569,649,598 bytes.
• Analysis time: 1,310 s (about 22 minutes) before the first answer. Later requests used the open session, so they did not wait for a new analysis.
• Extra code: tools/rea_session.mjs (60 lines) to work around the 330,000 ms default and the per-command import; tools/strs.py (21 lines) to show string text in the pseudocode.
• Two rejected tool calls and one question from you before the run started ("why doesn't Ghidra look into the binary"), then "Go".

8.4 Changes on this PC

• A permanent user environment variable, GHIDRA_INSTALL_DIR, points to the Ghidra 12.1.4 folder.
• The Ghidra folder holds the same 5,219 files as the zip.
• Claude Code's REA MCP tools still cannot see Ghidra until you restart Claude Code.
• The Ghidra process from 2026-10-10 still runs. I did not start it, so I did not stop it.

8.5 Changes in the repository

• New: ghidra/pseudocode/ (21 files), ghidra/evidence.tsv, tools/rea_session.mjs, tools/strs.py, and this page.
• Changed: flowlite/flowlite.py (77 lines), flowlite/receipts/flowlite_injected.log, flowlite/receipts/target.png (cropped to 656 × 189 px), wispr-flow-teardown.html (new section 7), DEVELOPMENT-JOURNEY.html (new section 17), index.html.
• No secret values from Wispr's files are in the pseudocode or on these pages.

9. The flowlite rebuild and its tests

flowlite is a Python script, so it has no build step. "Rebuilt" means that I changed flowlite/flowlite.py and ran the tests again, in the same commit, 0f18137.

New parts of the code:

• foreground_process() reads the name of the focused app through Windows calls (GetForegroundWindow, GetWindowThreadProcessId, OpenProcess, QueryFullProcessImageNameW).
• SHIFT_INSERT_APPS = {"code", "cursor", "windsurf"} and pick_keys() choose the paste keys.
• SLOW_RESTORE and restore_delay() choose the restore delay from the start of the process name.
• selftest() holds the checks for these rules.

Test results:

10. Open items

• Not decompiled: the keyboard hook, the privilege check FUN_140322010, the HTML conversion FUN_1403274e0, and the UI Automation text reading.
• Not known: the live flag values. Only a runtime capture of the server's flags could show them.
• Not tested: flowlite with a live voice, and the Shift+Insert branch in a real editor.
• Claude Code: restart it so that the REA MCP tools see Ghidra.
• Old Ghidra process from 2026-10-10: still running; it is yours to stop.
• Receipt file: flowlite/receipts/driver.py still contains the name of the test PC's audio device.
• Other engines: IDA and Hopper are still not set up. Hopper cannot be installed on Windows through REA.

11. The 21 functions

Each name is INFERRED from the log strings in the function. Each link opens the pseudocode file on GitHub.

12. Where each fact is recorded

Sources for section 2: REA 6.3.0 repository documents docs/installation.md, docs/windows-ghidra-p0.md and docs/ghidra-nativeaot.md, and the REA skill reverse-engineer-anything.