I wrote a 10,000-line Windows security suite in one Python file. Here's how the crypto container works, and ₹50 if you can break it
Related Stories
Certificate authority keys: eMudhra's browser and runtime trust gap
Dev.to
13 hours ago
9 Mothers (YC P26) Is Hiring in Austin, TX
Hacker News
14 hours ago
Who watches the watcher when the watcher is a file in the repo?
Dev.to
20 hours ago
Hazel (YC W24) Is Hiring
Hacker News
1 day ago
OpenCode lost the keys that lived in its cloud. The ones on disk were fine.
Dev.to
1 day ago
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! 🔐🔥