Case: akira-build2

Executive summary

This build was used to test whether build 1’s decryptor carries over to another build.

• Statically, the key generation is identical (03-static/01-comparison-with-build1.md):
  • no CSPRNG import;
  • every per-file value comes from a fresh Yarrow-256 seeded only with QPC × 100 written as a decimal string;
  • the same four draws (key1 32 B, iv1, key2, iv2) and the same 91-byte blob → 512-byte RSA footer;
  • the same ciphers, the same 2,000,000-byte Part threshold and the same command-line options.
• What changed: the string-obfuscation constants, the victim chat code (6729-HK-NIZN-WOPQ) and the operator RSA key.
• Live run (04-dynamic/01-b2run1-protocol.md): the run-6 protocol, with the harness frozen before detonation, the analyst’s files, the original hashes sealed before encryption, and no breakpoints during encryption. Build 1’s decryptor, unchanged, recovered 6 of 7 in-scope files hash-exact on the default pass, in 15–30 s each:
  • the PDF over 262 KB came back with keys found but its ChaCha8 middle not decrypted. It was recovered hash-exact afterwards (2026-10-14) by the decryptor’s new PDF stage-2 fallback: see 06-decryptor/stage2-investigation/ and the addendum in 04-dynamic/01-b2run1-protocol.md;
  • rule.yml was out of scope;
  • AnyDesk.exe was not encrypted (.exe exclusion).

Gates used for safe detonation

• WMI shadow-copy executor FUN_140078890: forced to return.
• Root-folder queue FUN_14007ac00: root std::wstring in r8, checked before the run continued.

Files

• 00-intake/00-intake.md: hashes, locations, safety.
• 03-static/01-comparison-with-build1.md: side-by-side with build 1.
• 04-dynamic/01-b2run1-protocol.md and 04-dynamic/b2run1-blind/: protocol, frozen driver, sealed listings, results.json.
• artifacts/b2run1-blind-recovery-2026-10-13.txt: the recovery log.
• 06-decryptor/stage2-investigation/ and artifacts/stage2-*: how the PDF was recovered after the run (xref test, deflate cross-check).
• NOTES.md: audit trail.