Hey guys,
I've been playing around with the firmware on my Moto G and I didn't understand some things related to bootloader/partition table version and I hope someone more knowledgeable can explain me some things, in a more technical way if possible. Links to documentation are also appreciated!
So, apparently you have to keep an eye on bootloader, partition table, and OS versions so they match. You also cannot easily downgrade bootloader versions.
Also, I saw that you can brick your device if you try to flash 5.0.1 ota, then go back to 4.4.2 and flash 4.4.4 ota because of mismatched bootloader versions and will have to wait for official motorola 5.0.1 images.
My first question is why does this happen? If I get stuck on a particular bootloader version (in this case 5.0.1 GPE, right?) why can't I just boot the corresponding OS, why does the device brick (is it incompatible bootloader and partition table, so the bootloader can't find stage 2)?
Second question, apparently you CAN downgrade the bootloader versions, but have to follow some specific steps and use specific files. Why is that? What checks does the devices makes when upgrading bootloaders and what kind of files allow me to downgrade while passing those checks?
Third, why can't you boot older android versions with newer bootloaders? Doesn't the bootloader just initialize some devices and loads the kernel, can't you modify and older kernel to boot with the new bootloader or chainload and older kernel from a newer one? Also why does the boot processes change so frequently when it should be something very stable?
Fourth, what is the rationale behind not allowing you to freely switch bootloader versions?
Well, thats it. Sorry for the long post and thanks to anyone that can help me . Maybe I should post this in android development instead?
I follow .
I believe on Nexus hardware changing Bootloader is an easier process as those devices are deliberately Developer friendly. Motorola are open enough to allow unlocking, but as you have discovered, flashing an older Bootloader is a messy and dangerous process. Perhaps if enough people petitioned for a change, things might be different.
The Bootloader and Kernel are interrelated and that is why newer Bootloader versions break compatibility with previous iterations of Android (each with a unique Kernel.)
It's possible Kernel DEVs could offer a solution, but I suspect the reality is so few people care. The majority of users will get OTA Updates and never go back.
Uh, bump?
Anyone can tell me if there is a more appropriate place to ask question like these?
I hope it will give you some reference in these topics.
http://elinux.org/Android_Booting
http://androidforums.com/threads/android-partitions-kernels-explained.278898/
aryal.subasha said:
I hope it will give you some reference in these topics.
http://elinux.org/Android_Booting
http://androidforums.com/threads/android-partitions-kernels-explained.278898/
Click to expand...
Click to collapse
Thanks, but I already found those in Google and they aren't very useful. Too superficial and both focus on what happens AFTER the kernel is loaded, I'm interested more in the bootloader, how it verifies the signatures, etc.
Anyone?
Related
(As a foreword, I've been searching and trying to find these answers myself but I haven't had much luck. If there are resources out there covering my questions, please direct me there. Thanks!)
Could someone please inform me of the specific difference(s) between the VRALEC and VRALE6 bootloaders? Also any background info would be interesting to know as well (order in which they were leaked, timeframes, circumstances etc).
Next question: I was able to successfully ODIN the VRALEC bootloader (only) to my stock phone on VRBMF1. When I tried to do the same with VRALE6 it failed with a signing-related error. However I was able to flash the VRALE6 directly using the CASUAL utility and that worked fine. I don't understand why/how the phone will allow itself to boot from that file, but wouldn't allow it to be ODIN'd. Could somebody enlighten me? Also, if I were to have tried ODIN'ing the entire VRALE6 bootchain, would that have succeeded?
Also, is there any rationale for using any other bootloader(s)? There appear to be at least 10 different bootloader and/or bootchain version varients out on the web in different places. From what I can gather though, only the two listed above are significant since they are 'unlocked'.
Lastly, which bootloader does the Developer Edition phone use? Does it come unlocked, or is it unlock-able via some web site or something? If it has its own 'special' unlocked bootloader, why could we not simply get a copy and use that on retail phones rather than the old/leaked version widely used now?
B
pluto01 said:
(As a foreword, I've been searching and trying to find these answers myself but I haven't had much luck. If there are resources out there covering my questions, please direct me there. Thanks!)
Could someone please inform me of the specific difference(s) between the VRALEC and VRALE6 bootloaders? Also any background info would be interesting to know as well (order in which they were leaked, timeframes, circumstances etc).
Click to expand...
Click to collapse
Well, for the longest time the VRALEC was titled the "boot chain" and I'm seeing now in Invisiblek's awesome thread over on Rootz, that's not the case anymore. So, I'll preface this by saying referring to both VRALEC and VRALE6 terms as "bootloaders" sounds weird now because VRALEC was originally titled "VRALEC.bootchain.tar".
VRALEC file should be a "tar" and the VRLE6 file should be a "zip." Cool? Here's how to differentiate, the VRALEC.bootloader.tar needs to be flashed in Odin to allow you to install a custom recovery. It is essentially just the first step of several to unlock the bootloader, it is not unlocked at this point. Someone of a more technical background can explain this better but its like this file is hijacking the boot sequence and telling the phone everything is still recognized as official firmware. There's no trigger that prompts the phone to give you the yellow triangle warning. Once a custom recovery is installed, you need to flash in recovery the VRLE6.zip to unlock the bootloader. Both of these files come from a pre-release VZW GSIII that were so graciously provided to AdamOutler by an African-Canadian Sock Monkey. Seriously, check post #317. This also serves to answer your question about times, leaked, etc. Moving on!
Next question: I was able to successfully ODIN the VRALEC bootloader (only) to my stock phone on VRBMF1. When I tried to do the same with VRALE6 it failed with a signing-related error. However I was able to flash the VRALE6 directly using the CASUAL utility and that worked fine. I don't understand why/how the phone will allow itself to boot from that file, but wouldn't allow it to be ODIN'd. Could somebody enlighten me? Also, if I were to have tried ODIN'ing the entire VRALE6 bootchain, would that have succeeded?
Click to expand...
Click to collapse
As I said above, VRALE6 should be a zip file and needs to be flashed in custom recovery NOT Odin. That's the key difference.
Also, is there any rationale for using any other bootloader(s)? There appear to be at least 10 different bootloader and/or bootchain version varients out on the web in different places. From what I can gather though, only the two listed above are significant since they are 'unlocked'.
Click to expand...
Click to collapse
Nope. Idk what you mean by "at least 10 different bootloader and/or bootchain version varients." Maybe there is a "bootloader" per each OTA that we have received? But honestly, every OTA thus far has been rooted/unlocked via almost the exact methods so this is a moot topic. There are only two unlock files of significance for any root/unlock method for the VZW GSIII: VRALE6.zip and VRALEC.tar
Lastly, which bootloader does the Developer Edition phone use? Does it come unlocked, or is it unlock-able via some web site or something? If it has its own 'special' unlocked bootloader, why could we not simply get a copy and use that on retail phones rather than the old/leaked version widely used now?
B
Click to expand...
Click to collapse
Well, AdamOutler actually received some help and got this phone unlocked well before the dev edition was released last year so there was never a need to look towards that device for bootloader unlock help. I have no clue about how to unlock that device and there's been no reason to think about having (at the time) a $650 dev edition GSIII when the retail one was officially unlocked. No clue on compatibility with bootloaders between either device.
Hello,
I was wondering if anyone could help point me towards a working Stock AOSP ROM (No TouchWiz). Is there one in the works for Verizon models?
That's a tall order for this phone. None of the variants have one yet AFAIK. No documentation for the Exynos chip makes it too hard to develop it seems.
Due to the locked bootloader, we can not flash the custom kernel that would be needed to make a stock AOSP rom work. Only TW-based roms will work unless someone figures out how to unlock the bootloader.
There is work being done on porting CyanogenMod to one of the international variants. (this thread for the curious). However, even if that project is successful, it would be useless unless the bootloader for this phone is unlocked to allow installation of custom kernels on the Verizon model. This could, as I understand it come about in a couple of ways. The first is that someone finds an exploit that allows it, a feat that grows harder with each new generation of phone. The second is that there appears to be some question about whether Verizon/Samsung even have the right to lock the bootloader on the phone (I don'e want to make authoritative claims, I haven't really done the legal research, but the discussion starts here, this post also contains a link to a petition).
tl;dr No, this doesn't exist at the moment.
Side note, this kind of post should probably go in Q&A.
Good afternoon people of XDA,
Today is the dawn of a new day. A day where we begin the road to unlocking the bootloader to something that many believe is unlockable. Me and a few other users are starting a bounty to bring the incentive to life for all active developers. You can find my previous thread here. Now, when I say progress has been made, I mean that we have gotten into fastboot, we have donation incentives and we already have root so our tools are there we just have to find the exploit. Every day people are finding new exploits furthering our cause into reaching our goal. Now to the developers who want to pursue this, I've very much so tried to get active commands in fastboot but basically its just a dead fastboot for right now. The board on this phone and technologies behind it are so similar to its predecessors that somethings got to give. If you are interested in this cause, i.e. donating or deving on it, please contact me here, or email me at [email protected]
This is in our grasps friends. Spread the word, grab your fellow developers and lets get this thing to be a free wad of cash for whoever can bust it. Lets do this.
Attached is the spreadsheet for the current donations.
this kind of things never work...i mean, you make a donation and the people or the persons behind the scenes when getting high values like 400-500$ then buy a new phone and move on letting the desired phone to get development in the trash!!
Noooo, people should see, if a year old phone never came to life in development in the first 6-8 months then the development for it is dead and if you like to custumize the phone and flash things you need to move to a more flashable-friend device!
I have to agree with this. The Tmobile version has unlocked bootloader yet barely no development. What would make me that unlocking VS990 bootloader would all of a sudden spur development.
beavis5706 said:
I have to agree with this. The Tmobile version has unlocked bootloader yet barely no development. What would make me that unlocking VS990 bootloader would all of a sudden spur development.
Click to expand...
Click to collapse
I personally (and I think many other users) don't really need cooked roms. With gravity box, xposed and some other apps, I can "cook" my own rom (and believe me, it won't be that hard). All we need is a method for rooting. Using an android without rooting is even worse than an iphone without jailbreaking since iphones are undoubtedly smoother
presariohg said:
I personally (and I think many other users) don't really need cooked roms. With gravity box, xposed and some other apps, I can "cook" my own rom (and believe me, it won't be that hard). All we need is a method for rooting. Using an android without rooting is even worse than an iphone without jailbreaking since iphones are undoubtedly smoother
Click to expand...
Click to collapse
Indeed, a rooting method for version above MM is the most importing thing for us rather than flashing custom rom. However, system-less root is need to root MM or above and this is required modifying boot.img, therefore, bootloader unlocking is need. Unless, we have found a way to sign the modified boot.img to deceive the offical bootloader.
ivangundampc said:
Indeed, a rooting method for version above MM is the most importing thing for us rather than flashing custom rom. However, system-less root is need to root MM or above and this is required modifying boot.img, therefore, bootloader unlocking is need. Unless, we have found a way to sign the modified boot.img to deceive the offical bootloader.
Click to expand...
Click to collapse
What did you mean by "unless"? Have you found an evidence that MM bootloader is unlockable or not?..
presariohg said:
What did you mean by "unless"? Have you found an evidence that MM bootloader is unlockable or not?..
Click to expand...
Click to collapse
I mean even if the bootloader is not unlockable, somethings can be done to let us perform the same things just like bootloader is unlocked.
For example, some dev in G2 and G3 have released a tool called "Bump!" before that can sign any third party image and let it able to be run on offical locked LG bootloader.
source: http://forum.xda-developers.com/lg-g3/orig-development/bump-sign-unlock-boot-images-lg-phones-t2935275
But of course, since LG have fixed the bug, we can no longer do the same tricks now.
In China, there is name ???he has lg tool, this tool can unpack repack kdz tot, add root in tot.
This is weibo id http://m.weibo.cn/u/1684239753
Need help
andy_zhang said:
In China, there is name ???he has lg tool, this tool can unpack repack kdz tot, add root in tot.
This is weibo id
Click to expand...
Click to collapse
Hey, So I've been working to be able to get root, so far I have added root to the system.img and that's all done, I need this tool to be able to repack. Can anyone, or you, contact him and get this tool? This would be so helpful for me to get root and release it!!!!
abine45 said:
Hey, So I've been working to be able to get root, so far I have added root to the system.img and that's all done, I need this tool to be able to repack. Can anyone, or you, contact him and get this tool? This would be so helpful for me to get root and release it!!!!
Click to expand...
Click to collapse
What version of Android you are going to add root? I wonder that you cannot simply add root in /system after Android 6.0.
ivangundampc said:
What version of Android you are going to add root? I wonder that you cannot simply add root in /system after Android 6.0.
Click to expand...
Click to collapse
I'm trying different things but still i need to figure out how to repack a tot to find out what's going to work!! Does anybody know how to get that application?
abine45 said:
I'm trying different things but still i need to figure out how to repack a tot to find out what's going to work!! Does anybody know how to get that application?
Click to expand...
Click to collapse
For MM, unless you've found a way to get the SELinux context needed, repacking the system image will not work.
anyone having any luck with rooting MM?
I think at this point what we really need is a small set of testers who have a good insurance policy on their phones and are willing to risk bricking their phones. We've got the outline of a method which looks viable, but the details haven't been worked out and is hence likely to produce a few bricks before we get it working.
Sorry for dropping of the face of the planet for the past two months. In testing with my device it ended up being FUBAR after wiping my aboot completely and with that the phone would not boot to anything but a black screen. I sent it into LG and after some time they finally just replaced my motherboard. But the absolute sad part is that they have me upgraded to 6.0 which absolutely is crushing my world. SO until further notice I will not be testing the unlocking of the bootloader anymore but I will make efforts here in a few weeks to start work on rooting the device. @alvislee[email protected]
Introduction
This is the bootloader unlock from ZTE. It was provided to me in private email by a ZTE engineer.
Warning
This package is for the USA version of the Axon 7 Mini (tulip) running 7.1.1 b14 firmware. If you are running any other device or firmware version, it may not work.
Note
After some testing, it appears that the Axon 7 Mini is not locked in any way. In other words, apparently neither this package nor tuliptool's unlock are required to flash custom ROMs. The only apparent advantage to flashing this is to get access to fastboot, which provides a way to flash a custom boot and recovery (among other things).
Flashing Instructions
Place axon_mini_unlock.zip on the root of your sdcard.
Reboot into recovery.
Select "Apply update from SD card".
Select axon_mini_unlock.zip.
Usage Instructions
After the package is flashed, you may boot into the bootloader:
adb reboot bootloader
Once in the bootloader, you will see an on-screen menu. Additionally, you may access the typical fastboot commands:
fastboot oem device-info
fastboot oem unlock
fastboot flash ...
... etc ...
Download
axon_mini_unlock.zip
md5: ea8f1a21c8a46b3045d00f17a37fe359
So, after this is done, I can flash TWRP through fastboot and tuliptool is no longer necessary, correct?
Yes, that is correct.
JoeGatto said:
So, after this is done, I can flash TWRP through fastboot and tuliptool is no longer necessary, correct?
Click to expand...
Click to collapse
This package is for the USA version of the Axon 7 Mini (tulip) running 7.1.1 b14 firmware. If you are running any other device or firmware version, it may not work.
Click to expand...
Click to collapse
Is this something your contact mentioned or something that you believe based on your experience?
Any harm in trying it on verdandi/other versions without any risk of bricking?
After some testing, it appears that the Axon 7 Mini is not locked in any way. In other words, apparently neither this package nor tuliptool are required to flash custom ROMs. The only apparent advantage to flashing this is to get access to fastboot.
Click to expand...
Click to collapse
Any way to confirm this is also the case with other versions as well?
Thanks TDM.... you're going to have a lot of Canadians asking about verdandi as it is quite cheap here at the moment. Better get those questions out of the way early. The source is released, same kernel version as the U.S. one with some small differences with drivers (from what I can see) and I am sure that if people know that custom roms are possible on that version (not bootloader locked forever) it would be appreciated.
trpn111 said:
Is this something your contact mentioned or something that you believe based on your experience?
Any harm in trying it on verdandi/other versions without any risk of bricking?
Any way to confirm this is also the case with other versions as well?
Thanks TDM.... you're going to have a lot of Canadians asking about verdandi as it is quite cheap here at the moment. Better get those questions out of the way early. The source is released, same kernel version as the U.S. one with some small differences with drivers (from what I can see) and I am sure that if people know that custom roms are possible on that version (not bootloader locked forever) it would be appreciated.
Click to expand...
Click to collapse
Yeah...verdandi is stuck on Marshmellow. But since it has different hardware it could brick if this is tried.
The ZTE engineer is USA based, he is not on the China development team (read: probably a support engineer). He said: "I attached the unlock update zip package, please try it. It is based on B14 build."
Sorry, that's all I have to go by for "official" information.
I do not want to be responsible for anyone bricking their device, so I cannot claim that this bootloader will work with anything other than a tulip device running 7.1.1 b14.
If you want to try and report back, I'm sure others will appreciate it. But I can't be responsible for the results.
trpn111 said:
Is this something your contact mentioned or something that you believe based on your experience?
Any harm in trying it on verdandi/other versions without any risk of bricking?
Any way to confirm this is also the case with other versions as well?
Thanks TDM.... you're going to have a lot of Canadians asking about verdandi as it is quite cheap here at the moment. Better get those questions out of the way early. The source is released, same kernel version as the U.S. one with some small differences with drivers (from what I can see) and I am sure that if people know that custom roms are possible on that version (not bootloader locked forever) it would be appreciated.
Click to expand...
Click to collapse
Oh, and here is some more information to help you decide...
The volume key combo to enter EDL is handled by aboot (bootloader, eg. the thing we are flashing). This means even if you aren't currently able to use the key combo, you should be able to use it with the new aboot here. And if you can get to EDL, you can never really brick the device.
The volume key combo is detected very early in the aboot code. Like, first thing after basic platform init. So even if this isn't compatible with your device, it's likely we could restore the old aboot (assuming you back it up first, of course).
I'm convinced that the tulip is not locked based on my investigation today. So I have no idea if this aboot is properly signed. If your device is locked and this aboot is not signed properly, the lower boot loader won't load it. I'm not quite sure if that kicks you into EDL or not.
Not sure if that makes the decision easier or harder...
How did you come to the conclusion that tulip is not locked to begin with? If we don't need tuliptool or this aboot, how can I check verdandi if the device is the same 'locked but not really locked' state?
I will have a read about backing up aboot and see what I come up with concerning getting into edl.
So here's the deal...
I initially assumed the bootloader was locked because... well... it's supposed to be. So I found the place in aboot code where it checks the lock flag in the devinfo partition. I used the firehose to write unlocked to that flag. Then I built TWRP, flashed it and it booted. So I assumed everything was working just as I expected.
Today, I flashed the aboot with fastboot support and ran "fastboot oem device-info". It said that my device was locked. So I went to look and, sure enough, my devinfo partition flag was still set. Hmm, that's odd.
So I wrote locked back to the flag. TWRP still booted. Now things are looking pretty suspicious.
But maybe the new aboot doesn't even support locking? So I flashed the original b14 version of aboot and TWRP still booted.
That's pretty hard evidence that aboot is ignoring the lock flag. I don't know what they did -- whether they just removed the code that reads the lock flag or introduced a bug or what.
This does not necessarily mean that the lower layers are unlocked. That is, the lower boot loader may still required a properly signed aboot. I don't know, and I'm not ready to brick my device trying to find out.
trpn111 said:
How did you come to the conclusion that tulip is not locked to begin with? If we don't need tuliptool or this aboot, how can I check verdandi if the device is the same 'locked but not really locked' state?
I will have a read about backing up aboot and see what I come up with concerning getting into edl.
Click to expand...
Click to collapse
Hmm... Looks like this package incompatible with ZTE/P852A11/tulip.
Got error while trying to flash it by stock recovery. Error message says that it is for A12 version of tulip.
Ah, yes, you have the euro model. See the "calling all mini owners" thread, posts #76 and #77.
maestromony said:
Hmm... Looks like this package incompatible with ZTE/P852A11/tulip.
Got error while trying to flash it by stock recovery. Error message says that it is for A12 version of tulip.
Click to expand...
Click to collapse
i get a message saying "cant update from sd card?"
yeshivabachur said:
i get a message saying "cant update from sd card?"
Click to expand...
Click to collapse
Make sure battery level is at least 30% before applying any update. It's a standard protection feature.
JoeGatto said:
Make sure battery level is at least 30% before applying any update. It's a standard protection feature.
Click to expand...
Click to collapse
My battery was 80%+ mine still said can't update from sdcard
Aries2010 said:
My battery was 80%+ mine still said can't update from sdcard
Click to expand...
Click to collapse
Try turning on the OEM unlock setting in developer settings.
JoeGatto said:
Try turning on the OEM unlock setting in developer settings.
Click to expand...
Click to collapse
Thank you so much that worked I appreciate the it . Now I have one more question I have been searching for a way to root stock rom but I can't find any instructions on it. Could you walk me through it or post a link for me if possible? I have the USA mini 7 with B14 firmware
Aries2010 said:
Thank you so much that worked I appreciate the it . Now I have one more question I have been searching for a way to root stock rom but I can't find any instructions on it. Could you walk me through it or post a link for me if possible? I have the USA mini 7 with B14 firmware
Click to expand...
Click to collapse
Rooting the stock ROM will require that you remove verity, so that the OS won't refuse to boot once you've made any changes to the system partition. You'll need to use tuliptool to flash a new boot image, which you can find in this section of the forum. Then, you could either install TWRP through fastboot or using tuliptool.
JoeGatto said:
Rooting the stock ROM will require that you remove verity, so that the OS won't refuse to boot once you've made any changes to the system partition. You'll need to use tuliptool to flash a new boot image, which you can find in this section of the forum. Then, you could either install TWRP through fastboot or using tuliptool.
Click to expand...
Click to collapse
Thank you sir I appreciate it I shall try it tomorrow.
here's a stupid question.... I have only dealt with Samsung devices so, I have trouble understanding any other kind of process that is not Samsung. If a new update comes out while my device is bootloader unlocked can i update it? or will it brick my device?
The "standard" (not Samsung) method of updating via OTA is to ship:
1. Full images of any firmware partitions (rpm, tz, aboot, etc.)
2. Full image of boot.
3. A delta (patch) to system.
Also note that custom recoveries generally do not work with vendor OTA's.
This means that if you wish to apply an OTA, you must first have stock recovery and a completely pristine, unmodified system partition. The rest doesn't matter.
yeshivabachur said:
here's a stupid question.... I have only dealt with Samsung devices so, I have trouble understanding any other kind of process that is not Samsung. If a new update comes out while my device is bootloader unlocked can i update it? or will it brick my device?
Click to expand...
Click to collapse
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