Most small encryption tools fail in boring places, not in the cipher. They fail on what happens with a wrong password, a doctored header, a rolled-back state file, or a corrupted chunk.

I spent a long time on those boring places for ATLOCK v5, and this post walks through the design. At the end there's a challenge for you.

1. The container format

Files, folders and Quick Lock items all use one container (v3.1):

magic(8) | salt(16) | kdf_packed(6) | chunk_size(4) | nonce_base(8) | commitment(32) | plain_len(8) | header_hash(32) | chunks...
  • Chunked AES-256-GCM. Every chunk is authenticated independently, so a single flipped bit is caught at that chunk and nothing gets decrypted blindly.
  • Per-seal chunk subkey. v3.1 derives a fresh subkey for each seal instead of encrypting everything under the raw master key.
  • Header-bound AAD. The header is mixed into authentication, so you can't swap parameters around without detection.
  • Optional Padme padding. The true file size is hidden by padding to a Padme bucket with random bytes, at no more than about 12% overhead.

2. Key commitment before any plaintext

AES-GCM alone doesn't commit to a key, which is why partitioning-oracle attacks exist. ATLOCK stores HMAC-SHA256(enc_key, "atlock-commit-v3") in the header and verifies it with a constant-time compare before a single byte of plaintext is produced. A wrong key is rejected at the header, and it never reaches the decryption loop.

3. KDF: Argon2id, and a parser that doesn't trust its own header

  • File floor: Argon2id, t=3, m=64 MiB, p=4
  • Vault and recovery: t=4, m=128 MiB, p=4
  • All sub-keys come from HKDF-SHA256 with per-purpose info strings (vault-enc, vault-verify, totp-wrap, backup-enc, and so on), so no key is ever reused across purposes.

The KDF parameters live in the header, which means an attacker can edit them. So the parser clamps untrusted values to hard ceilings (t≤6, m≤512 MiB, p≤8). A doctored file can't make ATLOCK burn gigabytes of RAM or minutes of CPU.

4. Sealed local state

Settings, guard list, vault index, lockout counters and logs are never stored as plain JSON. Every record goes through a SealedStore: AES-256-GCM with a key derived via HKDF from a DPAPI-protected state key (with extra entropy). A separate rollback anchor catches someone restoring an old state file to reset attempt counters.

There's also an optional hardware mode, where the state key becomes HKDF(DPAPI root || TPM secret) and every sealed file is re-sealed under it. If the TPM key is enabled but unusable, ATLOCK fails closed.

5. Public-key mode

Ephemeral X25519 for encryption (HKDF over the shared secret, salted with the ephemeral and recipient public keys), plus Ed25519 for signatures. Signatures can be pinned, so a file signed by a different key than the one you expect is rejected. There's also Shamir M-of-N splitting for recovery keys, FIDO2 hardware keys, TOTP and Windows Hello.

6. The unglamorous hardening

  • SetDefaultDllDirectories runs before any other import, against DLL planting.
  • Every child process is launched by full System32 path, never through a shell, with a rebuilt minimal environment (fixed COMSPEC/PATHEXT, no inherited PATH or PSModulePath).
  • PowerShell scripts are fixed strings, and variable data goes in over stdin as JSON, never interpolated.
  • Symlinks and junctions are refused. Data-folder ownership is checked, and anything inside OneDrive/Dropbox/Drive is detected so decrypted working copies never get synced.
  • Environment variables that influence paths (like the Nuitka onefile parent PID) are only honoured if they match the actual process layout.
  • Log output goes through a redaction filter for keys and tokens.

7. Detection layer

Ransomware canary decoys in Desktop/Documents/Pictures/Downloads, a startup-item watchdog with a baseline and allow-list, an audit log with its own verify command, and intruder photo/video capture after failed unlocks.

8. Testing

ATLOCK.exe --selftest runs against a throw-away data folder and registry key, so it never touches a real install. --fuzz N throws N random corruptions at the container parser.

Now the actual point: break it

I can't find my own blind spots, which is why I'm posting this here.

  1. Download ATLOCK_v5.zip: https://github.com/Akhouri-Systems/ATLOCK/releases/download/v5.0.0/ATLOCK_v5.zip
  2. Extract ATLOCK.exe. It's unsigned, so Windows SmartScreen will warn you. Click "More info → Run anyway", but do it in a VM or Windows Sandbox. You should treat any random exe from a stranger this way, including mine.
  3. Use it, then try to break it. Recover a protected file without the password, bypass lockout, forge or roll back state, or get plaintext where there shouldn't be any.

Reward: ₹50 via UPI for a valid break, ₹60 for a major one. Send a reproducible write-up in the comments or DM me, and I'll judge what counts.

I'm not rich, so that's what I can afford. Because my parents didn't give me money 💵 and in my fampay account I've only 110rupees 😂 The real reward is that every break you find gets fixed in v6, and your name goes in the credits.

I'm Anmol. I'm 13 and I build under Akhouri Systems. Yes, really. Tear it apart.