The Safe That Isn't Safe
Most people believe that high-security safes with the latest electronic controls provide reliable protection for firearms, cash, and medications. Hacker researchers James Rowley and Mark Omo have demonstrated that this belief is not warranted — at least for safes using SECURAM digital locks, which are among the most widely deployed in the world. Their technique opens these locks in seconds.
This article covers both methods they demonstrated: the Reset-Heath Attack (unlocking with a smartphone and no tools), and the Code-Snatch Attack (extracting the internal super code from a debug port). It examines what these vulnerabilities mean for the millions of safes currently in use, and why the manufacturer's response — no firmware update, buy a new product — is inadequate.
- The false security: design backdoors built into widely-deployed locks
- The Reset-Heath Attack: opening a safe with just a smartphone
- The Code-Snatch Attack: extracting the master code from a battery compartment
- Summary
Looking to optimize community management?
We have prepared materials on BASE best practices and success stories.
The False Security: Design Backdoors in Widely-Deployed Locks
High-security products create strong expectations of impenetrability. The research findings make clear that those expectations are not met by current SECURAM digital locks. The core problem is a designed backdoor: a reset function built into the lock so that locksmiths and manufacturer support can restore access when a user forgets their passcode. This is a legitimate operational need. But the mechanism implementing it has been left in a state that anyone with sufficient knowledge can exploit.
The brands affected extend well beyond SECURAM products sold directly. Liberty Safe, FortKnox, High Noble, Fire-King, Prosteel, and Rhino Metal — products widely distributed across the U.S. and globally — all share this vulnerability. The researchers tested multiple ProLogic locks purchased from eBay and confirmed that every unit exhibited the same flaw. If an attacker acquires this technique, the risk is not limited to a single compromised product: it scales across the full installed base of these products.
Security experts have long been aware that "backdoor" functionalities create exploitable risk profiles. The reset function embedded in these locks exists as an intended operational feature of the manufacturer — correctly used, it is not a problem. The problem is that the reset mechanism operates on factory-default settings, users are not informed of this, and there is no mechanism compelling them to change the relevant settings. The result: most safes in actual use remain in the vulnerable default state indefinitely.
The vulnerability implications reach beyond consumer safety. Liberty Safe provided the FBI with access codes for a safe during an investigation — a case that illustrates both the law enforcement utility of this mechanism and the risk that the same capability could be exploited maliciously. Consumer trust in security products is deeply affected when those products are revealed to have accessible backdoors. Manufacturers must now reckon with both security design and risk management.
The discovery also demonstrates that proprietary knowledge — "trade secrets" known only to locksmiths and a narrow circle of insiders — can be acquired and disseminated by researchers willing to analyze firmware directly. Once that knowledge is public, the security model that depended on obscurity collapses. Security through obscurity was always a weak guarantee. It is now demonstrably insufficient.
The Reset-Heath Attack: Opening a Safe With Just a Smartphone
The Reset-Heath Attack is the most accessible of the two methods. Mark Omo and James Rowley identified the core mechanism of the reset function built into SECURAM's ProLogic lock and developed a smartphone application that can compute the required response code on demand.
The attack sequence begins with entering the lock's reset mode. The attacker enters a recovery code — all nines — which causes the lock to display a challenge code. This challenge code is generated by a pre-programmed algorithm within the lock's firmware. The factory-default state of the lock is configured so that after a successful reset, the passcode "1111" becomes valid. The research team's smartphone application computes the correct response code from the displayed challenge code in seconds. Entering that response code resets the lock completely: all registered user data is deleted and factory defaults are restored. The safe can then be opened with the default code.
The technical backbone of this attack was firmware analysis. The researchers reverse-engineered the lock's firmware completely — exposing the encryption scheme for internal data and the code generation process. These components, once understood, can be replicated by anyone with the relevant technical skills. The researchers estimate that a competent engineer could build the necessary tool independently in approximately one week.
The demonstration was striking precisely because of its simplicity. No specialized physical tools. No drilling. No destructive entry. A smartphone and a custom application — and the lock resets. The audience response at the demonstration was described as shock at how straightforward the process appeared.
The broader implication is important: the reset function was not a design error in the conventional sense. It was an intended feature, designed for a specific operational purpose, implemented in a way that was never intended to be public knowledge. The problem is not that the feature exists — it is that the factory-default security posture leaves virtually every deployed unit in a state where this attack works, and that there is no manufacturer-driven mechanism to change this.
The appropriate near-term mitigation for users of affected products is to change the reset function's security configuration from factory defaults — a step that requires active action on the user's part, and that most users have not taken because they were never told it was necessary. SECURAM's stated response — no firmware update, new products for customers who want security — does not address the installed base.
The Code-Snatch Attack: Extracting the Master Code From a Battery Compartment
The Code-Snatch Attack goes further. Where the Reset-Heath Attack exploits the reset mechanism to restore factory defaults, the Code-Snatch Attack extracts the lock's internal "super code" — the master override code — directly from the hardware.
The researchers accessed the debug port located inside the lock's battery compartment. Debug ports are standard in embedded systems during development: they allow engineers to inspect and modify device state during testing and manufacturing. In a product that has shipped to end users, this port should be closed or physically disabled. In SECURAM's ProLogic lock, it is not.
The attack sequence: open the battery compartment door, locate the programming port inside, insert a custom-built small device. The device is a minimal computer with a display, purpose-built to interface with the lock's microcontroller. When connected, it reads out all stored code information from the lock's internal memory — including the encrypted super code and, simultaneously, the decryption key needed to interpret it. The super code appears on the device's display. The safe opens immediately.
The most significant concern with this attack is cost and accessibility. The components are commodity hardware, readily available, and inexpensive. The researchers have not published full construction details, but they state that the barrier to reproducing this attack is low for anyone with moderate electronics knowledge. The attack requires physical access to the battery compartment — which is accessible from outside the safe — making it a realistic threat in real-world scenarios.
SECURAM has acknowledged that the super code is stored in the lock's keypad component rather than in the safe body itself, and that this design choice leaves it physically accessible. The manufacturer has stated that a correction to this design should have placed sensitive storage inside the locked portion of the safe rather than in the externally accessible keypad housing. This acknowledgment does not come with a remedy for existing products.
The manufacturer's response to both vulnerabilities — release new products — means that the installed base of currently deployed locks will not receive a fix. Users who own affected products are exposed to both attack vectors indefinitely unless they take independent action. The absence of a firmware update path — or any other manufacturer-provided remediation — is a significant failure of post-sale security responsibility.
Summary
The two attack methods demonstrated by Rowley and Omo — the Reset-Heath Attack and the Code-Snatch Attack — collectively overturn the assumption that high-security safes with digital locks are reliably secure. The reset function backdoor exploited by the Reset-Heath Attack is a design feature left in factory-default state across millions of deployed units. The debug port exploited by the Code-Snatch Attack is an engineering convenience that was never disabled before products shipped to consumers.
Both attacks require no specialized knowledge to understand: the first uses a smartphone application; the second uses inexpensive commodity hardware. Both affect products from Liberty Safe, FortKnox, High Noble, Fire-King, Prosteel, Rhino Metal, and others — all using the same vulnerable SECURAM lock.
The response from SECURAM — no firmware update, buy new products — leaves the full existing installed base in a vulnerable state. Users who own these products should not assume that their safes provide the security they believe they do. The minimum reasonable action is to review and modify the reset function default settings of any affected product currently in use.
The broader lesson the research illustrates is the one that security professionals have argued consistently: absolute security is an illusion, and any product that treats its security model as permanent — rather than as something requiring ongoing maintenance and update — will eventually be demonstrated to be less secure than users believed. The appropriate response for manufacturers is to design for security maintenance from the start: firmware update capability, proactive vulnerability disclosure programs, and post-sale security communication with customers. The failure to do these things is what converted a designed feature into a broadly exploitable vulnerability.
Reference: https://www.youtube.com/watch?v=upVzWfokDQc
Streamline Event Management with AI | TIMEWELL Base
Struggling to manage large-scale events?
TIMEWELL Base is an AI-powered event management platform.
Track Record
- Adventure World: Managed Dream Day with 4,272 attendees
- TechGALA 2026: Centralized management of 110 side events
Key Features
| Feature | Benefit |
|---|---|
| AI Page Generation | Event pages ready in 30 seconds |
| Low-Cost Payments | 4.8% transaction fee (among the lowest in the industry) |
| Community Features | 65% of attendees continue networking after events |
Feel free to reach out to discuss streamlining your event operations.