SnooperStopper
Android device ecryption password manager and failed unlock attempts monitor
SnooperStopper allows you to have different device encryption password than
screen unlock pattern/PIN/password. You can have strong device encryption
password (which you only need to enter once after booting your device) but
simple pattern/PIN/password for unlocking your screen.
If attacker tries to guess your simple pattern/PIN/password, he has only
few tries (default is 3) after which the device is rebooted and he needs
to enter your strong device encryption password again.
Where to get it:
Google Play
Eutopia.cz F-Droid Repository
Project on GitHub
Why is it needed:
Android always sets device encryption password same as screen unlock pattern/PIN/password.
This is very unfortunate, because you should have encryption password as strong
as possible, but nobody wants to enter long password all the time just to unlock screen.
There is Android issue #29468
requesting different passwords for encryption and screen lock, but it seems to be
ignored by Google (it is there from 2012 and recently marked Obsolete by Google).
How to use it:
After installation, start SnooperStopper and grant it superuser permissions. Then
enable device admin in app, which allows SnooperStopper to monitor failed screen
unlock attempts and reboot device if maximum number is exceeded.
Whenever you change your screen unlock pattern/PIN/password, Android also changes
your device encryption password, so you have to set your strong encryption
password again. SnooperStopper automatically opens window where you can change it
right after you change your screen unlock pattern/PIN/password, so you should never
forget about it.
Requirements:
Android >= 4.0.3
enabled device encryption (Settings => Security => Encrypt phone )
root (Android doesn't allow apps to change device encryption password or reboot your device without root access)
Credits:
Whole device encryption password changing code is taken from Nikolay Elenkov's
Cryptfs Password Manager.
XDA:DevDB Information
SnooperStopper, App for all devices (see above for details)
Contributors
Mikos, Nikolay Elenkov
Source Code: https://github.com/xmikos/SnooperStopper
Version Information
Status: Stable
Current Stable Version: 1.3
Stable Release Date: 2016-03-21
Created 2015-07-13
Last Updated 2016-03-21
Hello,
Thanks for your great tool, this really fills the gap between a safe encrypted and a everyday easy to use device.
Unfortunately I can't change the encryption password on my maguro galaxy nexus device.
When I try to change my encryption password I get the message cannot get super access
For a short time the root access symbol lights up and disappears.
Snooper Stopper is listed in the device admin list. My nexus (which runs on slim rom lollipop ) asked me whether I would like to give root access to snooper stopper and I agreed.
I'd really like to help to fix this bug so I can use your tool.
Many greetings
Michael
P.S. Already opened a issue at github before I found this thread on xda
mischasworld said:
Unfortunately I can't change the encryption password on my maguro galaxy nexus device.
When I try to change my encryption password I get the message cannot get super access
For a short time the root access symbol lights up and disappears.
Snooper Stopper is listed in the device admin list. My nexus (which runs on slim rom lollipop ) asked me whether I would like to give root access to snooper stopper and I agreed.
Click to expand...
Click to collapse
Like I said on GitHub (writing it also here for reference):
It is problem with SELinux policy. if you have Android >= 5.0, you also need sepolicy-inject utility (you can find it here: setools-android with sepolicy-inject) or supolicy (part of SuperSU - but SuperSU is not opensource, so I highly discourage it).
New version 1.3 is compatible with Android 6 and CyanogenMod 13. Also starting from version 1.1 sepolicy-inject tool is included into SnooperStopper, so you don't need to install any external utility.
Hello Everyone
So I was wondering (I've searched the site,with no luck finding what I need)
I would like to customize and build the Android OS for my mobile phone.
My Physical Test Device Info:
- Samsung Galaxy J1 Ace, SM-J111F
- Running Android 5.1.1 (I've upgrade the rom from 4.x.x to 5.1.1)
Customizations would include:
- Password Protect The Recovery Menu (Like BitLocker's Password Prompt)
- Password Protect The OTA (Over The Air) Download Menu (Like BitLocker's Password Prompt)
- Password Protect The ABD Flashing (Enter Password Through The ABD Command Prompt, Before A User Could do any updates or data uploads/download to the Device)
Please could you let me know what files might need changing also any info relating to any tutorial which I can follow.
Kinda Starting from scratch (I have no android OS development experience, except for a few apk apps from Unity3D)
I'm a software engineer, I've worked with Embedded Systems Running C and C++. a few webs apps and some backend C# systems.
Thank you so much for the help and support in Advance!
Hi everyone,
I've had the nasty surprise of my pattern not being recognized a few days ago. Might be a memory corruption (bit flip from cosmic rays ) or just a very rare bug. Either way, I've won the lottery, because this hasn't happened in 4 years ...
My aim is to unlock the phone without losing internal storage data.
Fortunately, the fingerprint unlock still worked for three days, so I've:
- enabled USB debugging and approved my PC
- backed-up to SD card with Samsung's Smart Switch and did a backup via USB with adb backup (not sure how safe that is)
Currently the fingerprint doesn't work anymore, it forces me to unlock with the pattern. Haven't restarted yet to see if my original pattern will be restored, out of fear that ADB won't work anymore or the backup I did wasn't good enough and I've lost my chance to do a good backup. I'm waiting for my brute-force to finish (more on that below) and some replies from you guys .
My phone is:
Galaxy S8 (Android 9 - firmware G950FXXS5DSJ1 build date Sep 30 2019)
not rooted
My main question is, does this command silently fail after a number of attempts?
adb.exe shell locksettings verify --old xxxxxxx
I've written a script that loads the pattern combinations from file (kudos to delight.im for sharing the list) and saves the command output to file. I've tested it on Android 10 (updated nov 2020) and it throttles after 4 requests - command output is "Request throttled". On my locked phone (Android 9) it appears to never throttle, the output is always "Old password 'xxxxxxx' didn't match".
Found this comment of alecxs on StackOverflow where he says:
there is a 30 seconds timeout after x attempts (timeout may increase) and twrp will silently fail during this waiting period (even with the right pin) - it can even wipe your data (depends on gatekeeper settings and device).
Click to expand...
Click to collapse
Does this apply also to the locksettings verify command?
Can I view the "gatekeeper" settings somewhere?
If you've got any other suggestion on how to unlock the phone or do a better backup before factory reset, please feel free to write!
Thanks a lot!
Hi,
No phone, but router So i have a GL-MiFi router, which has lost its flash IC (that was a long journey).
The main problem is
- The router had a W25Q128FVS... flash
- Now i have W25Q128JV-xM , which is different (does not work) - and a 8MB W25Q64 , which is too small
- The Openwrt image is only 5,2MB
- I can flash U-Boot to the 8MB flash. It boots.
- But as soon as i save the environment or flash an Openwrt , the content turns into garbage (the U-Boot is working, but the environment turns into barbage and Openwrt cannot be started from flash - however, Openwrt works from TFTP.
...does anyone know, how to
- build U-Boot for a device with W25Q128JV-xM support?
- build it fro SD card support (the router has SD card)
- or define the partitions for the smaller flash?
- or where i can ask these?
Thanks in advance for all replies
Hello,
the proper section for my question was a bit tricky for me, so I will put it in General Q&A:
I use a device that comes with File based Encryption - namely Samsung Knox.
(But its not a Samsung Knox specific question)
For that I use some AOSP based ROM - namely LineageOS
(Im not too sure if thats some LOS specific question ... )
Now: File based Encryption comes as default.
But I want some Full Disk Encryption for personal preference.
The GUI of my ROM does not allow me to change the encryption method.
Neither can I deactivate FBE in my ROM, nor can I manually put a second layer with FDE ontop.
So: How to enforce FDE?
I guess with building my own ROM it could be achieved - but obviously I look for some easier way, like shell commands to get rid of FBE first and later use regular ROM capabilities to just use the AOSP internal FDE feature.
Anyone with any experience in this field?
Thanks
IMO you had better asked for help here:
Android Q&A, Help & Troubleshooting
This forum is for all of your questions about Android Development and Hacking. If you need help troubleshooting a problem, please be as specific as possible by describing your software configuration, including the ROM, kernel, and any modifications you've done.
forum.xda-developers.com
It's simply not a choice, you have to live with whatever the ROM provides. Of course you can disable encryption and format userdata at wish unencrypted.
May I ask what's the benefit of FDE compared to FBE?
(btw Samsung encryption is unrelated to Samsung Knox)
aIecxs said:
May I ask what's the benefit of FDE compared to FBE?
Click to expand...
Click to collapse
File Based Encryption (FBE)
Note: That's became default with the release of Android 10 in 2019.
Cold Device – contains a stock background image, user data is locked, and needs bruteforce to access.
Hot Device – background image is visible, the camera is accessible, so data collection can be performed on the phone with the proper tools without knowing the passcode.
Full Disc Encryption with Secure Start-Up (FDE)
Note: That's default encryption since Android 6.
Cold Device (Samsung) – must enter the user’s password before the device will even start
Cold Device (LG) – the operating system is not fully booted without the password
Understanding how to differentiate between cold and hot devices while collecting data will help ensure you use the proper tools.
BTW:
If on device USB-Debugging is enabled - most users do so to have an emergency entrance - a hacker can use ADB to easily intrude in device's Android and deduct data even if they are FBE encrypted, whereas on a FDE encrypted device a hacker stands in front of a closed door, IMO, although ADB may be fully functional.
If you use a screen lock on your Android smartphone, full-disk encryption is enabled by default.
jwoegerbauer said:
If on device USB-Debugging is enabled - most users do so to have an emergency entrance - a hacker can use ADB to easily intrude in device's Android and deduct data even if they are FBE encrypted, whereas on a FDE encrypted device a hacker stands in front of a closed door, IMO.
Click to expand...
Click to collapse
Thx but I asked OP.
adbd is running only after userdata is decrypted, as adb_keys is located /data/misc/adb. therefore that would make no difference (btw hacker would need adbkey.pub of victims PC) despites most user don't have enabled usb debugging at all.
There is no difference between FBE and FDE on "Hot Device" after first unlock (decrypt), except that FBE is more secure before first unlock, as the moment android lock screen appears, FDE whole disk is already decrypted, while FBE is splitted in (ce) credential encrypted + (de) device encrypted storage.
the so called secure start-up is optional. most stock FDE encrypted devices are simply encrypted with default_password and are easier to break (I have done many times). In such case it's even possible to bypass screen lock by simply deleting locksettings.db, while the same would for sure destroy FBE and make files unrecoverable.
But even on secure start-up it's easier to bruteforce passphrase online, as the (encrypted) DEK is saved in userspace (crypto-footer) only, which (in theory) allows attacker to backup & restore status quo to cheat gatekeeper timeout and it's even possible to reset failed decrypts counter, while on FBE encryption key is stored in TEE only which makes it impossible to backup (and therefore harder to cheat gatekeeper).
Furthermore, once decrypted, on FDE it's (hard but) possible to recover deleted files, while on FBE it's impossible to recover deleted files per design.
I see no reason to believe FBE is less secure than FDE and don't see the benefit.
btw Samsung devices provide (FBE) "Strong protection" which is successor to (FDE) Secure startup:
-> Settings -> Biometrics and security -> Other security settings -> Strong protection
jwoegerbauer said:
If you use a screen lock on your Android smartphone, full-disk encryption is enabled by default.
Click to expand...
Click to collapse
Completely unrelated to each other. Two cases:
1) I personally prefer unlocked bootloader and use no encryption at all (I have disabled forcefully), but still I am using pin as screen lock. (there is no private data on phone, that's my decision)
2) stock devices are encrypted on first boot, even before user reaches initial setup. user can decide to just swipe with no pin at all, still device itself is encrypted, despites it has no screen lock.
This applies to both FDE and FBE.
aIecxs said:
Thx but I asked OP.
adbd is running only after userdata is decrypted, as adb_keys located /data/misc/adb. therefore that would make no difference (btw hacker would need adbkey.pub of victims PC) despites most user don't have enabled usb debugging at all.
Click to expand...
Click to collapse
Only allowed me to do you often do.
If you could boot a device into recovery mode - what method used ever - then ADB is accessible and fully functional, AFAIK.
jwoegerbauer said:
If you could boot a device into recovery mode - what method used ever - then ADB is accessible and fully functional, AFAIK.
Click to expand...
Click to collapse
Right, if you can boot into custom recovery, which avb/dm-verity prevents on locked bootloader, at least it should
Still it makes no difference to bruteforce FDE or FBE then, assuming TWRP magically bypasses gatekeeper timeout.
btw Cellebrite, isn't that the company that got hacked by signal founder after false claim they could crack signal?
https://arstechnica.com/information...turns-the-tables-on-forensics-firm-cellebrite