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)!
Related
"The camera may be in use" and other camera problems after bootloader unlocking
Long story short, my camera app is giving me the "The camera may be in use by another application." error even after a factory reset.
Third party camera apps cannot focus and most of the time only produce a green picture when trying to save the image, or fail completely to do so.
The hardware works, as I can see the image on third party apps, and some third party apps manage to save the image as well.
The dirty details:
After getting my brand new X Compact, it quickly updated itself to 6.0.1 (34.1.A.3.49) and since rooting it with some random one-click app failed, I have haphazardly decided to unlock my bootloader, following the Sony guides.
The camera was definitely working OK, before attempting these steps.
I was aware, that some camera functionality would be lost, and I was like sure, whatever, but the end result was not exactly what I've expected.
Bootloader unlocking went fine (except of course I did not read the small text, so was rather surprised rebooting to a factory reset ), but since I still was unable to root the phone with stock firmware, I decided to relock the bootloader with Flashtool and leave it at that. (note, phone still on stock everything at this point).
Flashtool said relocking successful, but it did sort of stop half-way through the progress bar and didn;t move on from there.
Next reboot and the phone didn't accept my PIN or any other thing I could come up with, so after 30 tries it factory reset itself and the next morning I realized my camera is FUBAR.
I am honestly not sure whether everything was ok between unlocking and relocking.
now the Sony camera app is completely hopeless. I have tried stopping everything, including system apps, I've tried a factory reset, I've tried PC companion repair, nothing worked.
third party camera apps are a mixed bag. They all show the live preview image, but modifying anything or saving the image fails:
open camera doesn't seem to do anything (doesn't save the image or do anything when shutter pressed)
FV5 lite sometimes works sometimes not (perhaps depending on some settings? no idea tbh), when it works, can take pictures of the main camera, but cannot move focus. Front camera results in green image.
facebook, instagram etc work, but there's not much control in those. Also they do not auto focus at all.
The generated "green image" has a correct looking EXIF, but then where the image should be there is mostly just a long repeat of the following four bytes: 0A 28 A2 80
One possible hint is that in the file I can see the follwing string: "Qualcomm Camera Debug"
Anyone seen anything remotely familiar?
As I've already did the bootloader unlock, I chose not to send it back even if I have relocked the bootloader and I have no replacement phones available, so I kind of prefer not to be phoneless until it would get clarified.
I'm not sure if it's working, but try this:
unlock bootloader again. then flash your stock firmware again via flashtool. You know how to do that?
I did mark all wipes in flashtool. Then you load kernelpatcher V5.0 tool here:
http://forum.xda-developers.com/xpe...-kernel-dm-t3301605/post64990566#post64990566
follow all steps to patch you stock kernel with DRM-Fix. Did you backup yor TA befor unlocking bootloader?
So you can extract DRM keys and make .ftf in order to flash your DRM keys. If not, DRM Fix should work as well.
You can also read here:
http://forum.xda-developers.com/showpost.php?p=69993876&postcount=86
of course no TA backup, as I wasn't aware of this and didn't prepare for this properly (I just assumed following the Sony guides would be OK to follow, even if I loose some features)
To be fair, I may have screwed this up while trying to "relock" with flashtool, so there. Lesson learned.
Now that I start reading up on what even TA is, first hit on google: on sony's own forums about an unlocked Xperia-Z3-Compact and lost TA partition is eerily familiar and not promising much good (sorry, can't post links yet. Anyway, the guy's camera also stopped focusing.)
thanks for the tips, I'll look into these in a more relaxed moment.
Question: could the potentially damaged TA partition impact the functionality even on third party roms like CM?
I never used a custom rom, but i think if you did a clean flash of stock firmware, you should be able to flash a custom rom and everything shold be fine, except functions which need DRM keys.
Sorry for a noob question.
I rooted my previous device, Xperia Z3 compact, without unlocking bootloader, so I am completely new to this stuff.
I am looking into buying a used X Compact and worried that the device no longer has its TA intact.
I've searched the forum but didn't quite find an answer to my question.
So, for X compact and many other xperia models, there is DRM fix that restore DRM keys on a bootloader-unlocked device, even if you didn't backup your TA and your TA is completely wiped by unlocking, correct?
Then, how can you tell the difference between a device that has its original TA (either still intact or TA properly restored from backup) and a device without TA but DRM keys restored?
And, if you can't tell the difference, what is the point of having TA backup and restoring it later?
Sorry it seems pretty basic stuff but I can't find any direct answer to it.
Hope someone can help. Thanks in advance!
tapa_t said:
So, for X compact and many other xperia models, there is DRM fix that restore DRM keys on a bootloader-unlocked device, even if you didn't backup your TA and your TA is completely wiped by unlocking, correct?
Click to expand...
Click to collapse
Not exactly - the drm fix is a mod that attempts to replicate the features and functions that are lost when wiping ta. I've never used it, so can't say myself, but it seems like people who have are happy with it. The main issue with wiping ta is the loss of Sony camera features and quality. I believe there are also other things attached to the ta, but most people probably wouldn't ever miss them.
If you wipe the ta without backing it up, then it is gone, and your only option is drm fix. Most people would probably rather have the ta intact...
levone1 said:
Not exactly - the drm fix is a mod that attempts to replicate the features and functions that are lost when wiping ta. I've never used it, so can't say myself, but it seems like people who have are happy with it. The main issue with wiping ta is the loss of Sony camera features and quality. I believe there are also other things attached to the ta, but most people probably wouldn't ever miss them.
If you wipe the ta without backing it up, then it is gone, and your only option is drm fix. Most people would probably rather have the ta intact...
Click to expand...
Click to collapse
Thanks -- but that doesn't really answer my question. Question is *HOW* do you tell apart a phone with drm fix and no TA from a phone with an intact TA. If you can't tell the difference, people can't be sure they've got the TA intact whether they prefer it or not.
tapa_t said:
Thanks -- but that doesn't really answer my question. Question is *HOW* do you tell apart a phone with drm fix and no TA from a phone with an intact TA. If you can't tell the difference, people can't be sure they've got the TA intact whether they prefer it or not.
Click to expand...
Click to collapse
Service menu > service tests > security
See in screen shot :
- Widevine... "OK"
- ckb... "OK"
- Fido keys provisioned
with drm fix
zokkii said:
with drm fix
Click to expand...
Click to collapse
Interesting - and thats with drm keys missing (TA wiped)?
yes,without drm keys
That's only half of the story. The DRM Fix library has two working modes, and what defines which mode it'll pick depends if you have your unique device key (that get wiped when you unlock the bootloader) flashed in an alternate TA Unit. You can extract your device key and then flash it on an alternate unit as long as you have a TA backup taken before unlocking the bootloader (the RootKernel utility from @tobias.waldvogel ships with the required tools to extract and flash your device key).
On the "normal" mode (DRM Fix + device key flashed on alternate TA unit) you have exactly the same functionality you would get on a bootloader locked device with its TA intact, everything works. But, in case you don't have your device key flashed into an alternate TA unit (e.g. unlocked the bootloader without backing up the TA first, lost backup, etc), then DRM Fix will work in emulation mode. On emulation mode, most features that check for DRM will still work (e.g. camera algorithms, X-Reality Engine, etc) but some specific DRM features that requires the device key (e.g. Widevine L1 decryption, HDCP on Screen Mirroring, etc.) won't work. As it was increasingly more difficult to find exploits for newer devices and firmwares, that's the mode most DRM Fix users utilize, I guess.
Now, how to tell a DRM Fix restored device apart a device with intact TA is a little tricky, but you basically have 3 situations:
• Bootloader locked device, security test in Service Menu shows both Widevine and CKB as [OK] [Active] => stock device with TA partition intact
• Security test in Service Menu shows [unknown] or [generic error] on Widevine or CKB (or both) => TA partition wiped, DRM Fix not applied
• Bootloader unlocked device, security test in Service Menu shows both Widevine and CKB as [OK] [Active] => TA partition wiped, DRM Fix applied
When a device has the DRM Fix applied, it's not possible to tell if it's working in normal or emulation mode until you try something that requires the device keys (e.g. Widevine L1 or HDCP on Screen Mirroring). If it works, DRM Fix is in normal mode, otherwise it's in emulation mode. Also, you can't trust the "Bootloader Status" info on the Security Test of the Service menu to tell whether the bootloader was unlocked or not, as it'll always report "locked" if you have the DRM Fix applied. A safe way to tell the bootloader status is (re)booting the device and observing if the "Your device has been unlocked and can't be trusted" message appears before the Sony logo. If that message appears, the bootloader was unlocked.
You'll also find many people debating whether FIDO Keys being provisioned or not actually indicates the status of the DRM Fix, but from my experience, they aren't related. Fact is that I had FIDO Keys not provisioned on my Xperia X right after I turned it on for the first time (brand new device, had just taken it from the box), but upon registering a fingerprint, FIDO Keys became Provisioned again. Same thing occurred after I backed up my TA with the dirtycow exploit then unlocked the bootloader, FIDO Keys became not provisioned but after enrolling a fingerprint they became Provisioned again, even through I hadn't installed DRM Fix yet at that point.
And to finish, keep in mind all I said on this post is only valid for Xperia devices that launched before Xperia XZ Premium. With XZ Premium launch, Sony reworked many parts of the DRM protection and the original DRM Fix from previous devices didn't work at all. Another user eventually developed a new DRM Fix solution for those newer devices, but it works completely different and I have absolutely zero experience with it.
Does this work on the Android 9.0 custom roms? DRM Camera fix for 9.0?
sheeplings said:
Does this work on the Android 9.0 custom roms? DRM Camera fix for 9.0?
Click to expand...
Click to collapse
No
mbc07 said:
That's only half of the story. ...
Click to expand...
Click to collapse
Thanks A LOT for this information!
I have searched for a long time for something similar but everyone seems to just know this and expecting everyone else too, so it's never thoroughly described, until now!
mbc07 said:
On the "normal" mode (DRM Fix + device key flashed on alternate TA unit)
Click to expand...
Click to collapse
Do you have any information that would help a noob accomplish this? Link to a good, noob adopted, step-by-step guide? So far I'm out of luck finding anything that will give me confidence enough to try it.
Thanks again!
Holton181 said:
Do you have any information that would help a noob accomplish this? Link to a good, noob adopted, step-by-step guide? So far I'm out of luck finding anything that will give me confidence enough to try it.
Click to expand...
Click to collapse
Sorry, nope. The process is "half" streamlined if your phone happens to be supported by the original Root Kernel tool or the modded version posted on the last pages of that thread, but you would still need knowledge on how to get a TA backup on your particular device and on unlocking the bootloader / flashing a modded kernel. If your phone isn't supported then the process also involves manually modding the kernel to include the DRM Fix library too, and none of that is noob-friendly, at all...
If you can't/don't want to deal with it, your best bet is searching at your device's subforum, perhaps somebody already did the work for your particular phone model and published a ready to flash, DRM Fixed kernel there...
mbc07 said:
Sorry, nope.
Click to expand...
Click to collapse
Okay, thanks anyways. My understanding of this is much better already after your description.
Backing up TA, unlocking bootloader and rooting is the easy part, pretty good understanding how its done. It's how to make good use of the DRM:s that's all new to me.
My device is the full size X (not Compact as in this sub-forum), my wife's old working phone. I'll try to search the forum for it.
Edit: I worked out my issues, I'll leave this here in case others have similar trouble:
I needed to manually add in the RAW F53XX files from the github (https://github.com/Androxyde/devices/tree/master/F53XX), this allowed Flashtool to correctly detect the type of phone and apply the fsc. I was then able to flash my desired firmware, I chose the 6.0.1 release for Journalists to begin with as a test. This confirmed my suspicion that it was a software update issue causing the proximity sensor to malfunction (stuck on) and also fixed up the FACTORY STARTUP SERVICE-POWER OFF bug and the Warrantytimeservice permanent notification. I can now look at updating to later versions of Android and find the latest version before I have issues again.
---
tl;dr - I need a guide that actually works on downgrading the F5321 to a specific stock Android version with a locked bootloader.
I recently received a new, old stock version of the X Compact (F5321) that appears to be a HK variant as it started up with the Chinese language selected.
It was initially stock Android 6.0.1 with no apparent problems. After OTA updating all the way through to 7.1.x and onward to the latest 8.0, I now receive the "FACTORY STARTUP SERVICE" problem. Even if I'm quick enough to disable the service for the service flag, the proximity sensor does not work as well after updating, making phone calls impossible. I believe the issue is all related to software, not hardware. I want to downgrade to 6.x and go from there before I have to send it back for another replacement.
I'm having trouble with getting Flashtool to correctly detect and identify the firmware files that I want to flash. I want a completely stock version of Android, so keeping the bootloader locked is fine for me.
After downloading the firmware that I want to try, XperiFirm will close and Flashtool will successfully build the FTF. After clicking the lightning bolt > flashmode > the firmware list is blank.
I'm using Flashtool 0.9.26 (I have tried older versions as well with the same problems) with driver signature enforcement disabled and correct drivers installed to detect the phone.
The last time I used Flashtool was to flash my older Z5 Compact, I didn't have any issues then and it was all done within 10 minutes. I've already spent more than 5 hours on this phone and would appreciate any help.
I seem to have the exact same problem with a Hong Kong-sourced X Compact. I am familiar with Flashtool, and have used it for basic flashing of firmware. This time, however, I am experiencing the dreaded "FACTORY STARTUP SERVICE" problem. Was wondering if Flashtool could be used to circumvent the problem. I simply want the USA Android 8.0 firmware on the phone. I am not familiar with the various options that Flashtool offers. I note that you mention a specific script(?) that can be installed. Do you have any advice? Thanks
pseudonym58 said:
I seem to have the exact same problem with a Hong Kong-sourced X Compact. I am familiar with Flashtool, and have used it for basic flashing of firmware. This time, however, I am experiencing the dreaded "FACTORY STARTUP SERVICE" problem. Was wondering if Flashtool could be used to circumvent the problem. I simply want the USA Android 8.0 firmware on the phone. I am not familiar with the various options that Flashtool offers. I note that you mention a specific script(?) that can be installed. Do you have any advice? Thanks
Click to expand...
Click to collapse
The "FACTORY STARTUP SERVICE" and to a lesser extent, "Warrantytimeservice" problems surface only in the later version of Android. The only way I could remove them was by staying on 6.0.x only. Anything higher, and the problems show up again. It seems to be a byproduct of upgrading the HK variant that wasn't designed to actually be software upgraded - you won't be able to have the US 8.x firmware on the phone.
Sorry to say, but you'll be stuck on 6.0.x if you want a usable phone. I should mention that I was never able to maintain a newer firmware on that particular phone.
I've since sent the Compact X back (it was meant to be a gift) and replaced it with a Samsung A20.
h
I'm using SO-O2J and a sim card not docomo. Use the "Repair" in Xperia Companion and it auto flash Android 7.0
..
PioneerSeeker said:
Try different region's roms on www.xperiablog.net and I hope you'll be successful to find nougat or oreo at last for your phone.
Remember xperia devices do not need to unlock bootloader for downgrade...
Click to expand...
Click to collapse
Thanks; I was able to obtain an X Compact originally for the UK market, and was able to successfully flash the US Oreo firmware. All seems to be in order.
(Apologies if this isn't the right forum...it's the only one I found that seems to deal in topics that are universally applicable to the entire Xperia line-up.)
For the entire time I've been using Xperia phones, I've always used the third-party "Flashtool" by Androxyde to flash my phones, and "XperiFirm" by Igor Eisberg to source my Sony ROMs from Sony servers. Both tools have proven to be extremely flexible and powerful, so why waste time with the first-party tools which don't give you much say or control over the process?
I also just recently realized that I had an inaccurate understanding of at least one of the first-party Sony tools: what Sony calls "Flash tool" on their developers site, but which calls itself "Emma". Based on posts I had read by others (esp. surrounding the bootloader upgrades for Z1/Z3 series that enable using the FOTAKernel partition to store and boot from a standard recovery image), I came away with the conclusion that the ROMs that Emma downloads are *different* than the ones that Xperia Companion downloads...that Sony tailor-made ROM releases specifically for users who had unlocked their bootloaders, and Emma was the distribution mechanism for those.
Maybe this was already obvious to everyone else and I'm just late to the party, but I recently decided to play with both Emma and the current iteration of Xperia Companion, and discovered this isn't the case.
The firmwares Emma downloads are *identical* to the firmwares Xperia Companion does. Assuming you can get both Emma and Xperia Companion to download the same exact ROM version for the same exact phone model with the same exact regional or carrier customization, the pre-decryption FILE_######## filenames are the exact same, the file sizes are the exact same, and in fact the downloaded files from both tools are bit-for-bit identical with each other.
As far as my previous misconceptions go, it would also appear that the bootloader improvements that Sony made to earlier phone models were in fact released to the general public through standard channels: if you wanted a bootloader version that could treat the FOTAKernel partition as a Recovery partition instead, all you had to do was upgrade to the latest ROM for your phone (and then unlock bootloader & flash a recovery image of your choice using Fastboot afterward, naturally). It didn't *have* to be done through Emma: the upgrade would arrive OTA and/or through Companion just as well (or of course packaged in an FTF and then flashed by Androxyde's tool). And all subsequent phone models seem to just have these bootloader improvements incorporated straight from the factory...no need to get Emma involved whatsoever.
This to me raises the question: why 2 completely separate tools from Sony, anyway? Xperia Companion (and Sony PC Companion before it) *refuses* to work on phones with unlocked bootloaders, while Emma *refuses* to work on locked bootloaders. Since they are both dealing with the exact same ROM code, why do either of them give a crap what the state of the bootloader is? In the instance of Companion, I could see a case being made for refusing to do a firmware upgrade to a phone with an unlocked bootloader, for the same reason that unlocking the bootloader stops OTAs from working: an unlocked bootloader means you don't know & can no longer trust what the state of the /system partition is -- it could have been modified -- and so a differential upgrade could completely fail to apply and even make Android unbootable afterward. But that's no excuse for making Companion refuse to do a "software repair" (which wipes out all code and data) on a phone with an unlocked bootloader! And likewise there is no excuse for Emma refusing to "apply a service" to a phone with a locked bootloader!!
It gets even weirder when you look under the hood of both tools and realize that they both use the exact same core (Java) routines to download and flash ROM images from Sony servers to Xperia phones. There is thus ZERO reason to differentiate them based on bootloader lock status. I'm okay with Sony having a generally consumer-facing repair tool (Companion) and more power-user one (Emma), but they both should absolutely work regardless of the bootloader being locked or unlocked. That's a stupid and artificial restriction.
I get the impression that Emma is used by more than just users of unlocked bootloaders (or as Sony thinks of them, the "developer community"). I think this might also be the same tool that they distribute to their Sony service partners for phone repair. This would explain why early versions downloaded from developer.sony.com would pop up a login screen unless/until you edited some .INI file that pre-populated it with credentials to enable "Sony developer world" mode. This means Emma is also PERFECTLY CAPABLE of "applying service" to phones with locked bootloaders anyway. It just chooses not to if you aren't an authorized Sony service center.
The final observation I'll make here is that Emma, at least while in "developer world mode", does often allow you to download and apply older ROMs for your phone. This logically must mean that all of the past ROM versions still exist on Sony firmware update servers and can still be downloaded from them. So my question in light of this is, why can XperiFirm only ever download the latest versions?
Tangentially related, anybody have a clue what the decision-making process is behind which ROMs Emma will offer to you for the phone that you have plugged in? I have a couple of Z5 Compacts: a U.S. model E5803, and an E5823 of unknown origin, and they both give different -- and equally weird -- results.
When I plug the E5823 in and put it in flash mode, Emma gives me like 5 different ROMs to choose from: a Lollipop 5.1.1 ROM, a Marshmallow 6.0 ROM, a Marshmallow 6.0.1 ROM, a Nougat 7.0 ROM, and a Nougat 7.1.1 ROM...and all of them are of NOBA customization. But the Nougat 7.1.1 ROM that it offers to me is 32.4.A.0.160, and not the very last/latest 32.4.A.1.54 release. Why the heck is that? I can download 32.4.A.1.54 for NOBA region from XperiFirm just fine, and if I try to do "software repair" to the phone from Xperia Companion, it also downloads 32.4.A.1.54.
When I plug the E5803 model from the U.S. in and put it in flash mode, Emma gives me exactly one option and one only: a very old Lollipop release (32.0.A.6.200) for "MY" (Malaysia) customization. THAT'S IT. No Marshmallow, no Nougat, and no other customization options. This is despite the fact that at the time I plugged the phone in, it was already loaded with and running a "US" customization ROM!
One might wonder if, say, my "U.S." phone is in fact NOT a true U.S.-released phone, and was perhaps flashed with Customized US firmware before it got into my hands. Well, from looking at the upgrade logs in the TA partition, that doesn't appear to be the case: it clearly started life as a U.S. model. And just in case there was some point at which I flashed Customized MY to it without remembering, I restored an old backup of the TA partition (which has nothing but Customized US firmware entries in it!), had Emma check it again, and SAME THING. So from this I can only conclude that it's basing the ROM offering off of the serial or IMEI of the phone?? Even so, where is it coming up with this Customized MY firmware, and why is it ONLY offering me Lollipop?
Considering Sony's Flash Tool a.k.a. "Emma" comes from a more "internal" background, it isn't hard to imagine it looking up unique serial numbers (such as the IMEI, as you had guessed) instead of more general information such as device model numbers and customization variants.
The supply chain game is prone to all sorts of mistakes and your particular phone might just have been filed in the wrong place. For instance, I've found one HP laptop whose serial number is not recognized by the manufacturer's customer support website nor the more involved services used for looking up spare parts and replacement accesories (called "PartSurfer"). I've also come across a bunch of Samsung phones which wouldn't upgrade via OTA nor using Kies, but ODIN did the job just fine.
As for the locked/unlocked bootloader restrictions, it might have to do with how the different tools do data preservation (or how they don't). As far as I remember, there were serious pitfalls when flashing unlocked devices with official tools which sometimes led to a hard bricks. "Find my Xperia" on unlocked bootloaders comes to mind. I guess Sony just doesn't want to be liable for data loss and decided to proceed with this ham-fisted approach.
As for XperiFirm, yeah, I was sad when I found out you could no longer download older firmware releases with it.
Pixelado said:
Considering Sony's Flash Tool a.k.a. "Emma" comes from a more "internal" background, it isn't hard to imagine it looking up unique serial numbers (such as the IMEI, as you had guessed) instead of more general information such as device model numbers and customization variants.
The supply chain game is prone to all sorts of mistakes and your particular phone might just have been filed in the wrong place.
Click to expand...
Click to collapse
Theory makes sense on the surface, but I keep running across weird oddities with every phone I've tried to have Emma look up. In my experience it is MORE rare for Emma to return what I would expect to be the proper firmware list for a specific Xperia phone than it is for it to return something that doesn't exactly match, which seems VERY common. In addition to the phones I talked about in my original post, I have also tried seeing what Emma thinks about the 2 Z3 Compacts I bought that are clearly U.S. models & NOT AliExpress counterfeits. They both had U.S. customization firmware loads on them, but Emma wants to download Malaysia firmware for both of them.
Pixelado said:
As for the locked/unlocked bootloader restrictions, it might have to do with how the different tools do data preservation (or how they don't). As far as I remember, there were serious pitfalls when flashing unlocked devices with official tools which sometimes led to a hard bricks. "Find my Xperia" on unlocked bootloaders comes to mind.
Click to expand...
Click to collapse
I'll have to look this up as I'm not familiar with the pitfalls you're talking about or with the specific Find My Xperia example you cite. But so far I have yet to run across a scenario *when flashing official Sony firmware images* where it makes a difference whether the bootloader is locked or unlocked. I've flashed various Xperias with the third-party Flashtool a zillion times, both locked and unlocked with the exact same FTFs. There's no difference I can see. And also both Emma and Xperia Companion download the *exact same firmware files* from the Sony update servers. So the Sony decision to make Emma ONLY work with unlocked and Xperia Companion to ONLY work with locked strikes me as completely arbitrary and nonsensical.
Pixelado said:
As for XperiFirm, yeah, I was sad when I found out you could no longer download older firmware releases with it.
Click to expand...
Click to collapse
My point here was more that the XperiFirm author, as I recall, claims it is impossible to download older firmwares from Sony servers because Sony deletes them. Emma, however, seems to disprove this claim. So it would be *nice* if we could figure out what exact query Emma is running in order to find the older firmware files that OBVIOUSLY still exist, and then replicate that outside of Emma.
Sony Emma
https://software.sonymobile.com/emma/doc/emma_user_guide.pdf (manual)
Sony Emma is an internal tool to flash and repair phone softwares for authorized Sony personnels only. It can do anything, from customization change, sim unlock, thief protection unlock,....So Sony make Emma very secure and therefore have many restriction in "public" mode. About the firmware question, it uses the internal server, not the public one for Xperia Companion (and XperiFirm). The firmware on both servers is the same generally, but the public one are subject to end of life policy, the one not available are the ones Sony dont support anymore.
So I’m thinking about using MSM Tool to restore my OP8 Pro right now so I can fully update and get my firmware up to date for the new Lineage OS 19.1 builds, however, there isn’t a full update file available for that required update, only an incremental, hence needing to use the application to roll back to older software and apply each incremental. Seeing as I was on Lineage 18 before, I’m not using stock, and my attempt to update things didn’t go smoothly, as half the hardware is malfunctioning in LOS19. So, I’ve got a few questions as I’ve never used MSM Tool before:
1. I’ve read that using it breaks the fingerprint sensor calibration after the restore. I have a backup of my persist partition which should help me with fixing that, but it seems that root is required to fix that. Is it also possible to just take my backed up persist partition and write it back using fastboot to fix the issue? I know there’s already a set of instructions but I’m not sure if there’s perhaps an easier way.
2. Should I have to root to fix that partition, would that break my ability to install OTAs? If I recall, unlocking the bootloader stops OTAs from working.
Basically, what’s the best path to take such I can ensure my fingerprint scanner still works, but I can fully update the stock software so I can meet the requirements of the new Lineage update? (Perhaps be able to keep the bootloader locked after all is said and done to ensure everything is 100% stock again)