A deep dive into the architecture, security model, NTFS ACL protection, password vault, Intruder Ops, local-first design, failure handling, and the engineering decisions behind ATLOCK v4.
🚀 Try ATLOCK v4:
https://github.com/Akhouri-Anmol-Kumar/ATLOCK
⚠️ Important: ATLOCK is an independent Windows security project. It is not intended to replace Windows security features such as BitLocker, Microsoft Defender, enterprise endpoint protection, or dedicated password managers. The goal is to provide an additional local security layer and to explore practical Windows security engineering.
🧭 What You're Looking At
ATLOCK started as a relatively simple idea:
What if several useful Windows security functions could live inside one local application?
That idea eventually evolved into a much larger engineering problem.
The current ATLOCK v4 architecture brings together several different security mechanisms:
┌──────────────────────┐
│ ATLOCK v4 │
│ Windows Security │
│ Suite │
└──────────┬───────────┘
│
┌──────────────────────┼──────────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌──────────────┐
│ File Guard │ │ Vault │ │ Intruder Ops │
└──────┬──────┘ └──────┬──────┘ └──────┬───────┘
│ │ │
▼ ▼ ▼
NTFS ACLs PBKDF2 + Fernet Camera / Alert
│ │ │
└──────────────┬───────┴─────────────────────┘
▼
Local Windows System
And that's what makes the project interesting to me.
These aren't three versions of the same security mechanism.
They're solving different problems.
- The Core Design Philosophy
The biggest architectural decision wasn't a library.
It was this:
Don't use the same security mechanism for every security problem.
For example:
File access
The primary question is:
Who should be allowed to access this object?
That's an authorization problem.
Password storage
The primary question is:
How do we protect sensitive data if the storage itself is obtained?
That's a confidentiality + integrity/authentication problem.
Intrusion response
The primary question is:
What should happen when configured suspicious access/authentication events occur?
That's an event-response problem.
So the architecture becomes:
SECURITY PROBLEM
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Authorization Confidentiality Response
│ │ │
NTFS ACLs Fernet Intruder Ops
That separation is one of the most important lessons I've learned from building ATLOCK.
- 🛡️ File Guard — Using Windows' Existing Security Model
One of the most interesting parts of ATLOCK is File Guard.
I didn't want to invent an entirely separate permission system.
Windows already has one.
NTFS Access Control Lists.
An ACL can contain access-control entries describing permissions associated with security principals.
Conceptually:
PROCESS
│
▼
Windows Token
│
▼
Security Check
│
▼
NTFS Object
│
▼
ACL / ACEs
│
┌──────┴──────┐
▼ ▼
ALLOW DENY
This matters because the operating system is already involved in the access-control decision.
ATLOCK therefore isn't trying to become an entirely separate filesystem security subsystem.
Instead, File Guard works with a security mechanism Windows already understands.
- Why ACLs Instead of Encrypting Everything?
This distinction is easy to miss.
Suppose I have:
Documents/
├── project.pdf
├── passwords.txt
└── source.zip
There are at least two fundamentally different questions:
Question A
Can an unauthorized identity access these files?
That's where access control comes in.
Question B
If somebody obtains the underlying data, can they interpret it?
That's where encryption comes in.
Visualized:
FILE SECURITY
│
┌───────────┴───────────┐
│ │
▼ ▼
AUTHORIZATION CONFIDENTIALITY
│ │
NTFS ACLs Encryption
│ │
"Who can access?" "Can data be read?"
Neither mechanism is a universal replacement for the other.
That's why ATLOCK uses different mechanisms for File Guard and the Password Vault.
- 🔐 Password Vault Architecture
The Password Vault is where cryptography becomes central.
ATLOCK v4 uses Fernet for the vault.
The high-level flow is:
USER PASSWORD
│
▼
PBKDF2-HMAC-SHA256
│
▼
DERIVED KEY
│
▼
FERNET
│
┌─────────┴─────────┐
▼ ▼
Encrypt Decrypt
│ │
└─────────┬─────────┘
▼
VAULT DATA
The important thing here is that a user's password shouldn't simply be treated as a cryptographic key directly.
Password-based key derivation is a separate step.
ATLOCK uses:
PBKDF2-HMAC-SHA256
for that purpose.
- 🔑 Why PBKDF2 Exists
Human passwords and cryptographic keys are fundamentally different things.
A password might be:
my-password
A cryptographic key needs a suitable representation and should not simply be treated as an arbitrary human string.
So the architecture performs key derivation:
Password
│
▼
PBKDF2-HMAC-SHA256
│
▼
Derived cryptographic key
│
▼
Fernet
ATLOCK v4 uses 200,000 PBKDF2 iterations in the implementation you've described.
The purpose is to make password guessing more computationally expensive than simply applying a fast hash once.
- 🧱 What Fernet Gives the Vault
Fernet provides an authenticated-encryption construction.
In the implementation ATLOCK uses, this involves:
AES-128-CBC for encryption
HMAC-SHA256 for authentication/integrity
That means the vault isn't merely doing:
“Turn plaintext into ciphertext.”
It also has authentication/integrity protection.
Conceptually:
PLAINTEXT
│
▼
Encryption
│
▼
Ciphertext + authentication information
│
▼
Stored vault data
During decryption:
Stored data
│
▼
Authentication verification
│
├──── FAIL ────► Reject
│
▼
Decryption
│
▼
Plaintext
That failure path matters.
A cryptographic system shouldn't silently treat corrupted or unauthenticated data as valid plaintext.
- 📸 Intruder Ops
Then we reach one of the more unusual components:
Intruder Ops.
The basic concept is:
Configured security event
│
▼
Event logic
│
▼
Trigger condition
│
┌────┴────┐
▼ ▼
Alert Capture
│
┌──────┴──────┐
▼ ▼
Photo Video
The important engineering problem wasn't simply:
“How do I take a webcam picture?”
That's the easy part.
The harder question is:
How do I make hardware-dependent operations behave reliably inside a security application?
- 🎥 Webcam Capture Is Messier Than It Looks
For webcam capture, ATLOCK uses OpenCV, including cv2.VideoCapture.
On paper:
camera = cv2.VideoCapture(0)
looks trivial.
Real hardware isn't.
The camera can:
take time to initialize
already be occupied by another application
be unavailable
fail to open
return invalid frames
behave differently between devices
So the application needs to treat camera access as a failure-prone external dependency.
The conceptual workflow is:
Camera Request
│
▼
Initialization
│
┌────────┴────────┐
▼ ▼
Success Failure
│ │
▼ ▼
Capture Handle Error
│ │
▼ ▼
Release Continue Safely
And there's another important requirement:
The UI shouldn't freeze.
A security event shouldn't cause the entire application interface to become unresponsive while a camera operation initializes.
That pushed the implementation toward asynchronous/non-blocking handling of the capture workflow.
- 🔊 Security Alerts
Intruder Ops also interacts with the application's alert system.
That creates another small state machine:
EVENT
│
▼
TRIGGER
│
├───────────────┐
▼ ▼
AUDIO CAPTURE
ALERT │
▼
STORAGE
The goal is not to make the application constantly scream alarms.
The goal is to make security events observable to the user.
That's why ATLOCK v4 includes configurable sound effects and notification behavior.
- ⚙️ Settings Architecture
As ATLOCK gained features, another problem appeared.
Every new feature created more configuration.
Eventually:
File Guard
Vault
Intruder Ops
Sound
Notifications
Lockdown
all needed places where their behavior could be configured.
That's why v4 introduced a dedicated Settings dashboard.
Conceptually:
SETTINGS
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
Intruder Ops Audio Application
│ │ │
▼ ▼ ▼
Capture Sounds Preferences
Behavior Alerts
Centralizing configuration is not just a UI decision.
It also reduces the problem of having unrelated settings scattered across different screens.
- 🖥️ Desktop Lockdown
Another ATLOCK component is Desktop Lockdown.
The design objective here is different again.
It's not primarily about encrypting data.
It's about controlling the user's interaction with the application/system workflow during a locked state.
That makes it another example of why the suite shouldn't be thought of as:
“One giant encryption engine.”
It's a collection of different security controls working at different layers.
- 🧠 The Local-First Architecture
One of my strongest design choices was keeping ATLOCK local-first.
No mandatory account.
No mandatory cloud backend.
No requirement to upload security events to a remote server.
The conceptual architecture is:
ATLOCK
│
┌────────────┴────────────┐
│ │
Windows Local Storage
│ │
├── NTFS ├── Vault
├── Camera ├── Evidence
├── Audio └── Settings
└── UI
This doesn't magically make an application secure.
Local software still has to protect its local data and handle permissions correctly.
But it does remove an entire category of cloud-related dependencies from the basic workflow.
- 🌐 Why I Chose Local-First
Security software has a strange relationship with data collection.
A developer can always say:
“We'll collect telemetry to improve the product.”
And sometimes that's useful.
But every additional piece of collected information creates another responsibility.
You have to ask:
What is collected?
Why is it collected?
Where is it stored?
Who can access it?
How long is it retained?
What happens if that system is compromised?
ATLOCK's local-first approach intentionally avoids making cloud infrastructure a requirement for its core functionality.
- 🔄 The Application as a Collection of State Machines
One thing I increasingly realized while developing ATLOCK is that many “features” are actually state machines.
For example, authentication:
┌───────────────┐
│ LOCKED │
└───────┬───────┘
│
User attempt
│
┌───────┴────────┐
▼ ▼
SUCCESS FAILURE
│ │
▼ ▼
UNLOCKED Failure handling
Intruder Ops:
NORMAL
│
▼
FAILED EVENT
│
▼
THRESHOLD / RULE
│
├──── NO ────► Continue
│
▼
TRIGGER
│
▼
ALERT + CAPTURE
File protection:
UNPROTECTED
│
▼
Protection request
│
▼
ACL operation
│
┌───┴────┐
▼ ▼
SUCCESS FAILURE
│ │
▼ ▼
PROTECTED Error handling
Thinking in states rather than individual buttons made the architecture easier to reason about.
- 💥 Failure Handling Is More Important Than the Demo
A demo usually looks like this:
CLICK
↓
SUCCESS
↓
NEXT FEATURE
Real software looks like this:
CLICK
↓
Maybe success
↓
Maybe permission denied
↓
Maybe hardware unavailable
↓
Maybe malformed input
↓
Maybe process interruption
↓
Maybe unexpected state
That's especially important for security software.
A failure in a calculator is annoying.
A failure during a security operation can potentially create a much bigger problem.
So I increasingly evaluate ATLOCK by asking:
What happens when this operation fails halfway through?
rather than:
Does the happy path work?
- 🧪 My Testing Mindset
My testing process has gradually changed.
Instead of only testing:
Expected input → Expected output
I also think about:
Unexpected input
↓
Unexpected state
↓
Unavailable hardware
↓
Permission failure
↓
Interrupted operation
↓
Application restart
This is one reason building software yourself teaches things that tutorials don't.
A tutorial can show you how to implement a feature.
Your own application forces you to discover what happens when reality disagrees with your assumptions.
- 🔍 Threat Modeling ATLOCK
I'm also trying to become more disciplined about the threat model.
A security feature without a defined threat model can become security theater.
For each component, I want to ask:
Asset
What are we protecting?
Adversary
Who are we protecting it from?
Capability
What can the adversary actually do?
Boundary
Where does ATLOCK's protection begin and end?
Failure
What happens when the mechanism fails?
For example:
THREAT MODEL
│
┌────────┼────────┐
▼ ▼ ▼
Asset Adversary Boundary
│ │ │
└────────┼────────┘
▼
Control
│
▼
Failure
│
▼
Recovery
This is much more useful than simply saying:
“ATLOCK is secure.”
No serious security software should be evaluated with a sentence that simple.
- 🔐 What ATLOCK Is — and Isn't
ATLOCK is:
A Windows security application
A local-first security project
An exploration of Windows access control
A practical cryptography implementation
An event-response system
An ongoing engineering project
ATLOCK isn't:
A replacement for BitLocker
A replacement for Microsoft Defender
A replacement for enterprise EDR
A magic security layer
A guarantee that a Windows machine cannot be compromised
That's an important distinction.
Security engineering requires knowing the boundary of your protection.
- 🏗️ Why I Didn't Just Build Another Utility
There are already countless Windows utilities.
There are password managers.
There are encryption tools.
There are lockdown applications.
There are monitoring tools.
So why build another one?
Because building your own system forces you to understand the interaction between components.
For example:
Authentication
│
▼
Security Event
│
├──────────────┐
▼ ▼
Intruder Ops Application
│ │
▼ ▼
Capture UI State
│
▼
Local Evidence
The interesting engineering isn't necessarily inside each box.
It's often in the connections between the boxes.
- 🤖 Where AI Fits Into My Development
I also want to be transparent about how ATLOCK is developed.
AI tools have played a major role in my development workflow.
I use AI for things like:
explaining unfamiliar APIs
generating implementation ideas
debugging
refactoring suggestions
researching approaches
reviewing code
exploring alternatives
But there's an important difference between:
AI generated the code
and:
AI helped me build the software.
The second describes my workflow much better.
I still have to decide:
what feature to build
what architecture makes sense
what behavior I want
what to test
what failed
what needs changing
whether an implementation actually works
AI can accelerate implementation.
It doesn't remove the responsibility of understanding the system.
- 📦 Why the Portable Model Matters
ATLOCK is designed around portable Windows deployment.
The goal is straightforward:
Download
↓
Run
↓
Use
rather than forcing the user through a complicated installation workflow.
That makes experimentation easier.
It also fits the local-first philosophy of the project.
- 🧩 The Architecture Is Still Evolving
ATLOCK v4 isn't the end.
In fact, shipping v4 exposed more questions than it answered.
That's normal.
A real project evolves through:
Idea
↓
Prototype
↓
Implementation
↓
Testing
↓
Failure
↓
Feedback
↓
Redesign
↓
Release
↓
Repeat
Every version is essentially a snapshot of what I currently understand.
The next version should represent what I learned from this one.
- 🚧 What I Want to Improve Next
Some of the areas I'm particularly interested in improving are:
Security
More rigorous threat modeling
Stronger failure-state handling
Better permission-state recovery
More defensive input validation
Reliability
Better hardware failure handling
More robust asynchronous operations
Improved crash recovery
More extensive testing across Windows configurations
UX
Clearer security explanations
Better error messages
Simpler configuration
More transparent security states
Architecture
Cleaner separation between modules
Better internal abstractions
Easier testing
More predictable state transitions
- 📊 The Biggest Lesson
When I started, I thought building a security application was mostly about adding security features.
Now I think differently.
The real challenge is understanding boundaries.
Where does authentication end?
Where does authorization begin?
Where does encryption matter?
What does the operating system already provide?
What happens when hardware disappears?
What happens when permissions fail?
What happens when the user does something you didn't anticipate?
And most importantly:
What exactly are you promising to protect?
Those questions are where the real engineering starts.
🔥 Why ATLOCK Exists
ATLOCK isn't the result of me knowing everything about Windows security.
Quite the opposite.
It exists because I wanted to learn by building something difficult enough to expose what I don't know.
Every bug becomes a lesson.
Every failure exposes an assumption.
Every technical criticism gives me another perspective.
Every user who tests the application provides another environment I couldn't reproduce myself.
That's what makes building software addictive.
You don't just create the thing.
The thing changes the person building it.
Final Architecture
If I had to reduce ATLOCK v4 to one diagram, it would be this:
┌─────────────────┐
│ ATLOCK v4 │
└────────┬────────┘
│
┌─────────────────────────┼─────────────────────────┐
│ │ │
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ FILE GUARD │ │ VAULT │ │ INTRUDER OPS │
└──────┬───────┘ └──────┬───────┘ └──────┬───────┘
│ │ │
▼ ▼ ▼
NTFS ACLs PBKDF2-HMAC-SHA256 OpenCV / Camera
│ │ │
│ Fernet │
│ │ │
└──────────────┬──────────┴──────────┬──────────────┘
│ │
▼ ▼
Windows System Local Storage
│ │
└──────────┬──────────┘
▼
User Experience
And underneath all of it:
THREAT MODEL
+
FAILURE HANDLING
+
TESTING
+
USER FEEDBACK
│
▼
NEXT VERSION
That's the part of ATLOCK I'm most interested in.
Not simply what it does.
But why it works the way it does, where it can fail, and what I can learn from those failures.
🔒 Try ATLOCK v4
If you're a Windows developer, security enthusiast, or simply someone who likes experimenting with desktop software, I'd genuinely appreciate technical feedback.
GitHub:
https://github.com/Akhouri-Anmol-Kumar/ATLOCK
If you test it, don't just tell me:
“Looks good.”
Tell me:
“Here's what I think you got wrong.”
That's much more useful.
One Last Principle
Don't build security features because they sound impressive.
Build them because you can explain:
what they protect, what they don't protect, who they're protecting against, and what happens when they fail.
That's the standard I'm trying to hold ATLOCK to.
And I'm still learning.
— Akhouri Anmol Kumar
Akhouri Systems 🇮🇳
ATLOCK
"We Build What Others Forgot To Fix"
Top comments (0)