Akira_Encrypter: Data Encrypted for Impact (T1486)

What the sample does (build 1, 101bd45a…; build 2, 98877635…, is identical in the parts below):

• Ciphers. It encrypts in place with ChaCha8 and KCipher-2, in 0xFFFF-byte chunks. In every encrypted region, the first and last chunk use KCipher-2 and the middle chunks use ChaCha8.
• Modes, chosen by extension and size:
  • Full: database extensions;
  • Part: VM-disk extensions or files over 2,000,000 bytes, in four 10% stripes at the default 50%;
  • Spot: everything else, the first p% of the file.
• Keys. Each file gets key1 (32 B), iv1, key2 and iv2 (16 B each). Each value comes from a fresh Yarrow-256 seeded only with QPC × 100 written as a decimal string.
• Footer. The keys plus mode, percent and size form a 91-byte blob. It is RSA-4096 encrypted (PKCS#1 v1.5) and appended as a 512-byte footer.
• Rename. The file is renamed .akira, through a 532-byte .arika journal.

Code: the encrypter is not recreated as a standalone project. The decryptor re-implements Yarrow-256, ChaCha8, KCipher-2 and the mode and chunk plan byte-for-byte. Its round-trip tests (analysis/2026-10-11_101bd45ab673_akira-ransomware/06-decryptor/test_roundtrip.py) encrypt and decrypt with it.

The weakness: the keys depend only on uptime. With the victim’s clock offset measured on the same boot and each file’s last-write time, akira_decrypt.py recover rebuilds them blind. Results and limits are in the family README.

Detection: Detection/.