How ATLOCK v4 actually Locks Files at the OS level (A technical breakdown)

🔐 How ATLOCK's File Guard Actually Works

TL;DR — Most "file lock" apps just hide a file or wrap it in a password check that anyone determined enough can route around. ATLOCK's File Guard instead manipulates NTFS Access Control Lists (ACLs) directly — the same permission layer Windows itself enforces. Here's how that actually works under the hood.

I promised a technical follow-up on this after a few people asked how File Guard is different from typical "lock" utilities. Here it is.

🧱 The Problem With Most File Lockers

The typical approach:

Rename the file / hide the extension
Store a password somewhere
Check the password before "unlocking" (i.e., renaming it back)

This isn't real protection. Anyone with basic file system access — or malware running with the same user permissions — can bypass it entirely. It's a UI-level lock on top of a file system that never actually enforced anything.

🔧 What File Guard Does Differently

Windows already has a real permission system built in: NTFS Access Control Lists. Every file and folder on an NTFS volume has an associated security descriptor that defines exactly who can read, write, execute, or delete it — enforced by the OS kernel itself, not by any application sitting on top.

File Guard's job is to directly edit that security descriptor for a file so that no account — not even an administrator — has access, until ATLOCK explicitly restores it.

The rough flow:

1. User selects a file to guard
2. ATLOCK reads the file's current ACL (so it can be restored later)
3. ATLOCK strips/denies access for all relevant SIDs (Security Identifiers) on that file — including the owning user and Administrators group
4. The file is now inaccessible at the OS level — Explorer, command line, other processes, all get "Access Denied"
5. On unlock, ATLOCK restores the original ACL exactly as it was 🪟 Why This Is Harder Than It Sounds

A few things that made this genuinely tricky to get right:

Permission escalation for the operation itself. Editing a file's ACL is itself a privileged operation — the process doing the editing needs the right token privileges (SeRestorePrivilege / SeTakeOwnershipPrivilege in some cases) to override existing restrictions, even temporarily.

Not breaking the "restore" step. If you strip an ACL and don't store the exact original security descriptor first, you can permanently corrupt a file's permissions — including locking out the legitimate owner forever. Getting the save/restore cycle bit-for-bit reversible took the most iteration.

Avoiding ACL inheritance leaks. Windows permissions can inherit down to child objects and open handles. If a process already has a file handle open when you change the ACL, that handle may still work until it's closed — meaning the "lock" only takes effect for new access attempts unless you also handle already-open handles.

Doing this without requiring the user to run as full admin at all times. Ideally you don't want a security tool that demands admin rights just to exist in the background — so the privilege elevation needs to be scoped tightly to the moment it's actually needed.

🧰 The Tools Involved

All of this happens through the Win32 security API — there's no high-level Python library that does this safely out of the box. It means working directly with:

SetNamedSecurityInfo / GetNamedSecurityInfo for reading and writing security descriptors
Security Identifiers (SIDs) to correctly target the right accounts
Careful privilege token handling to perform the operation without over-broadening what the app can touch
🔒 The End Result

A file that's genuinely inaccessible — Explorer shows "Access Denied," del fails, copy fails, even a second admin account can't touch it — until ATLOCK restores the original permissions. That's a structurally different guarantee than a password dialog sitting on top of an otherwise-open file.

Where this fits in ATLOCK v4

File Guard is one piece of the broader suite — alongside System Lockdown, an AES-encrypted Password Vault (rebuilt from scratch in v4 with PBKDF2-HMAC-SHA256), and Intruder Ops (automatic photo/video capture on failed access attempts). v4 also removed every cloud dependency the app had — it's fully offline now.

🔗 GitHub: https://github.com/Akhouri-Anmol-Kumar/ATLOCK
🔗 Website: https://akhouri-anmol-kumar.github.io/Akhouri-systems/

If you've worked with NTFS ACLs or Win32 security APIs before, I'd genuinely like to compare notes — this was the single hardest part of the whole project, and I'm sure there are edge cases I haven't hit yet.

"We Build What Other Forgot To Fix"