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
infostrings (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
-
SetDefaultDllDirectoriesruns 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 inheritedPATHorPSModulePath). - 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.
- Download
ATLOCK_v5.zip: https://github.com/Akhouri-Systems/ATLOCK/releases/download/v5.0.0/ATLOCK_v5.zip - 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. - 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.
Top comments (19)
@xulingfeng bro just asking I don't know you know or not but I recently heard that China is trying to replicate ASML's lithography machine I guess which is only made by ASML in worldwide creating a monopoly and now China is trying to interrupt that monopoly.... bro please make xi jingping India's PM ☠️👑
Bro, that's quite a topic jump 😂 How did we go from finding bugs in your software to lithography machines? Focus, will you? ☠️
no just interested. because other than technology I love geopolitics too and if china is really trying to replicate ASML lithography machine then they are really gonna interrupt the monopoly of west.
You should look into it. China has already broken monopolies in quite a few other industries, not just lithography. The funny thing is, many of those products used to sell at ridiculously high prices. Once real competition showed up, prices started dropping. Funny how that works, huh? Monopolies are great — if you're the one making all the money. 😂
yeah and west is the one making money for now but seeing China's reverse engineering skills I am sure in next 2-3years China is gonna announce that they have now lithography machines too.
also even if China ignores to build lithography which they will not but still if we suppose still China has monopoly in rare earth metals required to build those machine parts.
Let's leave geopolitics aside. I'm afraid the more we talk about it, the prouder I'll get of my country. Hahaha. 😂
Goated Leader.
Bro can you give a Linux build? I only have an Ubuntu VM no Windows 😢
bro just go to windows feature on or off and on your windows sandbox feature, restart your PC and go to search and search sandbox and click it and here you go.
Windows Home 😊
bro then I don't know solution.
😭 my 50INR
☠️bro how you have so much confidence that you can break ATLOCK_v5 easily.
reminder: It's Akhouri Systems flagship product
and till now even mustafa Erbay has not confirmed whether he has braked it or not.
@merbayerp hehehehe
Hahaha, Anmol! 😂🔥 Bro, why are you putting my name on the battlefield already? ☠️
I haven’t confirmed a break because I don’t want to call something a vulnerability without reproducible evidence.
And honestly, I’m not here for your ₹50. Keep that money, my friend! 😂❤️
What interests me is the engineering behind ATLOCK. You’ve clearly put serious thought into key derivation, authenticated encryption, state integrity, and rollback protection.
But you know how security works: a strong design on paper and a secure implementation are two different things. 😉
If I find something meaningful, you’ll get a proper technical report with reproduction steps, impact, and suggested fixes.
Until then, don’t celebrate too early, bro! 😂🔐🔥
Hey Anmol! 😄🔐
Well, brother, you mentioned my name in the challenge, so I figured I owed you more than a quick look. 😂🔥
First, congratulations on the work you’ve put into ATLOCK v5. There’s a lot of thoughtful engineering here, and I genuinely appreciate your willingness to invite independent scrutiny.
After more than two decades working with enterprise infrastructure, systems architecture, and security, I’ve learned something important: cryptographic strength and implementation security are two very different things.
So I decided to take your challenge seriously.
I went beyond the documentation and performed a static analysis of the extracted ATLOCK v5 binary, examining the container format, padding implementation, and selected CLI execution paths.
And I found something interesting. 👀
🔴 Finding 1: Padme Size-Hiding Information Disclosure
Status: Supported by static data-flow analysis; Windows runtime confirmation pending.
Your v3.1 container includes an eight-byte plain_len field at header offsets 74–81.
The _v3_header implementation serializes this value as a big-endian unsigned 64-bit integer.
However, the original plaintext length appears to remain directly readable from the unencrypted header, even when Padme padding is enabled.
The padding changes the resulting container size, but not the original length stored in the header.
This means an observer who possesses an encrypted container may be able to recover its exact original plaintext length without knowing the password.
The issue doesn’t compromise AES-256-GCM or expose the plaintext itself. However, it undermines the specific confidentiality property that size-hiding padding is intended to provide.
The reproduction check is straightforward:
A dynamically generated padded v3.1 container is still needed to confirm the behavior end to end.
🟠 Finding 2: Potential CLI Lockout Enforcement Gap
Status: Static observation; bypass not demonstrated.
I also examined the CLI execution paths associated with --open and --verify.
The reviewed branches appear to invoke container operations without passing through the application’s normal lockout checks.
This raises an architectural question:
Is lockout enforcement guaranteed across every entry point, or is it primarily enforced by the interactive application layer?
To be clear, I have NOT demonstrated a successful lockout bypass, password-free decryption, or PIN-mode compromise.
Additional call-chain analysis and Windows runtime testing are required before treating this as a confirmed vulnerability.
A few thoughts from one engineer to another
Anmol, I respect the ambition behind this project.
But here’s something I consider fundamental in security engineering:
A security feature is only as strong as the property it actually enforces, not the property its design intends to enforce.
Padding should protect length confidentiality.
Lockout mechanisms should have clearly defined enforcement boundaries.
Authentication should remain consistent across supported interfaces.
And every security claim should be independently testable.
That’s why I prefer reproducible evidence over dramatic claims about breaking encryption.
I haven’t broken your cryptography, and I won’t pretend otherwise.
What I have identified is a statically supported information-disclosure issue and a separate enforcement question that deserves further investigation.
I’m happy to share the relevant technical details privately and help validate potential fixes.
And about your ₹50 reward… 😂❤️
Keep it, my friend. Invest it in ATLOCK v6.
I’m not interested in winning money from a young developer. I’m interested in seeing promising engineering become stronger through constructive security research.
You’ve already demonstrated something valuable: the willingness to put your work in front of people who will question it.
That’s how we all improve.
Respect from Türkiye! 🇹🇷🤝🇮🇳
Keep building, keep learning, and never stop challenging your own assumptions.
Security isn’t about proving that nobody can break your software. It’s about discovering where your assumptions fail before someone else exploits them.
Looking forward to seeing how ATLOCK v6 evolves, brother! 🔐🔥
Mustafa ERBAY BROOOOO!, u are 100% correct on both counts the Padme header leak and CLI lockout bypass are valid architectural flawsss, and i truly appreciate(🔥) you pointing them out constructively. these are going straight into the v6 fix list.
Respect from India! 🇮🇳🤝🇹🇷 (India-turkey bhai bhai maybe just because of pakistan our freindship is little bit tensed like country wise otherwise geopolitics aside you are my brooooo experienced broo.)
by the if you had even accept 50rupees still i can't give you because it's for indians or for those who have UPI and you are from turkey you will not have UPI that's why 😂
BROOOOO! 😂❤️🔥
Now THAT is the response I love seeing from a developer!
You didn’t get defensive, you didn’t make excuses, and you immediately added the findings to your v6 roadmap. That attitude is worth far more than ₹50, my brother. 😄
One small technical note, though: let’s still validate the CLI lockout behavior dynamically before calling it an exploitable bypass. Good security engineering means being just as careful when confirming vulnerabilities as when discovering them.
As for geopolitics, my friend, let’s leave that to the politicians. 😂
I’m from Türkiye, you’re from India, and we’re two people who genuinely enjoy technology, engineering, and learning from each other.
That’s more than enough for a friendship. 🇹🇷🤝🇮🇳
And about the UPI problem… don’t worry, bro. My bug reports come with free international shipping! 😂📦🔐
Keep building, Anmol. I’ll be genuinely happy to see ATLOCK v6 become stronger.
And remember, little brother: the best engineers aren’t the ones who never make mistakes. They’re the ones who turn every discovered weakness into a better design.
Much respect, brother! ❤️🔥
yup bro, ATLOCK v6 will follow your notes about the "the best engineers aren’t the ones who never make mistakes. They’re the ones who turn every discovered weakness into a better design"
I don't have any exact date I can give you that when I'm gonna start building v6 because I feel like now before reaching 3k downloads I should not start building that grand level project also till 3000 I'm not sitting and doing time pass before v6 my plan is to make my web app good APIC Web... I've said you to try it but you didn't replied never mind.