Decompiler

Bundled with Unleash skills pack. Source: C:\Users\Admin.agents\skills\decompiler\SKILL.md

Trigger Intents

Use this skill when user asks for:

• "decompile this function"
• pseudocode understanding or AST-level analysis
• local variable semantics in decompiled form
• decompiler-centric pattern mining (returns/calls/conditions)

Route to:

• annotations for persistent comments/renames after interpretation
• types for struct/enum/type construction and application
• disassembly when decompiler is unavailable or insufficient

Do This First (Warm-Start Sequence)

-- 1) Capability/profile probe
SELECT * FROM pragma_table_list WHERE name IN ('pseudocode', 'ctree', 'ctree_lvars');

-- 2) Pick one concrete function target
SELECT name, printf('0x%X', addr) AS addr, size
FROM funcs
ORDER BY size DESC
LIMIT 10;

-- 3) View decompiled text via primary read surface
SELECT decompile(0x401000);

Interpretation guidance:

• decompile(addr) is primary display surface.
• pseudocode/ctree* are structured query/edit surfaces.

Global Constraint Reminder (Critical)

Always constrain decompiler tables by function:

WHERE func_addr = 0x...

Without this, decompiler tables may decompile every function and become extremely slow.

Failure and Recovery

• No Hex-Rays/decompiler tables unavailable:
  • Fall back to disassembly + xrefs workflows.
• Empty/partial rows:
  • Confirm target func_addr exists and refresh decompile cache (decompile(addr, 1) where supported).
• Mutation did not appear:
  • Run mandatory mutation loop (read -> edit -> refresh -> verify).

Handoff Patterns

1. decompiler -> types for local type seeding and richer declarations.
2. decompiler -> annotations for persistent narrative and naming.
3. decompiler -> disassembly for opcode-level validation.

Decompiler Tables (Hex-Rays Required)

CRITICAL: Always filter by func_addr. Without constraint, these tables will decompile EVERY function - extremely slow!

pseudocode

The pseudocode table is a structured line-by-line pseudocode with writable comments. Use decompile(addr) to view pseudocode; use this table only for surgical edits (comments) or structured queries.

Filter behavior:

• WHERE func_addr = X: best performance; iterates pseudocode for one function only.
• WHERE addr = X: decompiles only the containing function and returns matching lines for that EA.
• WHERE line_num = N: scans functions and returns rows at that line index; use only when you need cross-function line alignment.

Comment placements: semi (after ;), block1 (own line above), block2, curly1, curly2, brace1, brace2, colon, case, else, do, asm, try. An unrecognized placement string is silently coerced to semi.

-- VIEWING: Use decompile() function, NOT the pseudocode table
SELECT decompile(0x401000);

-- COMMENTING: Use pseudocode table to add/edit/delete comments
UPDATE pseudocode SET comment_placement = 'semi',
                      comment = 'buffer overflow here'
WHERE func_addr = 0x401000 AND addr = 0x401020;

-- Add block comment (appears on own line above the statement)
UPDATE pseudocode SET comment_placement = 'block1', comment = 'vulnerable call'
WHERE func_addr = 0x401000 AND addr = 0x401020;

-- Delete comments at a resolved unique anchor
UPDATE pseudocode SET comment = NULL
WHERE func_addr = 0x401000 AND addr = 0x401020;

True function comments are not part of pseudocode:

• use UPDATE funcs SET comment = ... WHERE addr = ... for the regular function comment
• use UPDATE funcs SET rpt_comment = ... WHERE addr = ... for the repeatable function comment

pseudocode_orphan_comments

Persisted Hex-Rays comments that no longer attach to the current decompiled output of a live function. Use it to inspect or delete stale comments.

Rules:

• UPDATE ... SET orphan_comment = NULL or '' deletes that orphan comment.
• Any non-empty write is rejected.

pseudocode_v_orphan_comment_groups

Grouped, read-only orphan triage surface. One row per function with orphan comments.

Columns: func_addr, func_name, orphan_count, orphan_comments_json

Comment Anchor Resolution (Critical)

Use this recipe before writing heading-style decompiler notes.

Rules:

• Do not assume addr == func_addr.
• The first displayed pseudocode row often has addr = 0 and is not the right write target.
• One addr can map to multiple rows ({, statement, }); prefer a unique non-brace anchor.
• For true function comments, update funcs.comment / funcs.rpt_comment instead of pseudocode.

-- Resolve the first attachable non-brace row near function start
SELECT line_num, addr, line
FROM pseudocode
WHERE func_addr = 0x401000
  AND addr != 0
  AND TRIM(line) NOT IN ('{', '}')
  AND addr IN (
    SELECT addr
    FROM pseudocode
    WHERE func_addr = 0x401000 AND addr != 0
    GROUP BY addr
    HAVING COUNT(*) = 1
  )
ORDER BY line_num
LIMIT 1;

-- Write a heading-style summary using the resolved addr
UPDATE pseudocode
SET comment_placement = 'block1',
    comment = 'One-paragraph summary of the function.'
WHERE func_addr = 0x401000
  AND addr = (
    SELECT addr
    FROM pseudocode
    WHERE func_addr = 0x401000
      AND addr != 0
      AND TRIM(line) NOT IN ('{', '}')
      AND addr IN (
        SELECT addr
        FROM pseudocode
        WHERE func_addr = 0x401000 AND addr != 0
        GROUP BY addr
        HAVING COUNT(*) = 1
      )
    ORDER BY line_num
    LIMIT 1
  );

ctree

Full Abstract Syntax Tree of decompiled code.

ctree_lvars

Local variables from decompilation.

Mutation guidance:

• Prefer idx-based updates for deterministic writes.
• type accepts scalars, pointers, and array types — e.g. SET type = 'WCHAR[6]' or '_BYTE[392]' for wide stack strings / fixed buffers (the type must fit the local's stack slot).
• comment updates map to Hex-Rays local-variable comments (lv.cmt) and appear in decompile(...) output.

ctree_labels

Decompiler control-flow labels. Supports UPDATE (name) and mirrors label facilities on cfunc_t.

ctree_call_args

Flattened call arguments for easy querying.

Decompiler Views

Pre-built views for common patterns (always filter by func_addr):

Type Tables and Views

For types, types_members, types_enum_values, types_func_args schemas, type views, and type CRUD examples, see types skill.

SQL Functions — Decompilation

When to use decompile() vs pseudocode table:

• Read/show pseudocode -> always start with SELECT decompile(addr). Returns full function as one text block with per-line prefixes.
• Local declaration hints -> declaration lines include compact local-variable index hints ([lv:N]) so rename operations can target UPDATE ctree_lvars ... WHERE func_addr = ... AND idx = N safely.
• Need fresh output after edits -> use SELECT decompile(addr, 1) to force re-decompilation.
• Need structured line access or comment CRUD -> query/update the pseudocode table.

Targeting guidance:

• Use *_addr_arg helpers for repeated callees and call-site arguments.
• Use ctree_item_at(..., op_name, nth) plus *_addr_expr helpers for non-call expressions and assignment-side struct/union population stores.

SQL Functions — Modification

For applied_types, parse_decls(), and name writes via names/funcs, see types skill.

Preferred SQL write surface for function metadata:

• UPDATE funcs SET name = '...', prototype = '...', comment = '...', rpt_comment = '...' WHERE addr = ...
• prototype maps to applied_types behavior and invalidates decompiler cache.
• comment / rpt_comment map to get_func_cmt() / set_func_cmt().

Performance Rules

Critical rules:

• ALL decompiler tables require func_addr constraint. Without it, every function is decompiled.
• Generator tables (ctree, ctree_call_args) stream rows lazily and stop at LIMIT.
• Decompiler views (ctree_v_calls, ctree_v_indirect_calls, ctree_v_loops, etc.) inherit the func_addr constraint -- always filter.
• Hex-Rays cfunc cache: decompile(addr) is internally cached. decompile(addr, 1) forces a full re-decompilation -- only use when you need to see effects of a mutation.

Cost model:

decompile(addr)          -> ~50-200ms first call, ~0ms cached
decompile(addr, 1)       -> ~50-200ms always (forces re-decompile)
ctree WHERE func_addr=X  -> one decompilation + streaming rows
ctree (no constraint)    -> one decompilation per row in funcs

Additional Resources

• For detailed workflows (capability probing, mutation loop, call-site typing, local type seeding, fallback patterns, full worked examples): references/decompiler-workflows.md
• For detailed view schemas (ctree_v_indirect_calls, ctree_v_returns): references/decompiler-views.md
• For ctree node types, manipulation patterns, and advanced CTEs: references/ctree-manipulation.md

See Also

• data — raw bytes and string content referenced by decompiled code (the bytes table for per-byte reads and bounded-window reads via WHERE start_addr = X AND n = N; hex(blob_concat(value)) for hex output).
• disassembly — instruction-level ground truth for the same function (disasm_func, instructions, disasm_calls).
• xrefs — callers and callees of a decompiled function; pivot from pseudocode to call graph.
• types — applied prototypes drive ctree shape; retype via applied_types / funcs.prototype to clean up casts and indirect calls.