Evidence and provenance

The frozen source

One 483-line C file underlies the entire corpus. It was frozen — hash recorded — before any build, and re-checked before every one of the sixty-eight builds in the comparison matrix. That is the fact that makes the rest of the course possible: no difference between two specimens can be a difference in the program.

SHOWCASE CORPUS VERSION: 1.0
SOURCE FILE: showcase.c
SOURCE SHA-256: 39FEF0BB2A9742870F3D6F7CC864F7CFFA129136F6D2A59C4FB37F25906B99D2
VALIDATION DATE: 2026-09-11 (Australia/Sydney)

CANONICAL SEMANTIC INPUTS
g_input_a = 0x00001337
g_input_b = 0x12345678

EXPECTED RESULTS
demo_substitution       = 0x08080000
demo_bogus_control_flow = 0x6665BBBC
demo_flattening         = 0xDBEFFCE7
demo_calls              = 0x12345F05
demo_data               = 0x57977293
demo_combined           = 0xEEBB6D71

FREEZE STATUS
Validated clean on Windows x64 with MSVC 19.51.36248,
Visual Studio clang-cl 22.1.3, and MSYS2 UCRT64 GCC 16.2.0.
All three executables produced the expected output and exit status 0.

The same hash is recorded independently in the matrix report, the BinProtect report and the corpus description, and the copy this site publishes hashes to 39FEF0BB2A974287… — which is how you can tell nothing was edited in transit.

Its six exported targets each exist for a reason:demo_substitution has twenty-four repeated arithmetic sites,demo_bogus_control_flow has four genuine source conditions with memorable constants, demo_flattening has an if/else, a four-iteration loop and a four-way switch that reconverges, anddemo_calls, demo_data anddemo_combined cover calls, string and table data, and a mixed case. The program prints its six answers and checks them itself, which is what makes "did this build work?" a question with a one-line answer.

The specimens

Twenty-one executables, all Windows x64 PE. The retained runtime column is inherited from the original experiments and was not re-run during curation; the lab column is the course's own rule about what you may execute.

One row is the reason the last column exists. The file namedINCORRECT_DEOBFUSCATION_DO_NOT_USE_AS_WORKING_BINARY.exe is a structurally valid PE, produced by a real tool that exited zero, which returns the wrong answer. It is kept, under that name, as negative evidence. It is not a broken build to be fixed and it is not to be executed as a working program.

The execution boundary

Reading works anywhere. Source, IR, generated C, exact disassembly, recovered graphs, solver queries and every result file are published here and are enough for every core exercise in the course, offline, on any platform. Execution and debugging need the Windows x64 lab image. No Wine route is supported and no Linux rebuild is equivalent — a rebuild would be a different specimen with a different ABI and different lowering.

No BinProtect protected output is bundled either, and none is published here. All eight tested protected outputs failed at runtime — seven access violations and one hang — so that lane is static-analysis evidence only and has no runnable specimen to distribute.

No PDB or MAP file is included anywhere, on purpose. Navigate by export name or by loaded base plus RVA. For a rewritten specimen, decline the original PDB if a debugger offers it: the RSDS identifier can survive patching while the instruction mappings inside the rewritten function go stale, which is one of the four traps week 12 collects.

Two images on publication hold

Twenty-five disassembler screenshots were supplied with the package and all twenty-five were inspected. Two of them have visible content that contradicts their filename, and this site does not display either:

• demo_flattening5_clean_to_rewritten_1.jpg
• demo_substitution6_1.jpg

The first is labelled as one obfuscator's rewrite; its visible right pane carries state constants and a branch target that match a different family's rewritten graph. The second is named for the arithmetic target and both of its visible pane titles say demo_flattening.

Neither was renamed, deleted or quietly repurposed. They stay in the package with their holds recorded in VISUAL_INDEX.md, and this course uses the alternatives the index recommends instead. A filename is a claim about provenance like any other, and a course that teaches you to check the analyst's evidence should check its own.

There is also evidence the package simply does not contain: no confirmed screenshot of the arithmetic target under source-level encoding, and no screenshot of any lifted IR. Week 5 and week 11 use the retained disassembly and the retained IR text instead of an illustration, and say so.

Reading the artefacts

Three things about these files routinely confuse people on first contact, and none of them is a defect.

Two graph conventions. The branch-rewriting study used a dedicated PE-byte audit that does not split blocks at calls and treatsret as terminal. The unflattening study used Miasm's recursive graphs, which do split at calls. A block count from one is not comparable with a block count from the other, and every page that quotes one names it.

Three disassembly flavours. The retained listings were dumped at different times with different settings. Some are AT&T order with a byte column, some are Intel order with a byte column, and some are Intel order with the bytes packed. Read the operand order before comparing two listings — it is the cheapest provenance lesson available.

Windows paths inside the files. Result files and reports carry absolute E:\Workspace\… paths from the machine the experiments ran on. They are provenance, not instructions, and the research tree they point at is deliberately not bundled.

Six examples worth opening in a disassembler

If you have lab access and an afternoon, these six are where the corpus repays manual reading. Start from the matched clean binary in every case, navigate by export name or RVA, and decline the original debug symbols for any rewrite.

One warning about this table specifically: its story numbers are theolder evidence-pack IDs, not the ones the week pages use. The table's own note says so, and the crosswalk is in VISUAL_INDEX.md. Two numbering schemes for the same eight stories is exactly the kind of provenance hazard this course keeps pointing at, and it is in our own material.

Start here

• CLAIMS_AND_CAVEATS.mdevery result, its safe formulation and the overclaim beside it10 kB
• BEST_EVIDENCE_BY_TOPIC.mdtopic to artefact, with the matched comparator for each17 kB
• BINARY_GUIDE.mdper-specimen runtime status, execution rule and export RVAs6 kB
• VISUAL_INDEX.mdall 25 screenshots, what is visible in each, and the two holds21 kB
• EXPERIMENTAL_CORPUS.mdwhy this program, these functions and these constants5 kB
• FINAL_RESEARCH_OVERVIEW.mdthe whole study in thirteen sections, including what did not generalise12 kB
• selected_metrics.mdevery headline number with its convention and provenance6 kB
• VALIDATION_REPORT.mdthe curation QA: 298 assets hash-checked, holds recorded, limits stated4 kB

The complete published set, with a SHA-256 for each entry, is at published-evidence.json. The seventeen full research reports are under /artefacts/reports/ and are linked from the week that uses them.