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.
Related
Does anyone know if it would be possible to bake in security like Wave Secure type of thing in to custom ROMs? I've always thought Wave Secure is a bit pointless if a simple factory reset would clear it and therefore leave the phone ready for the thief or new owner to use as they see fit.
Another layer, not perfect, but still another layer that a thief or finder may not be immediately aware of would be to bake in some security features like tracing or locking in to a custom ROM so even a factory reset wouldn't remove it, possibly something in to the boot loader itself?
Has anyone thought of this?
DroidBois said:
Does anyone know if it would be possible to bake in security like Wave Secure type of thing in to custom ROMs? I've always thought Wave Secure is a bit pointless if a simple factory reset would clear it and therefore leave the phone ready for the thief or new owner to use as they see fit.
Another layer, not perfect, but still another layer that a thief or finder may not be immediately aware of would be to bake in some security features like tracing or locking in to a custom ROM so even a factory reset wouldn't remove it, possibly something in to the boot loader itself?
Has anyone thought of this?
Click to expand...
Click to collapse
People do and have bundled things into roms - often dropping them into /system/app directory, though I don't think anyones gone as deep as into the bootloader?
Though, if your phone is rooted, and your installed the app to /system/app, then a thief could in theory just flash your phone faster than if your phone WASNT rooted. They don't even need to root your phone at that point.
An interest aspect of hardening this, might be to compile your on recovery/bootloader that would require a password to get into.
I think what he's saying is to add the wave secure or similar app into the ROM so that if the thief does a quick "reset to factory settings" after lifting the phone, the security app would survive, perhaps long enough to recover it.
Most thieves would just wipe the phone (if that) to flip it and might not take the time to flash a new ROM.
The tough pay as I see it would be everyone would need their own custom ROM.
Sent from my SPH-D700 using XDA App
Xerloq said:
I think what he's saying is to add the wave secure or similar app into the ROM so that if the thief does a quick "reset to factory settings" after lifting the phone, the security app would survive, perhaps long enough to recover it.
Most thieves would just wipe the phone (if that) to flip it and might not take the time to flash a new ROM.
Click to expand...
Click to collapse
Yep, that's it. I'm assuming most thieves would not recognise a custom ROM or know what to do with it. At least buy some time to try and locate and recover the phone. Only time I'd want a front facing camera.
So what happens if they replace the SIM though? Sending SMS's is nice, but only if your number is still working with that phone. A hard baked security system would send an SMS when the SIM was changed at least.
You shouldn't make a ROM to put an apk into /system/app. You can simply push it through ADB or via terminal emulator. That will atleast survive a factory reset. I don't think many thieves actually take the time to flash a new image
So this is all we need to do? Use the ADB method? So I push through WaveSecure, that could survive a factory reset with settings intact?
Something baked in to recovery would be awesome too.
as far as I know when pushing an apk via adb into system/app then only the app itself is stored there, not the settings. the settings are gone after a system wipe. there needs to be some logic in the app to connect to a site and retrieve your settings from there... using your phone's ID or something.
RAMMANN said:
as far as I know when pushing an apk via adb into system/app then only the app itself is stored there, not the settings. the settings are gone after a system wipe. there needs to be some logic in the app to connect to a site and retrieve your settings from there... using your phone's ID or something.
Click to expand...
Click to collapse
The application itself will survive - but wouldn't all it's data, which still resides in /data/data be wiped?
So yes... the app survived... But it no longer knows who you are, or whose phone it is.
I think the just release CDMA/GSM Droid Pro may have the security you are looking for?
tbaker077 said:
I think the just release CDMA/GSM Droid Pro may have the security you are looking for?
Click to expand...
Click to collapse
It's a bit extreme to fork out another $700 on a new phone just for this. The whole point is to avoid spending money in case of theft or loss
Well part of my unspoke point is this is XDA-Developers, I sure there is a ways(one the rom comes out) to port some of those security files to other Android devices.
tbaker077 said:
Well part of my unspoke point is this is XDA-Developers, I sure there is a ways(one the rom comes out) to port some of those security files to other Android devices.
Click to expand...
Click to collapse
Didn't quite understand you, are saying it is possible to bake in some security?
I think once the Droid Pro, which has it baked in, is either rom dumped and extracted, or rooted then I think it could be possible.
tbaker077 said:
I think once the Droid Pro, which has it baked in, is either rom dumped and extracted, or rooted then I think it could be possible.
Click to expand...
Click to collapse
So something *is* possible via software, not requiring special hardware?
Once some gimboid puts in their own SIM you'd think that you can't send an SMS to control the phone although WaveSecure seems to cover that too.
I'd like something as subtle and as invisible as a good virus. Bootloader would be ideal. Theoretically then a full factory wipe wouldn't clear it.
I couldn't tel you. All I know is the Droid Pro is a 3G CDMA. GSM device with some special enterprise security features/software aimed at the BB users.
Doesn't really help us then if that's only available on the Droid Pro.. For the rest of us we still need to work out how to bake in WaveSecure or, ideally, something very subtle. If someone takes my phone I want to nail the little turd, or at least embarrass him when the phone siren goes off or he gets a loud spoken message or something.
Another point, with IMEI numbers, is this of any use if you bought your phone outright? I.e. if my phone is stolen, I can't get the IMEI blocked can I? And can IMEI numbers be changed?
This may meet your needs/requirements. It is called lookout mobile.
https://www.mylookout.com/
I know Paul at Modaco bakes wavesecure into his roms.. not sure if the data would survive a wipe but then whats the point of baking it in system if it doesn't right? Check it out:
Version R9: (requires membership)
http://android.modaco.com/content/h...-rom-for-htc-desire-online-kitchen-2-2-froyo/
R8: (Free for all)
http://android.modaco.com/content/h...for-htc-desire-with-online-kitchen-2-2-froyo/
Okay.. Just found out. This explains everything!
https://www.wavesecure.com/blog/how-to-make-wavesecure-hard-reset-proof.aspx
Hey there. Can't find any info about encryption and what it brings, so I'll just fire away a few questions about details for that matter. Not that I'm so obsessed with security, more like just curious about the possibility. And keeping things under protection is nice when dealing with business stuff.
What encryption brings? Only data in encrypted, or apps/system too?
Would someone be able to get something from TF by connecting it to a PC? Or he will fail even using ADB or nvflash?
How secure we're speaking about? Any info on encryption method and key length in bits.
If I forget my password, or any other weird thing happen, could I reset it with nvflash, loading new clean images? Maybe encrypted volumes are handled differently, and it's not so easy...
Clockwork Recovery. Would it work perfectly fine with encrypted tablet?
Custom ROMs (like Prime!). Any possible problems when messing with system files without total wipe?
Performance. How bad it could be affected? I'm not sure Tegra2 has RSA-optimized module built-in (or whatever method it's using).
Unlocking. Will I be prompted to enter password every time I see unlock screen, or only when I reboot?
Any known limitations, like password length (I like to set long passwords, it's more efficient and easier to remember).
Bump - heard that HC 3.2 enabled encryption at last. Anyone tried it and can answer any of my questions?
Never done it myself, but from information I read:
tixed said:
Hey there. Can't find any info about encryption and what it brings, so I'll just fire away a few questions about details for that matter. Not that I'm so obsessed with security, more like just curious about the possibility. And keeping things under protection is nice when dealing with business stuff.
What encryption brings? Only data in encrypted, or apps/system too?
Would someone be able to get something from TF by connecting it to a PC? Or he will fail even using ADB or nvflash?
How secure we're speaking about? Any info on encryption method and key length in bits.
If I forget my password, or any other weird thing happen, could I reset it with nvflash, loading new clean images? Maybe encrypted volumes are handled differently, and it's not so easy...
Clockwork Recovery. Would it work perfectly fine with encrypted tablet?
I guess this should be fine.
Custom ROMs (like Prime!). Any possible problems when messing with system files without total wipe?
Performance. How bad it could be affected? I'm not sure Tegra2 has RSA-optimized module built-in (or whatever method it's using).
I read that this would have lesser performance since it has to be decrypted on fly and also affects battery.
Unlocking. Will I be prompted to enter password every time I see unlock screen, or only when I reboot?
I guess every time when you unlock.
Any known limitations, like password length (I like to set long passwords, it's more efficient and easier to remember).
Click to expand...
Click to collapse
I found THIS little tid bit after a Google search.
I do know that it does NOT encrypt your removable MicroSD card or SD card. The encryption can take a considerable amount of time to encrypt all your data (1 to 3 hrs and has to be powered on and at 100%). It will require a PIN or Password prompt at power on and possibly for other data sensitive action. It will also allow for password mining which is the process by which you are required to reenter a new password after so long. Also once you encrypt the only way back is a factory reset. If you lose your PIN or Password your SOL about getting your sensitive data back.
You might be better off using an app that can encrypt individual files that you choose.
Cheers...
tixed said:
What encryption brings? Only data in encrypted, or apps/system too?
Would someone be able to get something from TF by connecting it to a PC? Or he will fail even using ADB or nvflash?
How secure we're speaking about? Any info on encryption method and key length in bits.
If I forget my password, or any other weird thing happen, could I reset it with nvflash, loading new clean images? Maybe encrypted volumes are handled differently, and it's not so easy...
Clockwork Recovery. Would it work perfectly fine with encrypted tablet?
Custom ROMs (like Prime!). Any possible problems when messing with system files without total wipe?
Performance. How bad it could be affected? I'm not sure Tegra2 has RSA-optimized module built-in (or whatever method it's using).
Unlocking. Will I be prompted to enter password every time I see unlock screen, or only when I reboot?
Any known limitations, like password length (I like to set long passwords, it's more efficient and easier to remember).
Click to expand...
Click to collapse
Had a brief experience with encryption before I wiped back to stock. I would strongly recommend against it unless you wish to stick to a stock system and very much need that type of security. From what I remember of my experience:
The data partition is encrypted (not sure what else, but not MicroSD). When your device boots, a prompt that somewhat resembles a lockscreen pops fairly early on when the OS attempts to mount those partition(s). Thereafter, everything is accessible as usual; you can grab things via ADB. You do not have to constantly enter the password (though you would probably want to lockscreen your device as general good practice). As to what nvflash would get you, I'm not sure, since that would be before the partition mount...probably nothing usable. The problem with having an encrypted partition is that CWM at moment can't really do anything useful to those partitions. You cannot flash, backup, or restore via CWM. This means your ability to work with custom ROMs is effectively crippled. In fact, to undo the encryption (or if you forget your password), I had to nvflash back to stock. Factory reset via CWM cannot be done since, again, the partitions are still encrypted.
If in the future, CWM is able to access the partitions like the stock recovery can, then you'd be fine. Performance was not noticeably slower in anyway.
Thanks for the replies. This feature seems pretty grim at the moment. Well, we can all hope that Google and ASUS will update it properly. At least, they did a lot of good updates recently.
I have thus far been unable to find the information I'm looking for in regards to full disk encryption for Android. When you encrypt the drive, Android uses the same password used for unlocking your phone. There are methods out there to defeat the lock screen. Does this bypass encryption as well?
I assume that if it's really encrypted then getting around the lock screen without the appropriate password/key combination would result in you being unable to access the data. If this is not the case then the question becomes whether or not the data can be considered encrypted while the hard drive remains on the phone.
Anyone have any practical knowledge of this, and of whether the key for turning the phone on is the same as for unlocking the phone? I would appreciate any input toward this discussion. Thank you!
-E
emccalment said:
I have thus far been unable to find the information I'm looking for in regards to full disk encryption for Android. When you encrypt the drive, Android uses the same password used for unlocking your phone. There are methods out there to defeat the lock screen. Does this bypass encryption as well?
I assume that if it's really encrypted then getting around the lock screen without the appropriate password/key combination would result in you being unable to access the data. If this is not the case then the question becomes whether or not the data can be considered encrypted while the hard drive remains on the phone.
Anyone have any practical knowledge of this, and of whether the key for turning the phone on is the same as for unlocking the phone? I would appreciate any input toward this discussion. Thank you!
-E
Click to expand...
Click to collapse
So, to be clear, any encryption can be bypassed. If the password is weak, then there is no issue and can be done in no time, if the password is strong (capital letters, numbers, symbols), then a brute-force attack can take years! Said that, you have to understand that Android devices has weaknesses, like every other device, and out there are also companies that guarantee they can decrypt any android device. Another way to decrypt an Android device is freezing the device at -10c (yes physically and no is not a joke). Researchers has demonstrated that if you freeze the device, and quickly disconnected and reconnected the battery will put the device in a vulnerable loophole. Even if encryption means data altering, and it requires a key to access/restore the data, this behavior probable occurs because the low temperatures causes data to fade from internal chips more slowly. That way is possible to obtain encryption keys and unscramble the phone's encrypted data. So, to reply to your question, yes, someone with enough knowledge can bypass your encryption.
Hey, thank you for your response! I read the article about bypassing encryption by slowing the rate of RAM fade and using FROST. I have a few minor follow on questions about that, however I'm not terribly concerned with tracking that down. I'm doing some research for a project, and I've just run out of time basically, so I can't try everything.
So, I know that it can be bypassed. I also know that you can run a kernel called Armored that supposedly keeps the keys for your encryption on the CPU instead of RAM, which supposedly shuts down cold boot attacks. I think that's a bit extreme for everyday situations, but it's there. I'm more curious about the authentication mechanism for the encryption I guess. It's ran through AES128, then salted with SHA, if I remember what I read. So without encryption, if you bypass the password, you're in. I'm curious, if you were to be able to bypass the encryption password (without actually getting it right). Would the system let you in, but leave everything encrypted and unreadable since you didn't provide the appropriate credentials?
-E
emccalment said:
Hey, thank you for your response! I read the article about bypassing encryption by slowing the rate of RAM fade and using FROST. I have a few minor follow on questions about that, however I'm not terribly concerned with tracking that down. I'm doing some research for a project, and I've just run out of time basically, so I can't try everything.
So, I know that it can be bypassed. I also know that you can run a kernel called Armored that supposedly keeps the keys for your encryption on the CPU instead of RAM, which supposedly shuts down cold boot attacks. I think that's a bit extreme for everyday situations, but it's there. I'm more curious about the authentication mechanism for the encryption I guess. It's ran through AES128, then salted with SHA, if I remember what I read. So without encryption, if you bypass the password, you're in. I'm curious, if you were to be able to bypass the encryption password (without actually getting it right). Would the system let you in, but leave everything encrypted and unreadable since you didn't provide the appropriate credentials?
-E
Click to expand...
Click to collapse
Encryption is carried out at boot time. After the device has booted, a lockscreen bypass will yield full access to the device's data. Encryption only protects your data when the phone isn't turned on, effectively. Or if you know the adversary won't be able to bypass the lockscreen, and would end up rebooting it without knowing it was encrypted.
pulser_g2 said:
Encryption is carried out at boot time. After the device has booted, a lockscreen bypass will yield full access to the device's data. Encryption only protects your data when the phone isn't turned on, effectively. Or if you know the adversary won't be able to bypass the lockscreen, and would end up rebooting it without knowing it was encrypted.
Click to expand...
Click to collapse
@pulser_g2 +++
Or if you have a tracking software that allows you to shut down your phone remotely... But in that case you may as well wipe your phone remotely.
Hey!
It's my first post here so it this isn't the best place for such a question then by all means mods pls move the thread to where it should be
Basically, where I'm currently living (Brazil), things tend to get pretty violent and phone thefts are very common. Now the thing is, if it's an iPhone usually the thieves just throw it away, as once it's locked it becomes useless. When it comes to Android though, some of them will dig deep trying to access your info like pictures, passwords, bank information, among other things. They even manage to break IMEI locks and stuff. I got my S5 stolen recently and the information theft part put me through hell. Yet, I'd much rather have an S8+ then any other iPhone currently, so my question is how could I completely theft proof it?
I'm not really worried about them restoring the phone and reselling it, more about them accessing the data inside of it. I know the SD card can be protected through cryptography (although would accept "stronger" tips if there are any). When it comes to apps, aside from the basics of trusting what you install and stuff, are apps like Cerberus, Knox 2.0, or other Samsung features I'm not aware of, any good against someone who knows what they're doing? Is there a way to disable airplane mode or power offs? Also what is probably my strongest concern: is there a way to completely not allow system changes through a computer, like the one that removes the lock screen?
Being a programmer and computer science undergrad student (although not specializing in security nor mobile), I'd have no problem if the solutions would involve some coding or tweaking, just as long as they prove to be effective.
So, would you guys have any tips on how to completely secure the data given those concerns?
The sd card can be Encrypted and if you have a password lock (fingerprint irsi etc...) then it will ask for that before it will unlock the phone.
Also they have a remote wipe. You can log i to google and remote wipe your phone when you found out its been stolen.
You can set the phone to require a password to decrypt it when it's restarted. You can encrypt the SD card too. You can set it to lock instantly when the screen turns off. And you can use only a password to unlock it (no biometrics), which is the most secure option (if you use a suitable password). Finally, you can set the phone so that you can wipe it remotely, or to wipe itself after a number of consecutive incorrect password attempts. But even without the last two measures, your data will be unreadable without your password.
Unfortunately, though, if thieves are violent enough, they may be able to coerce you into divulging the password. If they succeed, they have full access to your phone.
Gary02468 said:
You can set the phone to require a password to decrypt it when it's restarted. You can encrypt the SD card too. You can set it to lock instantly when the screen turns off. And you can use only a password to unlock it (no biometrics), which is the most secure option (if you use a suitable password). Finally, you can set the phone so that you can wipe it remotely, or to wipe itself after a number of consecutive incorrect password attempts. But even without the last two measures, your data will be unreadable without your password.
Unfortunately, though, if thieves are violent enough, they may be able to coerce you into divulging the password. If they succeed, they have full access to your phone.
Click to expand...
Click to collapse
What about stuff like that Dr. Fone Toolkit that supposedly removes the lock screen? From the quick look I took it seems it somehow patches the Android on the phone to remove the lock screen. Is there some sort of system encryption/lock to avoid that kind of stuff when connected to a computer?
xile6 said:
The sd card can be Encrypted and if you have a password lock (fingerprint irsi etc...) then it will ask for that before it will unlock the phone.
Also they have a remote wipe. You can log i to google and remote wipe your phone when you found out its been stolen.
Click to expand...
Click to collapse
Usually they just put it on airplane mode though, so google remote wipe is useless... Which is why I was looking for more of an offline fix through cryptography and such
I use smart Lockscreen protector to prevent somebody putting my phone to airline mode or shutting it down ( It won't help phones with removable battery)
If you have the phone encrypted and have the require pin on boot set. And you have the Qualcomm version that is locked down you have nothing to worry about.
Even the iPhone 7 has been jail broken or rooted the S8 with the Qualcomm chip is one of only a few phones that have not been hacked. It's actually WAY more secure than an iPhone.
lvrma said:
What about stuff like that Dr. Fone Toolkit that supposedly removes the lock screen? From the quick look I took it seems it somehow patches the Android on the phone to remove the lock screen. Is there some sort of system encryption/lock to avoid that kind of stuff when connected to a computer?
Click to expand...
Click to collapse
The phone is completely encrypted, so if you set it to require a password to restart and to turn the screen back on, then its contents are unreadable without the password regardless of how you connect to it.
lvrma said:
...
Usually they just put it on airplane mode though, so google remote wipe is useless... Which is why I was looking for more of an offline fix through cryptography and such
Click to expand...
Click to collapse
If you have a lock screen set you can lock the status of your phone(wifi state, airplane mode, power settings). This way you have to unlock it to toggle these modes.
I just ran across this, some good advice.
http://thedroidguy.com/2017/04/setu...security-features-tutorials-1071462#Tutorial1
lvrma said:
What about stuff like that Dr. Fone Toolkit that supposedly removes the lock screen? From the quick look I took it seems it somehow patches the Android on the phone to remove the lock screen. Is there some sort of system encryption/lock to avoid that kind of stuff when connected to a computer?
Click to expand...
Click to collapse
Like you, I'm interested with this topic, but unlike you, I would like the theief to have a useless phone if they cant unlock it. So that they would think twice the next time they want to steal an android. Else they would just continue stealing since you just put the phone on download mode, connect to a computer and root it.
About your question. Isnt disabling usb debugging mode on developer option block that risk? Also in my note 4, enabling knox will prevent your device from being rooted, at least thats what i understand from the description. i wonder where it is in s8.
speaking of knox, s8 has "Secure folder". its like a secured environment within a phone. Everything you put in here will be protected by knox. Apps, accounts, files, etc. And it would ask for another security to access it(pattern/pin/password).
lvrma said:
Usually they just put it on airplane mode though, so google remote wipe is useless... Which is why I was looking for more of an offline fix through cryptography and such
Click to expand...
Click to collapse
you mentioned cerberus app, it has a function than can wipe device memory and wipe sd card via SMS command. so if you are fast enough, while the thief is running away and before he pulls out your sim card from the phone, you can send an sms command to wipe data.
Since you mentioned you are a programmer, this may be interesting to you, locking download mode and recovery mode on android to prevent thief from flashing hack to your phone. but this require a bit of patience if android isnt your forte.
https://ge0n0sis.github.io/posts/20...-mode-using-an-undocumented-feature-of-aboot/
BratPAQ said:
Like you, I'm interested with this topic, but unlike you, I would like the theief to have a useless phone if they cant unlock it. So that they would think twice the next time they want to steal an android. Else they would just continue stealing since you just put the phone on download mode, connect to a computer and root it.
About your question. Isnt disabling usb debugging mode on developer option block that risk? Also in my note 4, enabling knox will prevent your device from being rooted, at least thats what i understand from the description. i wonder where it is in s8.
speaking of knox, s8 has "Secure folder". its like a secured environment within a phone. Everything you put in here will be protected by knox. Apps, accounts, files, etc. And it would ask for another security to access it(pattern/pin/password).
you mentioned cerberus app, it has a function than can wipe device memory and wipe sd card via SMS command. so if you are fast enough, while the thief is running away and before he pulls out your sim card from the phone, you can send an sms command to wipe data.
Since you mentioned you are a programmer, this may be interesting to you, locking download mode and recovery mode on android to prevent thief from flashing hack to your phone. but this require a bit of patience if android isnt your forte.
https://ge0n0sis.github.io/posts/20...-mode-using-an-undocumented-feature-of-aboot/
Click to expand...
Click to collapse
Don't put your phone anywhere besides your pocket. Get a cover that makes it look like as different phone with a cracked screen.
the easiest way to encrypt sd and phone, enable adoptable storage.
cantenna said:
the easiest way to encrypt sd and phone, enable adoptable storage.
Click to expand...
Click to collapse
How is that easier than just selecting the Settings options to encrypt the SD card and to require a password to unlock upon restart?
---------- Post added at 06:08 AM ---------- Previous post was at 05:11 AM ----------
lvrma said:
Usually they just put it on airplane mode though, so google remote wipe is useless[.] Which is why I was looking for more of an offline fix through cryptography and such
Click to expand...
Click to collapse
Yes, and even without airplane mode, they can physically enclose the phone to block all electronic signals. Encrypting the phone (and SD card), using a secure password as the sole unlock method, affords the strongest protection against all attacks (except coercing the password from you).
Gary02468 said:
How is that easier than just selecting the Settings options to encrypt the SD card and to require a password to unlock upon restart?
---------- Post added at 06:08 AM ---------- Previous post was at 05:11 AM ----------
Yes, and even without airplane mode, they can physically enclose the phone to block all electronic signals. Encrypting the phone (and SD card), using a secure password as the sole unlock method, affords the strongest protection against all attacks (except coercing the password from you).
Click to expand...
Click to collapse
oh yea, may bad, i often assume everyone on xda is here because there interested in unlocked boot loaders, root and custom kernels. My recomindation applies only to people who have unlocked pandor's box only.
the method of encyption you suggested the isnt availble for users like me but we can enable adoptable storage which does encrypt the system by other means and it is compatible with root, etc
dynospectrum said:
Don't put your phone anywhere besides your pocket. Get a cover that makes it look like as different phone with a cracked screen.
Click to expand...
Click to collapse
Where can you get/ how can you make such a cover?
Also sometimes when I'm in bad Areas, I go to developer options and turn on some of the screen update stuff, so it flashes the screen purple a lot and make it look messed up.
There are many sites selling Mix 3's some Chinese, some Global, some with locked bootloaders, and some with unlocked bootloaders, this thread is to help people "protect" the devices they have bought (or will buy).
It's through my understanding that the most "secure" way of protecting your phone & data from thief's is to have your bootloader locked, with no custom recovery, encryption on & usb debugging disabled right?
This is because with a unlocked bootloader, the thief has the ability to boot into TWRP (for example) & simply wipe your pin/password/lock off the phone completely, then just boot it up, factory reset it & sell it.
I know there is methods such as putting the phone in cold temperatures so you can retrieve the encryption keys from the RAM, but assuming the thief is just basic & what's to make some quick money off your phone...So...
What's the best way & most recommended thing to do with Xiaomi devices specifically, locked/unlocked, encrypted/not-encrypted, does it matter?, If not, why not?
Any help is appreciated! The more in-depth the better.
Even with a locked bootloader a thief can hold VolUp while booting, wipe phone and sell it. Wiping is possible in any case and thats not even the issue a stolen Phone is gone.
The issue are your data which can be stolen too when you have a unlocked bootloader. Simply boot to twrp connect usb and copy everything. But you can prevent that with encryption and enable "requires pattern to start". That way if your phone gets stolen the thief can still Install/use Twrp but he needs to enter a pattern to decrypt the storage. If he doesnt, twrp wont be able to read the partition and your data is safe. He can still wipe the Phone and sell it but you cant prevent that. I don't know if the pattern generates the encryption keys or retrieves them from somewhere but i'd assume it generates them, probably together with some device specific values, else that would be a flaw in my book. If someone could enlighten me here that'd be nice.
If your bootloader is locked he also can't access your data. Since stock recovers doesn't allow/support Usb-filetransfer. So a lockpattern is all you need there. Encryption shouldnt really matter against the normal thief.
I am going this way: Unlocked bootloader to get rid of Miui, Twrp to have a proper recovery menu, and encryption+pattern to save my data. Disable USB-Developer Options to prevent adb shenanigans.
But on the hand if you wan't to get really panariod a locked bootloader would be better since you still can read the system image from the phone from twrp, this means, and this is a easy way to do it, you could read it copy it to the pc and simply brutefroce the lockpattern. If you have the partitions you can simply try 3 patterns either it works or the phone locks itself up because you did 3 wrong. If it locks up you simply write the partitions back and try again. If you can do 3 in 30 seconds you are done in 45 days since there are only 390.000 different patterns on a 3x3 grid (which is what most people use since some Roms don't even allow for 4x4 or 5x5) but if you emulate it and can do 3 in 15 seconds you are down to 23 days. If you run it in 20 emulators you are done in 1 day. (That would be an awesome weekend project.) In emulation you could really optimize this since you can cut everything out what isn't needed for the attempt to encrypt the partition. you dont even need the screen to load, simply send the decryption module whatever the last module in the Numbers-from-touches-chain would have sent, everything that is loaded before the attempt to decrypt must be unencrypted therefore can be messed with, probably it's even universal across phones since that's a stock android thing. If it tries to write used attempts, save whatever what gets overwritten beforehand, let it write its thing, kill the process, revert changes and try again with the next set. Maybe you get it down to 3s or 4s for 3 attempts and boom you are at 6 hours to encrypt any android phone, no matter which version, with an unlocked bootloader which uses a 3x3 pattern. But your data would be really valueable to someone if they did this. You can't do that with a locked bootloader since you can't read the partitions or you could just use the 5x5 pattern, which you cant do on MIUI (i just tried and havent found where you could change it). But probably i have a giant oversight in there so this probably woudn't work
________________________________________________
On the other hand if you want to recover your phone you should make it as easy as possible to get the thief into your phone since you dont want them to run it off and wipe it. I DONT RECOMMEND THIS. But you could make a 2nd user who has no lock pattern on it. Concider your Data public at this point but while they are busy looking at your selfies you could use a app like prey to track the phone. But since Data are more important than a phone i'd never do or recommend that.
Or you could just buy a tin foil hat.
~phoeny~ said:
Even with a locked bootloader a thief can hold VolUp while booting, wipe phone and sell it. Wiping is possible in any case and thats not even the issue a stolen Phone is gone.
The issue are your data which can be stolen too when you have a unlocked bootloader. Simply boot to twrp connect usb and copy everything. But you can prevent that with encryption and enable "requires pattern to start". That way if your phone gets stolen the thief can still Install/use Twrp but he needs to enter a pattern to decrypt the storage. If he doesnt, twrp wont be able to read the partition and your data is safe. He can still wipe the Phone and sell it but you cant prevent that. I don't know if the pattern generates the encryption keys or retrieves them from somewhere but i'd assume it generates them, probably together with some device specific values, else that would be a flaw in my book. If someone could enlighten me here that'd be nice.
If your bootloader is locked he also can't access your data. Since stock recovers doesn't allow/support Usb-filetransfer. So a lockpattern is all you need there. Encryption shouldnt really matter against the normal thief.
I am going this way: Unlocked bootloader to get rid of Miui, Twrp to have a proper recovery menu, and encryption+pattern to save my data. Disable USB-Developer Options to prevent adb shenanigans.
But on the hand if you wan't to get really panariod a locked bootloader would be better since you still can read the system image from the phone from twrp, this means, and this is a easy way to do it, you could read it copy it to the pc and simply brutefroce the lockpattern. If you have the partitions you can simply try 3 patterns either it works or the phone locks itself up because you did 3 wrong. If it locks up you simply write the partitions back and try again. If you can do 3 in 30 seconds you are done in 45 days since there are only 390.000 different patterns on a 3x3 grid (which is what most people use since some Roms don't even allow for 4x4 or 5x5) but if you emulate it and can do 3 in 15 seconds you are down to 23 days. If you run it in 20 emulators you are done in 1 day. (That would be an awesome weekend project.) In emulation you could really optimize this since you can cut everything out what isn't needed for the attempt to encrypt the partition. you dont even need the screen to load, simply send the decryption module whatever the last module in the Numbers-from-touches-chain would have sent, everything that is loaded before the attempt to decrypt must be unencrypted therefore can be messed with, probably it's even universal across phones since that's a stock android thing. If it tries to write used attempts, save whatever what gets overwritten beforehand, let it write its thing, kill the process, revert changes and try again with the next set. Maybe you get it down to 3s or 4s for 3 attempts and boom you are at 6 hours to encrypt any android phone, no matter which version, with an unlocked bootloader which uses a 3x3 pattern. But your data would be really valueable to someone if they did this. You can't do that with a locked bootloader since you can't read the partitions or you could just use the 5x5 pattern, which you cant do on MIUI (i just tried and havent found where you could change it). But probably i have a giant oversight in there so this probably woudn't work
________________________________________________
On the other hand if you want to recover your phone you should make it as easy as possible to get the thief into your phone since you dont want them to run it off and wipe it. I DONT RECOMMEND THIS. But you could make a 2nd user who has no lock pattern on it. Concider your Data public at this point but while they are busy looking at your selfies you could use a app like prey to track the phone. But since Data are more important than a phone i'd never do or recommend that.
Click to expand...
Click to collapse
Really appreciate the time you took to type out this post, thankyou.