← Index

Wispr Flow 1.6.1102 — how it works on Windows

Static analysis of the installed app files, 2026-10-11. Target: C:\Users\<user>\AppData\Local\WisprFlow\app-1.6.1102\. Background: wisprflow.ai home page and wisprflow.ai/privacy. No part of the app was run.

1. Where the app is and what I inspected

Wispr Flow is not in your Desktop folder. Your Desktop (C:\Users\<user>\Desktop, plus the OneDrive Desktop) has no Wispr file or shortcut. The app is installed by Squirrel at C:\Users\<user>\AppData\Local\WisprFlow\, with three versions: app-1.4.303, app-1.4.338, app-1.6.1102. I analyzed 1.6.1102, the newest. User data is in C:\Users\<user>\AppData\Roaming\Wispr Flow\ (not opened). The project folder holds only a README.txt with this prompt and a link to the video “How To Use REA To Clone Any Software In Minutes” by Eric Tech; I did not watch the video.

How REA was used, and where it failed

Both REA MCP calls failed. analyze_javascript_application on the 133 MB ASAR sent no progress for 3,385 s and inspect_managed_artifact on the helper sent none for 3,666 s; Claude Code then stopped them on its MCP idle timeout. This is a harness limit (the MCP idle timeout), not a model error. inspect_managed_artifact was also the wrong tool: the helper has no CLR header, so it is not a managed PE.

The results below come from four sources: (1) I extracted the ASAR with a small Node script and read the bundles directly; (2) I scanned the helper's ASCII and UTF-16 strings; (3) I ran the REA CLI on the 22 extracted main-process bundles (result in section 6); (4) I ran REA with the Ghidra 12.1.4 engine on the helper and read its paste code as pseudocode (section 7).

Which REA engine did what: the JavaScript part needs no disassembler. REA reads it with its own analyzer, analyze_javascript_application. Only the helper is machine code. In the first pass, no disassembler was set up: rea doctor reported Ghidra, IDA and Hopper as missing_analysis_engine. I then installed Ghidra 12.1.4 and used it for section 7. IDA and Hopper are still not set up.

2. The pipeline, step by step

Servers named in the code

3. Proven, inferred, hidden

PROVEN from the app files

• Speech recognition does not run on your PC. All 902 ASAR entries contain no model file: 0 matches for onnx|ggml|gguf|tflite|.pt|.bin|whisper. The only "model" match is GNAudio.DeviceApis.ModelBase.dll (Jabra headset library). The website agrees: "Transcription always happens in the cloud."
• Formatting (punctuation, filler removal, style) is server side. The response has separate raw_text and formatted_text, and timings format, external_asr_time, external_llm_time. The client only sends style settings: WritingStyle (FORMAL, CASUAL, VERY_CASUAL, EXCITED, GENZ), EditingStrength (VERBATIM, LIGHT, MEDIUM, HEAVY), dictionary, replacements, snippets.
• The server can use more than one recognizer. The Origin enum lists MIXTURE, WHISPER, SCRIBE, VOXTRAL, QWEN; transcript_origin accepts internal, external, canto_1.0, canto_1.0.1, canto_1.1.
• Screen context goes to the server: text-box text before and after the cursor, selected text, accessibility words, OCR words, VS Code names, nearby text, AX HTML. The website calls this "Reads limited text from the app you're dictating into."
• The Context.screenshot field exists in the protocol, but getContext() sets it to an empty Uint8Array in this build. So 1.6.1102 does not send screenshot pixels in this field.
• Your first name, last name and email go in every Init.preferences.user.
• Local history flow.sqlite can keep axText and axHtml (the accessibility text of the target app) per dictation (migrations 20250113230038-add-axtext.js, 20250218194609-add-ax-html.js). The ax-inspect-server.mjs comment says its pages "render local Slack/email content".

INFERRED from names and structure

• "SCRIBE" may be ElevenLabs Scribe and "VOXTRAL" may be Mistral Voxtral. Only the names support this.
• "canto" is the in-house model name (the code also links https://wisprflow.ai/canto).
• The labels of the helper functions in section 7 (for example "SimulatePaste"). NativeAOT removed the function names; I named each function from the log strings inside it.
• The meaning of the window messages 0x305 and 0x306 in the helper (WM_RENDERFORMAT, WM_RENDERALLFORMATS). The numbers are in the code; the names are from my knowledge of Win32.
• The helper string rustc suggests a Rust component inside the helper. I did not confirm it.

HIDDEN (on the server or not opened)

• Which ASR models and LLMs run, how they are chosen, the prompts, and how context is used.
• What the server stores. The privacy page says audio "is deleted as soon as it's transcribed, unless you've turned on Dictation cloud storage." The code cannot prove this.
• The live values of the helper's feature flags (shift-insert, windows-key-up-simulation, disable-clipboard-restore). Ghidra shows both branches; the server sets the flags.
• The helper's keyboard-hook procedure, the UIPI check, and how it reads text through UI Automation. I did not decompile these.
• The default hotkey and the OCR engine on Windows.

4. A small version you can build

This copies the proven mechanism in its smallest form: one Python file, one hotkey, one recognizer, the clipboard, and a Ctrl+V keystroke. It skips context, streaming and verification.

# flowlite.py - hold F9, speak, release: text is pasted into the focused app.
# pip install faster-whisper sounddevice numpy keyboard pyperclip
import time, numpy as np, sounddevice as sd, keyboard, pyperclip
from faster_whisper import WhisperModel

RATE, KEY = 16000, "f9"
model = WhisperModel("base.en", device="cuda", compute_type="float16")  # ponytail: "cpu"/"int8" if no GPU

def record():
    chunks = []
    with sd.InputStream(samplerate=RATE, channels=1, dtype="float32",
                        callback=lambda d, *_: chunks.append(d.copy())):
        while keyboard.is_pressed(KEY):
            time.sleep(0.02)
    return np.concatenate(chunks)[:, 0] if chunks else np.zeros(0, np.float32)

def paste(text):
    old = pyperclip.paste()
    pyperclip.copy(text)
    keyboard.send("ctrl+v")
    time.sleep(0.15)          # ponytail: fixed delay; slow apps may paste the old clipboard
    pyperclip.copy(old)       # ponytail: text only; images/HTML on the clipboard are lost

while True:
    keyboard.wait(KEY)
    audio = record()
    if len(audio) < RATE // 4:
        continue              # under 0.25 s: ignore taps
    segs, _ = model.transcribe(audio, vad_filter=True)
    text = " ".join(s.text.strip() for s in segs).strip()
    if text:
        paste(text + " ")

Services it needs

• Local route: none. Your NVIDIA GPU with CUDA and the base.en model (~150 MB download on first run).
• Cloud route: one speech-to-text API key. Replace the model.transcribe line with an HTTP POST of the WAV.
• Optional cleanup: one LLM API key and a short prompt.

Known limits of this version

• Clipboard race: if the target app reads the clipboard after 150 ms, it pastes your old clipboard. Wispr verifies the field with UI Automation; this version does not.
• Restore keeps only text. Wispr snapshots all formats.
• No streaming: you wait for the full recording to transcribe. I did not measure latency on this machine.
• No context (no dictionary, no screen words), so names and jargon are less accurate.
• Elevated (admin) windows ignore keystrokes from a normal-level process.

Next steps, in order: (1) add a dictionary as faster-whisper initial_prompt; (2) add the LLM cleanup; (3) read the focused text box with uiautomation to verify the paste.

5. Not done

• Helper decompile: done for the paste path only (section 7). Not done for the keyboard hook, UI Automation reading, or the UIPI check.
• Renderer bundles: I scanned hub for audio code but did not run REA on the renderer windows.
• Runtime check: I did not run the app or capture its network traffic, so nothing here is observed at runtime.
• The YouTube video in README.txt: not watched.

6. REA CLI result

Command: npx -y rea-agents@6.3.0 analyze-javascript-application <22 extracted main bundles + package.json> --json. It finished with exit 0 in about 7 minutes and wrote a 505,348,651-byte Evidence file.

• Evidence ID: ev_caa9799415d6a1d4bb802cb454813ff0c86184024019966bd09b79f7a4fe718b
• Coverage: partial (graph and semantic graph). 21 JavaScript files parsed, 0 parse failures, 3,497,416 AST nodes visited, 819 findings.
• Electron summary: 11 BrowserWindow constructions, 3 utility processes (0 entrypoints resolved), 0 preload entrypoints, 0 native addon bindings resolved.
• IPC: 166 main-process handlers, 155 with literal channels, 11 with dynamic channel expressions. Renderer side: 0, because I gave REA only the main bundles.
• Semantic relations: 91,213 kept, 178,512 unknowns. Families: call-flow 4,651, data-flow 36,410, closure 44,551, event 111, timer 25, child-process 0, request 0.

Limit: the graph does not keep string values. The strings dictation:audioChunk, Wispr Flow Helper.exe and inference.wisprflow.com each have 0 matches in the Evidence file. REA also found 0 child-process and 0 request relations, but its own limitations say "Graph coverage is incomplete; unavailable facts remain explicit and must not be read as absence." So the helper launch (spawn) and the gRPC hosts in sections 2–3 come from my direct reading of the bundle text, not from REA.

7. The helper's paste code, read with Ghidra

The full account, with the reasons Ghidra did not run at the start and the consequences of this pass, is on the Ghidra pass page.

Setup. REA 6.3.0 with the Ghidra 12.1.4 engine (JDK 23.0.2) on Wispr Flow Helper.exe, 20,228,632 B, SHA-256 c58c61b106c83f7b77efc921b0e849bb7210154898504215f17306c1a6d6abe0. Ghidra found 56,803 functions and 14,969 strings (Evidence ev_63ff9ab0f8afa4dfd337adbc0aea57e776623c5a8e10cf35790ae26bea871bab). Its analysis took 1,310 s. REA's default Ghidra time limit is 330,000 ms, so the first run failed with provider_timeout. I raised REA_GHIDRA_STARTUP_TIMEOUT_MS to 10,800,000 and kept one REA session open with tools/rea_session.mjs.

Method. NativeAOT removes function names. REA's find_xrefs_to_name returned name_not_found for SendInput, SetClipboardData and SetWindowsHookExW, because the helper does not import them by name in its import table. The helper keeps its log messages as .NET string objects, and the code points at the object, which starts 12 bytes (0xC) before the characters. So I asked REA for references to string address − 12. That found the function behind each log message. Then I read each function as Ghidra pseudocode. tools/strs.py writes the string text next to each reference.

PROVEN paste rules (from pseudocode, constants and log strings)

1. Two paste paths. First the helper tries a delayed-render clipboard: it registers the text without copying it, then presses the paste keys. When the target app reads the clipboard, Windows sends the helper message 0x305. Then the helper 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. If that path fails, or the text has {{TAB}}/{{BREAK}} markers, it uses the regular path: save the clipboard, write the text, press the keys, restore.
2. Formats written. Text, and also HTML Format when htmlText is not empty.
3. Key combination. Ctrl+V is the key array 0x560011 (VK 0x11 Ctrl, VK 0x56 V). Shift+Insert is 0x2d0010 (VK 0x10 Shift, VK 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 retries a failed key-up 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, 50 ms between sections. On the regular path: 500 ms, then restore.
6. Restore delay per app (delayed path). The helper compares the start of the process name with comparison mode 5 (in .NET that is OrdinalIgnoreCase, so case does not matter; the mode name is from my knowledge of .NET):
   • 5,000 ms: vncviewer, tvnviewer, mstsc, msrdc, wfica32, vmware-view, rdcman, anydesk, teamviewer (remote-desktop apps).
   • 3,000 ms: OUTLOOK, olk, WINWORD, WhatsApp.
   • 500 ms: all other apps.
   If the app does not read the clipboard in time (3,000 ms for the two lists above, 1,000 ms for other apps), 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. The helper keeps two lists of clipboard formats. 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 logs failure cause 2. When the flag windows-key-up-simulation is on, it releases a held Alt (VK 0x12, 0xA4, 0xA5) or Windows key (VK 0x5B, 0x5C) with a "masking sequence" that uses VK 0x11 (Ctrl). If the target window runs at a higher privilege level, 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.

INFERRED

• The function labels in the table below. Each label comes from the log strings inside that function, not from a symbol.
• 0x305/0x306 = WM_RENDERFORMAT/WM_RENDERALLFORMATS, and formats 13/1 = CF_UNICODETEXT/CF_TEXT. These are standard Win32 values from my knowledge; the names are not in the binary.
• The purpose of a third list in the format setup function: 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 these lists are used.

STILL HIDDEN

• The live flag values. 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 UIPI 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.

Functions read (pseudocode in ghidra/pseudocode/)

Evidence locations

Offsets are character positions in the extracted files under scratchpad\asar_out\.webpack\.