Static analysis: comparison with build 1 (101bd45a…)
Question: does this build make its per-file keys the way build 1 does? Build 1 seeds a fresh Yarrow-256 with only the uptime counter, which is what its decryptor exploits.
Answer: yes, statically identical in every part that matters for seed recovery. This build is the same codebase, rebuilt with new string-obfuscation constants, a new ransom-note chat code, and its own operator RSA key (not compared).
| Item | Build 1 | Build 2 (this case) | Same? |
|---|---|---|---|
| Random source | QPC only; no CSPRNG import | QPC only. No BCryptGenRandom, CryptGenRandom or RtlGenRandom import. The advapi32 / api-ms-win-security-systemfunctions strings are MSVC runtime API-set entries, present in build 1 too |
yes |
| QPC wrapper | FUN_140078dd4 |
FUN_14007fc6c (+ frequency FUN_14007fc88); callers: __security_init_cookie, the per-value seed, the RSA context and two others |
yes |
| Per-value seed | FUN_14007b1f0: QPC → ns (QPC × 100 at 10 MHz) → decimal string → new Yarrow, seed, draw |
FUN_140082c90: identical sequence (FUN_140059e60 number → stream, FUN_140089b70 init, FUN_140089d60 seed, FUN_140089c20 random) |
yes |
| Per-file key set | FUN_140036740: key1 32 B, iv1 16 B, key2 16 B, iv2 16 B, in that order |
FUN_140036730: four calls, 0x20 / 0x10 / 0x10 / 0x10, same order |
yes |
| Key wrap | 91-byte blob → RSA → 512 B, words byte-swapped | FUN_140083370(ctx, 0x5b, …) → 0x200 B, the same byte-swap loops; then the ChaCha init (FUN_140082b50, 0x20 key / 0x10 IV) and the KCipher-2 init (FUN_140082f80, 0x10 / 0x10) |
yes |
| ChaCha constants | “expand 32-byte k / expand 16-byte k” | the same string at 0x1400ce750 |
yes |
| Part threshold | size > 2,000,000 → Part | cmp rax,0x1e8480 / jg at 0x1400b7ad1 in the per-file coroutine FUN_1400b6420 |
yes |
| Shadow-copy command | decoded with ((0x39 − b)·0x0B) mod 0x7F |
FUN_140078ff0: ((0x32 − b)·0x2A) mod 0x7F → powershell.exe -Command "Get-WmiObject Win32_Shadowcopy \| Remove-WmiObject" |
same command, new key |
| WMI executor (gate 1) | FUN_140071620 |
FUN_140078890 (the only CoCreateInstance caller), called from FUN_140078ff0 |
– |
| Root queue (gate 2) | FUN_140073950, r8 = root std::wstring |
FUN_14007ac00: moves the std::wstring from param_3 (r8) into an asio post, right after the thread-pool setup FUN_14007aa80 |
– |
| CLI | --encryption_path, --share_file, --encryption_percent, -localonly |
the same strings | yes |
| Note / extensions | akira_readme.txt, .akira, .arika |
the same; the note text is the same template, chat code 6729-HK-NIZN-WOPQ |
yes |
Not checked statically (left to the live test):
- the database and VM extension lists;
- the chunk size;
- the KCipher-2 / ChaCha round details;
- timing.
A hash-exact blind recovery covers all of these at once.