> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kong.fyi/llms.txt
> Use this file to discover all available pages before exploring further.

# Interpreting Kong Output

> How to read and understand Kong's analysis results

## Reading analysis.json

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

### `binary` — metadata

```json theme={null}
{
  "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

```json theme={null}
{
  "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](/concepts/signature-matching) without LLM analysis
* **skipped** — functions too small (trivial/thunk) to analyze

### `functions` — per-function results

Each function in the array includes:

```json theme={null}
{
  "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.                          |

<Note>
  These thresholds are provisional and may be recalibrated in future versions.
</Note>

## 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](/concepts/pipeline-overview), 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](/usage/output-formats) 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](/concepts/deobfuscation), 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](/concepts/type-recovery)

## Further reading

* [Output Formats](/usage/output-formats) — details on source, JSON, and Ghidra formats
* [XZ Backdoor](/case-studies/xz-backdoor) — see these concepts in a real analysis
* [Evaluating Results](/usage/evaluating-results) — score output against ground truth
