Database Info

Password Protect ADB?

Has anyone thought about implementing password protection to the G1's adb interface? If someone finds (steals) your phone, it' seems like they can get easy access to your data using adb if it is enabled? Instead of forcing the default to adb-debug disabled, it seems like requiring a password would be more useful?
I realize that this might be risky since it might prevent recovery when the password is forgotten, but at that point, there is still the "wipe all my data" unlock method right?
Without this, I find it hard to trust any sensitive data to my phone (since I do not want to toggle adb on/off constantly).

I agree with you any one who find our g1 or steal it, can find easy in the internet how to use adb, or they can even find out how you can do a wipe if you turn the phone off and start the phone using Home+Power button. And they will be good to go to use the G1. I hope someone can add a password protection to this 2 options.

I guess it might be nice to add a password option to the "wipe" option, but that seems like it would sorta defeat the purpose then, wouldn't it?
I am more concerned about my data than the device itself. If someone steals my phone and they can't use it, it doesn't really help me. But, if I can at least prevent them from reading my data... I envision using my phone as a secure token to access various logins at some point (anyone want to code that up? . So, I just want to ensure that they cannot get any keys/passwords on it.
The other problem with preventing someone from wiping it is, "what do you do if you forget your own password"? I would prefer to let the thief use the phone (without my data) than to potentially brick the phone for myself. Lastly, locking it permanently off to thieves would not be a deterrent to theft unless every phone did it since they would not know about it until they stole your phone!
I am surprised that the "serious" hackers have not implemented adb protection yet, have they?

Yea its kinda a good and bad thing tho. Look at it like this .
You put the password on your phone to stop people from doing anything to it, then you forgot your password, how do you get back in? You cant. Unless you have a way around that which if you have a way around that the thief would to.
The only thing i would like is to be able to protect files so if you lost your phone someone wouldn't be able to get into it without wiping the phone.

xile6 said:
Yea its kinda a good and bad thing tho. Look at it like this .
You put the password on your phone to stop people from doing anything to it, then you forgot your password, how do you get back in? You cant. Unless you have a way around that which if you have a way around that the thief would to.
The only thing i would like is to be able to protect files so if you lost your phone someone wouldn't be able to get into it without wiping the phone.
Click to expand...
Click to collapse
I agree with you and at the same time don't (right now I don't put personal files in my sd for that very reason if I lost the phone anyone can see what I have on the sd) regarding to the password I guess that it will be up to the people if you know that you forget passwords just don't use it I personally use 2 password 1 for forum 6 letter something simple and easy to remember, and one for (very important stuffs) 12 characteres letters and numbers. Plus I thing that everyone in that will be using this are people to frequent this forum wich I don't think they tend to forget passwords.

In order to gain access to program data (not applicable to sdcard), you still need to be either root, or to possess the userid of the particular program whose data you're trying to gain access to. Use of one of those secure-root password prompt programs will give you the ability to limit root access since the 'su' command will fail without the password being entered in the GUI.
This is not absolute though, since you can still boot on a recovery image, backup, and extract. Without actually encrypting the storage, there is no way to absolutely protect your data, and with a mobile device, the encryption/decryption overhead will take up too much CPU time to be practical. It could, however, be implemented on a program-by-program basis or on a data-but-not-program basis, i.e. encrypt /data/data, or /data/data-enc might be a better idea - leave data for user-programs encrypted, but system-services unencrypted, and mount the encrypted partition on screen unlock (i.e. password unlock). LUKS would be great for this. Allowing optional encryption for SD-card and allowing multiple SD-card partitions to be mounted (i.e. one encrypted, one not) would be ideal.

Well, perhaps the bootloader should get a password also? Would having both an adp and a bootloader passwords secure things completely?

Of course not. Bootloader passwords are virtually useless. All they do is stop you from booting, they do nothing at all to protect your data except from a real amateur, the likes of whom wouldn't be able to get your data off the thing even WITH root access.
As long as there is unencrypted data stored on the device, it definitely can be read off.

Could you please explain why you believe that a bootloader password would not work?
In other words, if a user is locked out from performing commands via the screen without the appropriate gesture, locked out from using adb without a password, and they cannot boot into the recovery image (or access NVRAM with fastboot) without a password, how can they access data on the internal NVRAM? I am not saying they can't (I don't know), I am asking what method you think they could use? Can the NVRAM be easily removed and plugged into another device and read? Are there other boot methods that I am not aware of (likely, I am fairly new to this) that would allow them to access the data? Or, are you just assuming that there is a method that an intelligent cracker could use?

1) you can use fastboot to boot off a recovery image file that is NOT ON THE PHONE,
2) you can connect directly to the chip and read its contents.
etc.
Keep in mind the way that bootloader passwords work; the password is NOT embedded in the bootloader - that would be stupid since you risk bricking the device every time you change the password. A password protected bootloader will access some configuration file that will have the details of the password. Fastboot would (and must) come before this stage.

It seems like you are pretty much just repeating/rewording the weaknesses already pointed out? I am not trying to be rude, if you do have some extra info, or there is something subtle that I am missing, please accept my apologies.
Specifically:
#1 should be assumed to be prevented by the bootloader password, no? Is there any reason you think this would not be effective?
As for #2, I was already asking if the NVRAM could easily be removed from the HTC? Do you have any useful info on this, on what it would take to do it? I assume this would require surface mount de-soldering?
My personal threat model would assume that my data is less valuable to a thief than my phone is. While I would prefer my data to not be easily acquired by a thief, I have nothing so secret that I would expect a thief to specifically steal my phone for it. Therefor, I assume that a thief has no incentive to destroy my phone (which he is in possession of and can use) just to get at my data. Of course, if there is an easy method to get my data (there currently are easy software methods), I would expect a thief to do so. I am hoping to close those easy software methods. If there are easy hardware methods, such as unplugging a chip or sdcard and simply inserting it into another phone, well, then perhaps the software holes are not worth plugging. But, any hardware hacks involving soldering (especially surface mount soldering) the phone are beyond my desire to foil.
Again, that is my personal objective, I understand if you do not share it. Can you think of any additional info that might be valuable with this in mind?
Thanks!

MartinFick said:
#1 should be assumed to be prevented by the bootloader password, no? Is there any reason you think this would not be effective?
Click to expand...
Click to collapse
No, bootloader password won't help you here, and I already explained why.
As for #2, I was already asking if the NVRAM could easily be removed from the HTC? Do you have any useful info on this, on what it would take to do it? I assume this would require surface mount de-soldering?
Click to expand...
Click to collapse
Sure, thats one way. The other way is by whatever mechanism HTC uses to initially write the bootloader to the device. I haven't looked, but there is probably a jtag port or something similar on it somewhere.
My personal threat model would assume that my data is less valuable to a thief than my phone is. While I would prefer my data to not be easily acquired by a thief, I have nothing so secret that I would expect a thief to specifically steal my phone for it. Therefor, I assume that a thief has no incentive to destroy my phone (which he is in possession of and can use) just to get at my data. Of course, if there is an easy method to get my data (there currently are easy software methods), I would expect a thief to do so. I am hoping to close those easy software methods. If there are easy hardware methods, such as unplugging a chip or sdcard and simply inserting it into another phone, well, then perhaps the software holes are not worth plugging. But, any hardware hacks involving soldering (especially surface mount soldering) the phone are beyond my desire to foil.
Again, that is my personal objective, I understand if you do not share it. Can you think of any additional info that might be valuable with this in mind?
Click to expand...
Click to collapse
Unfortunately, even if it were possible, securing it against that possibility isn't going to help you since the thief doesn't know that its worthless to him. He'll steal it anyways, and then garbage it when it turns out to be useless to him.

No, bootloader password won't help you here, and I already explained why.
Click to expand...
Click to collapse
Uh, no you didn't. You rambled on about the password being in some config file and therefore assumed that it would not be possible or desirable to actually implement a proper bootloader password. I do not accept this criticism, people reflash their bootloaders all the time and it is up to them to determine the level of "brick risk" they want. Perhaps you don't like it, that doesn't make things impossible.
As for putting the password in a config file somewhere, it is not the only solution, one could easily create a separate tiny partition just for the password if you did not want to put FS reading code into the bootloader. (That was your point, right? That the bootloader is simple and cannot read a filesystem?) Surely the bootloader knows how to read partitions, or how would it be able to boot the kernel? With this you could reduce most "brick risk" by providing a "boot from external kernel for recovery after wiping the partitions" option.
And, finally, perhaps there is some other minimal byte storage on the HTC Dream where a password could be easily stored? Something analogous to the CMOS of a PC, something the bootloader could easily read/write to change the password?
Sure, thats one way. The other way is by whatever mechanism HTC uses to initially write the bootloader to the device. I haven't looked, but there is probably a jtag port or something similar on it somewhere.
Click to expand...
Click to collapse
Valid concern, easy for someone with the right tools, and some very specialized expertise perhaps. I would be plenty happy to foil all thiefs who do not own such tools or have such knowledge, I believe those are the ones likely to steal my phone.
Unfortunately, even if it were possible, securing it against that possibility isn't going to help you since the thief doesn't know that its worthless to him. He'll steal it anyways, and then garbage it when it turns out to be useless to him.
Click to expand...
Click to collapse
Why is not going to help me? If he can't get my data (easily without desoldering), it helps me. I agree and already pointed out that it would not be a deterrent. Nowhere in my objective did deterrence come up.
You make some good points, points that are worthy of serious consideration for anyone attempting to implement this, but I would say that your points hardly make it impossible, in fact, they illustrate very well what a designer would need to consider! Thanks!

I never said that *anything* was impossible. I simply pointed out that IF the password was compiled into the bootloader, then THAT would be extremely dangerous since rather than trying out a tried and true bootloader, every change of password would be a serious brick-risk.
Regarding partition vs file, there is no difference. A partition *IS* a file in a very simple filesystem -- that which we refer to as a "partition table". As such, the risk is identical. I certainly did not suggest that a bootloader is incapable of reading a filesystem, the reverse is in fact, and MUST be true, since if the bootloader couldn't read the filesystem, then how is it to load something that is stored on said filesystem? The point is that if the filesystem were in some manner corrupted, overwritten, updated, etc., then so is your ability to boot the system PERMANENTLY, unless you maintain fastboot prior to the password, in which case it is trivial to boot off a different system image anyways, or unless you go to hardware level to unbrick the device, the same approach, of course, could be used by someone else to gain access.
Oh, and when you say "My personal threat model would assume that my data is less valuable to a thief than my phone is.", that suggests that your priorities are hardware first and then data.
I still say that the most feasible approach to this is selective encryption. Keep the important data from being accessed and not worry about the hardware, since there is no technical way to make it undesirable to a thief except, of course, to make it real ugly. Pack the thing into an old-style Palm case. Take a look into LUKS. It could *definitely* be made to work and is probably easier than you think. What you would have to do is first install support for it at the system level (that might require that you rebuild the kernel), encrypt a partition on the SDCARD with it, and link password, mount, and unmount into the lock screen. Once thats done, you just move and symlink important data onto the encrypted partition. For that matter, you don't even need to automate it with the lock screen, you can just write an app to password, mount, and unmount, or even run it from the terminal. Yes, this is just a linux device. This approach is barely more than trivial.

I never said that *anything* was impossible.
Click to expand...
Click to collapse
Sorry, the sentence below sounded like you were implying that it is was impossible.
No, bootloader password won't help you here, and I already explained why.
Click to expand...
Click to collapse
Oh, and when you say "My personal threat model would assume that my data is less valuable to a thief than my phone is.", that suggests that your priorities are hardware first and then data.
Click to expand...
Click to collapse
No, it suggests that those are the priorties of the thief. I don't believe a thief would steal my phone for its data. I accept that it can be stolen easily or that I might simply leave it on a table in a restaurant or something. At that point I would simply prefer that no one be able to easily snoop my personal affairs. Currently it is VERY easy. I had adb access to my phone before even using the screen, (I needed to register via wifi), it really is simple, it takes little expertise.
Regarding partition vs file, there is no difference. A partition *IS* a file in a very simple filesystem -- that which we refer to as a "partition table". As such, the risk is identical. I certainly did not suggest that a bootloader is incapable of reading a filesystem, the reverse is in fact, and MUST be true, since if the bootloader couldn't read the filesystem, then how is it to load something that is stored on said filesystem?
Click to expand...
Click to collapse
Call it what you will, I was giving you the benefit of the doubt.
Many bootloaders do not understand the filesystem they load from, they simply get a pre-created list of the disk blocks to load a kernel from and then load them and execute them.
The point is that if the filesystem were in some manner corrupted, overwritten, updated, etc., then so is your ability to boot the system PERMANENTLY, unless you maintain fastboot prior to the password, in which case it is trivial to boot off a different system image anyways, or unless you go to hardware level to unbrick the device, the same approach, of course, could be used by someone else to gain access.
Click to expand...
Click to collapse
For someone who seems to understand things well, you seem to willingly miss important points already mentioned:
With this you could reduce most "brick risk" by providing a "boot from external kernel for recovery after wiping the partitions" option.
Click to expand...
Click to collapse
You encryption points are well taken, they probably would be simple to implement, however they would likely have a significant performance impact.

MartinFick said:
You encryption points are well taken, they probably would be simple to implement, however they would likely have a significant performance impact.
Click to expand...
Click to collapse
Only if you're encrypting everything (i.e. programs). There is no reason to encrypt everything -- just encrypt the data you want to protect. There is no reason to bother encrypting apps that you install or the operating system since this is all available elsewhere. If you have private documents, emails, etc., keep those encrypted. The performance impact will be negligible since these files will be fairly small.

No way to require passphrase on startup!

I just got my pixel, and found two very bitter disappointments. First, as expected, even an unrooted device will not pass safetynet (i.e., let you run android pay) if you've unlocked the bootloader.
Second, however, and a bit more of a shock, there appears to be no way to require a passphrase on bootup. The option on the nexus 5X and 6P that you get while selecting a PIN simply does not exist. So does this mean there is basically no way to secure my phone?
This is doubly infuriating. On one hand Google wants to prevent me from learning my own device encryption keys, supposedly in the name of security. But then on the other hand, they reserve the right to extract my keys themselves if they ever sign a backdoored bootloader (that can extract the now unencrypted keys from firmware).
For me the whole benefit of the fingerprint reader has been that it lets me select a very long boot passphrase, since I don't have to type it to unlock the phone. However, I'm now seriously considering removing the PIN from my lockscreen so I don't delude myself into storing anything of value on my phone.
Am I the only one super annoyed at these security developments?

Mine asks for my pin on first login.

Moogagot said:
Mine asks for my pin on first login.
Click to expand...
Click to collapse
Yes, but by the time it prompts for a PIN, it has clearly already decrypted the flash storage. So this means that if your bootloader is unlocked, someone could have messed with your system partition to bypass the lockscreen.

15xda said:
Yes, but by the time it prompts for a PIN, it has clearly already decrypted the flash storage. So this means that if your bootloader is unlocked, someone could have messed with your system partition to bypass the lockscreen.
Click to expand...
Click to collapse
That's not true. With device encrypted data and Direct Boot enabled, this restricted mode allows apps to perform limited actions and access non-personal data (i.e. specific system files), allowing it to boot up to the lock screen securely without any user interaction.
You have to enable it though, by going to developer options and selecting "covert to file encryption”. This WILL perform a factory reset though.

msaitta said:
That's not true. With device encrypted data and Direct Boot enabled, this restricted mode allows apps to perform limited actions and access non-personal data (i.e. specific system files), allowing it to boot up to the lock screen securely without any user interaction.
You have to enable it though, by going to developer options and selecting "covert to file encryption”. This WILL perform a factory reset though.
Click to expand...
Click to collapse
There is no "convert to file encryption" option in the developer options on the Pixel. Anyway, since the lock screen shows personal images and notifications and such, clearly a lot of data is available if someone decrypts the file system, even if there were an option to double-encrypt a few individual sensitive files. Anyway, what are the chances that every app developer encrypts every file I care about? This is why I want full device encryption, and I want full device encryption without storing my keys someplace where a backdoored bootloader can get at them.

15xda said:
Anyway, since the lock screen shows personal images and notifications and such, clearly a lot of data is available if someone decrypts the file system, even if there were an option to double-encrypt a few individual sensitive files.
Click to expand...
Click to collapse
Well, I stand partially corrected, actually. The device definitely seems to show some of my settings on reboot, like, for instance, volume. On the other hand, it can't receive VOIP calls (suggesting it doesn't have access to the SIP password I configured in the dialer), and incoming mobile calls don't show the contact name. So I guess it does offer some protection, but it's much harder to figure out what.

In case anyone lands on this thread, here is an explanation of what is happening on bootup:
https://developer.android.com/training/articles/direct-boot.html
The short answer is Pixel uses file-based-encryption now instead of disk-based encryption. I'm still not happy about this design because it somewhat reduces privacy and potentially complicates examining applications as root, but it's not as bad as I originally throught.

Some Security questions

Hello guys, i have a few question that i would like to ask.
My boss is considering S8 as his new phone and he need to know about device security.
1.If you encrypt device how tough it is for police to open it?
No criminal activity done but police is part of the fight between companies. And it is the cheapest fighting method.
2.Is it possible to wire the phone without hardware mod?
Like for example using some sort of wireless method or wireless activation of cam or microphone?
3.If i turn on wipe device after 10 bad password attempts is it wiped completely without any possible way of recovery?
There will be no SD card used. Only internal memory.
4.What is safer? S8 or iPhone 7 Plus
5.Can there be software sent and installed to phone without user interaction?
Thank you so much for your answers.

It's impossible to directly crack the phone's encryption if you use a secure password. The SD card can be securely encrypted as well. Biometric unlocking is less secure, if you set that up (though if you shut the phone down, only the password will unlock it). There is an option to have the phone wiped after multiple failed password entries, but that gives no extra protection from serious attackers who can copy the phone's storage and work from the copy rather than the original. So you need a secure, unguessable password.
Courts may be able to compel you to unlock your phone (or jail you until you comply). Different jurisdictions have different (and changing) rules on the matter.
All phones are designed with strong measures against installing malware. And the S8's Secure Folders feature adds another layer of safety. Nonetheless, vulnerabilities are discovered all the time. They're patched by monthly security updates, but new ones still pop up. So it's impossible to guarantee the absence of malware (including malware that uses the microphone). Empirically, however, it appears to be quite rare for a modern phone, with up-to-date patches and other best security practices, to be seriously compromised.
But of course your boss will need to do their own research and verify all these claims from reliable sources, not from unknown people on an internet forum.

Why does Android reset the device upon RE-LOCKING the bootloader?

Why does Android reset the device to factory settings upon RE-LOCKING the bootloader on Pixel devices? is it just another hassel tactic from Google to make users not have the bootlader unlocked in the first place?
Please don't respond unless you have an answer with a real technical/security justification.
Thanks for your expertise.

fromusofa said:
Why does Android reset the device to factory settings upon RE-LOCKING the bootloader on Pixel devices? is it just another hassel tactic from Google to make users not have the bootlader unlocked in the first place?
Please don't respond unless you have an answer with a real technical/security justification.
Thanks for your expertise.
Click to expand...
Click to collapse
This link has some explanation of bootloader locking and unlocking, and the security side of things (scroll down to near the bottom).
https://source.android.com/security/overview/implement
It doesn't really do much to explain in detail why the relock requires a factory reset, but essentially it's to ensure that there is nothing in the phone that could have been compromised. When the bootloader is locked, certain app developers want to be sure that the device is secure. Any leftover remnants from a rooted device are a potential security issue.

NZedPred said:
This link has some explanation of bootloader locking and unlocking, and the security side of things (scroll down to near the bottom).
https://source.android.com/security/overview/implement
It doesn't really do much to explain in detail why the relock requires a factory reset, but essentially it's to ensure that there is nothing in the phone that could have been compromised. When the bootloader is locked, certain app developers want to be sure that the device is secure. Any leftover remnants from a rooted device are a potential security issue.
Click to expand...
Click to collapse
The link does not say that the device will be reset and the user data will be wiped upon relocking the bootloader. it just says that it will provide the same protection after locking the device upon installing any custom rom and then unlocking it again.
Who gets to say what is "compromised"? The OS provider Google or the device manufacturer or the users who have paid for the software and the hardware of the device and owns it?
if those certain armatures app developers can't write their own stuff secured enough and actually depend on OS to provide them protection at the expense of crappy user experience with limited innovation and hijacked creativity, then that's their problem. An owner of the device should be able to install any OS even that they may have build in their basement or any jack **** they want...or live with the crap that they got from OEM . Just like Windows on any computer can let you do what ever you want to do as an administrator...whichever sites and application you want to access and run. Why is Android (linux) so overtly protective about giving root access to its users?
Anyway, relocking the bootloader will wipe the device again even if you have not installed anything customized even immediately right after unlocking that has already wiped the device...I just don't understand or like the logic behind resetting the whole device upon relocking the bootloader...is Google afraid of people coming after them for security issues on their customized/rooted device? hmmm... if that was the case with Windows, Microsoft would've been bankrupted long ago.
sorry about the above rant, I just woke up after 18 years in coma and I find the mobile device industry still in its infancy... or maybe I just have lost my mind.

IS UNLOCKED BOOTLOADER LESS SECURE/HOW TO MAKE SECURE?

In what ways does having an unlocked bootloader make it easier for governments and (other) criminals to get into your device or data? Lots of people say "naaaaa it's not less secure, unlock your bootloader man... the data is ENCRYPTED" I know back in the day someone could just flash TWRP and delete the lockscreen! But now devices are encrypted and that can't be done anymore. I also experience that some security apps require root for their full features (Android Lost). But I'd think it'd be easier to inject some sort script or flash something to help them with trying to get into your device (like removing the unlock attempt limit like is done with iPhone). Luckily Oneplus can relock with custom ROM but most can't ) : .
If you wanna talk about specific devices, maybe talk about Xperia Z5 II and/or LG G8 Thinq. And whether it IS or ISN'T less secure, what can be done to BEST secure a device? Whether official or not.

A device with a locked bootloader will only boot the operating system currently on it. You can’t install a custom operating system – the bootloader will refuse to load it. If your Android phone has a standard locked bootloader when a thief gets his hands on it, he won’t be able to access the device’s data without knowing its PIN or password. (Of course, a very determined thief could crack open the phone and remove the storage to read it in another device.)
If you’re unlocking the bootloader of your device and want to protect against this, you could choose to enable Android’s encryption feature what dependes on Android version - either FBE ( default since Android 10 ) or FDE ( default since Android 6 ). This would ensure your data is stored in an encrypted form ( AES 256 ), so people wouldn’t be able to access your data without your encryption passphrase. However, even encryption can’t protect your data perfectly.
Conclusion:
Of course, you probably don’t need to worry about this too much. If you’re an Android geek installing custom ROMs and rooting your device for your own use, you probably aren’t going to be the target of a determined and skilled thief who wants to access the data on your device. If your device is stolen, it’s probably by someone who just wants to wipe the device and sell it. And this wiping can easily be done by connecting the Android phone via USB--cable with PC and from there launching a specific command.