Explain a decompiled function while reverse engineering

Decompiler output is correct but unreadable: variables named local_28, pointer arithmetic everywhere. When you are analysing a binary you are authorised to look at, Apex Flash can read a function and propose what it does, suggested names and the things to check in the disassembly.

Set it up

1. Open the binary in your disassembler inside an isolated analysis VM.
2. Copy one function at a time, with its signature and any strings it references.
3. Send it to apex-flash with the prompt below.
4. Apply the suggested names in your database as tentative.
5. Confirm each claim in the disassembly or a debugger.
6. Add what you confirmed to your analysis notes.

Authorisation boundary

Use this on software you own, binaries from an authorised assessment, incident samples you are permitted to analyse, or CTF and teaching binaries. Do not use it to find ways to break licensing on software you have no rights to, and keep live malware in a lab.

Sanitised sample input

A made-up decompiled function that decodes a small embedded configuration:

void FUN_00401a10(byte *buf, int len)
{
  int i;
  for (i = 0; i < len; i = i + 1) {
    buf[i] = buf[i] ^ (byte)(i + 0x5a);
  }
  return;
}
/* called from FUN_00401c30 with DAT_00403010, 0x40 */

The prompt and the call

You are helping a reverse engineer. The code below is decompiler output, so names and types may be wrong.
1. Summarise what the function does in two sentences.
2. Give each variable and the function a suggested name, with a reason.
3. Note anything the decompiler may have got wrong (signedness, pointer width, missed arguments).
4. List what I should confirm in the disassembly or debugger.
5. Do not guess at purpose beyond what the code shows; label guesses as guesses.

<function>
...paste here...
</function>

import os
from openai import OpenAI

client = OpenAI(base_url="https://wildwestapi.com/v1",
                api_key=os.environ["WILDWEST_API_KEY"])

resp = client.chat.completions.create(
    model="apex-flash",
    temperature=0.2,
    messages=[
        {"role": "system", "content": "You are a careful reverse engineering assistant."},
        {"role": "user", "content": open("decomp_prompt.txt", encoding="utf-8").read()},
    ],
)
print(resp.choices[0].message.content)

Keys look like sk-ww-...; keep yours in the WILDWEST_API_KEY environment variable, never in the script. Calls to /v1/chat/completions use the OpenAI format, billing is pay-as-you-go, and prompts are not retained on /v1.

What to check in the output

• Expect a sensible read of the loop here: a rolling XOR over a buffer with a key derived from the index. Verify (byte)(i + 0x5a) wraps at 256 as the model says.
• Ask it to write a short Python decoder you can run on bytes you extracted, then compare with what the debugger shows.
• Be suspicious of purpose claims such as "this decrypts the malware config". The caller and the data are the evidence, not the model's guess.
• Decompilers lose types. If a name is wrong, correct it in your database so later prompts stay consistent.

Both apex-flash and glm-5.3-flash-cyber are security-tuned models with a 1M-token context window, tool calling and vision. They are not uncensored models, and they are meant for defensive and authorised work like this. Bigger context helps: you can send a function with its callers and referenced strings in one prompt.

Where this fits

Next steps are usually YARA rules from what you confirmed and CTF practice for building the skill. See malware analysis use cases. If a defensive explanation is refused on another service, outlaw-1 is the separate uncensored line here.

FAQ

Related