Summary
A recent US prosecution dragged one of GrapheneOS’s most interesting privacy features into public discourse. Instead of unlocking a phone, a separate duress PIN or password, when entered, makes its data completely irrecoverable.
It sounded both useful and alarming enough to want to try it for myself. GrapheneOS supports Google and a handful of other devices, but not my Exynos Galaxy Note 20 Ultra.
DuressKeyboard promised a workaround. It’s an open-source app that adds a similar wipe command without needing to replace Android altogether. My Note 20, running Android 16 with ArtisianROM, became my sacrificial handset.
The command triggered, and the Samsung did reboot into recovery, but every single byte of data survived. That failure exposed the big difference between requesting a factory reset and baking duress protection straight into the operating system.
Android really didn’t want me installing this keyboard
Every warning made its powers sound more and more genuine
DuressKeyboard 7.0 is a free, open-source app that’s distributed through F-Droid for devices running Android 10 or newer. Its main purpose is to recognize a password and request an immediate factory reset upon entering it. The full version of the app also includes triggers for failed unlocks, reboots, USB connections, and even a deadhand switch for lost mobile service (faraday cage protection).
Android really, really didn’t want me to install this app. Installing the APK through my browser produced an App blocked to protect your device message. It warned me that the app could request sensitive access, increasing the risk of identity theft or financial fraud.
I had turned off Play Protect scanning before I attempted to install it, but Google’s separate protection for side-loaded apps stepped in and stopped the installation anyway.
I opted to install it through F-Droid instead. Android 16 raised yet another warning that DuressKeyboard had been built for an older Android version, though this time it at least allowed me to ignore the warning.
On the first launch, DuressKeyboard went straight for the Device Administrator privileges, and Android’s explanation of this danger was blunt, to say the least. Once accepted, DuressKeyboard can erase the phone without warning, monitor any incorrect login attempts, and control when the screen is locked.
DuressKeyboard
- OS
- Android
- Developer(s)
- pofesk0 DuressKeyboard is an open-source Android keyboard that can request a factory reset when a configured duress password is entered on the lock screen. It also offers optional automatic wipe and device-locking triggers.
- Price model
- Free and open-source
- Version
- 7 .0
- Platform
- Android 10 or newer It needed control of both my password and the entire phone The permissions were understandable, but hardly comforting Device Admin privileges were only the first step. DuressKeyboard demanded more. It also had to be enabled as an Android keyboard and made the default. As Samsung supplies its own keyboard for lock screen PIN entry, I had to replace the PIN and fingerprint unlock with a text password before the app could watch the login attempts. The developer does state that DuressKeyboard stays offline and collects nothing. Its source is public, making it easier to trust, but it still doesn’t feel great, making it the sole input method. Fair warning: the keyboard is ugly and makes it clear the developers prioritized utility over aesthetics. For some reason, the wipe-command field, where the erasure command is set, didn’t allow capital letters. So, I set my test code to erase26! and explored some of the more unsettling default settings:
- eSIM, external storage, and Factory Reset Protection wiping are enabled by default.
- Screen-off, charging, USB, reboot, network loss, and keyboard switching triggers are disabled.
- Dead Hand mode is also disabled by default.
Auto-wipe on incorrect password/PIN attempts is set to 0 , or “no limit.” The additional options menu also included some genuinely easy ways to accidentally wipe your own phone:
- A change in charge state, like USB connections or even Bluetooth, can trigger the reset.
- Trigger a reset on plugging in a normal brick charger.
- No mobile signal for more than three minutes to protect against being placed in a faraday cage.
- Rebooting the phone to trigger the reset and wipe.
- Every time the screen is turned on, an option to trigger a reset is enabled.
- A fake password field in the event the keyboard can’t be used on the lock screen. Before testing any kind of wipe tool, open your backups on another device. A backup you haven’t verified is only a hopeful copy. I filled the phone with four kinds of disposable data Resetting an empty handset would have proved almost nothing Since the battery was so poor, and I’m awaiting a new one, the phone has sat more or less empty since I flashed it. I needed to give it some items to prove that it had actually been properly wiped. I added some photos, including a picture of a marker text file, then created a contact named Duress Test Contact. I also changed the wallpaper and created a directory on internal storage named DURESS-TEST-DATA . In terms of settings and configuration, the Wi-Fi connection and saved app settings were more than enough to prove it had been used since flashing. The phone had no microSD card, and I wasn’t willing to sacrifice a working eSIM for the experiment. So, the experiment could prove whether the app was able to erase internal data, but not whether every single stated wipe flag worked 100%. After saving the erase26! wipe command, I unlocked the phone with the genuine password one last time. Everything remained intact, but the fail-safe was now definitely primed. My self-destruct code turned into a trip through TWRP The command fired, but the recovery environment never finished the job I locked the Note 20 and entered erase26! , held my breath, and pressed Enter. The response was immediate. The screen went black, the Samsung splash screen appeared, and then the phone rebooted. So far, DuressKeyboard lived up to its promise. Unfortunately, that’s where the factory reset process ended. I never saw an erasing message or Android initial setup screen. The phone simply landed at TWRP’s recovery menu and waited for me. I deliberately avoided TWRP’s Wipe button because erasing the phone manually would have completely defeated the purpose of using the duress command. Instead, I selected Reboot > System, then allowed ArtisanROM to boot up normally. Disappointingly, my normal password still unlocked it, and all the test items were still present on the device. Even DuressKeyboard itself had seemingly survived its attempted self-destruction. The command had clearly been recognized because nothing else could explain the immediate reboot of the phone. DuressKeyboard started initializing the factory-reset path, but my specific TWRP build hadn’t allowed execution of the pending wipe. Stock and TWRP Android recovery can absolutely support these commands in principle, so this isn’t evidence that every TWRP installation will fail to wipe the phone. It’s just evidence that mine unfortunately did, right when reliability mattered most. GrapheneOS doesn’t leave recovery holding the baton Destroying encryption credentials is very different from requesting a factory reset GrapheneOS doesn’t ask recovery to delete every single file. Its duress feature is built into the operating system and recognizes the alternate PIN or password anywhere the current profile’s credentials are requested. When it’s triggered, it destroys several independent secrets that are required to derive the keys that decrypt the user’s data, including those stored in hardware keystores and SSDs. It also wipes all installed eSIMs. The encrypted storage therefore becomes completely unrecoverable while GrapheneOS shuts down the phone to clear all remaining secrets from memory. DuressKeyboard operates at a higher level. Its input methods watch for the wipe command string and then call Android’s Device Policy Manager wipe function. The ROM then needs to pass that request to recovery, which must take over and complete the factory-reset workflow. DuressKeyboard does have the benefit of giving non-Pixel owners a capability that Android doesn’t normally expose. It has also been proven to work just fine in phones using compatible stock recovery rather than TWRP like mine. Unfortunately, however, an emergency wipe can’t really be assumed reliable when the only evidence of it working is destroying the user’s data. A wipe password is not a legal escape hatch Let’s be super clear about this When Samuel Tunick returned to Atlanta from the Dominican Republic on January 24, 2025, federal officers demanded access to his Google Pixel. He then supplied a code requested by the officers to unlock the phone that (according to filings), when entered, caused the phone screen to go black and restart. Prosecutors allege that Tunick knowingly caused the phone’s digital contents to be deleted to prevent any meaningful government seizure. A federal grand jury indicted him on November 13, 2025. Tunick faces one count under 18 U.S.C § 2232(a). The statute covers knowingly destroying, damaging, or disposing of property to prevent or impair lawful government custody. A conviction of this carries up to five years in prison. It doesn’t make installing GrapheneOS or configuring a duress password a crime in and of itself. The charge pertains to whether he acted knowingly for the purpose of circumventing lawful government custody. Tunick pleaded not guilty, and his defense moved to suppress the evidence and statements, arguing that the attempted search was unlawful. My own stakes were quite a bit smaller. When it was obvious the experiment failed, I disabled DuressKeyboard’s Device Administrator access and uninstalled it. The experiment only showed me that a regular Android app can imitate GrapheneOS’s trigger, but doesn’t actually guarantee the same results.