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,
I've tested the full verified boot stack of Nexus 5X, to better understand the various implications, especially for my SuperUser project ( http://forum.xda-developers.com/android/software-hacking/wip-selinux-capable-superuser-t3216394/ ).
First of all, I'd like to say that they took time, but with this bootloader, Google did a really nice piece of security, without excluding alternate ROMs. (No doubt they got their inspiration from Chrome project, which are(were?) ahead on the matter).
This means that we can have alternate ROMs, even possibly roots, without compromising our devices! (of course assuming root/ROMs do their part of the job)
Everything is explained in https://source.android.com/security/verifiedboot/verified-boot.html and https://source.android.com/security/encryption/index.html
For users who haven't got their hand on a Nexus 5X/6P yet, here are the various screens you might see on boot when booting a non official ROM: https://source.android.com/security/verifiedboot/verified-boot.html#user_experience
The bootloader has two states: locked or unlocked, nothing new here. locked won't let you flash, unlocked will.
But then, there are 4 boot state that can be shown (or not to the user):
- Green boot state: the device is locked and running Google's ROM. It's the only boot state which is not displayed by bootloader
- Orange boot state: the device is unlocked.
- Yellow boot state: the device is locked, running an alternate ROM
- Red state: This shouldn't happen, it means the boot.img has been badly signed. Could mean an attack is undergoing.
Yellow state has two different possible screens depending on if the boot.img is signed. The difference is, if it is signed, an ID is displayed: this is the fingerprint of the public key used to signed the boot.img.
This means that we, the users, have a way to always be sure we booted the boot.img made by the ROM developer.
The same way we know we are on a Google ROM when there is no warning screen, we know that we are indeed on the ROM we are expecting.
But wait, there is more! The bootloader gives to the TEE/Trustzone the public key of the boot.img, and the TEE/Trustzone changes its answers based on the public key.
The TEE/Trustzone answers are used to generate the key of the /data encryption.
This means that in locked mode, with a signed boot.img, a trusted keystore-owner (doesn't have to be Google), full disk encryption enabled, and dm-verity enabled, even if an attacker is capable of overwriting any part of eMMC through either a privilege escalation, or physical attempt, trying to phish you to prompt your password, then the attacker won't get access to your data!
The TL;DR is, it is now possible to be as secure as original Google's ROM with a custom ROM (you still have to trust Google though) thanks to verified boot features.
Here are my advices to fully benefit from this feature:
- KEEP Full Disk Encryption (forceencrypt)
- KEEP keystore/keymaster/qseecomd
- Lock bootloader back
- Use custom security keys, including verity key, and keep them safe.
- Sign boot.img (this is default AOSP behaviour I think)
- Use a different security key for recovery (so recovery won't ever access to your userdata)
- Untick "OEM unlocking" if you feel safe about your ROM, to have Factory Reset Protection working (ie anti-theft feature)
For unknown quality ROMs:
- When first booting a new ROM/security key, try to memorize the fingerprint. If you don't memorize it all, try to memorize characters are random position, not the beginning.
- When the device asks for you deciphering password, check you booted the proper fingerprint. Do that especially if you have unexpected reboots.
Even though I consider this is a really great step forward to having secure alternate ROMs, there are some downsides:
- There is no "verified" mode where you can flash anything, but it does apply the security policy. This makes TWRP/Flashfire/CWM/a proper OTA system needed to be able to flash again without erasing all data
- The fingerprint is 6bytes/48bits, this is by far lower than most security standards. Also, some algorithms make ascii-art from fingerprints to help user recognize matching fingerprint.
- Changing ROM is complicated: you either need to resign all ROMs with your own key, to factory reset or "transmit" in clear the cipher key
Despite the the downsides, I hope to convince some ROM devs, and users to go to lock mode and check they implemented my various advices.
Please note that this security works only on Nexus 5X/6P, it doesn't work on N6 or N9.
Next step is to add ability for the end user to create a chain of trust in bootloader area.
User must have the way to blow it's own public key to the SoC Qfuses/Qfprom and to sign a chain of bootloaders and activate a Secure Boot after that.
---
Sony Xperia A2 SO-04F (Japan version of Z1 Compact)
Did someone check the second public key emplacement in Qfuses is locked?
New piece of information about this feature, this should become widespread amongst devices.
The Android comformity document for Android M ( https://static.googleusercontent.co...com/fr//compatibility/6.0/android-6.0-cdd.pdf section 9.10) states that verified boot is mandatory.
It is/was unclear whether this document refers to https://source.android.com/security/verifiedboot/verified-boot.html, or just requires any verified boot.
But a commit in Qualcomm's bootloader gives some signs:
https://www.codeaurora.org/cgit/qui...3&id=3b6a87e4556587b3cc0c652ada680b7284d2fae7
"platform: msm_shared: update for bootloader's requirements."
It could be some overthinking, but anyway this means that all Android M-native devices will have this feature (OR be fully locked, this is allowed as well :/)
This is IMO a really great news as this means we will be able to have secure ROMs on all devices!
How could you have a secure custom ROM if you don't have ability to blow your own key (with wich partition's hashes is signed) to a SoC Qfuses/Qfprom?
---
Sony Xperia A2 SO-04F (Japan version of Z1 Compact)
I said it in my post. The encryption of /data is computed by the TZ and based on the public key of boot.img
I even think FRP is kept, though I don't really want to play with that
phhusson said:
Hello,
I've tested the full verified boot stack of Nexus 5X, to better understand the various implications, especially for my SuperUser project on N6 or N9.
Click to expand...
Click to collapse
Thanks for this.
Just a few questions (with respect to the nexus 6P):
1. Do you upload a custom keystore via "fastboot flash keystore" (nexus 6P)?
2. Will changing the key store as per (1) affect the OEM keystore (i.e. is that separate)?
3. Would you mind sharing how you made your own keystore?
- edit: found your repo https://github.com/phhusson/super-bootimg/tree/master/scripts
4. After you relock the bootloader, how are you supposed to flash a custom recovery given that there is no verified mode? My undestanding is that the stock recovery has to be in place before locking the bootloader (for data wipe to occur). Or does the locked state also use the custom keystore?
5. On a somewhat related matter, say you have no custom keystore and the boot chain is compromised so that the phone boots into the red state. Are you still able to access the android OS? I've seen conflicting information on this.
ceribik said:
1. Do you upload a custom keystore via "fastboot flash keystore" (nexus 6P)?
5. On a somewhat related matter, say you have no custom keystore and the boot chain is compromised so that the phone boots into the red state. Are you still able to access the android OS? I've seen conflicting information on this.
Click to expand...
Click to collapse
Although the keystore partition is flashable, it is useless.
The only thing checked is the public key with which is signed the boot.img
Thus the only red state possible is because of dm-verity.
The anti-signature change is provided by the fact that data are encrypted with a key based on the public key of the boot.img
2. Will changing the key store as per (1) affect the OEM keystore (i.e. is that separate)?
Click to expand...
Click to collapse
Nope. Even in CAF implementation which handles keystore, the state is different between OEM keystore and user keystore.
(Yellow in user keystore, green in oem keystore)
3. Would you mind sharing how you made your own keystore?
- edit: found your repo https://github.com/phhusson/super-bootimg/tree/master/scripts
Click to expand...
Click to collapse
Though it is mostly useless. The only use is for CAF devices, with verified mode.
4. After you relock the bootloader, how are you supposed to flash a custom recovery given that there is no verified mode? My undestanding is that the stock recovery has to be in place before locking the bootloader (for data wipe to occur). Or does the locked state also use the custom keystore?
Click to expand...
Click to collapse
I haven't checked that part yet, but I don't think you need original recovery.
But yes, the no-reflashing annoys me a lot, it means a custom ROM MUST provide an OTA system.
5. On a somewhat related matter, say you have no custom keystore and the boot chain is compromised so that the phone boots into the red state. Are you still able to access the android OS? I've seen conflicting information on this.
Click to expand...
Click to collapse
As mentioned earlier, I'm only aware of dm-verity-based red state, which can indeed be bypassed.
I hope this answers your questions, don't hesitate to ask for more
Dude I really wanna pick your brain on this. It's sad I arrive late to these parties Anyways I have a Pixel and believe this is more relevant than ever now because verified boot is strictly enforced. I want to have a modified phone with custom ROM & locked bootloader but after flashing super TWRP/SU/EX to kernel I'm positive it breaks signing.
So my question is how can I re-sign the kernel after it had been modified by SuperSU/TWRP/EX Kernel etc? I would like to flash my own keystore.img and sign the boot.img so my phone will boot with yellow warning. Can it only be done with a full build environment at compile time or can I grab some tools, generate the keystore & sign an image that pull with dd? This is something that is very new to me & there is really no step-by-step for this that I've found.
Please forgive me for my lack of knowledge on this subject but I am desperate to have a modified kernel /system and the ability to re-lock my boatloader. I can live without the dm-verity since I have a tendency to modify system files on a regular basis anyways. I sent you a PM cause I had lost this page. If I can figure out a step by-syep process to do this that didn't require a whole build env I can probably script a tool once I know necessary commands and tools.
So far I've generated my keystore keys
1.
Code:
/make_key keystore '/C=US/ST=California/L=Long Beach/O=Android/OU=Android/CN=Android/[email protected]'
now I am trying to figure out the keystore image.
2.
Code:
java -Xmx512M -jar BootKeystoreSigner.jar keystore.pk8 keystore.x509.pem keystore.img
Geofferey said:
Dude I really wanna pick your brain on this. It's sad I arrive late to these parties Anyways I have a Pixel and believe this is more relevant than ever now because verified boot is strictly enforced. I want to have a modified phone with custom ROM & locked bootloader but after flashing super TWRP/SU/EX to kernel I'm positive it breaks signing.
So my question is how can I re-sign the kernel after it had been modified by SuperSU/TWRP/EX Kernel etc? I would like to flash my own keystore.img and sign the boot.img so my phone will boot with yellow warning. Can it only be done with a full build environment at compile time or can I grab some tools, generate the keystore & sign an image that pull with dd? This is something that is very new to me & there is really no step-by-step for this that I've found.
Please forgive me for my lack of knowledge on this subject but I am desperate to have a modified kernel /system and the ability to re-lock my boatloader. I can live without the dm-verity since I have a tendency to modify system files on a regular basis anyways. I sent you a PM cause I had lost this page. If I can figure out a step by-syep process to do this that didn't require a whole build env I can probably script a tool once I know necessary commands and tools.
So far I've generated my keystore keys
1.
Code:
/make_key keystore '/C=US/ST=California/L=Long Beach/O=Android/OU=Android/CN=Android/[email protected]'
now I am trying to figure out the keystore image.
2.
Code:
java -Xmx512M -jar BootKeystoreSigner.jar keystore.pk8 keystore.x509.pem keystore.img
Click to expand...
Click to collapse
Off the top of my head, you have to add the public signing keys to the root directory of the ramdisk in the boot.img, and then sign the boot.img with the private keys.
I think the image is signed with the verity keys, and the public key has a special form for nougat/7.1/14.1, with some rounding. I think marshmallow was different. From the android build environment, you can use "make generate_verity_key". The actual source is here system/extras/verity if you just want to compile the pieces parts.. The script will be in the out/host directory if you use the make command. Use the convert option "generate_verity_key -convert <path-to-x509-pem> <path-to-key>" to convert the keystore.x509.pem cert that you made. This script will generate the public key in the just the right form that android is looking for. This is what goes into the root of the ramdisk. I think it has to be named verity_key. Yes, I know you aren't turning on dm-verity for the system image, but the boot is signed with the same key.
There is probably a script in one of the aosp repos that will make and sign the boot image. You want to find that and figure out what it is doing.
The finger print will be the first 6 words from the sha1 fingerprint:
Code:
openssl x509 -noout -in keystore.x509.pem -fingerprint -sha1
Hope that helps.
Edit: In the system/extra/verity dir, there is a boot_signer script that references a bootsignature.jar that might do what you are looking for. You'll probably have to build it since it will be in the out/host/ directory somewhere. or just hotwire the java yourself.
Off the top of my head, you have to add the public signing keys to the root directory of the ramdisk in the boot.img, and then sign the boot.img with the private keys.
I think the image is signed with the verity keys, and the public key has a special form for nougat/7.1/14.1, with some rounding. I think marshmallow was different.
There is probably a script in one of the aosp repos that will make and sign the boot image. You want to find that and figure out what it is doing.
The finger print will be the first 6 words from the sha1 fingerprint:
Hope that helps.
Click to expand...
Click to collapse
I'm slowly starting to figure this out, but I have one problem. On the Pixel there is no keystore partition so I can't flash my keystore.img. Do I need to flash a keystore for my signed images to boot? If not I will continue and sign but it was my understanding that I would need that. I suppose I should also grab the verity tools from a 7.0 tree instead of phhussons repo?
Geofferey said:
I'm slowly starting to figure this out, but I have one problem. On the Pixel there is no keystore partition so I can't flash my keystore.img. Do I need to flash a keystore for my signed images to boot? If not I will continue and sign but it was my understanding that I would need that. I suppose I should also grab the verity tools from a 7.0 tree instead of phhussons repo?
Click to expand...
Click to collapse
The pixel night be different, but I think the signature is appended to the boot.img. i don't think you need the keystore partition? I could be wrong. The fingerprint lets you know that it wasn't re-signed by a different key.
I think you want to use a nougat branch for sure.
Pixel Locked Bootloader Custom ROM / Kernel
Okay so I got this whole thing figured out. Just had to read stuff all over the place. Everything we need is in phhussons repo under the keystore_tools and the 6.0 CAF tree will suffice. I knew I was close.
BTW: I only recommend this for flawless ROMs with no major issues. Once re-locked DO NOT disable Allow OEM Unlock in the developer options menu unless you are 100% sure your phone will boot especially after /data wipes etc. Do not make modifications of any kind in a locked state with OEM unlock off. I learned the hard way with a 5X when I tried to dd a vendor.img via adb on a locked bootloader without TWRP. Don't do anything crazy! You have been warned!
Here is how you can re-sign after mods beofore re-locking a Pixel.
Grab boot images from android (needs root or twrp):
I actually used Android Terminal Emulator for this step
Code:
sailfish:/ # cd /dev/block/platform/soc/624000.ufshc/by-name
sailfish:/dev/block/platform/soc/624000.ufshc # dd if=boot_a of=/sdcard/boot_a.img
sailfish:/dev/block/platform/soc/624000.ufshc # dd if=boot_b of=/sdcard/boot_b.img
Generate Keystore:
Code:
./make_key keystore '/C=US/ST=California/L=Long Beach/O=Android/OU=Android/CN=Android/[email protected]'
openssl rsa -in keystore.pk8 -inform der -outform der -pubout -out keystore.pub.pk8
Sign the boot Images:
Code:
java -jar BootSignature.jar /boot boot_a..img keystore.pk8 keystore.x509.pem boot_a_signed.img
java -jar BootSignature.jar /boot boot_b..img keystore.pk8 keystore.x509.pem boot_b_signed.img
Reflash with fastboot:
Code:
fastboot flash boot_a boot_a_signed.img
fastboot flash boot_b boot_b_signed.img
Relock the bootloader (will erase device)
Code:
fastboot oem lock
One thing I have noticed is the fingerprint isn't displayed on boot, yet still starts up fine. Maybe it's because I didn't place the .pub key in ramdisk before signing? It could also be due to the use of CAF & not AOSP tools. In any case I got the pixel to boot yellow in a locked state after modifying the kernel.
I'm a newbie compared to you guys and I had problems running Java. I've unpacked the boot image and repacked it after modifications. I have also generated keys and I'm wondering if there is a script (Python?) that I can run to sign the boot image? Also, where should I copy the public key inside the ramdisk? This is for a 7.0.1 Nougat boot image of OnePlus 3. Thanks,
Unfortunately there is no other method that I have found to sign boot images with besides the BootSignature.jar in phhusson's repo. You could also setup a build environment but the method I described is magnitudes simpler. Both methods require java there is no python script to perform this. You put the .pub key at root of RAM disk renamed as verity_key. I think that's only required if you are using dm-verity and a generated tree for your system image.
What OS are you running? I did my signing in Ubuntu.
Was this tested on OnePlus 5 by anyone before?
Geofferey said:
Okay so I got this whole thing figured out. Just had to read stuff all over the place. Everything we need is in phhussons repo under the keystore_tools and the 6.0 CAF tree will suffice. I knew I was close.
BTW: I only recommend this for flawless ROMs with no major issues. Once re-locked DO NOT disable Allow OEM Unlock in the developer options menu unless you are 100% sure your phone will boot especially after /data wipes etc. Do not make modifications of any kind in a locked state with OEM unlock off. I learned the hard way with a 5X when I tried to dd a vendor.img via adb on a locked bootloader without TWRP. Don't do anything crazy! You have been warned!
Here is how you can re-sign after mods beofore re-locking a Pixel.
Grab boot images from android (needs root or twrp):
I actually used Android Terminal Emulator for this step
Code:
sailfish:/ # cd /dev/block/platform/soc/624000.ufshc/by-name
sailfish:/dev/block/platform/soc/624000.ufshc # dd if=boot_a of=/sdcard/boot_a.img
sailfish:/dev/block/platform/soc/624000.ufshc # dd if=boot_b of=/sdcard/boot_b.img
Generate Keystore:
Code:
./make_key keystore '/C=US/ST=California/L=Long Beach/O=Android/OU=Android/CN=Android/[email protected]'
openssl rsa -in keystore.pk8 -inform der -outform der -pubout -out keystore.pub.pk8
Sign the boot Images:
Code:
java -jar BootSignature.jar /boot boot_a..img keystore.pk8 keystore.x509.pem boot_a_signed.img
java -jar BootSignature.jar /boot boot_b..img keystore.pk8 keystore.x509.pem boot_b_signed.img
Reflash with fastboot:
Code:
fastboot flash boot_a boot_a_signed.img
fastboot flash boot_b boot_b_signed.img
Relock the bootloader (will erase device)
Code:
fastboot oem lock
One thing I have noticed is the fingerprint isn't displayed on boot, yet still starts up fine. Maybe it's because I didn't place the .pub key in ramdisk before signing? It could also be due to the use of CAF & not AOSP tools. In any case I got the pixel to boot yellow in a locked state after modifying the kernel.
Click to expand...
Click to collapse
Signing the boot image.
What does it actually do? From the semantics, it looks like it is signing the boot image with the generated private key.
How does the bootloader in the device know to trust the images(like recovery, system or roms) signed with this private key?
praveenkv1988 said:
Signing the boot image.
What does it actually do? From the semantics, it looks like it is signing the boot image with the generated private key.
How does the bootloader in the device know to trust the images(like recovery, system or roms) signed with this private key?
Click to expand...
Click to collapse
See the class B implementation of verified boot.
https://source.android.com/security/verifiedboot/verified-boot
The boot is signed with the key and it is verified against the included certificate. Yes, someone else could just sign the boot image with their key, but you can verify the fingerprint when the device boots to make sure it was signed with the correct key. This makes it tamper evident, not tamper proof.
The rom itself should use dm-verity to check the integrity at the block level. The boot image, which is signed, has the dm-verity public key so that the rom can be verified. Similar verification process can apply to recovery if it is signed and has dm-verity. Most don't, but it is certainly possible to do.
Since lineageos builds are signed by their private key, Can we just lock the bootloader after installing lineageos? Will it boot in yellow state?
praveenkv1988 said:
Since lineageos builds are signed by their private key, Can we just lock the bootloader after installing lineageos? Will it boot in yellow state?
Click to expand...
Click to collapse
On 14.1- the locked bootloader will show the yellow state and the LOS key fingerprint. But, if you don't lock down the recovery, there's little point in locking the bootloader. It also seems risky to lock the bootloader with a rom that is signed with a private key that you don't control. Depending on the phone, you night not be able to decrypt data in recovery (think backups).
On 15.1, I think things are more complex and this or related parts in LOS might not be working yet.
My bootloader is locked and I was trying to upgrade my n5x to 15.1 yesterday and all I got were bootloops. I reverted to 14.1 and recovered, but there are no guarantees.
Lastly, the way you asked the question makes me think you shouldn't lock you bootloader. Not trying to be mean or rude, but I am trying to prevent you from losing your data or being locked out of your phone. The hard part about locking the bootloader is that you can't use fastboot to flash things like radios, vendor images, etc.
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,
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