Breaking Akira’s clock: recovering files without the ransom key

The binary is a 64-bit Windows executable written in modern C++ (C++20 coroutines on the asio I/O library), with the Nettle crypto library compiled in. It brands itself Akira: .akira extension, akira_readme.txt notes and Akira onion addresses. This build has no command-and-control, no persistence and no data theft. It encrypts and leaves.

Every finding in this post comes from our own static analysis in Ghidra and seven controlled detonations under x64dbg in an isolated VM: six of this build and one of a second build. Each cryptographic primitive was re-implemented in Python and matched against data captured from the running sample.

The whole engagement was run by Claude Code, Anthropic’s agentic CLI, on the analysis host. It worked through two MCP servers inside the malware VM: one exposing Ghidra, one exposing x64dbg. Claude never had a shell on the VM. Everything it did there went through the disassembler’s and the debugger’s own APIs, and the samples never left the VM. I set the goals, chose the test files, reverted snapshots, and made the calls on what counted as proof.

What each tool was used for

Seven detonations, each with one job

Keeping it honest

• One case folder per sample. Every script, raw output, run log and note lives in it, with an append-only audit trail.
• Our own evidence only. No sandbox reports or third-party write-ups were used. Every claim traces to a decompilation, a debugger capture or a test.
• Frozen before the test. For the blind runs, the decryptor, the recovery driver and the clock collector were hashed before encryption. The run logs print those hashes, and the original files’ hashes stayed sealed until the end.
• Small surprises, written down. Two are worth knowing if you build a similar setup:
  • the debugger bridge’s “load binary” call dropped command-line arguments, so every launch used x64dbg’s own init command and was checked against the PEB;
  • memory writes were capped at 512 bytes, so larger files took the long way round.

1. Reads its targets from --encryption_path=, a share list (--share_file=), or, with neither, a sweep of the first five drive letters. -localonly skips network shares. A bare -p is silently ignored, which turns a targeted run into a whole-machine run.
2. Opens an operator log named Log-DD-MM-YYYY-HH-MM-SS.txt in its working directory.
3. Deletes Volume Shadow Copies by asking WMI to start a hidden powershell.exe -Command "Get-WmiObject Win32_Shadowcopy | Remove-WmiObject". The PowerShell process appears as a child of WmiPrvSE.exe, not of the ransomware.
4. Frees locked files with the Restart Manager, force-closing whatever holds them while sparing a built-in list of 20 system processes.
5. Drops akira_readme.txt in each folder it enters, then hands files to a pool of encryptor threads (two on our 2-CPU VM).
6. Encrypts each file in place, appends a 512-byte RSA footer and renames it to name.akira. A temporary name.arika journal lets an interrupted file be resumed and is deleted afterwards.

Each file gets four fresh 16-byte values, generated back to back: key1, iv1, key2 and iv2. Each value comes from its own new random generator, and every generator is seeded the same way.

Three modes, chosen by extension and size

The sample rarely encrypts a whole file. It reads the file in 0xFFFF-byte chunks. The first and last chunk of each encrypted region use KCipher-2, and the chunks in between use ChaCha8.

The uptime counter ticks ten million times a second. If you know when a file was encrypted to within one second, there are only 10⁷ possible seeds for each key, and every seed gives exactly one key. If you know it to within a few milliseconds, there are tens of thousands.

The four values of a file are also generated in a fixed order and very close together. On our test VM, consecutive seeds were about 0.4 ms apart (median 4,121 ticks between key2 and iv2; 20 of 21 files under 8,000). So once you have one value, the next is never far away.

Guess the uptime at the moment a file was encrypted and you can rebuild that file’s keys. Many files only need key2 and iv2: at the default 50%, a Spot-mode file under about 250 KB is encrypted in at most two chunks, and both use KCipher-2.

1. Narrow down when the file was encrypted. On the still-running victim machine, read its clock and its uptime counter at the same moment to learn how one converts to the other. The encrypted file’s “last modified” time then gives its uptime at encryption to within a few milliseconds.
2. Guess the key. Try every uptime value in that window, about 90,000 candidates for a 9 ms window. Each candidate rebuilds a key exactly as the ransomware did.
3. Guess the companion value. It was made about 0.4 ms after the key, so for each key candidate try the next few thousand uptime values. That is roughly 380 million pairs in total.
4. Check each guess. Every PDF starts with %PDF-1., every PNG with the same 16 bytes. Decrypt the first few bytes with each pair; the pair that produces the right header is the right one.
5. Decrypt the file. Replay the sample’s own chunk plan with the recovered keystream, strip the 512-byte footer, and the original is back byte for byte.

Steps 2–4 are the slow part. In pure Python they took about 30 minutes per file on our 20-thread analysis host. With the optional compiled engine (pip install numpy numba) the same search takes about 20 seconds. In the decryptor this is one command:

python akira_decrypt.py recover report.pdf.akira \
    --qpc-offset 134362707471549158 \
    --mtime 134362716175578720 \
    --known-hex 255044462d312e \
    --out report.pdf

--qpc-offset is the clock-to-uptime offset from step 1 and --mtime the file’s last-write time, both as Windows FILETIME values. --known-hex here is %PDF-1.. The values shown are from our run-5 PDF.

If the first pass misses. Occasionally the companion value comes much later than usual (section 07). Run a second pass anchored on the companion instead. On all eighteen files whose keys we have found so far, across both builds, it landed 0.5–1.9 ms before the file’s timestamp, so you can afford to try much larger gaps:

python akira_decrypt.py recover photo.png.akira \
    --qpc-offset 134362707471549158 \
    --mtime 134362716175680085 \
    --anchor iv2 --mtime-window 2.5:0.1 --gap 8001:30000 \
    --out photo.png

Large PDFs. For a file with ChaCha8 chunks, the same command goes on to search for key1 and iv1. For a PDF it falls back to the PDF checks described in section 07 on its own; --stage2 pdf runs only those.

Run 5. For the first test we reverted the VM, placed four real files in a folder, and let the sample encrypt them with no hooks and no breakpoints in its crypto path. Two safety gates stayed in place: the shadow-copy deletion was skipped, and the target folder was confirmed before anything ran. Afterwards we used only what a responder would collect:

• the .akira files and their last-write times;
• one clock reading (system time and uptime counter together) taken on the same boot, after the attack;
• known bytes from the file type, or from the file itself: the standard PNG header, %PDF-1., and for the DOCX the first ZIP header rebuilt from its central directory, which Spot mode leaves unencrypted.

The fourth file: a timing outlier. The first pass searched the whole span from 2 ms before the ransom note to just after the file’s own timestamp, allowing any gap up to 8,000 ticks between the two seeds, and found nothing in 81 minutes. Its seeds turned out to be 26,718 ticks (2.67 ms) apart, almost seven times the usual 0.4 ms. That fits the one outlier we measured earlier (27,109 ticks), on a VM that had been up for only 15 minutes. The second pass searched from the companion value, which still sat 0.93 ms before the timestamp, and allowed gaps from 8,001 to 30,000 ticks. It found the keys in 21 minutes, and the decrypted screenshot was SHA-256 identical to the original.

Run 6: a fully independent re-test

Run 5 had a weakness: we designed the second pass while solving its fourth file. So we ran the whole test again, with three changes:

• Rules fixed in advance. Before anything was encrypted, we recorded the SHA-256 of the decryptor, the search engine and the recovery script, together with the rules they apply: the default pass, an automatic second pass if it misses, and which known bytes to use for each file type. The run log prints the same hashes, so nothing could be tuned afterwards.
• Files we had not seen. After a full VM revert, the analyst chose eight files and placed them in the target folder. The hashes of the originals were sealed before encryption and read only after every file had been processed.
• Nothing in the crypto path. As in run 5, the same two safety gates were applied, then every breakpoint was removed. One clock reading after the attack gave an offset whose seven samples agreed within 7 µs.

What run 6 shows.

• Six of seven in-scope files are hash-exact. All six were found by the default pass in about 25 seconds each, against roughly 30 minutes per file in run 5. That covers every file without ChaCha8 chunks.
• No timing outlier this time. The widest seed gap was 5,570 ticks, so the automatic second pass never ran.
• The timestamp anchor held. The companion value sat 0.55–1.86 ms before each file’s last-write time.
• The JPEG rule worked first time. This run tested it for the first time, and all three JPEGs recovered.
• Two inputs repeat run 5: the DOCX and one screenshot. They were encrypted with fresh keys, and the search uses nothing from a file except its type header, so they still count.

A second build, same flaw

A different Akira-branded build, SHA-256 988776358d0e45a4907dc1f4906a916f1b3595a31fa44d8e04e563a32557eb42, was the next test. It is the same C++ codebase recompiled with new string-obfuscation constants, a new victim chat code and its own operator RSA key. We read its code before running it:

• Same random source. It imports no secure random API. Each key and IV still comes from a fresh Yarrow-256 seeded with nothing but the uptime counter, written as a decimal string.
• Same key set and footer. It draws the same four values in the same order, packs them into the same 91-byte blob, and wraps that in the same 512-byte RSA footer.
• Same file handling. It keeps the same ciphers, the same 2,000,000-byte Part-mode threshold and the same command-line options.
• Different hiding. Its shadow-copy command decodes with different constants, but it is the same command.

We then repeated run 6 exactly:

• a fresh revert;
• the analyst’s files;
• the original hashes sealed before encryption;
• the same two safety gates, located in this build’s own code;
• no breakpoints during encryption.

Recovery used build 1’s decryptor byte-for-byte unchanged.

The result matches build 1.

• Every file without ChaCha8 chunks came back hash-exact, all on the default pass.
• The timestamp anchor held. The companion value sat 0.9–1.9 ms before each file’s timestamp, and the second pass never ran.
• The large PDF stopped at the same ChaCha8 limit, until the PDF check described next.

Reading the code showed the key generation was the same. This run confirmed what reading code cannot: the chunk layout, the cipher details and the timing all line up.

Afterwards: recovering the two PDFs

Both blind runs left one PDF half-decrypted. We went back to find out whether the ChaCha8 key was missing from the search window or the check was rejecting it.

The check was wrong, not the search. In both files, the bytes at the start of the first ChaCha8 chunk are compressed. In the run-6 PDF the whole ChaCha8 region sits inside one 291 KB compressed drawing stream, and the zeros/text check rejected all 971 genuine 64-byte samples of it, so even the right key could never pass. In the build-2 PDF the first bytes are the tail of a compressed stream. About half of the region further in would have passed, but the check never looks there.

After stage 1, most of a PDF is already readable: the KCipher-2 chunks and the whole unencrypted second half. That allows two better checks:

• Object headers from the index. A PDF’s cross-reference table lists the exact byte position of every object, and each object starts with text such as 26 0 obj. In the build-2 PDF the table sat in the readable half and pointed at 968 objects inside the ChaCha8 chunks. ChaCha8 can produce its keystream at any position directly, so each candidate key costs one 64-byte block.
• Keep decompressing. When a compressed drawing stream starts in a readable chunk and runs into the ChaCha8 chunk, feed each candidate’s output to the decompressor and check that what comes out is valid PDF drawing syntax: numbers followed by operators that take the right number of values. In a trial, the best wrong key produced 24% valid commands; the right key produced 100%.

Both keys were inside the normal search window, with seed gaps of 3,910–4,287 ticks, which is ordinary for this sample. Both checks are now in the decryptor as a fallback for PDFs: if the zeros/text check finds nothing, recover retries with them on its own, and the unchanged command line recovered the two files in 8 and 5 minutes. On the build-2 PDF the decompression check, run on its own, found the same key. With the fallback, every in-scope file from both builds is recoverable. We still report the blind runs as six of seven, because the decryptor frozen for those runs did not have this check.

This is a real weakness, but it is a timing attack. Everything depends on knowing when each file was encrypted. Read these before promising anyone their data back.

1. Do not reboot or power off the affected machine. Isolate it from the network instead.
2. Capture memory if you can, then record a clock pair with the snippet below. Run it a few times and keep the median.
3. Collect, with timestamps intact: the .akira files, every akira_readme.txt (its creation time marks when a folder started), the operator’s Log-*.txt, and the System event log.
4. Work on copies, smallest and most important files first.

Add-Type @'
using System; using System.Runtime.InteropServices;
public static class Clk {
  [DllImport("kernel32.dll")] public static extern bool QueryPerformanceCounter(out long c);
  [DllImport("kernel32.dll")] public static extern bool QueryPerformanceFrequency(out long f);
  [DllImport("kernel32.dll")] public static extern void GetSystemTimePreciseAsFileTime(out long ft);
}
'@
$f = 0L; $q0 = 0L; $ft = 0L; $q1 = 0L
[void][Clk]::QueryPerformanceFrequency([ref]$f)
[void][Clk]::QueryPerformanceCounter([ref]$q0)
[Clk]::GetSystemTimePreciseAsFileTime([ref]$ft)
[void][Clk]::QueryPerformanceCounter([ref]$q1)
$q = [long](($q0 + $q1) / 2)
"freq=$f  qpc=$q  filetime=$ft  offset=$($ft - $q)"

With a 10 MHz counter (freq=10000000, the usual value) the offset is simply FILETIME minus the counter, and it goes straight into --qpc-offset. On other frequencies, scale the counter to 100 ns units first.

The earliest reliable signal is the shadow-copy deletion: PowerShell started by WmiPrvSE.exe with Win32_Shadowcopy and Remove-WmiObject on its command line. It happens before any file is touched. After that, a burst of .arika creations followed by .akira renames is unmistakable. A YARA rule and Sigma rules are in the downloads below.

The tools are standard-library Python 3.8+ and PowerShell. GitHub links coming soon