FORUMS
Remove All Ads from XDA

The TWRP Password Protection Thread

2,657 posts
Thanks Meter: 4,439
 
By Lanchon, Senior Member on 2nd January 2015, 06:00 AM
Post Reply Email Thread
8th January 2015, 05:56 PM |#21  
Member
Thanks Meter: 26
 
More
Out of curiosity, I tried the following on my Nexus-S:

- relock bootloader using "fastboot oem lock" (worked fine, shows status locked; trying to fast-boot another kernel is refused by the device)
- boot CM11 which was already there before re-locking using the locked bootloader (worked fine as well, seems not to check kernel signatures)
- send "fastboot erase data" from locked bootloader (worked fine as well !?! phone booted to fresh data partition):

Code:
$ fastboot erase userdata
erasing 'userdata'...
OKAY [  0.272s]
finished. total time: 0.273s
Recovery - no matter if password protected or not - was not involved at all in the process. In case the phone was not encrypted, stuff in userdata would be lost but I could easily access the emulated internal storage. With some file recovery techniques, I should be probably also able to restore most stuff in userdata, since the "wipe" by "fastboot erase", which took less than 300ms, probably just wrote a new filesystem signature to the data partition without really wiping anything.

Now, if I can get root (i.e. if the previous rom was rooted already or an exploit exists) I can now easily flash a new password-unprotected recovery and revert everything back to stock. And probably so can the burglar which you wanted to lock out with password-enabled TWRP. To put it with your terms, I don't consider this for the list of "other phones which actually make an effort to defend your data. "

Since you counted all Google Nexus devices in your whitelist of "secure phones", can you please confirm that newer devices like Nexus 4, Nexus 5 or OnePlus One are not affected by this vulnerability?
 
 
8th January 2015, 05:58 PM |#22  
Lanchon's Avatar
OP Senior Member
Thanks Meter: 4,439
 
Donate to Me
More
Quote:
Originally Posted by Defier525

Internal sdcard in /data/media since AOSP 4.0: This was new to me, but it seems to be implemented this way in my Nexus S. I just wonder why my Xperia V does not handle it this way then?

eMMC and secure erase: Okay this was new to me as well. But afaik, TWRP does not use these commands for wiping, does it?

locked bootloader and password protected TWRP: What if an attacker would try to fastboot erase the data or recovery partition? Will a locked, properly implemented bootloader prevent that?

devices that were released in android 2.x days with "internal sdcard" emulated in the phone's emmc typically have a fat32 partition that implements it. devices released with android 4.x typically have a fuse process that reflects some content under /data/media (ext4 or some other linux fs) as the sdcard, emulating fat32 properties (no fs level security, case insensitive file names, etc). when devices are upgraded from android 2 to android 4, either by the OEM or by hobbyists, they are typically not repartitioned and the original schema is maintained.

typically all custom recoveries do this because they are based on stock recovery, unless its disabled to work around some bug (brickbug in the exynos 4210 platform, long wipe times in the nexus 5, etc). for CM recoveries see:
https://github.com/search?q=BOARD_SU...nMod&type=Code

locked fastboot means no change to the emmc is possible and no booting of kernels over usb. no exceptions made, no signatures are looked for. locked means fastboot is not an attack vector.
The Following User Says Thank You to Lanchon For This Useful Post: [ View ] Gift Lanchon Ad-Free
8th January 2015, 06:16 PM |#23  
Member
Thanks Meter: 26
 
More
I don't agree with you in these points:
- considering fastboot, please read my previous posting (probably posted while you were writing this). I definitely consider this a serious attack vector, at least on my Nexus S.
- considering partition layout, I posted the internal layout in stock ROM from my Xperia V in another forum. The Xperia V originally came with Android 4.0 (unlike the Nexus S) and it uses 15 partitions for the internal eMMC. Userdata and SDCard are on separate partitions, no matter how they are mounted later with fuse. Therefore, only wiping Userdata will not affect the internal sdcard at all.
8th January 2015, 06:18 PM |#24  
Lanchon's Avatar
OP Senior Member
Thanks Meter: 4,439
 
Donate to Me
More
the wipe in CM recovery is done here:

https://github.com/CyanogenMod/andro...ils/wipe.c#L42
The Following User Says Thank You to Lanchon For This Useful Post: [ View ] Gift Lanchon Ad-Free
8th January 2015, 07:27 PM |#25  
Dees_Troy's Avatar
Senior Recognized Developer
Flag KC MO
Thanks Meter: 13,578
 
Donate to Me
More
Quote:
Originally Posted by bigbiff

3 people in the entire world do a majority of the work for TWRP. We are welcome for contributions to the TWRP projcect at OMNI's gerrit for people who want to get this done.

Quote:
Originally Posted by Lanchon

i thought of that, but adding a feature like this to TWRP probably requires too much effort for somebody who doesnt know the codebase. i imagine that TWRP is sort of an app framework in itself. i chose to advocate for it instead of implementing, i just can't justify the effort it would take *me*. i also tried to help by centralizing ideas on how it should be implemented, if somebody chooses to.

anyway, it's great to know you are not opposing the idea and you would consider merging if somebody implements, that is a good start.

btw, there is a tangentially related issue i'd love to hear your opinion on:

i hear TWRP can mount encrypted partitions and there is a UI for entering PINs, passwords, patterns etc. but i dont have my phone encrypted because if i break my display with the phone encrypted then im toast: i cant extract my files from the device anymore.

would you consider implementing a way to enter the encryption password via usb? maybe some sort of adb shell command?

The features you're asking for will likely only be used by a tiny subset of users on a small subset of the overall devices that we support. The number of devices that allow you to relock the bootloader and still allow you to boot an unsigned image is basically just Nexus devices and the OPO. The number of users that need / want the feature you're requesting is very small, probably less than 20 people.

The amount of time and effort needed to properly implement what you are requesting is not small. Finding a safe location and method to store the password will hardly be trivial. We need to make sure that adb is completely disabled until after the correct password is entered, otherwise an attacker would be able to use adb to bypass most of the security measures. We cannot safely store the password anywhere in /data because the data partition may be encrypted and thus not accessible.

You still haven't come up with a solution to a fastboot erase command that I believe still works on Nexus and probably the OPO devices even if the bootloader is locked. As I said in my write-up, your best case scenario if someone else gets hold of your phone is that they don't get access to your private data.

You might be able to enter a password on a device with a broken display using a USB keyboard and USB OTG cable. As mentioned earlier, leaving adb running leaves a humongous gaping security hole open that basically makes all of your arguments for better security null and void.

The fact that you don't encrypt your device and the fact that you aren't willing to do the development yourself tells me you aren't that serious about security.

I guarantee you that I have thought about this subject way more than you have. It's extremely unlikely that you're going to win this argument, and even if you "win", it's extremely unlikely that I'm going to develop this feature for you as part of regular TWRP development because of the limited benefit to the overall project. I do take contract work though, on occasion if it is something that you're serious about. It's not cheap though.

Also, for the record, the Nexus S does NOT have unified storage. You can get unified storage on the Nexus S using lvm and some other "hacks", but in stock form it does not have unified storage.
8th January 2015, 07:27 PM |#26  
Lanchon's Avatar
OP Senior Member
Thanks Meter: 4,439
 
Donate to Me
More
Quote:
Originally Posted by Defier525

Out of curiosity, I tried the following on my Nexus-S:

- relock bootloader using "fastboot oem lock" (worked fine, shows status locked; trying to fast-boot another kernel is refused by the device)
- boot CM11 which was already there before re-locking using the locked bootloader (worked fine as well, seems not to check kernel signatures)
- send "fastboot erase data" from locked bootloader (worked fine as well !?! phone booted to fresh data partition):

Code:
$ fastboot erase userdata
erasing 'userdata'...
OKAY [  0.272s]
finished. total time: 0.273s
Recovery - no matter if password protected or not - was not involved at all in the process. In case the phone was not encrypted, stuff in userdata would be lost but I could easily access the emulated internal storage. With some file recovery techniques, I should be probably also able to restore most stuff in userdata, since the "wipe" by "fastboot erase", which took less than 300ms, probably just wrote a new filesystem signature to the data partition without really wiping anything.

Now, if I can get root (i.e. if the previous rom was rooted already or an exploit exists) I can now easily flash a new password-unprotected recovery and revert everything back to stock. And probably so can the burglar which you wanted to lock out with password-enabled TWRP. To put it with your terms, I don't consider this for the list of "other phones which actually make an effort to defend your data. "

Since you counted all Google Nexus devices in your whitelist of "secure phones", can you please confirm that newer devices like Nexus 4, Nexus 5 or OnePlus One are not affected by this vulnerability?

im assuming you rebooted the bootloader after oem unlock and before erase.

well, you stumbled onto a bug. your device is 4 generations old and discussing a bug of your bootloader in detail here is off-topic. many, many devices have security broken, by design or by bugs, but that doesnt mean TWRP should break the security of those -many or few- that get it right.

let's do this anyway but please let's keep it brief.

recovery is only invoked on device wipe (oem unlock), never on fastboot erase. the emulated partition was deprecated 4 years ago, before encryption was added to android. current devices are of the /data/media type and encryption on these devices encrypts everything. on the other hand, fastboot oem unlock wipes everything, including emulated sdcard on old emulated partition devices.

fastboot (device side) understands the GPT but does not know about file systems. for sure fastboot erase did not "just wrote a new filesystem signature", it probably issued a (nonsecure) DISCARD emmc command spanning the partition. (or else maybe it did a no-operation?) nonsecure DISCARD is actually very efficient: it only unmaps blocks. the data is still in the flash though, the NSA could get it back. the emmc will be erasing the affected erase blocks at its leisure, when it needs to, or when it is idle, or the main cpu informs the emmc it's time to do housekeeping (device unused and charging, for instance).

after the DISCARD is issued, you would be unable to read anything out of the emmc. the emmc synthesizes blocks of zeros when reading out unmapped blocks. data is really gone, unless you can hack the emmc firmware (entirely possible for a worthy adversary), or you decap the module and access the flash directly. SECURE DISCARD on the other hand actually wipes the flash, including the many stale copies that might exist of the wiped blocks.

in any case, fastboot erase should be inaccessible in a locked bootloader and whatever it did in your device is nonstandard and not our concern here. write the nexus S off as an insecure device if you will.

moving on, the next point is moot: if you get root you are over the bootloader protection. the whole point of this thread is preventing root access by an unauthorized party.

i never white-listed any phones! for sure all nexus make a desgin effort to defend your data, but implementations can be flawed. in particular, the boot-into-recovery-to-wipe-and-then-unlock bootloader behavior, i can only vouch for it on the OPO where i tested it. and ive stated this in the OP. but according to messages ive read, it seems to hold true for the nexus 4 and 5 at least.

i cannot confirm or deny the fastboot erase vuln on other phones at this time. (this would wipe all useful data on newer phones though.)
8th January 2015, 08:29 PM |#27  
Lanchon's Avatar
OP Senior Member
Thanks Meter: 4,439
 
Donate to Me
More
Quote:
Originally Posted by Dees_Troy

The features you're asking for will likely only be used by a tiny subset of users on a small subset of the overall devices that we support. The number of devices that allow you to relock the bootloader and still allow you to boot an unsigned image is basically just Nexus devices and the OPO. The number of users that need / want the feature you're requesting is very small, probably less than 20 people.

The amount of time and effort needed to properly implement what you are requesting is not small. Finding a safe location and method to store the password will hardly be trivial. We need to make sure that adb is completely disabled until after the correct password is entered, otherwise an attacker would be able to use adb to bypass most of the security measures. We cannot safely store the password anywhere in /data because the data partition may be encrypted and thus not accessible.

You still haven't come up with a solution to a fastboot erase command that I believe still works on Nexus and probably the OPO devices even if the bootloader is locked. As I said in my write-up, your best case scenario if someone else gets hold of your phone is that they don't get access to your private data.

You might be able to enter a password on a device with a broken display using a USB keyboard and USB OTG cable. As mentioned earlier, leaving adb running leaves a humongous gaping security hole open that basically makes all of your arguments for better security null and void.

The fact that you don't encrypt your device and the fact that you aren't willing to do the development yourself tells me you aren't that serious about security.

I guarantee you that I have thought about this subject way more than you have. It's extremely unlikely that you're going to win this argument, and even if you "win", it's extremely unlikely that I'm going to develop this feature for you as part of regular TWRP development because of the limited benefit to the overall project. I do take contract work though, on occasion if it is something that you're serious about. It's not cheap though.

Also, for the record, the Nexus S does NOT have unified storage. You can get unified storage on the Nexus S using lvm and some other "hacks", but in stock form it does not have unified storage.

hi and thanks for answering! and for TWRP too

i absolutely understand the cost vs. return argument, i only wrote this thread because i didn't agree with the "we shouldn't do it because it's useless" stance as a way to trigger constructive discussion, such as this here.

as an option to where to store the password:

last sector of the recovery partition: a header plus integrity checking at the end of the sector (that could be the same hash function used to store the password). on init, the recovery reads the last sector of the recovery partition. (that shouldnt cause a problem in fastboot boot scenarios.) if the sector doesnt pass header/integrity checks, continue booting. otherwise ask for a password if the payload section of the sector has a password hash in it.

downside: susceptible to induced glitching attacks during the sector read. workaround (far from perfect): read the sector twice (bypassing caches) and fail to boot if the reads differ. (real workaround: die hard enthusiasts can build their own TWRP that fails to boot if the sector fails the checks.)

the fastboot erase vuln: this should be fixed by google if it wasnt ages ago. they can easily fix bootloaders in the field too. i will try to investigate this and post results here.

usb: well, because i always used patterns to unlock, i never thought i could encrypt the phone with a password then use a usb keyboard to decrypt. this is so simple it's brilliant! do you know if this would work while booting standard encrypted android? would the kernel connect usb keyboards before mounting data? (for sure BT keyboards wouldnt work.) if this works i would encrypt my phone.

yes, i stated in post #2 that adbd and mtpd have to remain disabled before auth of course. or some new adbd mode could be used to get the password. or maybe a completely independent, hacked adbd binary could do it; that could make maintenance of standard adbd easier.

lol, i AM serious about security! im paranoid about my printers getting worms! really, i am serious, so much so that my phone doesnt keep anything of value outside of my keepass vault. it is protected by a 30 or so character passphrase that cannot be dictionary attacked. you should see me typing that phrase to unlock my laptop harddrive in public places such as airports: im so wary of cameras filming my figer movements, you'd think im scheming to blow something up, its ridiculous!

on the realistic side, with the opaque baseband owning the phone, connected to everything, and presumably full of vulns, no phone can really be trusted. phones will never be a trusted device for me.

yes, the first /data/media nexus was the galaxy nexus. the cutoff was probably at android 4.1, not 4.0 as i previously stated, i dont really remember.
8th January 2015, 09:03 PM |#28  
Member
Thanks Meter: 26
 
More
Quote:

You still haven't come up with a solution to a fastboot erase command that I believe still works on Nexus and probably the OPO devices even if the bootloader is locked. As I said in my write-up, your best case scenario if someone else gets hold of your phone is that they don't get access to your private data.

I think that it is very essential to actually confirm or falsify this hypothesis first. A friend of mine has a Nexus 4, and when he unlocked the bootloader he simply intercepted the first boot after "fastboot oem unlock" so it went straight to the bootloader again, leading to userdata not being wiped at all.

@launchon I don't own any of these "probably-secure" devices you mentioned (Nexus 5 or OPO), but if you don't mind, please backup your userdata and internal sdcard and try "fastboot erase userdata" with your locked bootloader. In case this should be successful, boot your ROM and see if you can access data on sdcard or not. In case this erase behavior is broken on all Nexus devices, adding TWRP password protection would only protect you in case your data is encrypted (to some degree).

I can only tell from my personal experience with the Sony Xperia V Stock ROM. I had data encryption turned on and after entering the wrong passphrase too many times, the device rebooted and wiped my data without prior warning (I didn't know that!)! To my big surprise, only userdata was affected and the internal sdcard remained untouched. If you look at the partitioning scheme used on this device (which I mentioned in my last post) you will see that there is no such thing as /data/media, with media being just a symlink or something and with sdcard and userdata being physically on the same partition. Instead, there are two partitions: mmcblk0p14 for userdata and mmcblk0p15 for sdcard.

Also, my Nexus S has two flash memory devices: One mtd device and one eMMC. It seems like userdata, media and system are on eMMC while the rest is on MTD. The eMMC part is also split in separate partitions for userdata, media and system:

Code:
~ # ls -l /dev/block/platform/s3c-sdhci.0/by-name
lrwxrwxrwx    1 root     root            20 Jan  8 20:26 media -> /dev/block/mmcblk0p3
lrwxrwxrwx    1 root     root            20 Jan  8 20:26 system -> /dev/block/mmcblk0p1
lrwxrwxrwx    1 root     root            20 Jan  8 20:26 userdata -> /dev/block/mmcblk0p2
Well, maybe my understanding of how Android does mount the sdcard into encrypted data is wrong. Please explain it to me. As far as I have seen, you can specify "encryptable=sdcard" in fstab.vendor (like it is done e.g. for the Nexus S) - see this fstab. My understanding is that Android then encrypts the sdcard as well, putting a second cryptofooter at the end of the internal sdcard's partition and not using one cryptofooter for both userdata and internal sdcard. I will try to find out by experiment and post the results.

I looked into the source for fastboot.c, but I did not really understand it so I cannot tell what fastboot erase really does. But it seems like it falls back to less secure erase in some situations. After erasing, I was unable to retrieve the cryptofooter (which was previously there) and also other parts showed just zeros, therefore I assume that your description regarding DISCARD is correct. Yet, it would be better to dd if with zeros or random data afterwards but for the "regular burglar" scenario you mentioned it should be sufficiently secure.

Quote:

in any case, fastboot erase should be inaccessible in a locked bootloader and whatever it did in your device is nonstandard and not our concern here. write the nexus S off as an insecure device if you will.

I certainly will. Nevertheless I am not sure if I understood you correctly: You already tried to fastboot erase your OPO with locked bootloader and it denied to wipe it or you just suspect / expect it to behave this way without having actually trying it?

Quote:

The amount of time and effort needed to properly implement what you are requesting is not small. Finding a safe location and method to store the password will hardly be trivial. We need to make sure that adb is completely disabled until after the correct password is entered, otherwise an attacker would be able to use adb to bypass most of the security measures. We cannot safely store the password anywhere in /data because the data partition may be encrypted and thus not accessible.

Why not simple store it in / of /system with appropiate rights? If someone gains enough rights to read that, he should certainly also have enough rights to replace a password protected TWRP with something insecure (or less secure, that's what this thread is about).
8th January 2015, 09:28 PM |#29  
Lanchon's Avatar
OP Senior Member
Thanks Meter: 4,439
 
Donate to Me
More
Quote:
Originally Posted by Defier525

I think that it is very essential to actually confirm or falsify this hypothesis first. A friend of mine has a Nexus 4, and when he unlocked the bootloader he simply intercepted the first boot after "fastboot oem unlock" so it went straight to the bootloader again, leading to userdata not being wiped at all.

@launchon I don't own any of these "probably-secure" devices you mentioned (Nexus 5 or OPO), but if you don't mind, please backup your userdata and internal sdcard and try "fastboot erase userdata" with your locked bootloader. In case this should be successful, boot your ROM and see if you can access data on sdcard or not. In case this erase behavior is broken on all Nexus devices, adding TWRP password protection would only protect you in case your data is encrypted (to some degree).

I can only tell from my personal experience with the Sony Xperia V Stock ROM. I had data encryption turned on and after entering the wrong passphrase too many times, the device rebooted and wiped my data without prior warning (I didn't know that!)! To my big surprise, only userdata was affected and the internal sdcard remained untouched. If you look at the partitioning scheme used on this device (which I mentioned in my last post) you will see that there is no such thing as /data/media, with media being just a symlink or something and with sdcard and userdata being physically on the same partition. Instead, there are two partitions: mmcblk0p14 for userdata and mmcblk0p15 for sdcard.

Also, my Nexus S has two flash memory devices: One mtd device and one eMMC. It seems like userdata, media and system are on eMMC while the rest is on MTD. The eMMC part is also split in separate partitions for userdata, media and system:

Code:
~ # ls -l /dev/block/platform/s3c-sdhci.0/by-name
lrwxrwxrwx    1 root     root            20 Jan  8 20:26 media -> /dev/block/mmcblk0p3
lrwxrwxrwx    1 root     root            20 Jan  8 20:26 system -> /dev/block/mmcblk0p1
lrwxrwxrwx    1 root     root            20 Jan  8 20:26 userdata -> /dev/block/mmcblk0p2
Well, maybe my understanding of how Android does mount the sdcard into encrypted data is wrong. Please explain it to me. As far as I have seen, you can specify "encryptable=sdcard" in fstab.vendor (like it is done e.g. for the Nexus S) - see this fstab. My understanding is that Android then encrypts the sdcard as well, putting a second cryptofooter at the end of the internal sdcard's partition and not using one cryptofooter for both userdata and internal sdcard. I will try to find out by experiment and post the results.

I looked into the source for fastboot.c, but I did not really understand it so I cannot tell what fastboot erase really does. But it seems like it falls back to less secure erase in some situations. After erasing, I was unable to retrieve the cryptofooter (which was previously there) and also other parts showed just zeros, therefore I assume that your description regarding DISCARD is correct. Yet, it would be better to dd if with zeros or random data afterwards but for the "regular burglar" scenario you mentioned it should be sufficiently secure.



I certainly will. Nevertheless I am not sure if I understood you correctly: You already tried to fastboot erase your OPO with locked bootloader and it denied to wipe it or you just suspect / expect it to behave this way without having actually trying it?



Why not simple store it in / of /system with appropiate rights? If someone gains enough rights to read that, he should certainly also have enough rights to replace a password protected TWRP with something insecure (or less secure, that's what this thread is about).

nexus 4: not true on the opo. the recovery wipes, then the recovery unlocks. if the recovery doesn't boot, the oem unlock doesnt unlock. verified on opo. i heard this is the case on the nexus 4 too. any other design would be silly, i dont deem google engineers silly.

opo: i will not touch my device, but i might experiment on a different one. you have to understand this: modern phones do not have an "internal sdcard" partition, its all stored in /data. if /data goes, everything goes. if /data is encrypted, everything is.

the nexus S: is an obsolete device (yes, it has two flash chips, fast and big). we've established it's not secure. discussing it beyond that point is not relevant to this thread. same thing applies to you xperia.

fastboot erase is not secure. nor it is meant to be, at all. in android phone wiping is done by the recovery, never fastboot. and btw, secure erase is not done writing zeros, it's done with the right secure erase command of the emmc.

opo: i stated eralier: "i cannot confirm or deny the fastboot erase vuln on other phones at this time. (this would wipe all useful data on newer phones though.)" this applies to the opo too.

/system is a possible store. but is very intrusive, is asking for trouble in the future, and interacts badly with flashing and backups. the password can be unexpectedly reset under many circumstances. the last sector of recovery is way better IMHO.
8th January 2015, 09:42 PM |#30  
Lanchon's Avatar
OP Senior Member
Thanks Meter: 4,439
 
Donate to Me
More
confirmed: the fastboot erase vuln is NOT present in the OPO.
(thus, probably also not present in recent nexuses, i suppose.)

Code:
[email protected] ~ $ sudo fastboot devices
[sudo] password for rod: 
e615fff	fastboot
[email protected] ~ $ sudo fastboot oem device-info
...
(bootloader) 	Device tampered: true
(bootloader) 	Device unlocked: false
(bootloader) 	Charger screen enabled: false
OKAY [  0.004s]
finished. total time: 0.006s
[email protected] ~ $ sudo fastboot erase userdata
******** Did you mean to fastboot format this partition?
erasing 'userdata'...
FAILED (remote: 	Device not unlocked cannot flash or erase)
finished. total time: 0.003s
[email protected] ~ $
things of note:

1) this is a "new" straight out of the box OPO delivered to spain by oneplus. it says "tampered: true". (mine didn't.) oneplus is probably selling refurbs as new units. some people reported receiving unwiped phones, with pictures taken by the previous owner inside and all. oneplus is also making it next to impossible to return the device on warranty. oneplus, i have to say, is shady IMO. this is the SECOND "new" OPO that i personally found to be sold in the "tampered" state.

2) fastboot (device side) refuses to erase the partition, as it should.

3) "fastboot format" (host command) creates the formatted partition on the PC side, then forwards and flashes the partition image like any other image. fastboot (device side) does not understand file systems.
The Following User Says Thank You to Lanchon For This Useful Post: [ View ] Gift Lanchon Ad-Free
8th January 2015, 09:44 PM |#31  
Lanchon's Avatar
OP Senior Member
Thanks Meter: 4,439
 
Donate to Me
More
Quote:
Originally Posted by Dees_Troy

You still haven't come up with a solution to a fastboot erase command that I believe still works on Nexus and probably the OPO devices even if the bootloader is locked.

the vuln is not present in the OPO, please see the previous post.
Post Reply Subscribe to Thread

Tags
twrp security password

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes