Database Info

[R&D] Toshiba (11 series) Bootloader Unlock Discussion

Because the the other old Dev thread is getting a bit messy i've created a new thread to continue development of a boot loader unlock for 11 series devices.
Dont post ANYTHING unrelated to development of a way to change toshiba chip's cid!!!
@GeTex says she may be able to get us the firmware / vendor cmds which would be awesome!
===================================JULY 30 UPDATE==================================
Trying to reprogram CID abandoned, looking at alternate methods of unlocking b/l (or getting a custom kernel past QSB/Knox) @GeTex working on writing to memory using the Futex(towelroot) exploit to load some kernel modules.
Relevant links:
http://blog.nativeflow.com/the-futex-vulnerability
http://blog.nativeflow.com/escalating-futex
http://blog.nativeflow.com/pwning-the-kernel-root
====================================Original post====================================
So far we know what Beaups did to get the 15 series chip exploit.
1) Get vendor cmds (we know its cmd26 to reprogram the cid but do not know the args for toshiba chips)
2) Dump eMMC firmware
3) Look through code for how it is programmed
4) Create a tool to use this info and reprogram the CID
We need to
1) Find the args for the command
2) dump toshiba emmc controler's firmware
3) Find how to program CID
4) Modify Beaups tool
Alternatively, If we know what the controller is and the pin map we could manually dump the firmware with existing SD card tools (Wouldn't count on it)
Not sure where you can find it but if you can dump the chip's firmware then we dont need the first step
Relevant docs:
https://drive.google.com/open?id=0BxoK4ISYhlfbbW02TzJ0VlhoV0E
https://drive.google.com/open?id=0BxoK4ISYhlfbdDZvbGxxV2F3OUU
https://github.com/beaups/SamsungCID (read samdunk disclosure)
http://toshiba.semicon-storage.com/us/product/memory/nand-flash/mlc-nand/emmc.html (Our chip is the THGBMHG7C1LBAIL I believe)

http://forum.xda-developers.com/showpost.php?p=37936242&postcount=72
Dumping emmc Ram, Not sure if that helps

deleted

I don't think I can dump the firmware using a JTAG box due to security, can i?

GeTex said:
I don't think I can dump the firmware using a JTAG box due to security, can i?
Click to expand...
Click to collapse
it doesn't look good the JDEC spec says most of those registers are write once read only
what I wanna know is where in the boot process does it check the CID registers and is there anything we can do to manipulate it to read whatever value we feed it

GeTex said:
I don't think I can dump the firmware using a JTAG box due to security, can i?
Click to expand...
Click to collapse
I do not think you can jtag the eMMC chip. and @Legitsu that would involve modifying the bootloader or kernel which we would need an unlocked bl for.

autonomousperson said:
I do not think you can jtag the eMMC chip. and @Legitsu that would involve modifying the bootloader or kernel which we would need an unlocked bl for.
Click to expand...
Click to collapse
maby not what if you modified the locked bootloader.yes it would normally fail the SB and crc checks but its not entirely out
there is also some interesting bits in the cmds uses to read registers
and kernel mods can be done with modules

Legitsu said:
maby not what if you modified the locked bootloader.yes it would normally fail the SB and crc checks but its not entirely out
there is also some interesting bits in the cmds uses to read registers
and kernel mods can be done with modules
Click to expand...
Click to collapse
I think the CID check is before the kernel is even loaded.... Seems to be all with the bootloader

autonomousperson said:
I think the CID check is before the kernel is even loaded.... Seems to be all with the bootloader
Click to expand...
Click to collapse
I would think so as well but may not stop us from doing some tricks such as chainloading exploits
where we boot from the locked aboot patch the cid and somehow make it reset and load the other aboot and feed it that CID
kexec is very very close to being working on the S4 @Surge1223 how up2date is the source for that in your repo ?
honestly I think kexec is going to be the future for all devices its less effort and more viable then finding the rare exploits for actually unlocking the bootloader
I just don't have the time I once did and my skills are rusty AF

Legitsu said:
I would think so as well but may not stop us from doing some tricks such as chainloading exploits
where we boot from the locked aboot patch the cid and somehow make it reset and load the other aboot and feed it that CID
kexec is very very close to being working on the S4 @Surge1223 how up2date is the source for that in your repo ?
honestly I think kexec is going to be the future for all devices its less effort and more viable then finding the rare exploits for actually unlocking the bootloader
I just don't have the time I once did and my skills are rusty AF
Click to expand...
Click to collapse
We can try to get it to go into rescue mode where it boots off sd. Idk how far that will get us as sd boot still needs to be signed (I think). Even if we try to chain load something its only temp and will need to be done every boot and could get messy. Chaining the CID directly is the best option.

autonomousperson said:
We can try to get it to go into rescue mode where it boots off sd. Idk how far that will get us as sd boot still needs to be signed (I think). Even if we try to chain load something its only temp and will need to be done every boot and could get messy. Chaining the CID directly is the best option.
Click to expand...
Click to collapse
see I know the S4 the sdboot no longer works as of NK4 but it works on the S5 ?
recovery mode may show us more info
I wonder what would happen if you imaged a devedtion bootloader and then killed the aboot and let it try from the sdcard (would tell us what it checks when attempting recovery)
messy would be fine as it would provide more info

Legitsu said:
see I know the S4 the sdboot no longer works as of NK4 but it works on the S5 ?
recovery mode may show us more info
I wonder what would happen if you imaged a devedtion bootloader and then killed the aboot and let it try from the sdcard (would tell us what it checks when attempting recovery)
messy would be fine as it would provide more info
Click to expand...
Click to collapse
The dev edition BL on sd would work as its signed BUT it wont display as a dev editon as the CID doesnt match. I think as soon as you touch the sd card bl it will refuse to boot. Unfortunately I no longer have a vzw test device (pulled the samsung eMMC BGA off of it 0/10 would not recommend )

autonomousperson said:
The dev edition BL on sd would work as its signed BUT it wont display as a dev edition as the CID does not match. I think as soon as you touch the sd card bl it will refuse to boot. Unfortunately I no longer have a vzw test device (pulled the samsung eMMC BGA off of it 0/10 would not recommend )
Click to expand...
Click to collapse
I wonder if there is a way to manipulate the CID while its in qualcom-recovery
once you boot it as a DEV edition that opens a lot of doors to do other things
I am still reading the JDEC spec pdf nothing so far

Legitsu said:
I wonder if there is a way to manipulate the CID while its in qualcom-recovery
once you boot it as a DEV edition that opens a lot of doors to do other things
I am still reading the JDEC spec pdf nothing so far
Click to expand...
Click to collapse
Renember that its just a general specification, toshiba has to follow all of it but they can change or add extra features. They said they had some extra security features or something.
http://toshiba.semicon-storage.com/ap-en/product/memory/nand-flash/mlc-nand/emmc.html
THGBMHG7C2LBAIL
Products which applied "Command Queuing" and "Secure Write Protection" functions standardized in JEDEC e・MMC™ Version 5.1 as optional features.

autonomousperson said:
Renember that its just a general specification, toshiba has to follow all of it but they can change or add extra features. They said they had some extra security features or something.
http://toshiba.semicon-storage.com/ap-en/product/memory/nand-flash/mlc-nand/emmc.html
THGBMHG7C2LBAIL
Products which applied "Command Queuing" and "Secure Write Protection" functions standardized in JEDEC e・MMC™ Version 5.1 as optional features.
Click to expand...
Click to collapse
yes but the JDEC spec exists for a reason changing that spec opens you to creating other flaws :>
and neither of those have anything todo with the registers we are interested in

Idk what to do then. The stuff we want (cid) is managed by the eMMC firmware. The bl then reads and compares it to the aboot. We could try a man in the middle thing but we would need it to load before the check happens.

autonomousperson said:
Idk what to do then. The stuff we want (cid) is managed by the eMMC firmware. The bl then reads and compares it to the aboot. We could try a man in the middle thing but we would need it to load before the check happens.
Click to expand...
Click to collapse
read though page 28/29/30/ect of *B51 pdf
look at how they describe the alt operation mode
it says you can set the csd register I wonder what else you can set durning that time (ignore for the moment we don't have a way of setting any registers yet ..(

Legitsu said:
read though page 28/29/30/ect of *B51 pdf
look at how they describe the alt operation mode
it says you can set the csd register I wonder what else you can set durning that time (ignore for the moment we don't have a way of setting any registers yet ..(
Click to expand...
Click to collapse
We would have to find a way to trick it into thinking it is booting. (I think it is first boot, not every boot)

autonomousperson said:
We would have to find a way to trick it into thinking it is booting. (I think it is first boot, not every boot)
Click to expand...
Click to collapse
indeed but progress

Legitsu said:
indeed but progress
Click to expand...
Click to collapse
BUT
We would still need to figure out how to get it to write a new CID (specifically what tf cmd 26 is)
OR
We can use vendor commands like Beaups (would need to find them)

Does Latest TWRP & Supersu together work well with latest 7.1.1 on Pixle device

Does latest Twrp & root together work well with latest 7.1.1. just got my real blue pixel, read some posts and found the new device differs from the old ones.
But I have to root to use the TitaniumBackup and to enable location report and brevent.

and how to tell whether the device is from google store or it is a verizon based device. As I found Verizon login APP under app settings

Yes to first post and as for second check the purchase receipt.
Not kidding. Factory Verizon >is flashed with a Verizon firmware or euro or other, but it is possible to flash any factory image to any Pixel so unclear ultimately without receipt. Check Build Number in settings and compare to factory image list on Google
Latest firmware is for all carriers, so no way to tell without just knowing.. Maybe!
(BTW I do NOT have a Verizon Pixel, but i do have those apps. They install more stuff and enable features if your carrier is Verizon)
Sent from my sailfish using XDA Labs

I manually updated to 26Q with the Google image so I'm not sure how to tell anymore (have VZW Pixel). The way it works is Google will issue the security patches and Verizon will handle the firmware updates. I believe the VZW build will have a different code than the Google updates. That's why the Verizon branded units will get locked down with 7.1.1 and the Play editions won't.
As for TWRP/SU I have the latest and so far I see no issues.

FernBch said:
I manually updated to 26Q with the Google image so I'm not sure how to tell anymore (have VZW Pixel). The way it works is Google will issue the security patches and Verizon will handle the firmware updates. I believe the VZW build will have a different code than the Google updates. That's why the Verizon branded units will get locked down with 7.1.1 and the Play editions won't.
As for TWRP/SU I have the latest and so far I see no issues.
Click to expand...
Click to collapse
Here is my theory.
Google will post the code and it will be the same as Google's, there won't be any separate builds. The locking is some trickery in the code. Based on CID or IMEI.
Sent from my Pixel XL using XDA Labs

TonikJDK said:
Here is my theory.
Google will post the code and it will be the same as Google's, there won't be any separate builds. The locking is some trickery in the code. Based on CID or IMEI.
Sent from my Pixel XL using XDA Labs
Click to expand...
Click to collapse
The locking isn't trickery in the code. Verizon will do as they always have. The update they push will have a locked, AKA different, bootloader. Since that component is different the build will be different. Same old story......
If they were the same builds there would be no way to differentiate between the Verizon and Google versions.
---------- Post added at 01:10 PM ---------- Previous post was at 12:54 PM ----------
You may want to read more here. Pay particular attention to items 5&6. There is no guarantee that the updates for the Pixel/Pixel XL sold by Verizon will get an OS update at the same rime or on the same schedule as the Google sold devices. This will like lead to different build numbers so the two devices can be distinguished. Google will push security updates to all devices but Verizon has control over OS updates to the devices they sell.
https://www.google.com/url?sa=t&sou...SEx8oJKWAQNk7lueQ&sig2=AWtYaP2LMe9rsKQeDjdviQ

FernBch said:
The locking isn't trickery in the code. Verizon will do as they always have. The update they push will have a locked, AKA different, bootloader. Since that component is different the build will be different. Same old story......
If they were the same builds there would be no way to differentiate between the Verizon and Google versions.
---------- Post added at 01:10 PM ---------- Previous post was at 12:54 PM ----------
You may want to read more here. Pay particular attention to items 5&6. There is no guarantee that the updates for the Pixel/Pixel XL sold by Verizon will get an OS update at the same rime or on the same schedule as the Google sold devices. This will like lead to different build numbers so the two devices can be distinguished. Google will push security updates to all devices but Verizon has control over OS updates to the devices they sell.
https://www.google.com/url?sa=t&sou...SEx8oJKWAQNk7lueQ&sig2=AWtYaP2LMe9rsKQeDjdviQ
Click to expand...
Click to collapse
The bootloaders are the same. It's more likely verizon phones are recognized by the IMEI and or CID. If the difference was in the bootloader, you could unlock, flash a Google bootloader (if there was a difference between the Google and Verizon bootloaders) and then relock, update to 7.1.1 and then unlock again. Something you can't do. If you tried it, you'd wish you hadn't.
A simple way to know if your phone is a Verizon or Google phone is to look in developer options and see if OEM unlocking is available to you. If it's grayed out and you can't select it, it's a Verizon device. If not grayed out and you are able to select it, it's a Google device.

Thank you all, the phone is from Google store as the bootloader can easily be unlocked.

FernBch said:
I manually updated to 26Q with the Google image so I'm not sure how to tell anymore (have VZW Pixel). The way it works is Google will issue the security patches and Verizon will handle the firmware updates. I believe the VZW build will have a different code than the Google updates. That's why the Verizon branded units will get locked down with 7.1.1 and the Play editions won't.
As for TWRP/SU I have the latest and so far I see no issues.
Click to expand...
Click to collapse
Hi there. Verizon builds were different than Google's pre 7.1.1 but now they're the same. Reference my post here (applicable part quoted below) and the Google Nexus/Pixel firmware page https://developers.google.com/android/images.
roirraW "edor" ehT said:
One question I've been wondering about and haven't noticed if it's been addressed anywhere, the 7.1.1 builds are all the same for Verizon and non-Verizon. They're all NMF26O for the first release of 7.1.1 and NMF26Q for the second OTA of it.
So I'm wondering if putting a Verizon SIM in does anything anymore if you're on a stock 7.1.1 image. I could relatively easily find out, but it's not a huge priority.
Also, as long as you already unlocked the bootloader, nothing will re-lock it, even Verizon OTAs, unless you manually do so.
No idea if there'll be Verizon-specific builds again later.
Click to expand...
Click to collapse
Might soon find out, reportedly there's a new update for Verizon soon: NMF26U. It's not on Google's page, at least yet. http://forum.xda-developers.com/pixel/how-to/verizon-update-nmf26u-t3527199/post70281819#post70281819

roirraW "edor" ehT said:
Hi there. Verizon builds were different than Google's pre 7.1.1 but now they're the same. Reference my post here (applicable part quoted below) and the Google Nexus/Pixel firmware page https://developers.google.com/android/images.
Might soon find out, reportedly there's a new update for Verizon soon: NMF26U. It's not on Google's page, at least yet. http://forum.xda-developers.com/pix...ate-nmf26u-t3527199/post70281819#post70281819
Click to expand...
Click to collapse
This would fit the pattern for Verizon. In the past, irregardless of device/manufacturer, Verizon would issue a new build. The new build would have a different bootloader that had whatever exploit patched to prevent the new bootloader from being unlocked. The build number would also be different so the different variants could be distinguished from each other. Been on Big Red for a number of years and have watched this game play out time after time.
The details are not exactly clear but the original story from Google/VZW was Google will update all Google sold devices and issue security patches to all devices no matter where bought from. Any OS updates to Verizon devices would come from Verizon. They get the next build from the OEM and make sure it is up to their requirements (and patch if needed) then push it to their devices. Somewhere in the process I am guessing that there is a way to tell what Google sold from what Verizon sold. This would prove or disprove that only Verizon sold devices can actually get locked down if still locked.
Google may have tried to say no to VZW control like that but when it all settles out money is the key. And Google is going to make a bunch......
---------- Post added at 12:07 AM ---------- Previous post was at 12:00 AM ----------
Reading the article and the linked article inside it seems to point out that NMF26U is targeted towards the UK carrier and is supposed to address MMS issues.

FernBch said:
This would fit the pattern for Verizon. In the past, irregardless of device/manufacturer, Verizon would issue a new build. The new build would have a different bootloader that had whatever exploit patched to prevent the new bootloader from being unlocked.
Reading the article and the linked article inside it seems to point out that NMF26U is targeted towards the UK carrier and is supposed to address MMS issues.
Click to expand...
Click to collapse
Regarding the bootloader, it's not handled the same way as on some other devices. The bootloader is the same on both Google Store and Verizon Pixels.
Also from my understanding, the vulnerability wasn't in the bootloader itself.

Take good care of installing TWRP
According to the guide from the developer, I install TWRP step by step,
after fastboot boot path/to/twrp.img, the lockscreen pin/pattern/password did not get prompted.
So I have to reboot, then lost all my data.
Therefore, it is necessary to clear all your locksreen pin/pattern/password before using TWRP

roirraW "edor" ehT said:
Regarding the bootloader, it's not handled the same way as on some other devices. The bootloader is the same on both Google Store and Verizon Pixels.
Also from my understanding, the vulnerability wasn't in the bootloader itself.
Click to expand...
Click to collapse
Ah. That I did not understand.
So, I guess there is something else I need to learn.

bush911 said:
According to the guide from the developer, I install TWRP step by step,
after fastboot boot path/to/twrp.img, the lockscreen pin/pattern/password did not get prompted.
So I have to reboot, then lost all my data.
Therefore, it is necessary to clear all your locksreen pin/pattern/password before using TWRP
Click to expand...
Click to collapse
I don't believe it matters whether or not there was a password. I've tested this with security on one Pixel, and without on a XL. I flashed stock to both phones prior to testing. I used a PIN password on the Pixel, and never ever installed any type of security on the XL. The key is whether or not the phone is encrypted. I don't have a Google store phone as both of mine came from Verizon. On mine, they were encrypted out of the box. You can see this status under Security, Encryption. Both phones have troubles, but only one out of 6 entrances into TWRP RC1, that they were not successfully decrypted. I then used the Reboot to Recovery from within TWRP, still couldn't decrypt after several reboots. However, in my experiments, if I powered off the devices completely, my very next execution of TWRP decrypted successfully. I don't recall a case in which I had problems after a power off. Just does not make sense. When TWRP doesn't decrypt, you'd see that warning right at the first screen, unless you had previously checked the "Do not warn me again" box. Then you'll see your folders and files all understandably garbled.
I then attempted a couple methods to decrypt the phones from the get-go to see if TWRP would behave if there was no encryption. However, both methods require Magisk which no longer works with 7.1.1. So my attempt to decrypt went nowhere.
All that said, you should never lose your data though. If TWRP doesn't decrypt the phone, and you don't do any file management, the data is still there untouched.

Maybe you are right, I did not catch you very well.
My Pixel was from Google store I tried twice to install TWRP RC1 strictly following the guidelines by the developer.
For the first time, the phone with pattern set up, TWRP did not get me prompted to enter the pin and ended up losing all my personal data.
After rebooted several times, I cleared the pattern and succeeded.
My point is whether TWRP prompts you to enter pin or not, as I never saw this.
quangtran1 said:
I don't believe it matters whether or not there was a password. I've tested this with security on one Pixel, and without on a XL. I flashed stock to both phones prior to testing. I used a PIN password on the Pixel, and never ever installed any type of security on the XL. The key is whether or not the phone is encrypted. I don't have a Google store phone as both of mine came from Verizon. On mine, they were encrypted out of the box. You can see this status under Security, Encryption. Both phones have troubles, but only one out of 6 entrances into TWRP RC1, that they were not successfully decrypted. I then used the Reboot to Recovery from within TWRP, still couldn't decrypt after several reboots. However, in my experiments, if I powered off the devices completely, my very next execution of TWRP decrypted successfully. I don't recall a case in which I had problems after a power off. Just does not make sense. When TWRP doesn't decrypt, you'd see that warning right at the first screen, unless you had previously checked the "Do not warn me again" box. Then you'll see your folders and files all understandably garbled.
I then attempted a couple methods to decrypt the phones from the get-go to see if TWRP would behave if there was no encryption. However, both methods require Magisk which no longer works with 7.1.1. So my attempt to decrypt went nowhere.
All that said, you should never lose your data though. If TWRP doesn't decrypt the phone, and you don't do any file management, the data is still there untouched.
Click to expand...
Click to collapse

bush911 said:
Maybe you are right, I did not catch you very well.
My Pixel was from Google store I tried twice to install TWRP RC1 strictly following the guidelines by the developer.
For the first time, the phone with pattern set up, TWRP did not get me prompted to enter the pin and ended up losing all my personal data.
After rebooted several times, I cleared the pattern and succeeded.
My point is whether TWRP prompts you to enter pin or not, as I never saw this.
Click to expand...
Click to collapse
No big deal. I'm saying there are two different components at play here. One is the built-in encryption structure on the phone. The other is the user-assigned password (PIN, pattern, fingerprint). The PIN, pattern, fingerprint are used to access your phone -- we all recognize that. However, whether or not that password is set, the phone's encryption setting is set elsewhere. Namely, it's under Settings - Encryption. My phone can be passworded, but its data is not encrypted. Or vice versa, it can be encrypted but does not require an unlock to access it.
I'm also making the observation that TWRP sometimes, for whatever reason, does not decrypt the Pixel successfully. Many times I've entered the correct PIN on the TWRP screen, it advanced to the menu screen, but folders and docs were still garbled by encryption. Same thing would also happen on my XL without any password. After I powered off both phones, TWRP magically decrypted both phones, with and without PIN code, successfully by the fact that they now show folders and files properly. So, in my logic, once TWRP irons out its decrypting glitches, this issue goes away. Either that or whenever I figure out how to disable encryption permanently.

TA Backup by using ‘Spectre’ and ‘Meltdown’ CPU vulnerabilities

Hello to all great developers.
As we know that sony Xperia Devices are ‘Spectre’ and ‘Meltdown’ CPU vulnerabilities
So it is possible to use these vulnerabilities and make a tool that can backup TA Partition of Xperia XZ Premium ?
@munjeni
@DevShaft
@rayman
@serajr
@IgorEisberg
@zxz0O0
@AdrianDC
 @sToRm//

Yes, it would be possible.
Someone just have to write something for it.
This would also be possible by abusing any critical vulnerability listed on the Android security bulletin.

zohaib0001 said:
Hello to all great developers.
As we know that sony Xperia Devices are ‘Spectre’ and ‘Meltdown’ CPU vulnerabilities
So it is possible to use these vulnerabilities and make a tool that can backup TA Partition of Xperia XZ Premium ?
Click to expand...
Click to collapse
You didn't ask @sToRm//

taking this further, is it possible to gain root access without having to unlock bootloader and flash a custom ROM? reason I ask is that there are a number of users out here with locked bootloaders and are unable to unlock them,

dazza9075 said:
taking this further, is it possible to gain root access without having to unlock bootloader and flash a custom ROM? reason I ask is that there are a number of users out here with locked bootloaders and are unable to unlock them,
Click to expand...
Click to collapse
No

dazza9075 said:
taking this further, is it possible to gain root access without having to unlock bootloader and flash a custom ROM? reason I ask is that there are a number of users out here with locked bootloaders and are unable to unlock them,
Click to expand...
Click to collapse
Spectre and Meltdown can only read kernel data as far as I'm aware.
TA backups would prob also take longer than usual using this since those exploits arent the fastest from what demos Ive seen

Mackay53 said:
No
Click to expand...
Click to collapse
Chocolate tea Pot
BigBrainAFK said:
Spectre and Meltdown can only read kernel data as far as I'm aware.
TA backups would prob also take longer than usual using this since those exploits arent the fastest from what demos Ive seen
Click to expand...
Click to collapse
Ok, so the exploits can read kernel level information but cant execute it which would mean it cant execute code to root a device, ok
but would it be possible to read and exploit other apps running, or gain access to memory that system apps or services are using which in turn could allow further exploits? I have no idea but it seems to me if we can take information out of secure memory, then if the right info was there to be taken then perhaps that might be useful?

Any update ?

This sounds very interesting... anybody here to help?

almost April. hope there will be one TA backup tool based on Spectre and Meltdown soon. I keep my XXP at 1st firmware of Oreo only for this purpose. XD So laggy but I won't move to current version unless i got TA backup'ed.

I'm holding back updates as well for this reason.
However, seeing that most people already updated and that there's noone working into this direction, I don't think there's a reason to keep doing this.

4rz0 said:
I'm holding back updates as well for this reason.
However, seeing that most people already updated and that there's noone working into this direction, I don't think there's a reason to keep doing this.
Click to expand...
Click to collapse
I think this is possible, though I don't have the skill to write an exploit for it.
First, the Meltdown vulnerability probably doesn't exist on the SD835, so we're relegated to the Spectre variants.
But essentially, it should be a matter of writing a Spectre exploit that can read the private TA sectors by priming the cache with known data, then speculatively calling functions which rely on calls to the private TA functions.
At the very least, it should, theoretically, be possible to get the device specific keys.
That said, I'm still applying updates to my XZ1c, simply because I don't want other people exploiting my device.
If you're holding back on updates, you may want to consider the fact that you can still revert back to older firmware versions if an exploit does become available. So even if you take an update, you could manually flash the device to an older firmware later.
On the XZ1c, the bootloader changed from LA1_1_O_77 with firmware 47.1.A.2.374 to version LA1_1_O_79 in firmware 47.1.A.5.51. I suspect that you can still flash the older bootloader, since the signing key's version signature hasn't changed, but I just choose to not flash the newer bootloader.
Basically, if you're paranoid that Sony will lock you out of flashing older firmware:
1 - Wait to see if anyone is reporting that you can't go back to an older firmware version.
2 - Don't flash updated bootloader versions if you don't have to, and
3 - Don't worry about updating everything else.
Otherwise, you're just risking your own security for no real benefit if you aren't keeping your firmware updated.

I know your idea.
But flashing backward will most likely ruin your data section.
And some apps just don't allow you to perform "adb backup".
Like some apps with security concerns or the authors of them just won't want data to be analyzed.
So that's one point I don't wanna upgrade.
pbarrette said:
I think this is possible, though I don't have the skill to write an exploit for it.
First, the Meltdown vulnerability probably doesn't exist on the SD835, so we're relegated to the Spectre variants.
But essentially, it should be a matter of writing a Spectre exploit that can read the private TA sectors by priming the cache with known data, then speculatively calling functions which rely on calls to the private TA functions.
At the very least, it should, theoretically, be possible to get the device specific keys.
That said, I'm still applying updates to my XZ1c, simply because I don't want other people exploiting my device.
If you're holding back on updates, you may want to consider the fact that you can still revert back to older firmware versions if an exploit does become available. So even if you take an update, you could manually flash the device to an older firmware later.
On the XZ1c, the bootloader changed from LA1_1_O_77 with firmware 47.1.A.2.374 to version LA1_1_O_79 in firmware 47.1.A.5.51. I suspect that you can still flash the older bootloader, since the signing key's version signature hasn't changed, but I just choose to not flash the newer bootloader.
Basically, if you're paranoid that Sony will lock you out of flashing older firmware:
1 - Wait to see if anyone is reporting that you can't go back to an older firmware version.
2 - Don't flash updated bootloader versions if you don't have to, and
3 - Don't worry about updating everything else.
Otherwise, you're just risking your own security for no real benefit if you aren't keeping your firmware updated.
Click to expand...
Click to collapse

huawei p20 qu1ckr00t possible?

Hello Huawei P20 Mates,
i read about it shortly, that there would be an exploit that allows root access. i read about it on this website httpx://helpnetsecurity.com/2019/10/17/android-root-cve-2019-2215/ (need to change it since new users arent allowed to use links in this forum <.<). the code for accessing root would be even available on github (i wonder why, wait - isn't this illegal?). but anyway, i read from another site that the huawei p20 with october 2019 update would be vulnerable for this one. so basically, its an now open door for us huawei p20 users to root our phones, isnt it?
i just wonder how to use this. i understand the process of compiling it, but what did he mean with "change with device code"? maybe i just didnt get it right. does anyone know what he is talking about in his github project?

p0w3r_off said:
Hello Huawei P20 Mates,
i read about it shortly, that there would be an exploit that allows root access. i read about it on this website httpx://helpnetsecurity.com/2019/10/17/android-root-cve-2019-2215/ (need to change it since new users arent allowed to use links in this forum <.<). the code for accessing root would be even available on github (i wonder why, wait - isn't this illegal?). but anyway, i read from another site that the huawei p20 with october 2019 update would be vulnerable for this one. so basically, its an now open door for us huawei p20 users to root our phones, isnt it?
i just wonder how to use this. i understand the process of compiling it, but what did he mean with "change with device code"? maybe i just didnt get it right. does anyone know what he is talking about in his github project?
Click to expand...
Click to collapse
As far as I know, at the moment No. Huawei stopped releasing boot lock codes.
On the positive side, and thing May change on Android 10
I confirmed this with one click root and some other dev database which I should be able to post her as I believe it doesn't breach the rules since its a developer sits that should imo be linked here but I don't want to post it here but I can pm you the link.
Fundermentaly speaking, I China is rumoured to merge and work hand in hand with Google after trump stepped up the game. It was posted on AC, and a feed I received from the app MEDIUM.
tldr no boot unlock, but no root.

2ISAB said:
As far as I know, at the moment No. Huawei stopped releasing boot lock codes.
On the positive side, and thing May change on Android 10
I confirmed this with one click root and some other dev database which I should be able to post her as I believe it doesn't breach the rules since its a developer sits that should imo be linked here but I don't want to post it here but I can pm you the link.
Fundermentaly speaking, I China is rumoured to merge and work hand in hand with Google after trump stepped up the game. It was posted on AC, and a feed I received from the app MEDIUM.
tldr no boot unlock, but no root.
Click to expand...
Click to collapse
did you even read what i wrote or used the link i told here? i told, that there is a 0-Day Exploit. Its *not* about boot lock codes or fastboot. its about a exploit, using to obtain root rights. then, you could easily read out the nvme file. but i dont understand how to use this relatively new exploit.

p0w3r_off said:
Hello Huawei P20 Mates,
i read about it shortly, that there would be an exploit that allows root access. i read about it on this website httpx://helpnetsecurity.com/2019/10/17/android-root-cve-2019-2215/ (need to change it since new users arent allowed to use links in this forum <.<). the code for accessing root would be even available on github (i wonder why, wait - isn't this illegal?). but anyway, i read from another site that the huawei p20 with october 2019 update would be vulnerable for this one. so basically, its an now open door for us huawei p20 users to root our phones, isnt it?
i just wonder how to use this. i understand the process of compiling it, but what did he mean with "change with device code"? maybe i just didnt get it right. does anyone know what he is talking about in his github project?
Click to expand...
Click to collapse
Yeah it might work, but if you try to modify something using root it would Brick cause of SecBoot.

madoxx77 said:
Yeah it might work, but if you try to modify something using root it would Brick cause of SecBoot.
Click to expand...
Click to collapse
you too, didnt fully read what i wrote, or did you? why are the answers always short like "no wont work because xy - but we ignore z, w and v"?
the thing is, you should *not* change the phone with this exploit. i wouldnt have any interest in changing it with this method. i have more interest in getting the nvme bootloader unlock code which most certainly is stored there since it was with the old huawei phones before that way. like you know, obtaining root rights, saving nvme partition, then open nvme partition with hex editor and then search for BL Code. then, i would unlock the phone the regular way. do you understand what im trying to do?

p0w3r_off said:
you too, didnt fully read what i wrote, or did you? why are the answers always short like "no wont work because xy - but we ignore z, w and v"?
the thing is, you should *not* change the phone with this exploit. i wouldnt have any interest in changing it with this method. i have more interest in getting the nvme bootloader unlock code which most certainly is stored there since it was with the old huawei phones before that way. like you know, obtaining root rights, saving nvme partition, then open nvme partition with hex editor and then search for BL Code. then, i would unlock the phone the regular way. do you understand what im trying to do?
Click to expand...
Click to collapse
Calm down you haven't said anything about bootloader code in original post, simply you cannot obtain BL code cause it's encrypted(not in NVME partition) ? In EMUI 8 it was possible to unlock bootloader using modified NVME but in EMUI 9 you cannot do it. There is one way to obtain BL code but you need to disassemble your phone and it costs like 30 euro, you can find it in mate 20 forum, it's called BLK-RSA

madoxx77 said:
Calm down you haven't said anything about bootloader code in original post, simply you cannot obtain BL code cause it's encrypted(not in NVME partition) In EMUI 8 it was possible to unlock bootloader using modified NVME but in EMUI 9 you cannot do it. There is one way to obtain BL code but you need to disassemble your phone and it costs like 30 euro, you can find it in mate 20 forum, it's called BLK-RSA
Click to expand...
Click to collapse
okaaay this is news to me that this changed in EMUI 9. but, if that is the case, then maybe we should really check if the exploit is maybe working for older versions than android 9? especially the version before the may/june patch 2018 may be different. so the roadmap may be:
- downgrade to EMUI 8.1 version *before* security patch May 2018
- try to use exploit to get root rights in order to read (non-encrypted? - i need more information on this) bootloader code?
two questions are rising here: is the exploit only working for android 9, or is this exploit existing for longer time and versions before? i dunno how it is here. and second thing, is the BL Code already encrypted in EMUI 8.1?
the reason why im asking all of this is, that it may be better to get these informations before i try to do something and even brick my phone in the worst case. or doing hours of work without any result (which would be simply a waste). writing a few lines takes only a few minutes - at all.

p0w3r_off said:
okaaay this is news to me that this changed in EMUI 9. but, if that is the case, then maybe we should really check if the exploit is maybe working for older versions than android 9? especially the version before the may/june patch 2018 may be different. so the roadmap may be:
- downgrade to EMUI 8.1 version *before* security patch May 2018
- try to use exploit to get root rights in order to read (non-encrypted? - i need more information on this) bootloader code?
two questions are rising here: is the exploit only working for android 9, or is this exploit existing for longer time and versions before? i dunno how it is here. and second thing, is the BL Code already encrypted in EMUI 8.1?
the reason why im asking all of this is, that it may be better to get these informations before i try to do something and even brick my phone in the worst case. or doing hours of work without any result (which would be simply a waste). writing a few lines takes only a few minutes - at all.
Click to expand...
Click to collapse
You cannot downgrade to EMUI 8.1 before May 2018cause of xloader, only way is to open your phone and flash old firmware through test points. Also it can maybe work on EMUI 8 but BL code is still encrypted in there, yeah you can unlock bootloader through NVME but you cannot obtain BL code. The only way is as I said before the BLK RSA method.

madoxx77 said:
You cannot downgrade to EMUI 8.1 before may cause of xloader, only way is to open your phone and flash old firmware through test points. Also it can maybe work on EMUI 8 but BL code is still encrypted in there, yeah you can unlock bootloader through NVME but you cannot obtain BL code. The only way is as I said before the BLK RSA method.
Click to expand...
Click to collapse
that is absolutely wrong? i did in the past via the tool from huawei and yeah that was w/o *any* problem? and that was only a few months ago "where i already had EMUI9"? are you even *want* to root/unlock it, or do you just want to say what is not possible but in reality it is?

p0w3r_off said:
that is absolutely wrong? i did in the past via the tool from huawei and yeah that was w/o *any* problem? and that was only a few months ago "where i already had EMUI9"? are you even *want* to root/unlock it, or do you just want to say what is not possible but in reality it is?
Click to expand...
Click to collapse
Why you have to be so offensive ?I just wanted to help you not to brick your phone if you try to do some **** with it. I forgot to say that you can't downgrade from EMUI 9.1 to EMUI 8.1,in past if you had EMUI 9 it was possible to downgrade to EMUI 8.1 via Hisuite

p0w3r_off said:
Hello Huawei P20 Mates,
i read about it shortly, that there would be an exploit that allows root access. i read about it on this website httpx://helpnetsecurity.com/2019/10/17/android-root-cve-2019-2215/ (need to change it since new users arent allowed to use links in this forum <.<). the code for accessing root would be even available on github (i wonder why, wait - isn't this illegal?). but anyway, i read from another site that the huawei p20 with october 2019 update would be vulnerable for this one. so basically, its an now open door for us huawei p20 users to root our phones, isnt it?
i just wonder how to use this. i understand the process of compiling it, but what did he mean with "change with device code"? maybe i just didnt get it right. does anyone know what he is talking about in his github project?
Click to expand...
Click to collapse
I tried running both the original PoC code and quickroot on my P20 Pro (EMUI 9.1.0.328, last patched 1/8/2019) but this EMUI version doesn't seem vulnerable, neither PoC yielded elevated permissions. I'm digging some more into this.

cptnfrd said:
I tried running both the original PoC code and quickroot on my P20 Pro (EMUI 9.1.0.328, last patched 1/8/2019) but this EMUI version doesn't seem vulnerable, neither PoC yielded elevated permissions. I'm digging some more into this.
Click to expand...
Click to collapse
Okay glad to hear you try that. Maybe going back to EMUI 9 would help. The dload method still should work, right?

p0w3r_off said:
Okay glad to hear you try that. Maybe going back to EMUI 9 would help. The dload method still should work, right?
Click to expand...
Click to collapse
I'm not sure, the descriptions of the vulnerability mention that the P20 is affected - one site says only on Android 8 so it's unclear. I'm not familiar with the dload method, can you post a link?
The thing is, as maddoxx77 posted earlier, even if this worked as a way to gain root we'd still have no way to obtain the BL code and possibly only brick the device while trying. Perhaps some hardware based method could work but I don't really have the knowledge or time to dig into it deeper.
F.C.K YOU HUAWEI.

ROM recommendation?

Are there any secure ROMs which allow the bootloader to be relocked, can support Google services and will continue security fix support, after Google ends direct support?
It must support VoLTE on ATT.
Thanks

dzr said:
Are there any secure ROMs which allow the bootloader to be relocked, can support Google services and will continue security fix support, after Google ends direct support?
It must support VoLTE on ATT.
Thanks
Click to expand...
Click to collapse
With no responses, it seems stock firmware and buying a new phone. :-(

dzr said:
With no responses, it seems stock firmware and buying a new phone. :-(
Click to expand...
Click to collapse
You can try graphene OS, although it doesnt come with google services by default, the bootloader is lockable. There is a way to get sanboxed google apps though, so you'll have to look into that.
Personally, i would just install lineage or a GSI from the project treble page and keep the bootloader unlocked. The only security vulnerability an unlocked bootloader would have is if someone stole your physical device. They'll be able to copy your data through usb.
Edit: If you can build and sign lineage yourself with your own keys, there is a way to relock the bootloader but thats beyond my skills.

Is Android 13 gsi working anyway?

allrightlite said:
Is Android 13 gsi working anyway?
Click to expand...
Click to collapse
I don't think the pixel 3a is getting an official Android 13. 3 years of updates is over this may. As for project treble android 13 GSI, they dont exist yet.

Roarmaster said:
You can try graphene OS, although it doesnt come with google services by default, the bootloader is lockable. There is a way to get sanboxed google apps though, so you'll have to look into that.
Personally, i would just install lineage or a GSI from the project treble page and keep the bootloader unlocked. The only security vulnerability an unlocked bootloader would have is if someone stole your physical device. They'll be able to copy your data through usb.
Edit: If you can build and sign lineage yourself with your own keys, there is a way to relock the bootloader but thats beyond my skills.
Click to expand...
Click to collapse
Thank you. I seem to have missed your reply. Graphene looks great except for the fact that they will not support the phone past the end of its official support. As such, that won't help me.
Building lineage by myself, I haven't seen a way to build both lineage and the gaaps... At least including signing the packages. As well, I'm not sure I have any computer which is good enough for the job.
Regarding using unsigned lineage, a supporter of graphene posted that is more than just a physical vulnerability, but it will allow malware to survive a reboot (maybe a reset as well?)
Thanks