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.
I have downloaded the Android 8.0 source code，Decryption code should be the run first time, when you enter the right password after power on. But I didn't find the decryption related code.
Can anyone give any advice, thank you very much!!!
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.
I need some help on decryption. I'm developing a TWRP recovery for the Atom XL and am stuck at the moment. I was able to set up the stock trustkernel (teed) and keymaster. The recovery boots fine and "/data/system" gets decrypted and is readable BUT everything else is still encrypted.
In the log I get the message "Unable to locate gatekeeper password file '/data/system/gatekeeper.pattern.key'" but checking after booting into the OS there is no such file anywhere on "/data". I did a little bit of research in the source code and as far as I understand the function "Get_Password_Type" in "Decrypt.cpp" the check for "/data/system/gatekeeper.pattern.key" is just a fallback if "/data/system_de/0/spblob/" cannot be read.
And I have in fact that folder but it's still encrypted in TWRP while it is fully readable in the OS. Now my guess is that "/data/system_de" doesn't get decrypted properly. DE means Device Encryption and that should be done the same way as the decryption of "/data/system" or am I wrong? So what am I missing?
I checked with many other TWRP device trees who claimed to be able to decrypt but I can't find any (significant) differences.
wkr ADT
EDIT: It's an Android 10 (LineageOS 17.1) device with FBE. TWRP is 3.5.1_10.0
So I was finally able to figure everything out.
Here is my story for those who are struggling like me:
Decryption is not (completely) working · Issue #3 · ADeadTrousers/twrp_device_Unihertz_Atom_LXL
After booting into the recovery and browsing the filesystem, everything looks a little bit "garbled". Especially the /sdcard doesn't seem to be alright. Here you can only see folders with "GUID"-li...
github.com
It's for a mediatek helios p60 (mt6771) device using "trustkernel" (teed / app/t6) as it's security framework.
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