Related
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.
Hi,
I have HTC Mazaa and want to enter its SPL mode. But the normal Volume Down + Power on combination as well as the Volume Down + Camera + Power on combination are not working for me.
According to someone, the bootloader is locked. Is there any solution for this problem? Can I somehow unlock the bootloader.
Plz reply.
You sure the volume down combinations' are meant for HTC devices? I don't think so.
I believe they are for Nokia Lumias'.
And i don't think there's an unlock available for your device.
For enter to bootloader mode you have to try vol up + vol down and when you hold these buttons press the power button.
babu.rajiv2007 said:
You sure the volume down combinations' are meant for HTC devices? I don't think so.
I believe they are for Nokia Lumias'.
And i don't think there's an unlock available for your device.
Click to expand...
Click to collapse
Yes this combination is for HTC Windows Phone devices. But not working on my HTC Mazaa.
Budniu said:
For enter to bootloader mode you have to try vol up + vol down and when you hold these buttons press the power button.
Click to expand...
Click to collapse
I also tried this, but its also not working. This combination does a strange thing. The phone vibrates five times and kind of becomes dead and doesn't boot again unless you take out the batter and insert it back.
Any other suggestion?
The Mazaa is a developer device, not a retail one. It's quite likely that its firmware is a little different, and may therefore either not have all the same modes as normal HTC devices, or may not use the same button combos to access them.
GoodDayToDie said:
The Mazaa is a developer device, not a retail one. It's quite likely that its firmware is a little different, and may therefore either not have all the same modes as normal HTC devices, or may not use the same button combos to access them.
Click to expand...
Click to collapse
Can you please help me with finding the button combo. I have been trying a lot but without luck.
I also want an interop-unlock on my phone but probably you already know that HTC Mazaa does not have database for the HTC Connection Setup app, so I can't use the normal interop-unlock method. Perhaps you could help me how I can install the database for Connection Setup app by using cab sender tool. I have the database's .pkg file in a .cab file that is basically HTC's oem update.
The app stating it can't find the database can be either due to the lack of the database files, or the inability to use the HtcFileUtility driver. I don't have a Mazaa, and have never really examined one, so I can't say for sure which is the case here. Similarly, I'm not sure how you expect me to help you find a button combo that might not even exist on a device that I don't have.
As for sending the CAB, if you have a signed update CAB, that should work unless the versioning is different (which it probably is). Otherwise, you'd need Microsoft's private key in order to sign that CAB, and there's no way I can get that for you.
GoodDayToDie said:
The app stating it can't find the database can be either due to the lack of the database files, or the inability to use the HtcFileUtility driver. I don't have a Mazaa, and have never really examined one, so I can't say for sure which is the case here. Similarly, I'm not sure how you expect me to help you find a button combo that might not even exist on a device that I don't have.
As for sending the CAB, if you have a signed update CAB, that should work unless the versioning is different (which it probably is). Otherwise, you'd need Microsoft's private key in order to sign that CAB, and there's no way I can get that for you.
Click to expand...
Click to collapse
Sorry if I sound silly, but is it possible to include the HTC Connection Setup database .pkg file into one of the CABs for the Tango update. I am planning to update to Tango with those cabs tonight. And those Tango CABs will be signed with Microsoft's private key. Will it help?
Modifying the CAB will invalidate the signature, unfortunately. A cryptographic signature consists of taking a strong hash (like SHA-256) of the data, and then encrypting the hash with a private key. It's possible for anybody with the public key (which your phone has) to verify the signature - they decrypt it, and then re-run the hash algorithm and see if the decrypted signature matches.
The problem is that if you modify the data at all, even a single bit, the hash will change substantially. Theoretically it's possible to find a "hash collision" where the modified data has the same hash result as the original, but practically speaking that's impossible (or rather, it will happen approximately once in 2^256 attempts).
GoodDayToDie said:
Modifying the CAB will invalidate the signature, unfortunately. A cryptographic signature consists of taking a strong hash (like SHA-256) of the data, and then encrypting the hash with a private key. It's possible for anybody with the public key (which your phone has) to verify the signature - they decrypt it, and then re-run the hash algorithm and see if the decrypted signature matches.
The problem is that if you modify the data at all, even a single bit, the hash will change substantially. Theoretically it's possible to find a "hash collision" where the modified data has the same hash result as the original, but practically speaking that's impossible (or rather, it will happen approximately once in 2^256 attempts).
Click to expand...
Click to collapse
Very well explained. I understand it all now. But please help me find a way around. Either I have to interop-unlock my HTC Mazaa or flash a custom ROM on it. I found a method while searching. Can you please tell me what will happen if I flash the ROM provided in the following method.
http://www.jayceooi(DOT)com/2011/09/16/how-to-install-windows-phone-7-5-mango-7720-on-htc-hd2-video/
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.
Hello - I have a rather unique situation and have been searching for possible solutions since last few days. I have forgotten my pin or potentially an update or my office apps have locked my phone. I have it connected using fastboot to my PC however I am not able to flash TWRP as it gives an error: Flashing not allowed in Lock State. Is there any way for me to back up the data before doing a reset? Is there any code which can be used to bruteforce different pin combinations in recovery mode / fastboot mode? Any help is greatly appreciated. I have the output of "fastboot getvar all" in case that can help you locate the partition to boot/erase. thanks a ton!
Oneplus8TPinFinder said:
Hello - I have a rather unique situation and have been searching for possible solutions since last few days. I have forgotten my pin or potentially an update or my office apps have locked my phone. I have it connected using fastboot to my PC however I am not able to flash TWRP as it gives an error: Flashing not allowed in Lock State. Is there any way for me to back up the data before doing a reset? Is there any code which can be used to bruteforce different pin combinations in recovery mode / fastboot mode? Any help is greatly appreciated. I have the output of "fastboot getvar all" in case that can help you locate the partition to boot/erase. thanks a ton!
Click to expand...
Click to collapse
In what way are you phone locked? I don't think there are anything you can do to save your data if you don't know your password/pin. TWRP wouldn't have helped in this case either.
Hi - thanks for your reply. My pin is not working and every pin trial is taking quite a bit of time. I am able to try pins quickly in recovery mode but trying all possible 4 digit combinations will take quite a bit of time. Alternatively, a brute force code to keep trying different pins would also be beneficial if you are aware of it.
Wont adb would have let me back up my phone data?
No way to bruteforce it that I am aware off.
your pin is needed to decrypt the encryption key that is used to decrypt data. So you can't access or backup any data without your pin. This is by design.
But cant the encryption key be overwritten using my biometrics which I have registered as well? Or something that manufacturer can do because there are tonnes of solutions for samsung and lg devices but am struggling to find something for oneplus..
Oneplus8TPinFinder said:
But cant the encryption key be overwritten using my biometrics which I have registered as well? Or something that manufacturer can do because there are tonnes of solutions for samsung and lg devices but am struggling to find something for oneplus..
Click to expand...
Click to collapse
Perhaps this is because OnePlus has properly secured their devices and Samsung/LG hasn't? Though I do contest that statement. By my knowledge all devices perform a data wipe when the bootloader is unlocked (aside from one OP device that had a flaw in this area IIRC).
Please view this from another perspective: if your device was stolen and you've PIN protected it, would you want the thief to be able to unlock it and view all your pictures/videos/documents/etc?
Timmmmaaahh! said:
Perhaps this is because OnePlus has properly secured their devices and Samsung/LG hasn't? Though I do contest that statement. By my knowledge all devices perform a data wipe when the bootloader is unlocked (aside from one OP device that had a flaw in this area IIRC).
Please view this from another perspective: if your device was stolen and you've PIN protected it, would you want the thief to be able to unlock it and view all your pictures/videos/documents/etc?
Click to expand...
Click to collapse
I agree but one pin cant and should not be the only way to unlock phone. In my particular case, I have now started to think that some of the app has messed up with the pin or an android update has messed up with the pin. I am quite surprised that a forgot pin / pattern option doesnt even come as if no one can forget pin. Is there a way to hack into my phone given I am logged into same gmail and other apps as I am logged into my new realme phone?
Oneplus8TPinFinder said:
I agree but one pin cant and should not be the only way to unlock phone. In my particular case, I have now started to think that some of the app has messed up with the pin or an android update has messed up with the pin. I am quite surprised that a forgot pin / pattern option doesnt even come as if no one can forget pin. Is there a way to hack into my phone given I am logged into same gmail and other apps as I am logged into my new realme phone?
Click to expand...
Click to collapse
First time I've heard of a failing PIN, let alone an app that would mess with it (which is absolutely impossible). Asking for a hack into your phone is asking for an illegal way to access your device, which crosses a boundary we will not get into on this platform. We tweak devices, we add functionality, we use exploits to alter the aesthetics of a device and we surely mess them up a lot but we will not support anything beyond our terms.
But! If there indeed is an issue with the OnePlus 8T PIN security, I hope people will report it here. AFAIK there is no such issue widely known.
I also hope it's a lesson in creating proper backups. I guess learning the hard way is the best way. I think we've all been there. I sure have!
you could reset it and enter email registered with that device they fix or email you code to fix
Hi!
I'm considering buying Pixel 6a for its worth at around 300USD worth but after using Android for several years, I'm concerned about security after rooting, like after theft etc.
Afaik, if bootloader is unlocked, the thief can just flash a new image and that's it!
It's different with iOS where icloud lock (even after jailbreak) can render the device practically unusable.
Can someone guide if some kind of google lock is a possibility nówadays with Android or newer versions of Android?
Are you looking at this from a data security standpoint? Or from "make sure its worthless to the thief".
Data security I believe is much more important than causing the phone to self destruct if stolen, and from a data security standpoint, you don't need to worry about root, because the data stored in the userdata partition is ENCRYPTED, and this encryption is tied to lockscreen security. In other words, they need to be able to legitimately get past the lockscreen in order to have unencumbered access to your data, regardless of what they change with respect to boot and system partitions.
If on the other hand, you're more worried about rendering the device worthless if stolen (i.e., thief can't actually use it), then you're actually talking about gooble's factory reset protection, which pretty much locks you to factory images, and locked bootloaders, and the "unlock bootloader" switch set to not-unlockable.
Factory reset protection works by forcing you to validate that you are the owner of the gooble account previously registered as owner of the device. It can be trivially bypassed as long as the "allow oem unlocking" flag is set to true, or the device has a 3rd party OS key installed, such as from grapheneos.
Also, having the device REPORTED as stolen if it is, will make it unable to connect to a cellular network, which pretty effectively makes it worthless.
Thanks for detailed answer. It answers my question.
While data is first priority, rendering device non-usable is also a deterrent.
Gotta find some ROMs which allow encryption tho. Thanks again
tarun0 said:
Thanks for detailed answer. It answers my question.
While data is first priority, rendering device non-usable is also a deterrent.
Gotta find some ROMs which allow encryption tho. Thanks again
Click to expand...
Click to collapse
It isn't a useful deterrent to theft, because they have to steal it first before they can find out if its been rendered useless or not. Its not like they'll return it if they find out that its useless.
tarun0 said:
Hi!
I'm considering buying Pixel 6a for its worth at around 300USD worth but after using Android for several years, I'm concerned about security after rooting, like after theft etc.
Afaik, if bootloader is unlocked, the thief can just flash a new image and that's it!
It's different with iOS where icloud lock (even after jailbreak) can render the device practically unusable.
Can someone guide if some kind of google lock is a possibility nówadays with Android or newer versions of Android?
Click to expand...
Click to collapse
You should be worried more about having unlocked bootloader as opposed to root.
Root can only be obtained via Magisk, which creates a layer making your System think that Magisk is a part of it. No root could be obtained other than through Magisk manager, and even then, you will get a prompt to allow root to an app or adb. You can provide time limited root or one time only for apps. In other words, root gives the user control. Your OS already has root regardless of Magisk. All Magisk does is give you the power to grant or deny root.
Locked vs unlocked bootloader: this is where you should be concerned. If your bootloader is unlocked, it might be possible to boot or flash a modified recovery or TWRP that will have full write access to your system partitions, which are not encrypted. Android, unlike Linux or Windows never encrypted anything but data partition, and a few years ago, Google dropped even that in favor of file encryption. So, your data partition is no longer encrypted, just the files. So, when TWRP has full access to your system, an adversary may succeed in removing your screen lock/password/pattern and force system to boot straight without any lock. Note, the attacker wouldn't have to deal with encryption at all, but rather use natural Android weakness, which is: the first boot after installing a brand new rom is always without password prompt. So, in this case, the attacker will have the full access to your data.
With locked bootloader, this is not possible, as all fastboot actions are disabled.
99.9% of custom roms require unlocked bootloader. Those few, which are available on locked bootloader, do not provide root. There are only 1 or 2 developments that can provide optional root + locked bootloader.
optimumpro said:
You should be worried more about having unlocked bootloader as opposed to root.
Root can only be obtained via Magisk, which creates a layer making your System think that Magisk is a part of it. No root could be obtained other than through Magisk manager, and even then, you will get a prompt to allow root to an app or adb. You can provide time limited root or one time only for apps. In other words, root gives the user control. Your OS already has root regardless of Magisk. All Magisk does is give you the power to grant or deny root.
Locked vs unlocked bootloader: this is where you should be concerned. If your bootloader is unlocked, it might be possible to boot or flash a modified recovery or TWRP that will have full write access to your system partitions, which are not encrypted. Android, unlike Linux or Windows never encrypted anything by data partition, and a few years ago, Google dropped even that in favor of file encryption. So, your data partition is no longer encrypted, just the files. So, when TWRP has full access to your system, an adversary may succeed in removing your screen lock/password/pattern and force system to boot straight without any lock. Note, the attacker wouldn't have to deal with encryption at all, but rather use natural Android weakness, which is: the first boot after installing a brand new rom is always without password prompt. So, in this case, the attacker will full access to your data.
With locked bootloader, this is not possible, as all fastboot actions are disabled.
99.9% of custom roms require unlocked bootloader. Those few, which are available on locked bootloader, do not provide root. There are only 1 or 2 developments that can provide optional root + locked bootloader.
Click to expand...
Click to collapse
Ahhh... So there are options albeit just 1 or 2 which can root with bootlocker locked!!
I thought it's just impossible to root without unlocking bootloader.
Thanks for the nice explanation
tarun0 said:
Ahhh... So there are options albeit just 1 or 2 which can root with bootlocker locked!!
I thought it's just impossible to root without unlocking bootloader.
Thanks for the nice explanation
Click to expand...
Click to collapse
Just my view: if I were you, I wouldn't buy any Pixels phone that has Titan chip in it. It is just one more reliance on such a 'bastion' of privacy as Google. Note Titan is closed source, and not only it deals with certificates, but it can also modify firmware. Here is Zdnet's description:
"The Titan chip manufacturing process generates unique keying material for each chip, and securely stores this material -- along with provenance information -- into a registry database. The contents of this database are cryptographically protected using keys maintained in an offline quorum-based Titan Certification Authority (CA).
"Individual Titan chips can generate Certificate Signing Requests (CSRs) directed at the Titan CA, which -- under the direction of a quorum of Titan identity administrators -- can verify the authenticity of the CSRs using the information in the registry database before issuing identity certificates."
So, each machine's individual key is stored with some 'magic' database maintained by Titan Certification Authority. In other words, an entity funded by three-letter agencies now has an additional database holding individual keys for each phone.
optimumpro said:
Just my view: if I were you, I wouldn't buy any Pixels phone that has Titan chip in it. It is just one more reliance on such a 'bastion' of privacy as Google. Note Titan is closed source, and not only it deals with certificates, but it can also modify firmware. Here is Zdnet's description:
"The Titan chip manufacturing process generates unique keying material for each chip, and securely stores this material -- along with provenance information -- into a registry database. The contents of this database are cryptographically protected using keys maintained in an offline quorum-based Titan Certification Authority (CA).
"Individual Titan chips can generate Certificate Signing Requests (CSRs) directed at the Titan CA, which -- under the direction of a quorum of Titan identity administrators -- can verify the authenticity of the CSRs using the information in the registry database before issuing identity certificates."
So, each machine's individual key is stored with some 'magic' database maintained by Titan Certification Authority. In other words, an entity funded by three-letter agencies now has an additional database holding individual keys for each phone.
Click to expand...
Click to collapse
Thanks for the opinion broski! But what brand are available there?
I don't like Samsung anymore because they destroy screen with update and don't help customers. Rest brand look more on papers but not in real.
tarun0 said:
Thanks for the opinion broski! But what brand are available there?
I don't like Samsung anymore because they destroy screen with update and don't help customers. Rest brand look more on papers but not in real.
Click to expand...
Click to collapse
Onepluses allow relocking bootloader on custom roms.
tarun0 said:
Thanks for the opinion broski! But what brand are available there?
I don't like Samsung anymore because they destroy screen with update and don't help customers. Rest brand look more on papers but not in real.
Click to expand...
Click to collapse
Don't be intimidated by the technical language - it's not as complicated as it seems. All hardware security modules come with a key that is installed at the factory and signed by the manufacturer. This initial key is only used to establish a basic level of trust, and the HSM will then generate a unique key for encrypting your data and performing attestation. This process is the same no matter what brand of device you use, whether it's an OnePlus, a pixel, or any other brand
Newer pixel models have a feature called ATTEST_KEY that allows each device to have its own unique keys. If one of these HSM keys were to be compromised, it wouldn't affect your security. However, rooting your phone can compromise your security and make verified boot ineffective, even if the bootloader is locked. If you value security, it's important not to root your phone
tarun0 said:
Ahhh... So there are options albeit just 1 or 2 which can root with bootlocker locked!!
I thought it's just impossible to root without unlocking bootloader.
Thanks for the nice explanation
Click to expand...
Click to collapse
This statement is incorrect. The Android user interface was not designed to handle permission prompts for root access. When you root your phone, you increase the potential for UI bugs that were previously not able to cause harm to become attack vectors that can be used to gain full access to your phone. Rooting also weakens the security of your phone by adding new permissive domains and making the *_app SELinux domains more permissive
It is heavily recommended to read this article https://madaidans-insecurities.github.io/android.html
tarun0 said:
Thanks for detailed answer. It answers my question.
While data is first priority, rendering device non-usable is also a deterrent.
Gotta find some ROMs which allow encryption tho. Thanks again
Click to expand...
Click to collapse
For the past five years, it has been required that all Android phones have encryption enabled by default. If you purchase a Pixel phone, it will come with encryption already enabled, but you can further enhance the security of the encryption by installing GrapheneOS as they increase the file name padding length to the maximum supported by the kernel make certain attacks harder.
Block-based encryption is generally considered to be less secure than file-based encryption because it uses a single key to encrypt all data, rather than multiple keys for individual files (which is what FBE does). Android 10 introduced metadata encryption, which encrypts the sector 0 on the data partition, making it inaccessible to attackers even when attempting to access the data through recovery mode. One of the main reasons file-based encryption is preferred over block-based encryption is that it is more difficult to verify the security of block-based encryption, and the algorithms used in block-based verification can be complex and challenging to implement correctly. Additionally, block-based encryption only encrypts data and does not provide any integrity checking, so if the data becomes corrupt, there is no way to detect it and the decryption process will continue. This can result in broken files at best and potentially allow attackers to tamper with or exploit the Linux kernel at worst, as noted by Linux kernel maintainers
optimumpro said:
So, when TWRP has full access to your system, an adversary may succeed in removing your screen lock/password/pattern and force system to boot straight without any lock. Note, the attacker wouldn't have to deal with encryption at all, but rather use natural Android weakness, which is: the first boot after installing a brand new rom is always without password prompt. So, in this case, the attacker will have the full access to your data.
Click to expand...
Click to collapse
This quote is mostly (the bad part) FALSE. The decryption on the files cannot be performed until AFTER the device has been unlocked. If an attacker installs something that skips the lockscreen, the files will NOT be decrypted, since that lockscreen password/pin/pattern/etc. is needed to gain access to the key.
No matter what, whether the device bootloader is unlocked or not, or the device has root access or not... if the device is physically outside of the owner's control, it is necessary to assume that security on it has been compromised and should not be trusted. As the owner, you should assume that it has been backdoored, so wipe it fully and reinstall OS.
there is one exception, though. in AFU state, FBE is already decrypted (same as FDE)
https://bugs.xdavidhu.me/google/2022/11/10/accidental-70k-google-pixel-lock-screen-bypass
(does not concern powered off devices)
96carboard said:
Are you looking at this from a data security standpoint? Or from "make sure its worthless to the thief".
Data security I believe is much more important than causing the phone to self destruct if stolen, and from a data security standpoint, you don't need to worry about root, because the data stored in the userdata partition is ENCRYPTED, and this encryption is tied to lockscreen security. In other words, they need to be able to legitimately get past the lockscreen in order to have unencumbered access to your data, regardless of what they change with respect to boot and system partitions.
If on the other hand, you're more worried about rendering the device worthless if stolen (i.e., thief can't actually use it), then you're actually talking about gooble's factory reset protection, which pretty much locks you to factory images, and locked bootloaders, and the "unlock bootloader" switch set to not-unlockable.
Factory reset protection works by forcing you to validate that you are the owner of the gooble account previously registered as owner of the device. It can be trivially bypassed as long as the "allow oem unlocking" flag is set to true, or the device has a 3rd party OS key installed, such as from grapheneos.
Also, having the device REPORTED as stolen if it is, will make it unable to connect to a cellular network, which pretty effectively makes it worthless.
Click to expand...
Click to collapse
Not all of this is really right on the head.
tarun0
FRP is VERY easy to bypass. Takes me about 2 minutes on Android 13 Jan 2022 update on 7 Pro, 7, 6a, 6 pro, 6, 5a, 5, 4a 5g and the 4a. The data is wiped though, so it at least can't have data stolen, but the FRP is more like a fence with a gate that you can just reach the other side to unlock with a paper clip lol
As far as getting past lock screen, there's USB plug-in's that if a true back actor wanted to get into the phone, it bypasses usb debugging and can force test thousands of pins and patterns per minute without flagging the maximum attempt trigger. But again, what's the chance of a phone getting stolen by someone with that level of knowledge? 90% of phone thieves take it, run and sell it quick flip.
Also, with a custom Android recovery, adb commands are possible, so if the device is rooted with a custom recovery, there's ways to extract the lock screen file where its stored and use it. I don't think the recoveries based on LineageOS can do this, but TWRP definitely can as I've done it personally. So far there's no twrp for any android 13 device to my knowledge. Even the android 12 variants of twrp are shotty and barely function.
Dirty flashing a rom will also remove any passcode generally on a phone. and make data accessible.
Reporting it stolen only goes so far. You can spoof the IMEI if rooted or straight up change it if you have tools like MiracleBox
Long story short, an unlocked bootloader and a rooted android device make the device very insecure. The only roms out there that let you re-lock the bootloader after flashing the rom are Graphene and CalyxOS. And I really don't recommend calyx. Its a pile of ****. Don't root graphene either, as you'll have to leave the bootloader unlocked
TechX1991 said:
Dirty flashing a rom will also remove any passcode generally on a phone. and make data accessible.
Click to expand...
Click to collapse
we are talking about FBE encryption, not old FDE encryption with default_password. do not claim what you haven't tested yourself. FBE is simply secure in BFU state. also against bruteforce as gatekeeper lives in TEE. after 140 attempts the timeout has increased to 1 day.
kindly read about how FBE works
https://android.stackexchange.com/a/241688