Illustrative learning material. Examples are not presented as actual model outputs or completed tool tests.

Make the question smaller

“Explain this application” is difficult to finish and difficult to verify. A better first investigation asks about one observable behavior: how a displayed value is calculated, which branch rejects an input, or how a small transformation works.

This is an introductory method with an illustrative source-code example. It is not a recorded installation tutorial or a claim that a particular tool produced the example below.

Choose a workflow you can inspect

Start with the analysis environment you can already use. An agent-connected tool such as REA and an extension such as GhidrAssist have different dependencies. The tool directory separates ecosystems, execution modes and pricing models so you can narrow the options.

Before installation, check the current official instructions, supported platform and required host version. Record where analysis runs and where the model processes context as two separate questions.

Use a sample with a known answer

The following small C function makes the evaluation concrete. Its source is included here so that an explanation can be checked independently.

unsigned int checksum(const char *s) {
    unsigned int n = 0;
    while (*s)
        n += (unsigned char)*s++;
    return n;
}

For the ASCII string abc, the bytes are 97, 98 and 99. Their sum is 294. For an empty string, the loop never runs and the result is zero. These checks give you something more specific than “the explanation looks plausible.”

The sample source is available separately. This source-level exercise does not claim to be a binary decompilation benchmark.

Ask for evidence as well as an answer

An investigation prompt can state the task and the standard of evidence without steering the model toward a particular conclusion:

Explain this function's input and output.
Identify the operations supporting your explanation.
Show one normal example and one boundary case.
Separate observations from assumptions.

If your actual workflow starts from a compiled artifact, preserve the compiler, flags, artifact hash, tool version and model details. Without those, a future reader cannot tell whether they are repeating the same task.

Check the explanation independently

Walk through the loop. Check the byte conversion. Try an empty input. Ask what happens at the terminator. A fluent description that calls this a cryptographic hash, for example, would overstate what the code establishes.

Write down what you confirmed and what remains uncertain. A narrower verified conclusion is a useful outcome.

Keep a short investigation record

Save the input, tool/environment versions, question, response, supporting program locations and your own checks. Do not silently replace an earlier failed response with a later successful one. If you change the sample or configuration, label the new run.

Continue with checking an AI answer against code, or compare REA and RevEng.AI if you are still deciding how to organize the workflow.

Sources & further reading

Tools in this guide