Tutorial

Download the installer from the download page and run it. It is not yet code-signed, so SmartScreen will warn; the checksum is published beside the download, and verifying it before you run it is the correct habit for a tool that takes untrusted binaries as input.

$ certutil -hashfile klarion-1.1.0-windows-x64-setup.exe SHA256

You get three things: klarion.exe, the application; klarion-cli.exe, the same engine without the window; and a python folder holding klarion.pyd. The application needs no licence and no account. The command line, scripting and the Python module do — that line is drawn at automation, not at analysis.

Klarion is keyboard-first; the mouse is for the graph. Two keys cover most of a session — Ctrl+P to go anywhere by name, and Escape to come back — and if you forget everything else, Ctrl+Shift+P has every command in the application with its shortcut printed beside it. Every binding below is rebindable.

Analysis is dramatically better with debug information, and Klarion takes it from wherever it exists. Put a .pdb beside the binary, or a DWARF-carrying ELF or Mach-O, and names, real function boundaries, parameters, locals and source line numbers all come across. A PDB is matched on both its identifier and its age, so a stale one left from an earlier link is refused rather than applied to addresses it no longer describes.

Where you have no symbols, two things stand in. Signature databases identify statically linked library code and report the library, version and compiler each match came from, so you can judge a match rather than take it. And where you have another build that does have symbols, diff the two and carry the names across:

$ klarion-cli diff with-symbols.exe stripped.exe --apply-names --save

Functions are matched on several independent signals at once — identical bytes, a normalised hash that ignores relocation and layout, mnemonic sequences, control-flow shape — and then along the call graph. Only meaningful names port, only above a confidence bar higher than the one for merely listing a match, and never over a name you set. --show-skipped tells you what did not port and why, which is usually more interesting than the list that did.

The command line is the same engine, and every command emits JSON, so it drops into whatever you already run. The full reference covers all nineteen commands; the shape worth internalising is that stdout carries data and stderr carries everything else, so a redirect always produces a file that parses.

$ klarion-cli functions app.exe --min-size 64 --json | jq -r '.[].entry'

The other split worth internalising: some commands read the file and answer, others run the whole pipeline first. info, sections, imports and strings are instant; functions, xrefs, analyze, diff and strings --referenced-only are not.

When a command stops being enough, the same analysis is reachable from a script. Ctrl+L opens the Scripts panel in the application, and the same file runs headless:

$ klarion-cli script target.exe survey.lua

The question every triage starts with, as a script — not which APIs are imported, but which are actually reached, and from how many places:

-- Which imported functions does this binary actually call, and-- from how many places? The first thing worth knowing about-- something you were handed with no context.local counts = {}for _, mod in ipairs(klarion.importedModules()) do  for _, sym in ipairs(mod.symbols) do    local n = #klarion.xrefsTo(sym.address)    if n > 0 then      counts[#counts + 1] = { name = sym.name, module = mod.name, uses = n }    end  endend table.sort(counts, function(a, b) return a.uses > b.uses end)for i = 1, math.min(#counts, 20) do  local c = counts[i]  print(string.format("%4d  %s!%s", c.uses, c.module, c.name))end

  35  api-ms-win-core-com-l1-1-0.dll!CoTaskMemFree  26  api-ms-win-core-heap-l1-1-0.dll!GetProcessHeap  23  USER32.dll!SendMessageW  15  api-ms-win-core-synch-l1-1-0.dll!AcquireSRWLockExclusive  14  api-ms-win-crt-private-l1-1-0.dll!_o__errno  13  api-ms-win-core-libraryloader-l1-2-0.dll!GetModuleHandleW  12  api-ms-win-core-winrt-string-l1-1-0.dll!WindowsCreateStringReference  11  api-ms-win-core-errorhandling-l1-1-0.dll!GetLastError  11  api-ms-win-crt-string-l1-1-0.dll!wcsnlen  10  api-ms-win-core-handle-l1-1-0.dll!CloseHandle

Twelve lines that would have taken an afternoon of clicking, and the shape of the answer is the useful part: this is a program that frees COM allocations, talks to windows and manipulates strings.

Lua is sandboxed: its os and io libraries are never opened, so running a script against a binary you do not trust does not hand it your machine. Changes a script makes live in memory until --save writes the project.

For a notebook, a CI job or a pipeline that already exists, the relationship goes the other way: your interpreter imports Klarion. Put the installed python folder on PYTHONPATH and import klarion. It binds the same forty-three operations under the same names, with the no-argument ones spelled as properties.

# Triage a directory: which of these binaries touch the APIs# you care about, and how big is each one's real code surface?import globimport klarion WATCH = {"CreateRemoteThread", "VirtualAllocEx", "WriteProcessMemory",         "WinHttpConnect", "RegSetValueExW"} for path in sorted(glob.glob("samples/*.exe")):    with klarion.open(path) as program:        hits = sorted({            symbol.name            for module in program.imported_modules            for symbol in module.symbols            if symbol.name in WATCH        })        stats = program.statistics        print(f"{path:40} {stats.functionCount:6} functions  {', '.join(hits) or '-'}")

It is a CPython 3.13 extension for 64-bit Windows, and unlike Lua it confines nothing — it is a library in a process you already control, and klarion.isolation() says so. The scripting reference documents both languages together.

The MCP server exposes twenty-two tools over JSON-RPC on stdio, so a model can drive the engine the way you drive the window: open a binary, list functions, disassemble, decompile, chase cross-references, read RTTI, rename and comment. Three of those write to the analysis and each says so in capitals before it is called; none of them touches the binary on disk. Scripting is not registered at all unless the server was started with --allow-scripting.

The honest summary of what Klarion will and will not do for you: it recovers a great deal, it tells you which parts are evidence and which are inference, and it counts what it could not work out instead of hiding it. The three counts to keep an eye on are unresolved indirect branches, decode failures, and how many functions came from the gap scan rather than from the exception table.