Malware Analysis Series

Static analysis: encrypted file format, .arika journal and on-disk artifacts

Address: 0x1400ae840 (per-file coroutine), 0x1400adb00 (journal), 0x1400b5a20 (footer), 0x140042420 (note) Callers / callees: encryptor threads → FUN_1400ae840

Purpose

How an encrypted file is laid out, and what else the sample leaves on disk.

Walkthrough

Per-file sequence (FUN_1400ae840), confirmed live:

  1. Open the target. If it is locked, run Restart Manager unlocking and retry.
  2. Create the journal <dir>\<name.ext>.arika with CreateFileW(GENERIC_READ|GENERIC_WRITE|DELETE, share R/W, CREATE_ALWAYS, FILE_FLAG_OVERLAPPED) (FUN_1400adb00).
  3. Write the journal header at offset 0.
  4. Encrypt the regions for the chosen mode. Before and after each chunk, overwrite journal bytes 0–8 with a progress record.
  5. Append the 512-byte RSA footer at offset = original size (FUN_1400b5a20).
  6. Rename the open handle to <name.ext>.akira with SetFileInformationByHandle(FileRenameInfo), then DeleteFileW the journal.

Key constants / structures

| Structure | Offset | Size | Content | |—|—|—|—| | .akira footer | S (original size) | 512 | RSA-4096 ciphertext of the 91-byte blob, 32-bit words byte-swapped | | .arika header | 0 | 1 | 0xFF at first; then 0 (chunk read and encrypted) or 1 (chunk written) | | .arika header | 1 | 8 | progress offset (end of the last processed chunk) | | .arika header | 9 | 11 | 0x01, mode, percent, original size | | .arika header | 20 | 512 | the same RSA blob as the footer (532 bytes in total) |

An encrypted file is exactly 512 bytes larger than the original. Because the journal carries the RSA blob and the progress mark, a file caught mid-encryption by a crash or kill can still be decrypted by the operator. The decryptor supports this with --journal.

Other artifacts:

Findings

Cross-references