Hi all!
I am writing some instructions for newbies like me that wish to root their Xperia Tablet Z. I spent a lot of hours trying to understand how things work and I try to fill this gap with this post. If anybody knows, I would like to have an answer on the DRM, and model type questions that I have colored red in the text.
I was a "proud" owner of Sony Xperia Tablet Z WIFI 32GB (SGP312) that I bought from northern Europe last September. It was my first Android device and I consider myself super newbie on this "sport". Since my last official Sony system upgrade ~1-2 months ago I had sound problems with skype. I could not make a call without a handset and also my sony speakers refused to reproduce any youtube video. Nonetheless, the alarm was working fine! I was disappointed and after a factory reset the sound problems persisted. Thus, I decided to delve into the rooting world.
So long story short, we can install whichever stock/original firmware we want if it is designed for our devices consulting the precious links in xda-developers.com forums. Then we can either stay with this or install custom "ROMs" having our tablet "rooted".
My first goal is to fix the sound problem so I tried following the stock firmware route.
I flashed the firmware(s) with the quite intuitive Flashtool. Beware that I had already installed the required Google's Android SDK/ADT kit in my windows machine, although I performed every task in my linux machine in order to have working fastboot and adb commands with the minimal fuss installation-wise. To flash the stock firmwares, or the so called FTF files, I was entering the flash mode holding/pressing down the Volume Down key while connecting the device with the USB to my PC. I note that holding down the Volume Up key, instead, connects the tablet in the fast boot mode
After/Before every firmware flashing I was trying not to forget to:
Enable the USB Debugging mode
Trust installation from unknown sources (this probably is redundant) and
Use massive storage instead of MTP in my USB connection options.
Then, I tried to unlock my bootloader (for experimenting purposes) following the official SONY instructions. I successfully did (fastboot was saying OK!), without keeping any DRM keys, since I guess I do not need them, right? However with some FTF stock firmwares my screen was freezing while booting and showing the "flying colors" and then it was eternally rebooting again and freezing again and so on. I tried this and verified it with a couple of FTF stock firmwares. The one was for sure the SGP312 Global Xperia Tablet Z WiFi 32 GB - 10.4.1.B.0.109, I do not remember the others. This 10.4.1.B.0.109 was working fine but not with the bootloader unlocked. I found out that I could break the boot/freeze loop by entering flash mode (Volume Down while connecting the USB) just after it was turned off after the "flying color" freeze.
So I tried with this stock firmware: SGP312 10.4.B.0.577 (UK version 32GB WIFI Unbranded) and after using my tablet for ~30mins I can say that I did not encounter any problems.
But I wanted to view the rooting world, so to do this I found out that installing a Recovery Software would help.
So I installed XZDualRecovery. I followed the instructions and downloaded TabZ-lockeddualrecovery2.7.123-BETA.installer.zip and also the *flashable.zip from the same site.
Before starting to implement the instructions, the same XZDualRecovery post was mentioning I should install a 10.3.1.C.0.136 firmware and so I did, getting the SGP312 10.3.1.C.0.136 VMo EU4 firmware. This 10.3.1.C.0.136 was also working quite well, and after unlocking the bootloader (I do not know if I have to do unlock the bootloader everytime I flash a stock FTF) it was botting properly and my speakers were working fine.
I runned the install.sh for linux (install.bat for windows). I noticed that the third option was "3/ Attempt installation on unrooted device" which I tried and was successful, since then, the "Root Checker" app was saying that my tablet was rooted. That was really cool!
I wanted to enter the recovery mode so I turned on my tablet and when the "SONY" letters appeared (or a bit earlier) I started pressing multiple times the Volume Up key and a nice purple screen (like this) with the recovery appeared. There, I chose Wipe Data/Factory Reset (it was quite fast) and then Install multiple Zip files from the SD card.
The Zips I had in my card were the Cyanogen Mod, the Google Apps and the XZDualRecovery:
I downloaded Cyanogen Mod, pollux_windy for our devices, from here. I chose the latest stable version, cm-10.2.1-pollux_windy.zip 2014-02-01 01:07:05, but I hope another one will see the light soon.
I also installed the latest google apps that for today are these and the latest versions can be found here.
The TabZ-lockeddualrecovery2.7.123-BETA.flashable.zip metnioned above. I am not sure if this is really needed but I think I read somewhere that I should included or else I would not be able to Reboot to Recovery after flashing.
The problem with the pollux_windy zip was that I panicked since the recovery zip installation stopped with the error: assert failed [...] status 7 and I was pretty sure I had an SGP312 device!!! So I deleted the first line in the cyanogen zip file:
Code:
/META-INF/com/google/android/updater-script
like it appears here or here. This forum post says I should not extract the zip, but I did and it worked.
After all the above steps I booted my tablet and everything seems almost ok so far. I say almost because:
I notice that my device, according to the settings is now the "SGP311" and not the SGP312 (how could I change that?), but in my free space I still see 25+GB (although I am still using only ~3GB).
Also, some times while I am scrolling e.g. in Play Store I see infinitesimal freezes in the movement of the webpage (AnTuTu benchmark returns a rating of ~19800-20118).
Moreover, I have installed ~30 apps, but the installing procedure seems somehow slow, and the last ~10 apps I tried to install have not been installed "due to an error 495". The above was "fixed" after a reboot, but I must say I never encountered this problem with my stock firmware.
To the first question in red: DRM keys are needed for Playstation Mobile, Video and Music Unlimited, I think something regarding Screen Mirroring and, until Android 4.3, no Bravia Engine 2. With 4.4, it works again.
About the 311 and 312 thing, it is because you flashed a firmware that wasn't specifically for your device. You can go into build.prop file, and change every SGP311 you find to SGP312.
Nevertheless, awesome guide
Sent from my LT26i using Tapatalk
Thanks for the time to share
Hi all,
I have the SGP312 but it's not the "global" version (I noticed one of the stock firmware used was the UK one). I have the US/Canadian/North American version.
Would I brick my device if I flashed with the UK firmware? I haven't for the life of me found any guides/threads for my device.
I know it's the "pollux windy" (wifi 32gb) but I'm...afraid.
Thanks!
UberBaumer said:
Would I brick my device if I flashed with the UK firmware? I haven't for the life of me found any guides/threads for my device.
Click to expand...
Click to collapse
no.
I'll start with how this began, a family friend brought me a taco'd Xperia Z1, I knew nothing about the Xperia devices. I was asked to recover photos and videos. After I was able to get the logicboard to boot with USB and back everything up for them, as payment, they gave me the taco'd phone.
Now, being a Samsung user, I was thinking Galaxy S, S2, S3, etc. No, for some reason Sony felt that the Xperia Z1 means it's the second model lol.
Long story short, I needed a C6906 donor phone, and ended up buying a C6606 because I didn't look into it further, my bad.
The cheapest one I found was a bad ESN C6606 which is (T-Mobile) that was on eBay.
I live in Canada and I didn't realize my mistake until I got the phone and noticed it was much smaller.
So, to try and make the best of things, this is my project for getting a bad ESN T-Mobile C6606 working on Bell in Canada.
To start, some of you may know, others may not, banned ESN's do NOT transfer betweens countries yet, a US carrier with identical radios (T-Mobile/AT&T) will work in Canada as long as its unlocked.
First thing I did was look into unlocking codes, went to SafeUnlockCode, I think it was around $40 Canadian after exchange rate. Six days later, got my code, typed it in, worked like a champ, Bell SIM reads and it would make calls and send SMS but no Data, so I checked the network info, no APN settings, entered the Bell APN settings, gave it a reboot, works perfect, like nothing happened.
T-Mobile for whatever reason is the only carrier who is still on firmware 10.4.C.0.814 which is Android 4.3
Bell received 10.5.A.0.230 (4.4.2) and 10.5.1.A.0.292 (4.4.4)
So, naturally, I want to update this to KitKat for no other reason then to have it up to date, but I like the fact that this phone is branded T-Mobile, gives it the hipster appeal that no one else here has one lol.
This is where I backup the T-Mobile boot and shut down animations and sounds from /system/media
It's now time to start the upgrade, I used XperiFirm to download the C6616 4.4.2 and 4.4.4 firmware, made sure to unchecked the box that asks to unpack files (because FlashTool requires them to be packed)
Next was opening FlashTool, I had to make a FTF bundle from the 4.4.4 Bell files. After that was done, I did the exact same process but only for the 4.4.4 kernel, and then again for the 4.4.2 kernel (this is for rooting)
After 4.4.4 booted for the first time, set it up, checked it out, now it needs root to swap the T-Mobile animations and sounfs back, so back to FlashTool.
Because of an issue with the 292 kernel, it wont allow root, so I flashed the 4.4.2 kernel that was made earlier, after first boot, WiFi is broken but mobile data still works so first I went to settings and then security, enabled unknown sources, and then on chrome I searched towelroot, and downloading the apk by clicking the red icon in the middle, used towelroot, now have root.
Back to computer, plug in USB, open FlashTool, now says I have root, now flashing the 4.4.4 kernel that was made and once that finished, rebooted phone, everything works perfect. Now download ES file manager from Play Store, copied T-Mobile files from earlier back into system/media and rebooted again. Everything works, all back to normal, looks like T-Mobile both on and off.
I now have a C6606 with Bad ESN from T-Mobile running Android 4.4.4 from Bell and rooted with 292 kernel.
That's my story, I hope some of you got some information needed for flashing, making ftf files, rooting, using other C660X firmwares, unlocking, or just info on bad ESN phones.
I'll update this later with all the images, links, and make it pretty with BBCode so its not as primitive.
I'm currently at work using the Xperia Z from this project.
Reserved for links and credits
Hi all.
I've asked this question in numerous threads so, to be fair to all the others whose questions I'm getting in the way of, I thought I'd post it here and wait with baited breath for a potential solution.
I very recently bought an XT1684 (3GB/32GB) UK G5 Plus. I installed all the official OTAs and got myself up to firmware version NPNS25.137-33-11. All was well, amazing battery life, but needed root for some apps. The steps I followed are roughly as follows:
1. Unlocked bootloader: I did this the usual way, got my code, chucked it into fastboot etc voila, job done.
2. BOOTED Twrp: I did this so I could attempt to back everything up without modifying, for purpose of returning to stock. It didn't work, I could not back anything up nor could I install magisk or a custom kernel. My Twrp would not read the internal storage and said something about formatting data. I ended up formatting data, which actually formatted the whole damn thing, losing my stock ROM completely.
3. FLASHED Twrp: By this point I had to, as I had limited access to the internet outside of my phone so put a lineage ROM on my phone and some gapps and flashed it.
4. Installed magisk 15.3
5. Installed Alize kernel: I did this because I was looking for improved battery life over the lineageos kernel. It hasn't been better.
So that's where I am. I have two main reasons I need to return to stock:
1. The battery life was better on my stock firmware.
2. Whenever I use lineage, I find my signal not to be as strong, and it seems to randomly lose all signal for a few seconds several times an hour, usually affecting my data more than voice calls. This is absolutely not something that happened on stock. I dunno if it's related to baseband or something, but it happens and I don't like it.
My main issue is I have seen several retUS versions of the firmware above, and lots about many other XT16xx models but nothing about my XT1684 and no fastboot images for retGB. I'm comfortable flashing pretty much anything via Twrp as I have a full backup of all partitions including OEM, system image etc but these were taken after installing lineage. I'm just totally not comfortable fastboot flashing anything except the exact correct firmware, as I've had this phone literally a week.
If anyone can help me locate the right firmware, or advise me how I could possibly return totally to stock, that would be amazing. I can provide any logs or other information required, but may need walking through more obscure commands as I am only technically proficient enough to do a basic fastboot flash, Twrp, etc.
Many thanks for reading and my apologies to all of those whose threads I've muscled in on up to this point.
Filmware is here https://firmware.center/firmware/Motorola/Moto G5 Plus/Stock/
And there is a tool that automates flashing in the development section here..
https://forum.xda-developers.com/g5-plus/development/toolkit-moto-g5-plus-toolkit-root-t3605203
Firmware - https://firmware.center/firmware/Motorola/Moto G5 Plus/Stock/
How to flash - https://forum.xda-developers.com/g5-plus/how-to/solution-to-flash-stock-romfactory-t3691396
?hope it helps.
Thing is, there's no xt1684 version or retgb version. I fear it could be the wrong one, can't afford to replace phone so can't risk hard bricking it.
Could someone confirm that these are safe to flash for me? Thanks for the replies, though.
Your filmware is there yes? Having said that mine is a xt1685 the same filmware number as yours but mine is euret dual SIM. Sold by Amazon UK
My confusion is that I thought they were for US models.
Well US version has no NFC but had a compass.
Has yours?
Mine has NFC and no compass lol!
darkglobe87 said:
Mine has NFC and no compass lol!
Click to expand...
Click to collapse
Seems to be typical for EU G5+ devices, NFC but no compass.
The retail firmwares don't appear to have region restrictions, hence no labelling for retEU/retGB/retUS etc. However, as you may have noticed, flashing the incorrect build for your region causes all sorts of headaches, including loss of SIM network.
That being said, you know what firmware you need (NPNS25.137-33-11) and that particular firmware was only released for EU/UK devices to the best of my knowledge. India/Brazil, US and other territories had different firmware builds released.
So, you should be okay with flashing that particular firmware - but please verify you have the correct firmware downloaded and the correct flashing instructions, and take your time in flashing.
Also, if you choose to re-lock your bootloader, re-locking your bootloader will unfortunately not restore your warranty with Motorola (which is 2 years now for EU/UK users at least). However, UK consumer laws may cover you in the eventuality of hardware repairs, just be careful. Also, re-locking will erase your device and requires firmware of the same build or newer than what is currently on your device.
Good luck whatever you decide.
I have the UK version and have gone back to stock a few times, I used this thread, and the linked firmware is the same as UK one. The guide is for bootloader locking, but ignore that part if you only wish to return to stock.
https://forum.xda-developers.com/g5-plus/how-to/how-to-lock-bootloader-potter-version-t3694952
EDIT 07/27/2021: Though this method didn't end up panning out (different signing keys on stock XZ Marshmallow! who would've thought!), I found a way to get temp root on the XZs and thus pull the TA partition off the device. Details in the bottom half of my latest post.
From reading through the forums here, it's clear that nobody has yet devised a way to perform a temporary root exploit on the XZs prior to bootloader unlock so that the TA partition (and thus the DRM keys) can be backed up on this model before bootloader unlock erases them forever.
Most pre-SD835 Xperia phones rely on the "dirtycow" exploit to do so, which is only available pre-Nougat. The XZs is somewhat unique in that it's an SD820-based model that shipped with Nougat from the start. The other two Xperia models that share the SD820, and are even considered to be part of the same underlying Xperia platform ("tone"), are the X Performance and the XZ, and both originally shipped with Marshmallow, which is "dirtycow"-exploitable. The X Performance and XZ are even supported by backupTA v2, even though XZs is not due ONLY (as far as I can tell) to the lack of Marshmallow firmware for the XZs.
I also have found a few posts on here from people who considered trying what occurred to me: if the XZs is so similar to the XZ, what about trying to flash the XZ Marshmallow firmware to an XZs? It would only be temporary, long enough to run the backupTA script on it, so even if not all of the hardware is 100% the same (and thus not all of the drivers work), you would only need enough things to work (main CPU, eMMC, USB port) in order to run backupTA, and then flash back to actual XZs firmware.
Unfortunately, it sounds like the few people brave enough to try this were met in the end with bricked phones. I have so far not run into anybody who claims to have tried this who managed to "un-brick" their device. :crying:
But, I suspect what may be going on is that, sure: if you flash the WHOLE XZ firmware to an XZs, yeah, you probably risk a brick, because there are likely enough low-level components not in common between the two getting flashed. My guess is that what's actually going on is that when the XZ bootloader gets flashed to the XZs, either there is some hardware-level thing on the XZs it doesn't know how to deal with, or perhaps Sony used different encryption keys on the XZ vs. XZs, so the (signed by Sony) XZ bootloader freaks out when on the XZs and refuses to start the phone.
Result: brick. Maybe even hard brick (unless you want to unsolder the eMMC and reflash with an external programmer).
But what I don't think anybody has tried yet is trying to only flash enough software components necessary to get a Sony-signed Marshmallow release running on the XZs. In other words, DON'T flash bootloader, modem/baseband, and all that stuff.
Hypothesis: it MIGHT be possible to get a barebones "dirtycow"-exploitable Marshmallow release running on the XZs by flashing ONLY the "boot" (kernel) and "system" SIN files from the XZ ftf. Sure, go ahead and wipe userdata and cache too, but don't touch anything else: leave modem/baseband alone, do NOT flash any TA files, etc. Has anybody tried that?
At worst, I can imagine that it simply won't work, and it's possible that it won't because I imagine that Sony probably *did* use separate encryption/signing keys for XZ vs. XZs. But it's also possible that they did, given how similar the devices are. If the keys aren't a match, then the XZs bootloader (which will still be intact, since you didn't try flashing the XZ bootloader!) will simply refuse to boot the XZ kernel. And in that case, you should only have a "soft" brick, easily recoverable by going back into flash mode and re-flashing official XZs boot.sin and system.sin files to it.
Thoughts?
-- Nathan
My experience with swapping xzs with xz firmware is an unresponsive camera. TA can be recovered/restored, but not backed up (what's the point if it's recoverable?). Would be great to see temp root exploit imported to the 820; unlikely, as all the attention are for newer models that run p and q. Only real benefit is for those running locked bootloaders and it's pretty minimal what could be accomplished on after. Would rather see someone spoof signatures on custom roms.
&(*) said:
My experience with swapping xzs with xz firmware is an unresponsive camera. TA can be recovered/restored, but not backed up (what's the point if it's recoverable?).
Click to expand...
Click to collapse
I'm not 100% sure I understand you, or if maybe you misunderstood me.
Are you saying that you have successfully tried flashing XZ firmware to an XZs, and it worked? In all of the threads I have read on XDA from others who have tried this, the result has been a bricked phone...
It doesn't matter if the camera is unresponsive when running XZ firmware on an XZs. Running the XZ firmware would be *temporary*. You would only have it on your phone long enough to extract a complete copy of the TA partition, with all DRM keys intact. Once you have extracted a TA backup, you would re-flash back to XZs firmware. So, you maybe will run your phone with XZ Marshmallow firmware for 5 minutes, tops.
You can't "recover" or "restore" TA if you don't have a backup to begin with, so I'm not sure what you are talking about there. If you unlock your bootloader without first making a backup of TA, then your DRM keys are gone. Forever. NO recovery is possible. So, of course, if you have already unlocked your bootloader, it is too late, and putting XZ Marshmallow on your phone for 5 minutes to make a backup of TA would be pointless. My proposal is for people who have XZs phones still with LOCKED bootloader, who want to make a pristine backup of their DRM keys *before* unlocking for the first time.
Up until now, XZs users have had no means of making a backup of TA before unlocking their bootloader. So only solution for XZs users who unlock is "drmfix", which does some tricks to make *some* of the Sony software think that DRM keys are present even though they are not.
This is not as good of a solution as actually keeping your DRM keys, however. Most of the Xperia models before XZs have a more comprehensive "drmfix", where you extract the DRM keys for your phone from your TA backup that you made *before* unlocking your bootloader, flash them *back* to the TA (*just* the DRM part, and nothing else), and then you have the perfect solution: DRM keys AND unlocked bootloader!
Plus, with a copy of the original, pre-unlock TA partition, you have the option to flash the whole TA backup back to your phone at any time in order to re-lock your bootloader and put things back to stock.
All of this is only possible with SD820 or older Xperia models. The ones that came with SD835 and newer (XZ Premium, XZ1, XZ2, etc.) have additional security. It's still possible to extract DRM keys from TA on some of these phones before unlocking the bootloader, but you can never go back to locked bootloader on those phone models, even with a complete TA backup.
-- Nathan
You're right, my mistake - I meant DRM is recoverable (sort of) not TA . What you are suggesting with a locked bootloader will not work, as it will not contain the verification keys to allow a rewrite of it - in short.
&(*) said:
You're right, my mistake - I meant DRM is recoverable (sort of) not TA . What you are suggesting with a locked bootloader will not work, as it will not contain the verification keys to allow a rewrite of it - in short.
Click to expand...
Click to collapse
I think we are still talking past each other. I'm not talking about writing anything to a "locked bootloader". What I'm describing is exactly how things already work for the vast majority of pre-SD835 AArch64 Xperia models when it comes to unlocking the bootloader while simultaneously preserving the DRM keys. Almost all pre-SD835 AArch64 Xperia models, that is, except for XZs, simply because the XZs lacks an exploitable stock firmware version...or does it?
The TA partition contains all sorts of Xperia-specific data in it, not JUST DRM keys. In pre-SD835 models, the TA partition also happens to contain the bootloader lock status. So if you unlock your bootloader and then later decide you want to re-lock it, simply take the TA snapshot you made while the phone was locked, and re-flash that back to your phone. This is no longer true in SD835 and beyond, where Sony is now seemingly taking advantage of the TrustZone feature in newer Snapdragons.
I have a couple of Z5 Compacts myself, and I've tested this flow many, many times on both of them, and it works...what follows is not conjecture or hypothesis:
Start with a phone that is running stock, untouched firmware, and a locked bootloader
If said phone is running Nougat, the downgrade to a stock Marshmallow or Lollipop firmware; this is possible to do without unlocking the bootloader since such images are signed by Sony
Use backupTA v2 to achieve temporary root, and use temporary root to do a bit-for-bit copy of the TA partition to a backup file that you pull back to your computer for safe keeping/a rainy day
Go ahead and upgrade back to Nougat or later after that, if you so desire...you only had to boot Marshmallow once so that you could achieve temporary root, in turn so that you could image the TA partition
Unlock the bootloader, which in turn wipes the DRM keys from the TA partition
Use the flash_dk script from rootkernel suite to extract the DRM keys from your TA partition backup image made in step 3
Flash the DRM keys (and ONLY the DRM keys) back to the TA partition using Flashtool, pointing it at the FTF that flash_dk outputted for you in the previous step
Have rootkernel bundle up for you a modified kernel image with an initramfs that contains the drmfix, and flash that to the phone
Bam: you now have an unlocked bootloader AND you have managed to preserve your unique Sony DRM keys
If at any time you want to return to completely stock software and re-lock your bootloader, simply push the TA backup image you made at the start of this guide to the phone, and then bit-for-bit write the contents of it back to the TA partition (using 'dd' or your weapon of choice)
Of course, after you do this, if you had previously modified either the system partition or the kernel, you will need to re-flash stock, unmodified, Sony-signed kernel and system images before the phone will boot again
You can always re-unlock your bootloader again using the same code that you got from the Sony website in order to unlock it the first time, so keep that code around
If you do NOT back up your TA/DRM keys prior to unlocking, they are lost forever, but in that case "drmfix" can employ a sort-of workaround, where it "fakes out" having DRM keys for some Sony apps. This does not restore 100% of functionality, though, UNLIKE if you actively work to preserve the DRM keys prior to unlocking, in which case you DO retain 100% of functionality post-unlock (plus you're always free to go back to being locked + still having 100% functionality, which is not possible if you don't make a TA backup first prior to unlocking!)
As the rootkernel post explains: "First [drmfix] tries to use the device key which you flashed with flash_dk. If it does not exist it uses an alternative method which cannot fix everything (e.g. Widevine will not work, but X-reality, Camera denoise etc. will work)." This is also very well summarized/explained in this post by another forum member.
Therefore, it is within every Xperia owner's interest to accomplish a TA backup before performing a bootloader unlock, even though "drmfix" exists, because "drmfix" is able to "fix" more things if it has your actual DRM keys to work with. "drmfix" + your actual DRM keys > "drmfix" by itself.
Up until now, XZs owners have had to be satisfied with drmfix by itself, because there has been no known way of accomplishing temporary root with a locked bootloader on this model. I'm not the first to think about maybe trying to flash XZ Marshmallow to an XZs in order to achieve temporary root for the purpose of making a TA backup, but I don't think I've seen anyone else suggest flashing ONLY the XZ Marshmallow 'system.sin' and 'boot.sin' partitions to an XZs, while leaving every other partition alone (except maybe wiping userdata and cache, of course...but don't touch bootloader, modem, etc.).
I don't have an XZs myself or I would try this. I do, however, have a friend with one which still has a locked bootloader, and who is mildly interested, but is understandably nervous given the other attempts people have made at flashing XZ Marshmallow to their XZs only to result in a brick (because, as I theorized before, they're flashing EVERYTHING, including bootloader). I'm pretty sure, however, that the worst that could happen if you made sure to only flash system and boot/kernel is that the bootloader simply would refuse to boot the XZ kernel. At that point you should be able to re-flash the XZs kernel and system to get back to status quo.
Boot.sin would not suffice, boot is now a folder with a number of files to choose from based on what is read from the bootloader status during flash. There are keys stored and keys appended to the enrolled verified signatures during an upgrade, a downgrade would attempt the same with keys for that version or possibly based on how it parses the list insert the keys to the top of the list. In order for the bootloader to accept a write to the table and enroll the keys for signed images of the sort, the bootloader requires a key itself to allow a write to it. The key for the XZs bootloader will more than likely not match is my thought at which point the loader is flagged for being corrupt and will no longer boot or simply not write and abort (which apparently other's state is not the case). I'm not missing the point here, it's just not likely that the bootloader or the TA where the flags are set will allow a write to the loader itself considering how it handles OEM signed images and how it verifies each partition before it writes to it with keys (signatures). My understanding might not be descriptively accurate in terms of technicality with the order and operations of how the bootloader protects itself, best bet here is to coach your friend on the flashing process and report the results. I don't think the loader will allow a downgrade to a system it didn't support during it's lifecycle.
&(*) said:
Boot.sin would not suffice, boot is now a folder with a number of files to choose from based on what is read from the bootloader status during flash.
Click to expand...
Click to collapse
Sorry, my mistake...I meant kernel.sin, not boot.sin. I misspoke since I had in mind that fastboot itself calls the kernel partition 'boot', so when you reflash a new kernel (in uImage format, not .sin) with fastboot, you use 'fastboot flash boot'. So, a brain fart moment on my part.
Yes, I'm aware the bootloader itself is made up of a number of files in a folder, though until your explanation I did not know what the point of the diversity of files was.
&(*) said:
There are keys stored and keys appended to the enrolled verified signatures during an upgrade, a downgrade would attempt the same with keys for that version or possibly based on how it parses the list insert the keys to the top of the list. In order for the bootloader to accept a write to the table and enroll the keys for signed images of the sort, the bootloader requires a key itself to allow a write to it.
Click to expand...
Click to collapse
Got it; thanks. I was not aware of this.
But this sounds like the bootchain keys in the TA only get touched/written to when the bootloader itself is being flashed. What if only main application processor code (kernel, system) partitions are being touched while in flashmode?
&(*) said:
The key for the XZs bootloader will more than likely not match is my thought at which point the loader is flagged for being corrupt and will no longer boot or simply not write and abort (which apparently other's state is not the case). I'm not missing the point here, it's just not likely that the bootloader or the TA where the flags are set will allow a write to the loader itself considering how it handles OEM signed images and how it verifies each partition before it writes to it with keys (signatures).
Click to expand...
Click to collapse
Right; my mistake was in misleading you by writing "boot.sin", when I was trying to reference the Linux kernel. It seems to me that if you attempt to only flash kernel and/or system from a different model with a locked bootloader, at most you risk the system not booting because bootloader refuses to chain off to the kernel on account of mismatched keys or whatever, but this is a state that can be recovered from by going back into flashmode (which still works, since XZs bootloader hasn't been touched and is still intact) and reflashing actual stock XZs kernel and system again. So, on the off-chance that it works, my thought is why not give it a try, since the only thing you potentially have to lose/waste is time...
This is all predicated on the theory that pre-SD835, Sony largely re-used the same set of bootchain signing keys across all models. Which admittedly could be entirely wrong. The main reason why it seems probable is that there doesn't seem to be any problem with cross-flashing different firmware customizations within a model, nor with cross-flashing between variants of a model (e.g., any Z5c E5803 firmware of any version can be flashed to E5823, or vice-versa), all while running a locked bootloader. It's also never been a problem to upgrade or downgrade Android version at-will with a locked bootloader, suggesting (to my simple mind) that the keys haven't changed over the lifetime of that platform.
I suppose one test that would be interesting would be to see if I could flash and boot a Marshmallow kernel and userland on a Z5c with a bootloader from either a Lollipop or Nougat firmware bundle, while the bootloader is in a locked state. If a mismatched but locked bootloader willingly passes off to a signed kernel from a different firmware version than what it itself shipped with, that's an indication the signing keys didn't change. Right?
What I have heard almost no chatter about, other than in XZs-land, is attempting to cross-flash between any models that are part of a larger shared platform (e.g., flash any official Kitakami platform firmware to any other Kitakami model phone with locked BL). XZ and XZs are both part of such a shared platform (Tone).
-- Nathan
Ran some tests on my Z5 Compact with a locked bootloader, the results of which are promising.
I wanted to see what would happen if I booted various levels of mismatched bootloader + kernel sets, increasing the amount of differences between them as I went:
...where the bootloader and kernel were for the same hardware model but from different firmware bundles for different Android versions,
...where the bootloader and kernel were not only from different firmware versions but also from different but related hardware models within the same immediate family, and
...where the bootloader and kernel were from different models taken from different families within the same common platform.
First up, different firmware versions:
I flashed the bootloader that comes with latest official Nougat release for this platform (32.4.A.1.54) to my phone, and then I flashed kernel and system from an old Lollipop release (32.0.A.6.200). Bootloader from the Nougat bundle booted the entire Lollipop system without any complaint.
While in this state, I went ahead and enabled USB Debugging under Developer Tools, and permanently authorized my PC for adb access over USB.
So, success!
Next up, different models from same device family:
Next I grabbed the same Lollipop release (32.0.A.6.200) for different but related device (Z5), and flashed just the kernel from it to the Z5c. The locked Z5c Nougat bootloader also booted the Z5 Lollipop kernel, no problem. Granted, I couldn't see anything on the display which remained black the whole time (probably because the display is one obvious major difference between Z5 and Z5c), but the system still came up, which I knew because I was able to get an adb shell after it booted. So USB was working. Audio was also working, as it would make chime noises whenever I plugged the USB cable in.
Looking good. And now we know that at least within Z5 family, the boot signing keys are the same across major Android system versions, and also the same across the entire family ("sibling" models).
What about the real test: entire shared platforms (which, in Sony's world, is usually any set of phones that use the same SoC)?:
I decided to try flashing a Z3+ kernel to my Z5c. Both are based on Snapdragon 810, and both are internally categorized as "Kitakami" platform devices. So not only do Z3+ and Z5 share SoC, but firmware updates for both are released with the same version #. I was unable to find a Z3+ Lollipop firmware available for direct download from Sony via XperiFirm, and didn't feel like searching around for one elsewhere, so I switched gears and settled on Marshmallow instead.
So first, as a sanity test & control, I flashed Z5c Marshmallow 32.2.A.5.11 kernel and system while leaving Nougat bootloader still in place, cleared userdata and cache, and as expected based on the earlier Lollipop test, phone booted up fine. I set it up as new, enabled Developer Tools, enabled USB Debugging again, and whitelisted my PC, just as before.
I grabbed Z3+ Marshmallow 32.2.A.5.11 firmware, flashed JUST the kernel from it, and the results exactly match what I experienced with the Z5 kernel: the bootloader booted it just fine, and most everything worked except for the screen itself! So I adb shell'd in, watched logcat scroll by, heard the speakers chime whenever I plugged the USB cable in, etc.
So what I believe I did here was approximate/proof-of-concept on my Z5c what I am hypothesizing is probably also doable on XZs: I used a locked Nougat bootloader to boot a signed-by-Sony Marshmallow kernel that was built and intended for an older device that shares the same SoC.
The test would probably have been more "fair" if I had used a Z5 instead of a Z5c, since the Z3+ and Z5 displays are also identical, but I don't have a Z5. The XZ is much more similar to the XZs than the Z3+ is to the Z5c, and yet despite the differences, it still worked.
In conclusion: we know that Sony finally "got wise" (or at least wiser) for their next set of flagship phones (XZ Premium and XZ1 family), but unless they made moves that aren't public knowledge to tighten down the screws within the SD820 "Tone" family of devices (X Performance, XZ, XZs) compared to the SD810 "Kitakami" ones, a bootloader from any one of these phones within that platform family can likely boot a kernel from any other one of these phones, regardless of which Android version either the bootloader or the kernel was intended for. Thus, there is a fairly high degree of likelihood that you can flash and boot just the XZ Marshmallow kernel and system on a XZs, and that the hardware support in the XZ kernel may be enough that it's at least possible to perform a temporary root and TA extraction by this means.
What I haven't yet done is taken the time to do a system flash from the Z3+ to the Z5c, too. I intend to also try that shortly.
-- Nathan
&(*) said:
[...]
Click to expand...
Click to collapse
Z5 Compact + locked bootloader + Z5c bootloader from Nougat + Z3plus kernel + Z3plus system:
It works.
A stock, Sony-signed kernel and system image for Android 6.0 from a KITAKAMI device (Z3+) can be booted just fine by a locked bootloader (from the Android 7.1.1 firmware, no less) on a KITAKAMI-r2 device (Z5c). I have an ADB shell and a logcat running and everything.
Now, naturally, things don't run *well*. I can't see anything on the screen because the Z3+ display is higher resolution than the Z5c display, and so the Z5c display isn't initialized properly by the Z3+ kernel. (Touch inputs work, however! I'm hitting targets blind, but every once in a while I'll get it to vibrate or make a sound like I managed to tap something.) logcat reveals that basically all radio-related processes are going berserk: the NFC server is crashing and relaunching itself every second or so, and almost just as often, the system is trying to communicate with the cellular baseband and failing to do so. Also, the phone runs HOT. Probably because these processes are freaking respawning themselves every 1-2 seconds. I imagine CPU load is through the roof. (Also, as a fun test, if I try to flash the Z5c kernel back to the phone while leaving the Z3+ system image in place, the display initializes properly, but everything form text to images is all rendered hilariously huge, given both the resolution and DPI difference between the Z3+ and the Z5c.)
But none of this matters. And that's because the only reason why you would theoretically want to do this anyway is so that you can run the dirtycow exploit against the phone in order to gain temporary root and then do a dump of the TA partition. So the only things that need to be working are the USB port and eMMC access. And since both are working, I was able to successfully do exactly this to this phone while it was in this state.
I would be shocked if a similar thing were not possible with XZs (TONE-r3) using the Marshmallow kernel + system from XZ (TONE-r2)...
You would need an oem (vendor), kernel, and system .sin along with the partition layout to theoretically accomplish what you are proposing.
&(*) said:
You would need an oem (vendor), kernel, and system .sin along with the partition layout to theoretically accomplish what you are proposing.
Click to expand...
Click to collapse
It only remains theoretical on the XZs...I believe that I demonstrated that the concept is sound by flashing and booting Z3+ kernel and system on a locked Z5c.
Vast, vast majority of Snapdragon-based devices -- including SD-based Xperias -- utilize a GPT partition table, not static LBA offsets hard-coded into the kernel (or passed to the kernel by the bootloader). And then all partitions are looked up by name, not sequence#, UUID/GUID, or whatever. Partitioning should be a non-issue, and it most definitely was not an issue with Z3+ code running on Z5. I would definitely be very nervous about flashing partition.sin from XZ to an XZs (or from Z3+ to a Z5). Chances are good anyway that the partition layout changed either very little or not at all between the two models, but GPT should abstract away any subtle differences.
oem, maybe. If XZs oem partition contains stuff that happens to confuse the XZ system software, and causes it to behave badly or go into a crash/restart loop, then yeah, I could see trying to flash oem along with kernel and system. Should be no biggie. It's likely, though, that even if you left XZs oem contents in place, the base of the system would work "enough" to be able to do a TA partition dump, which is all we really care about. Only thing I believe that's needed to accomplish that is an ADB shell over USB. ADB is started up early enough by the system during boot (well before the Android user environment has even rendered a single pixel on-screen) that I just don't see this being a problem.
The tricky part is actually enabling ADB while running the "wrong" kernel and system. I have war stories on this topic with the Z3+ > Z5c test. I accomplished it on there, but the XZs may be a different story. If I am given a chance to try it, I'll let y'all know.
You need oem, as it pertains to what software the kernel loads for system I believe. Partition more than likely is necessary due to the shift from legacy (M) to HAL (>=N); whether or not the architecture was implemented in M for XZ is questionable, having a look through the developer binaries at the repo from Sony might indicate it. What is more likely the case, you will need to make sure your paths for everything are in order for a mostly clean boot so that the system will accept what you propose without much fuss (like not losing adb ie flashmode).
Long time no post.
Good news / bad news:
Bad news first, as per tradition. I finally got hold of my friend's XZs to test this theory on, and I can't even get as far as flashing a signed, stock XZ Marshmallow kernel to it, because the phone while in flashmode fails to validate the SIN header of the XZ Marshmallow kernel.sin. So it would seem that perhaps Sony finally got wise and used different signing keys for firmwares issued to different devices within the same "family" (in this case, the Tone family, which includes X Performance, XZ, and XZs, all of which share the same SoC and thus kernel source tree in common with each other)...and since of course my whole plan was predicated on Sony sharing the same software signing keys between all models from the same family, this is officially kaput.
...though I have another theory about the signing key difference. By their end-of-life, all Tone phone models were running builds of Oreo that were kept in-step with each other: before support for a given model finally dropped off, it was getting firmware releases identical in version number to what the other models were getting within the 41.3.A.x.y range. This is very similar to how they treated the Kitakami family (Z3+/Z4 and all Z5 submodels): they all ended with Nougat releases versioned identically (32.4.A.x.y). It's not clear to me what all of the various components of the Xperia firmware version numbers represent, but it seemed clear that the second number would get +1'd every time the base Android version changed (so for Kitakami, 32.2.A.x.y was Marshmallow 6.0.x, 32.3.A.x.y was Nougat 7.0.x, and 32.4.A.x.y was Nougat 7.1.x), and the first number *seemed* like it might represent either a family, SoC, or major kernel revision change, since it would often stay consistent within a given Xperia family.
Well, interestingly, while X Performance and XZ went from 39.0.A.x.y for Marshmallow to 39.2.A.x.y for Nougat 7.0, when XZs was released with Nougat 7.1, it was versioned as 41.2.A.x.y, and then when X Performance and XZ got their Nougat 7.1 updates, they too jumped from 39.blah to 41.blah. I am now wondering if that first number perhaps also indicates a change in signing keys. If so, then probably the only way to make this work would be to try to force the bootloader from XZ 39.blah firmware onto the XZs...but of course assuming that was even possible, this is in no way wise as there's an *extremely* high likelihood of ending up with a brick. I could, however, as a fun test, take a Nougat kernel from an XZ 41.2.A.x.y bundle and try to flash it to the XZs: if the locked phone accepts it and it even happens to boot, that would provide more evidence for this theory.
But of course this is all academic at this point, which leads to my...
GOOD NEWS, everyone! I stumbled across a way to successfully make a TA backup from a locked XZs anyway despite this setback.
Turns out the Tone-family Oreo kernels are all vulnerable to CVE-2019-2215, which at this point has been exploited on many phones of this vintage. j4nn famously exploits this vulnerability in his bindershell temp root tool for Yoshino family devices, for example.
I was sure that I was going to have to end up doing some kernel spelunking on the XZs in order to identify the right offsets for the various things in kernel memory that need to be manipulated to get full root (SELinux policies and toggles, etc.), but it ended up being waaaaay easier than that: turns out that this pre-compiled binary "just works" on (at least) the very last XZs firmware release, out-of-the-box. Upload to your phone where you have write access (e.g., /sdcard), copy over to a place where it's possible to set execute permissions (e.g., /data/local/tmp), run the thing, bingo: instant temp root with permissive SELinux. At that point, dd your TA partition over to a file on /sdcard, pull it off the device, and voila.
(You do have to be running Oreo...the Nougat kernels for XZs use an older version of the Android binder driver that is *not* vulnerable to the exploit.)
Theory about the "major" version number of Xperia firmware versions having a uniform set of signing keys seemingly confirmed: I was able to successfully flash an XZ (F8331) Nougat 7.1.1 kernel.sin to this locked XZs (G8232) that's running Oreo and the phone took it without a complaint.
It didn't fully boot, but that's likely at least in part due to the fact I didn't bother flashing system.sin, just the kernel. Unlike when I've had an unsigned kernel flashed to an Xperia with a locked bootloader, though, the bootloader did display the normal Sony boot logo, so I'm guessing it successfully verified the signature and then chained off to the kernel, but that due to initrd and booting differences between Nougat & Oreo, it eventually hung at some point in the boot process. (Actually, just occurred to me that there would be massive mismatch between Nougat kernel and any kernel modules included with Oreo...)
nlra said:
but it ended up being waaaaay easier than that: turns out that this pre-compiled binary "just works" on (at least) the very last XZs firmware release, out-of-the-box.
Click to expand...
Click to collapse
@nlra ,
With the binary provided I was able to backup/restore the TA and relock the bootloader after unlocking it (no more exclamation posting on boot)!