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.
Related
Hey guys,
A few days ago I encrypted my device running the latest Exodus 5.1 with standard kernel. The first few boot ups I had to draw a pattern for boot (in TWRP as well). Now, after a week or so, it doesn't ask me for my pattern anymore. Not on normal system boot, neither in TWRP. But in settings it still tells me encryption is enabled.
Wth? What am I doing wrong?
Cheers
Settings -> lockscreen -> screen lock -> tap on pin / password / pattern (whatever you have set up) -> next screen you can choose if pin/password/pattern should be prompted for at device boot.
Oh, I see. Stupid me. Actually it's good that this is disabled because TWRP unfortunately does not support my 4x4 pattern (any workarounds got this btw?).
But with this option disabled, is the encryption still useful? Probably not right? So if someone steals my shutdown device he can simply access data through TWRP or booting it up, right? Encryption would be useless in this case?
Twrp does support pattern unlock for decrypt since version 2.8.6.0. If your pattern is to swipe the first row from left to right, this would be password "1 2 3" (just like you are swiping over a dialpad).
If you want to secure your data, then you must use a pin/password/pattern lock. If you don't use it, there is no real benefit using encryption.
Yes, TWRP supports 3x3 patterns, but not my 4x4 pattern. So is there any possibility unlocking your pattern via code then? Would it be like this then:
1 2 3 4
5 6 7 8
9 10 11 12
13 14 15 16
And where do I type the code then?
I use a 4x4 pattern lock. I just don't use the option that it has to be entered before boot (after unlocking the SIM card you have to unlock via pattern).
Sorry I misread. Twrp still can only decrypt 3x3 patterns. If your pin/password/pattern is not prompted for at device boot, someone could still access your data through twrp (and e.g. copy it to usb-otg).
Okay thanks. Then I'll hope TWRP is going to be able to decrypt 4x4 soon, so I can enable the boot decrypt. I don't want to go back to 3x3 neither get locked out of my system if I need TWRP to restore, update or whatever.
Preface: I have rooted my device before (TWRP, Magisk).
Because I go on vacation, I wanted to try out the Android Device Manager for locating, locking and purging my Android smartphone..
I registered Android Device Manager app with device administrators.
I went to the Google Device Manager website (https://www.google.com/android/find), have chosen my smartphone and hit lock. The website asked me about PIN, info text and telephone number to display. I pasted (not typed!) "1234" in all of the three fields. The PIN box was masked but was showing 4 asterisks for 4 characters ("1234"). I hit lock and the issue begun.
After 1-3 seconds my smartphone locked up (yay) and showing info text + telephone number (both "1234" as pasted) and I tapped the PIN field to enter the PIN. I entered "1234" and the smartphone just vibrates and the PIN field was emptied.
I tried "1234" several times until the dialog shows "only 2 more tries" (or similar).
I shutdown the smartphone and created a full backup with TWRP and copied the backup and data files to an external USB stick.
Question: Can I remove/reset/change the Google Device Manager PIN? Either with ADB/Root/TWRP/whatever? I tried the website but while in the locked state it only shows the fields for info text and telephone number.
Device Info:
OnePlus 3T (OxygenOS 4.1.6)
Somehow I found a "solution" which make me thing this is completely useless.
After performing the backup with TWRP I restarted the device into normal mode.
I was asked about the device password (not Device Manager PIN). I saw the "locked by Device Manager" in the background. I have entered my device password (not the Device Manager PIN) and everything was unlocked!
Why on earth is there a Device Manager PIN when "the system" is using the device password anyway?
burnersk said:
Somehow I found a "solution" which make me thing this is completely useless.
After performing the backup with TWRP I restarted the device into normal mode.
I was asked about the device password (not Device Manager PIN). I saw the "locked by Device Manager" in the background. I have entered my device password (not the Device Manager PIN) and everything was unlocked!
Why on earth is there a Device Manager PIN when "the system" is using the device password anyway?
Click to expand...
Click to collapse
Hello
Because the one who stole it maybe able to decrypt your device ?
++ you could have deleted pin files from twrp
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!
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