Dynamic analysis: run 6, fully independent blind recovery (protocol fixed 2026-10-13, before detonation)

Why run 6

Run 5 proved blind recovery on four real files. But the second-pass rule (--anchor iv2) was designed while solving run 5’s fourth file, and later re-runs used files whose answers were already known. Run 6 tests the finished method on files nobody has analysed yet, with the rules frozen before encryption.

Frozen before the detonation

| Item | SHA-256 | |—|—| | 06-decryptor/akira_decrypt.py | 870c6db94f5bf94a52be630905131c24138555afd3bcef2a7bdc59ee6b81a8fe | | 06-decryptor/akira_fast.py (numba engine) | 07352777bff09eb30f14a8c826c503e9247948d1385b7dcc8cd02288f4606927 | | run6-blind/run6_blind_recover.py (driver) | ae0df7dff7008eb0004366d1dbed69936fb958255949a21434b9f6346862218d | | run6-blind/collect_clock_and_times.ps1 (collector) | 15fbf5794497b64ac954ba86bc012776971105a6a37a21137d2c4dd45eee7ff4 |

The driver prints both hashes at the top of its log. If any of them differs in the run-6 log, the run is not the pre-registered one, and the log must say why.

Harness check: the driver was dry-run on the run-5 files (scratch copy). Result: 4 of 4 hash-exact in about 100 s, with the outlier PNG found by pass 2 (artifacts/run6-driver-dryrun-on-run5-2026-10-13.txt). This checks the harness only. It is not evidence for run 6.

Files

• Chosen and placed by the analyst after the VM revert, in C:\Users\deadtrace\Desktop\samples\data. Claude does not see them before encryption.
• Pre-encryption listing (collect_clock_and_times.ps1 -Tag pre → pre_run6.txt). It is pulled to the host only after the driver has processed every file.

Detonation (as in run 5)

• Launch: --encryption_path=C:\Users\deadtrace\Desktop\samples\data -localonly.
• Gates: the WMI shadow-copy executor 0x140071620 is forced to return, and the root gate 0x140073950 is checked.
• Then: all breakpoints are deleted and the sample runs to exit. No hooks and no seed reads.
• After the run, same boot: run collect_clock_and_times.ps1 -Tag post → post_run6.txt, then pull the .akira files and the post listing to run6-blind/ via a Ghidra raw import + read_memory.

Recovery rules (in the driver)

• QPC offset: the median of the post-run pairs, first pair excluded.
• Pass 1: key2 window = mtime − offset, −8/+1 ms; gap 3,800–8,000 ticks.
• Pass 2 (only if pass 1 misses): --anchor iv2, iv2 in mtime −2.5/+0.1 ms; gap 8,001–30,000 ticks.
• No third pass counts toward the result. Any later exploratory search is reported separately.
• Known plaintext at offset 0, by type:

Any other type is out of scope: it is listed, and not counted in the success rate.

• Outcome per in-scope file:
  • MATCH: the decrypted SHA-256 equals the original;
  • KEYS FOUND, OUTPUT DIFFERS;
  • NOT FOUND.
• Headline: MATCH / in-scope files.

Known risks, stated in advance

• Files over 262,140 bytes (Spot 50%), database types (Full), or files over 2 MB (Part) also contain ChaCha8 chunks.
  • The stage-2 ChaCha search accepts a key only if the decrypted chunk looks like zeros or text.
  • That heuristic is untested on real compressed data (PNG/DOCX bodies) and may miss. The result would then be KEYS FOUND, OUTPUT DIFFERS, with only the KCipher-2 chunks correct.
  • The stage-2 search is also pure Python, so it is slow.
• JPEG: EXIF-first JPEGs do not start with JFIF, so the JPEG rule misses them.
• Seed gaps over 30,000 ticks fall outside both passes.

Results (2026-10-13): 6 of 7 in-scope files hash-exact; keys found for all 7

Log: artifacts/run6-blind-recovery-2026-10-13.txt (driver ae0df7df… and decryptor 870c6db9…, both as frozen). Machine-readable: run6-blind/results.json. Outputs: run6-blind/decrypted/. Every .akira file matched the VM’s post-run SHA-256.

Detonation:

• full VM revert; x64dbg was empty (no leftover instance);
• image base 0x7FF658870000; entry +0x855B8, same binary as run 5;
• the WMI executor was forced to return; the root gate showed one root, ...\samples\data;
• then no breakpoints;
• operator log: 2 threads, 44,652 ms.

Responder data: QPC offset 134363534101375013 from 7 clean post-run pairs, spread 69 ticks.

Notes:

• Every key2/iv2 pair was found by pass 1. Pass 2 never ran, and no gap exceeded 5,570 ticks in this run.
• The PDF is the risk flagged before the run. Its KCipher-2 seeds were found. The stage-2 ChaCha search, over iv1/key1 gaps 3,105–8,000 (24 M pairs), found nothing that its zeros/text check accepts. So only the KCipher-2 chunks of the 240,815-byte region (the first and last 64 KiB) are decrypted, and the two ChaCha chunks between them are not. Two causes are possible, and this run does not separate them:
  • the check rejects real compressed PDF data;
  • the ChaCha gaps fall outside the window.
• Timing, relative to the note and using the live offset:
  • key2 sat 3.5–20.9 ms after the note;
  • mtime − key2 was 0.94–2.27 ms;
  • mtime − iv2 was 0.55–1.86 ms. The 0.55 ms PNG sits below run 5’s 0.8–1.8 ms range, but well inside the pass-2 window.
  • The two photo_ JPEGs share one mtime, and their key2 seeds are 8 µs apart: both encryptor threads set up a file at the same moment, as in run 5.
• Two inputs repeat run 5: the DOCX and the 125745 PNG. They were encrypted with new keys, and the recovery uses no file content beyond the type rule, so they count. The other five in-scope files had never been analysed.
• pre_run6.txt: the analyst copied it to the host after the run (SHA-256 62fa58a9…, 3,066 B). It was read only by the driver’s final comparison. Its size matches the copy imported into Ghidra /run6 before detonation. A byte comparison with that copy is still to do, because the Ghidra bridge disconnected after the run.

Verdict:

• Files without ChaCha chunks: independent blind recovery worked on 6 of 6, all on the default pass, in about 25 s each.
• Files with ChaCha chunks (here, anything over 262,140 bytes): the KCipher-2 keys are found, but the ChaCha key needs a better check before such files can be recovered in full.

Addendum (2026-10-13/14): the PDF, recovered after the run

This addendum does not change the blind result above (6 of 7), because the frozen driver did not include the test below.

• Cause settled: the check, not the window.
  • The PDF’s whole ChaCha region (bytes 65,535–196,605) is inside one 291 KB compressed page-content stream (object 7).
  • The zeros/text check accepts 0 of 971 genuine 64-byte windows of that stream.
• Targeted rerun (06-decryptor/stage2-investigation/, log artifacts/stage2-pdf-oracle-run6-window-2026-10-13.txt):
  • the test continues the stream’s deflate from the readable chunk 0 and requires valid page-content syntax;
  • it searched the same 24 M-pair window and accepted exactly 1 pair;
  • the rebuilt file’s SHA-256 equals the sealed hash (a13ccfca…). Seeds: 566543569000, 566543980000, 566544406300, 566544820400; gaps 4,110 / 4,263 / 4,141 ticks.
• Now in the decryptor as a stage-2 fallback for PDFs (recover --stage2 auto, the default). The unchanged command line recovers this file hash-exact in 8 min 16 s (artifacts/stage2-integrated-recover-2026-10-14.txt).
• With the fallback: 7 of 7 in-scope run-6 files are recoverable.