Interpreting Kong Output

Reading analysis.json

Kong’s JSON output has three top-level sections:

`binary` — metadata

{
  "name": "libc.so.6",
  "path": "/lib64/libc.so.6",
  "arch": "x86-64",
  "format": "ELF",
  "endianness": "little",
  "word_size": 8,
  "compiler": "GCC"
}

This comes from Ghidra’s analysis and tells you what you’re looking at.

`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
}

Key fields:

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

These determine which functions enter the analysis queue. The size classification appears in 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

Case Studies

Interpreting Kong Output

Reading analysis.json

`binary` — metadata

`stats` — aggregate results

`functions` — per-function results

Confidence tiers

Classification categories

LLM-assigned classifications

Triage size classifications

Source export

Obfuscation indicators

Variable renames and struct proposals

Further reading

​Reading analysis.json

​binary — metadata

​stats — aggregate results

​functions — per-function results

​Confidence tiers

​Classification categories

​LLM-assigned classifications

​Triage size classifications

​Source export

​Obfuscation indicators

​Variable renames and struct proposals

​Further reading

Reading analysis.json

`binary` — metadata

`stats` — aggregate results

`functions` — per-function results

Confidence tiers

Classification categories

LLM-assigned classifications

Triage size classifications

Source export

Obfuscation indicators

Variable renames and struct proposals

Further reading