Reading analysis.json
Kong’s JSON output has three top-level sections:
{
"name": "libc.so.6",
"path": "/lib64/libc.so.6",
"arch": "x86-64",
"format": "ELF",
"endianness": "little",
"word_size": 8,
"compiler": "GCC"
}
stats — aggregate results
{
"total_functions": 2842,
"analyzed": 2314,
"named": 2314,
"renamed": 1847,
"confirmed": 467,
"signature_matches": 156,
"high_confidence": 2100,
"medium_confidence": 180,
"low_confidence": 34,
"skipped": 528,
"errors": 0,
"llm_calls": 2314,
"duration_seconds": 2823.2,
"cost_usd": 123.45
}
- renamed — functions where Kong chose a new name (the interesting ones)
- confirmed — functions where Kong agreed the existing name was already correct
- signature_matches — functions identified by signature matching without LLM analysis
- skipped — functions too small (trivial/thunk) to analyze
functions — per-function results
Each function in the array includes:
{
"address": "0x00401a30",
"original_name": "FUN_00401a30",
"name": "parse_http_header",
"signature": "void parse_http_header(char *header, int max_size)",
"confidence": 92,
"classification": "networking",
"comments": "Parses an HTTP request header into components",
"reasoning": "String references to HTTP methods and standard header fields...",
"obfuscation_techniques": [],
"deobfuscation_tool_calls": 0
}
Confidence tiers
Kong reports confidence as a percentage (0-100) per function, then aggregates into three tiers:
| Tier | Range | Meaning |
|---|
| High | 80%+ | Kong is confident in the name and type. Usually means it recognized a clear pattern, algorithm, or strong string/API evidence. |
| Medium | 50-79% | Reasonable inference but multiple interpretations possible. The name captures the general purpose but may not be precise. |
| Low | Under 50% | Educated guess. Limited evidence — the function may be too generic or too small for confident naming. |
These thresholds are provisional and may be recalibrated in future versions.
Classification categories
LLM-assigned classifications
During analysis, the LLM classifies each function by purpose:
| Category | Description |
|---|
crypto | Cryptographic operations (AES, SHA, RSA, etc.) |
networking | Network protocols (TCP, HTTP, DNS, etc.) |
io | File I/O, device I/O, stream operations |
memory | Allocation, deallocation, copying |
string | String manipulation, parsing, encoding |
math | Mathematical operations, sorting, searching |
init | Initialization, setup, configuration |
cleanup | Deinitialization, teardown, resource release |
handler | Signal handlers, callbacks, event handlers |
parser | Parsing, deserialization, format decoding |
utility | General utility functions |
unknown | Function purpose unclear |
Triage size classifications
Separately, during triage, functions are classified by size:
| Classification | Description |
|---|
imported | External library functions (linked dynamically) — skipped |
thunk | Single-instruction wrappers — skipped |
trivial | ≤16 bytes — usually skipped |
small | ≤64 bytes |
medium | ≤256 bytes |
large | >256 bytes |
kong info output; the LLM classification appears in the analysis results.
Source export
The source format groups functions by classification and annotates each with a JSDoc-style comment including name, description, confidence, classification, and address. This is designed to be readable as a standalone document — you can skim the annotated source to understand the binary’s functionality without loading it in Ghidra.
Obfuscation indicators
If a function was deobfuscated, the obfuscation_techniques field lists what was detected (e.g., ["cff", "bogus_cf"]), and deobfuscation_tool_calls shows how many tool invocations the LLM used during the agentic deobfuscation loop.
Variable renames and struct proposals
In the full analysis output, each function may also include:
- variables — a list of renamed local variables (
local_10 → buffer, param_1 → request)
- struct_proposals — proposed struct definitions inferred from pointer access patterns, which feed into type recovery
Further reading
