⚔️
One is the current flagship. The other is being engineered.
ATLOCK v4.0 is publicly available. ATLOCK v5.0 is under development.
This isn't a battle between two released products.
It's a look at how ATLOCK is evolving — from its current security suite to a development build with a substantially expanded security architecture.
And today, we're putting both versions under the spotlight. 🔥
🔒 ATLOCK
TOTAL SECURITY SUITE
An Akhouri Systems Product
⚫ Built around privacy.
🛡️ Designed for Windows security workflows.
⚙️ Evolving through continuous development.
🥊 ROUND 1 — MEET THE CONTENDERS
| 🔐 ATLOCK v4.0 | ⚡ ATLOCK v5.0 |
|---|---|
| ### THE CURRENT FLAGSHIP - Publicly available - Established security features - File Guard and Password Vault - Intruder detection features - System lockdown functionality - Existing user-facing application **Status:** Released | ### THE NEXT GENERATION - Currently under development - Expanded cryptographic architecture - More advanced vault and file-protection systems - Additional security monitoring capabilities - Recovery and maintenance improvements - Expanded authentication options **Status:** Building stage |
Important: ATLOCK v5 is not publicly released. Its feature set is not final, and its current code represents the development state rather than a finished release specification.
🛡️ ROUND 2 — FEATURE-BY-FEATURE COMPARISON
Let's examine what each version actually brings to the table.
1️⃣ FILE PROTECTION
🔐 ATLOCK v4.0
ATLOCK v4 includes File Guard functionality built around Windows file permissions and its own application-level protection mechanisms.
Its documented capabilities include:
- Protecting files through File Guard.
- Authentication before removing protection.
- Monitoring guarded files.
- Responding to incorrect authentication attempts.
- Applying Windows NTFS access controls.
The v4 code also includes a warning about a retained developer bypass. That is a material security consideration, not something that should be hidden from users.
⚡ ATLOCK v5.0
The current v5 development code introduces a more extensive file-protection architecture.
It includes:
- Encrypted file containers.
- Chunked AES-256-GCM encryption.
- Authentication of encrypted data.
- Key commitment checks.
- Recovery mechanisms for Quick Lock items.
- Container verification and repair functionality.
- Key rotation functionality.
- Protected temporary working copies.
- Monitoring for guarded-container changes.
The current code also sets the guarded-item limit to 31, compared with 10 in v4.
The difference: v4 focuses on its established File Guard system, while v5's current implementation introduces a more comprehensive encrypted-container and recovery architecture.
2️⃣ PASSWORD VAULT
🔐 ATLOCK v4.0
The v4 Password Vault uses Fernet-based encryption and PBKDF2-HMAC-SHA256 key derivation.
Its documented functionality includes:
- Master-password authentication.
- Encrypted credential storage.
- Adding and editing entries.
- Deleting entries.
- Locking the vault session.
- Applying a hard lock after repeated failed authentication attempts.
⚡ ATLOCK v5.0
The current v5 code introduces a more extensive cryptographic foundation.
Its implementation includes:
- Argon2id-based password-derived keys.
- AES-256-GCM authenticated encryption.
- Protected local state.
- Vault maintenance and repair functionality.
- Vault import and export commands.
- Vault auditing.
- Master-key rotation functionality.
- Additional authentication and recovery mechanisms.
The difference: v5 moves beyond the v4 vault's Fernet/PBKDF2 design into a more extensive authenticated-encryption and state-protection architecture.
This is an architectural comparison, not a claim that every v5 component has already undergone independent security auditing.
3️⃣ INTRUDER DETECTION
🔐 ATLOCK v4.0
The v4 Intruder Ops system includes:
📸 Camera photo capture following an incorrect authentication attempt.
🎥 Short video capture following specified repeated failures.
🔔 Alarm sounds and security notifications.
🗂️ Local storage for captured media.
⚙️ Settings for controlling capture functionality.
⚡ ATLOCK v5.0
The current v5 code retains camera and video functionality while introducing additional handling for security events.
Its code includes:
- Camera and video capture components.
- Configurable security settings.
- Security-event notifications.
- An optional Telegram alert component.
- Protected handling of certain local security data.
The difference: v5's current implementation connects intrusion-related functionality with a broader security-monitoring and notification architecture.
Camera availability, operating-system permissions, configuration, and network connectivity can affect how these features work.
4️⃣ SECURITY MONITORING
This is one of the most notable differences in the current development code.
🔐 ATLOCK v4.0
The v4 feature set focuses on:
- System lockdown.
- File Guard.
- Password Vault.
- Intruder Ops.
- Settings and security notifications.
⚡ ATLOCK v5.0
The current v5 code contains additional security-monitoring components.
| Component | Purpose |
|---|---|
| Windows Defender integration | Retrieve Defender status and initiate supported scans |
| Startup Watchdog | Monitor selected startup locations and identify changes |
| Ransomware Canary | Use decoy files to detect certain suspicious modifications |
| VirusTotal integration | Support file lookups using an API key |
| Audit verification | Verify supported ATLOCK audit data |
| Emergency disconnect | Provide a network-disconnection action |
| Process hardening | Apply selected Windows process mitigations on a best-effort basis |
These components are present in the current development code. Their existence does not mean ATLOCK replaces Windows Defender or provides comprehensive antivirus protection.
The difference: v5's current architecture extends beyond protecting individual files and credentials into additional monitoring, auditing, and security-management functions.
🧠 ROUND 3 — AUTHENTICATION AND RECOVERY
🔐 ATLOCK v4.0
The current v4 code provides password-based authentication for its protected features, along with its existing lockout and recovery-related behavior.
⚡ ATLOCK v5.0
The current v5 code includes additional authentication and recovery components:
- Windows Hello integration.
- Time-based one-time password functionality.
- Recovery codes.
- Quick Lock recovery keys.
- Password and passphrase generation.
- Vault recovery and repair operations.
- Key rotation and container verification.
These capabilities are part of the current implementation. Their availability and exact behavior may change before a public release.
🖥️ ROUND 4 — WHAT HAPPENS WHEN RAM USES ATLOCK?
Let's make this comparison practical.
Meet Ram, a Windows user who wants to protect personal documents and credentials.
He has two options:
- Use the publicly available ATLOCK v4.0.
- Consider the ATLOCK v5.0 development build.
We'll examine what changes in his workflow.
🔐 SCENARIO A — RAM USES ATLOCK v4.0
Ram installs the currently available version.
Situation 1: Ram wants to protect a document
He can use File Guard to protect a supported file.
ATLOCK v4 provides file-protection functionality and Windows NTFS access-control mechanisms.
Ram can authenticate when performing supported operations to remove protection.
Situation 2: Ram wants to store credentials
He can use the Password Vault to create and manage credential entries.
The v4 implementation uses Fernet-based encryption and PBKDF2-HMAC-SHA256 for its password-derived key.
Situation 3: Someone repeatedly enters an incorrect password
ATLOCK v4 includes incorrect-attempt handling, security notifications, and lockout behavior.
Its Intruder Ops functionality can also respond to specified failed-authentication events.
Situation 4: Ram wants additional security monitoring
He has v4's existing security functionality, but the broader collection of monitoring and maintenance components in the current v5 code is not part of the documented v4 feature set.
What Ram gets with v4
A publicly available security suite with established File Guard, Password Vault, lockdown, and intrusion-related functionality.
However, Ram should understand the documented developer-bypass issue in the v4 code before trusting it with sensitive information.
⚡ SCENARIO B — RAM USES THE CURRENT ATLOCK v5 DEVELOPMENT BUILD
Now imagine Ram is evaluating the current v5 code in a controlled development environment.
This is a hypothetical workflow, not a claim that v5 is publicly released or ready for general use.
Situation 1: Ram wants to protect a document
The current v5 implementation provides encrypted-container functionality using chunked AES-256-GCM.
It also includes container verification, key commitment checks, and recovery-related functionality.
That gives Ram a different protection architecture to evaluate compared with v4's existing File Guard implementation.
Situation 2: Ram wants to manage protected files
The current code includes Quick Lock functionality, recovery keys, recovery codes, and protected temporary working copies.
It also includes container repair and key-rotation operations.
The precise user experience and availability of these functions may change during development.
Situation 3: Ram wants stronger password-derived key protection
The current v5 code uses Argon2id for password-derived keys in relevant components.
It also introduces authenticated-encryption and protected-state mechanisms.
These are implementation changes. They should not be interpreted as proof that every possible attack is prevented.
Situation 4: Ram wants to monitor his system
The current development code contains Windows Defender integration, a Startup Watchdog, Ransomware Canary functionality, and VirusTotal lookup support.
These give Ram additional security-monitoring workflows to evaluate.
However, a canary is not a complete ransomware detector, and a file lookup service is not a replacement for endpoint protection.
Situation 5: Ram wants additional authentication and recovery options
The current code includes Windows Hello, TOTP, and recovery-related functionality.
The exact availability and behavior of these features remain subject to development and testing.
What Ram gets from the current v5 code
A broader, more extensively engineered security architecture to evaluate — but not a finished public product.
Ram should not assume that a development build is production-ready simply because it contains more components.
📊 ROUND 5 — THE COMPARISON MATRIX
| Capability | ATLOCK v4.0 | ATLOCK v5.0 current code |
|---|---|---|
| Public availability | Yes | No — development stage |
| File Guard | Available | Expanded protection architecture |
| Encrypted containers | Not the documented v4 design | Chunked AES-256-GCM |
| Password Vault | Fernet + PBKDF2 | Expanded Argon2id-based architecture |
| Intruder Ops | Available | Present in current code |
| Windows Defender integration | Not in documented v4 feature set | Present |
| Startup Watchdog | Not in documented v4 feature set | Present |
| Ransomware Canary | Not in documented v4 feature set | Present |
| VirusTotal lookup | Not in documented v4 feature set | Present |
| Windows Hello | Not in documented v4 feature set | Present in current code |
| TOTP | Not in documented v4 feature set | Present in current code |
| Recovery functionality | Existing v4 behavior | Expanded recovery mechanisms |
| Container repair and key rotation | Not in documented v4 feature set | Present in current code |
| Finalized feature set | Released version | Not finalized |
This table describes the supplied v4 source and current v5 development code. It does not represent independent security certification, a completed release audit, or a guarantee that all development features will ship.
⚠️ ROUND 6 — THE REALITY CHECK
Security software deserves honest communication.
More features do not automatically mean better security.
More cryptography does not automatically mean fewer vulnerabilities.
And a longer feature list does not prove that an application can defeat every attacker.
The current v5 source explicitly acknowledges several limitations:
- A sufficiently privileged local attacker may still be able to modify the application or inspect its process memory.
- Python cannot guarantee that every copy of sensitive data is erased from memory.
- Secure deletion on SSDs cannot be guaranteed because of wear-levelling and storage behavior.
- Rollback protections have limitations against sufficiently privileged attackers.
- ATLOCK operates at the application layer; it does not use a kernel driver.
- The current code is not code-signed.
These are important engineering considerations.
ATLOCK should be evaluated based on its actual implementation, threat model, testing, and security review — not marketing language alone.
🏁 FINAL ROUND — THE EVOLUTION OF ATLOCK
ATLOCK v4.0 represents the current publicly available flagship.
It brings together File Guard, Password Vault, system lockdown, and intrusion-related functionality in an established application.
ATLOCK v5.0 represents the next stage of development.
Its current code expands the architecture with authenticated encrypted containers, Argon2id-based key derivation, recovery and maintenance operations, and additional Windows security-monitoring integrations.
But v5 is still being built.
Its features are not finalized, and its current implementation should not be confused with a completed, independently audited release.
The real story isn't simply v4 versus v5. It's the engineering evolution between two stages of the same product.
🔒 ATLOCK v4.0
THE CURRENT FLAGSHIP
Publicly available. Ready for users to explore.
⚡ ATLOCK v5.0
THE NEXT CHAPTER
Currently under development.
Features and release plans are not final.
Stay tuned for future development updates.
🚀 Explore ATLOCK
GitHub Repository:
https://github.com/Akhouri-Anmol-Kumar/ATLOCK
Download the current public release:
https://github.com/Akhouri-Anmol-Kumar/ATLOCK/releases/download/v4.0/ATLOCK.zip
💬 YOUR TURN
If you were evaluating a security application, which areas would matter most to you?
- 🔐 File protection and encryption
- 🗝️ Password and credential management
- 🛡️ Security monitoring and intrusion alerts
- ♻️ Recovery, verification, and maintenance
- ⚙️ Authentication and ease of use
Share your thoughts in the comments.
ATLOCK is evolving. The development journey continues.
ATLOCK is an Akhouri Systems product developed by Akhouri Anmol Kumar.
ATLOCK v4.0 is the current public release. ATLOCK v5.0 is a development build; its features, behavior, and release plans may change. This article describes the supplied source code and does not constitute an independent security audit or a guarantee against data loss, malware, or unauthorized access.
Top comments (2)
@xulingfeng , The Lazy girl, Mustafa ERBAY
if you 3 are reading this message then thanks for reading.
ATLOCK v5 is set to be released soon.
I will provide you 3 download link as fast as possible so that you all try it and if you find major issues I will delete the release before any trouble.
ATLOCK V5 ( THE FLAGSHIP PRODUCT OF AKHOURI SYSTEMS | ATLOCK )
ATLOCK v5
☠️🔥🔥📈
Absolute Cinema ✋🤚