Related
II don't want to be an alarmist but back on 17th June 2016 I created this thread DM Verification failure , Please flash ENG binary then install DNK
At the time I wasn't sure what had caused the problem but last night with a different phone I used KingoRoot and it corrupted a second phone of mine. Now two out of three of my Verizon Note 4's have the dm-verification-failure.
The symptoms of the problem are when I am navigating some of the swipes lag. Sometimes when typing there is a lag delay before it is entered. Sometimes Wifi lags before it is turned on and the phone forgets my wifi password.
I found this thread How to solve dm-verity verification failed/need to check drk first on samsung devices but I don't have the experience to do it. Can a developer create the fix for the Verizon Note 4 , PLEASE, Thanks
doctor-cool said:
II don't want to be an alarmist but back on 17th June 2016 I created this thread DM Verification failure , Please flash ENG binary then install DNK
Now two out of three of my Verizon Note 4's have the dm-verification-failure.
Click to expand...
Click to collapse
I am at the end of consolidating all the info I can to determine if I should get a Note 4. Root is the thing that matters to me, but I have learned that regardless of 4.4.4 or 5.1.1 you have to unlock the bootloader which is the challenge.
Just as I think I have it all together and that the methods provided (on XDA only) are the only only ones available and apparently stable, I read this.
Am I COMPLETELY MISUNDERSTANDING your post? Is your post from here http://forum.xda-developers.com/not...bilized-process-to-unlock-bootloader-t3375527 which I've saved as reference for rooting a device no longer accurate?
I'm overwhelmed from so much research and think I've curated the posts that matter, then I see this. Can you offer anything on this? Again, I may not be understanding. I am NOT a developer or programmer. I've rooted a few devices, but it has been a long time with the most recent not requiring the seeming complication of this one (thanks a lot, Verizon!).
jecilop said:
I am at the end of consolidating all the info I can to determine if I should get a Note 4. Root is the thing that matters to me, but I have learned that regardless of 4.4.4 or 5.1.1 you have to unlock the bootloader which is the challenge.
Just as I think I have it all together and that the methods provided (on XDA only) are the only only ones available and apparently stable, I read this.
Am I COMPLETELY MISUNDERSTANDING your post? Is your post from here http://forum.xda-developers.com/not...bilized-process-to-unlock-bootloader-t3375527 which I've saved as reference for rooting a device no longer accurate?
I'm overwhelmed from so much research and think I've curated the posts that matter, then I see this. Can you offer anything on this? Again, I may not be understanding. I am NOT a developer or programmer. I've rooted a few devices, but it has been a long time with the most recent not requiring the seeming complication of this one (thanks a lot, Verizon!).
Click to expand...
Click to collapse
The stabilized-process-to-unlock-bootloader I posted is still valid. I recommended using Kingroot. I found the dm-verity problem with KingORoot. We need more feedback to be sure. I never had the problem with Kingroot. I removed the link to KingORoot from my guide today.
doctor-cool said:
The stabilized-process-to-unlock-bootloader I posted is still valid. I recommended using Kingroot. I found the dm-verity problem with KingORoot. We need more feedback to be sure. I never had the problem with Kingroot. I removed the link to KingORoot from my guide today.
Click to expand...
Click to collapse
Hmmm..ok..thanks for the reply.
That's interesting as I've read so many posts that say KingRoot is not the way to go but rather KingOroot is the correct on to use. Specifically, a lot of people seemed to have tried it unsuccessfully in the process.
I was also hoping to avoid KR as I've read it is a bit sketchy. I've used it twice before doing that and found a Nextbook tablet it worked great on with seemingly no apparent problems since. Another Samsung phone was rooted with it (I was actually searching for KOR, but didn't remember the name exactly and ended up with KR on a search). Unfortunately, the security pop-up keeps coming up trying to remove it. The user who didn't know what they were doing inadvertently gave it the OK to remove it, and now I haven't been able to re-root with it...arrggh..
I recently thought to install their Purify app (which they push when doing KingRoot) separately, but the permissions in the app say that you give it the ability to analyze the content on the screen in an window...I can't figure how THAT is needed to block startup programs or background one to save battery!
So, I was hoping this meant the KOR was good to go with the process after the bootloader is unlocked and stable per your post. I wonder if anyone else is running into problems. I know this is all very new still.
I don't suppose you could tell me:
1) Is permaroot available (with these new methods) only on 5.1.1 , or is it also available on 4.4.4 ? I haven't been able to decipher that.
I kind of prefer KitKat over the material design changes that are just wasting space on my screen in JellyBean. The Note 4 I got to purchased recently (unfortunately, it was a sketchy phone now being returned), had notifications on constant screen overflow because they waste SO MUCH SPACE with them and with unnecessary notifications that I cannot stop from showing (Power Saving, Wif connected, Blocking on). I know a good bit of that is Samsung, but the non-compact use of the notifications is Android ( Google's changes). It was better on my SG3 with 4.4.4 even though they still has persistent notifications.
I'm hoping to root and find a mod to stop showing those. I'm aware enough to check my connections via the settings when needed.
Thanks Again.
jecilop said:
Hmmm..ok..thanks for the reply.
That's interesting as I've read so many posts that say KingRoot is not the way to go but rather KingOroot is the correct on to use. Specifically, a lot of people seemed to have tried it unsuccessfully in the process.
I was also hoping to avoid KR as I've read it is a bit sketchy. I've used it twice before doing that and found a Nextbook tablet it worked great on with seemingly no apparent problems since. Another Samsung phone was rooted with it (I was actually searching for KOR, but didn't remember the name exactly and ended up with KR on a search). Unfortunately, the security pop-up keeps coming up trying to remove it. The user who didn't know what they were doing inadvertently gave it the OK to remove it, and now I haven't been able to re-root with it...arrggh..
I recently thought to install their Purify app (which they push when doing KingRoot) separately, but the permissions in the app say that you give it the ability to analyze the content on the screen in an window...I can't figure how THAT is needed to block startup programs or background one to save battery!
So, I was hoping this meant the KOR was good to go with the process after the bootloader is unlocked and stable per your post. I wonder if anyone else is running into problems. I know this is all very new still.
I don't suppose you could tell me:
1) Is permaroot available (with these new methods) only on 5.1.1 , or is it also available on 4.4.4 ? I haven't been able to decipher that.
I kind of prefer KitKat over the material design changes that are just wasting space on my screen in JellyBean. The Note 4 I got to purchased recently (unfortunately, it was a sketchy phone now being returned), had notifications on constant screen overflow because they waste SO MUCH SPACE with them and with unnecessary notifications that I cannot stop from showing (Power Saving, Wif connected, Blocking on). I know a good bit of that is Samsung, but the non-compact use of the notifications is Android ( Google's changes). It was better on my SG3 with 4.4.4 even though they still has persistent notifications.
I'm hoping to root and find a mod to stop showing those. I'm aware enough to check my connections via the settings when needed.
Thanks Again.
Click to expand...
Click to collapse
I can only report my findings. We need more feedback.
The only real negative I've noticed with KingRoot is that it's erased the serial numbers from both of the phones I've used it on. Thankfully it didn't affect the IMEI, but whenever I try to check the serial number on those two devices, it just shows a bunch of zeros. Back up your EFS partition first (if you can without being rooted, I'm not sure), or at least make a note of the serial number. You can manually edit /efs/FactoryApp/serial_no to restore your serial number as long as you know what it is. I don't believe the serial number is used for anything (except maybe warranty-related things), just annoys me that KingRoot erased it.
As far as removing KingRoot, after you unlock the bootloader you can flash a modified stock firmware file for the phone (one that has had aboot.mbn removed) and still retain an unlocked bootloader. Flashing anything with an aboot.mbn will re-lock your bootloader, so be sure you remove that from any Odin tars before flashing. I had access to the full factory firmware for the device (containing the PIT file and a couple of other partitions not found in the home firmware files hosted by sites like SamMobile) so I stripped aboot.mbn from it and flashed that to make sure I started with a clean, KingRoot free device.
blindmanpb said:
The only real negative I've noticed with KingRoot is that it's erased the serial numbers from both of the phones I've used it on. Thankfully it didn't affect the IMEI, but whenever I try to check the serial number on those two devices, it just shows a bunch of zeros. Back up your EFS partition first (if you can without being rooted, I'm not sure), or at least make a note of the serial number. You can manually edit /efs/FactoryApp/serial_no to restore your serial number as long as you know what it is. I don't believe the serial number is used for anything (except maybe warranty-related things), just annoys me that KingRoot erased it.
As far as removing KingRoot, after you unlock the bootloader you can flash a modified stock firmware file for the phone (one that has had aboot.mbn removed) and still retain an unlocked bootloader. Flashing anything with an aboot.mbn will re-lock your bootloader, so be sure you remove that from any Odin tars before flashing. I had access to the full factory firmware for the device (containing the PIT file and a couple of other partitions not found in the home firmware files hosted by sites like SamMobile) so I stripped aboot.mbn from it and flashed that to make sure I started with a clean, KingRoot free device.
Click to expand...
Click to collapse
Thanks, I like the way you think.
Is there some file I can take from a good working Note 4 and repair the DM verification issue ? Do you think I could do it with efs Profestional. Just wondering.
I initially used KingRoot, and it failed 20 out of 20 times to root my phone. I used KingOroot on my laptop (in a VM) and it rooted my phone first try. I don't have any Wifi issues and I don't see any "DM Verity" messages anywhere on my phone.
raduque said:
I initially used KingRoot, and it failed 20 out of 20 times to root my phone. I used KingOroot on my laptop (in a VM) and it rooted my phone first try. I don't have any Wifi issues and I don't see any "DM Verity" messages anywhere on my phone.
Click to expand...
Click to collapse
I think, You would only see the DM Verity" messages when you are in stock recovery. Once you log into your google account, it remembers your passwords. But on my phoneS, I still get the other lagging problems. What ROM are you on?
blindmanpb said:
The only real negative I've noticed with KingRoot is that it's erased the serial numbers from both of the phones I've used it on. Thankfully it didn't affect the IMEI, but whenever I try to check the serial number on those two devices, it just shows a bunch of zeros. Back up your EFS partition first (if you can without being rooted, I'm not sure), or at least make a note of the serial number. You can manually edit /efs/FactoryApp/serial_no to restore your serial number as long as you know what it is. I don't believe the serial number is used for anything (except maybe warranty-related things), just annoys me that KingRoot erased it.
As far as removing KingRoot, after you unlock the bootloader you can flash a modified stock firmware file for the phone (one that has had aboot.mbn removed) and still retain an unlocked bootloader. Flashing anything with an aboot.mbn will re-lock your bootloader, so be sure you remove that from any Odin tars before flashing. I had access to the full factory firmware for the device (containing the PIT file and a couple of other partitions not found in the home firmware files hosted by sites like SamMobile) so I stripped aboot.mbn from it and flashed that to make sure I started with a clean, KingRoot free device.
Click to expand...
Click to collapse
That why I kept the original box with the serial numbers on it lpl
Sent from my SM-N910V using Tapatalk
raduque said:
I initially used KingRoot, and it failed 20 out of 20 times to root my phone. I used KingOroot on my laptop (in a VM) and it rooted my phone first try. I don't have any Wifi issues and I don't see any "DM Verity" messages anywhere on my phone.
Click to expand...
Click to collapse
Same here, only I used the Kingoroot APK, no issues on either the retail or DE. On JasmineROM (6.0 on the DE and 7.0 on the retail)
fz798 said:
Same here, only I used the Kingoroot APK, no issues on either the retail or DE. On JasmineROM (6.0 on the DE and 7.0 on the retail)
Click to expand...
Click to collapse
The lag is most apparent on stock rom that I rooted with KingOroot apk. On CyanogenMod it is more like a hesitation. The damage is so far as I know irreversible.
The other phone that has only been rooted with KingRoot is a a factory DE it does not have the DM Verification issue and it runs as smooth as silk on every ROM I have tried. So I say the problemS came from KingOroot. But we need more data points/ feedback to be sure.
pfcland said:
That why I kept the original box with the serial numbers on it lpl
Sent from my SM-N910V using Tapatalk
Click to expand...
Click to collapse
Verizon Note 4 does not list serial number on the box, unfortunately.
Can you post a short video detailing the issues and is there something I can do to immediately verify if there is a dm verification problem with my device? I also used Kingoroot on my Note 4 due to KingRoot not working after several tries, but I don't notice anything out of the ordinary, just the usual ocassional lag that is on every Android device.
Only noticeable issues I've experienced have been the "Unauthorized Actions Detected" issue and Wifi passwords not saving using PaulPizz 6.0.1/OscarKernel, but that was corrected with the freezing of a couple Samsung security apps and a build.prop edit.
NeoandGeo said:
Can you post a short video detailing the issues and is there something I can do to immediately verify if there is a dm verification problem with my device? I also used Kingoroot on my Note 4 due to KingRoot not working after several tries, but I don't notice anything out of the ordinary, just the usual ocassional lag that is on every Android device.
Only noticeable issues I've experienced have been the "Unauthorized Actions Detected" issue and Wifi passwords not saving using PaulPizz 6.0.1/OscarKernel, but that was corrected with the freezing of a couple Samsung security apps and a build.prop edit.
Click to expand...
Click to collapse
I'm working this now FIx DRK/dm-verity, Factory CSC and Serial Number So far I have been able to restore my serial#. after I turned on the hidden menu.You have to be in stock recovery to see the dm-verity verification failed message. You would have to Odin back to stock to see it.
Lag is not normal unless you have a ton of apps running. ., Wifi passwords not saving is not normal not even once , I bet you got the bug.
Maybe, but I don't have the wifi passwords issue unless I flash OacarKernel over either Jasmine or Paulpizz, stock kernels are OK in that regard.
How bad of a lag are we talking about? Slight hesitation or full on freezes for more than a second at a time?
After a few weeks of using the device with custom ROMs, no lag spikes have been out of the ordinary for me, feels more responsive than my Note 3 and noticeably better than both the Nexus 6/Moto X I've previously used.
The only truly frustrating lag spikes I've noticed are trying to use this site without any form of adblock on Chrome.
NeoandGeo said:
Maybe, but I don't have the wifi passwords issue unless I flash OacarKernel over either Jasmine or Paulpizz, stock kernels are OK in that regard.
How bad of a lag are we talking about? Slight hesitation or full on freezes for more than a second at a time?
After a few weeks of using the device with custom ROMs, no lag spikes have been out of the ordinary for me, feels more responsive than my Note 3 and noticeably better than both the Nexus 6/Moto X I've previously used.
The only truly frustrating lag spikes I've noticed are trying to use this site without any form of adblock on Chrome.
Click to expand...
Click to collapse
The Best example is scrolling lagging on this site with Chrome. My phone without the issue is as smooth as silk. No hesitation. The phones with the bug maybe two swipes work then the third swipe lags then the page jumps to catch up. It is uncomfortable to use.
XDA forums have been fine for me in Chrome since I installed an ad blocker not too long ago. Before that I would get annoying pauses and skips, like you're talking about. Though this also happened on my Note 3/Moto X/Nexus 6 as well on this site.
Is there any way to see if any running processes have large latency spikes when these lags/pauses occur?
Also is there another kernel I can try on PP 6.0.1 ROM or a way to easily flash the stock kernel on it without restoring a backup? Seems like the minor issue with Wifi only crops up with OscarKernel.
doctor-cool said:
I'm working this now FIx DRK/dm-verity, Factory CSC and Serial Number So far I have been able to restore my serial#. after I turned on the hidden menu.You have to be in stock recovery to see the dm-verity verification failed message. You would have to Odin back to stock to see it.
Lag in not normal unless you have a ton of apps running. ., Wifi passwords not saving is not normal not even once , I bet you got the bug.
Click to expand...
Click to collapse
Verizon devices do not have the typical Samsung serial number. The only serial number your device uses in the last 32 bits of your eMMC CID. The EFS serial number is supposed to be 00000000, and will not affect any functionality of your device. You had your DRK (Device Root Key) erased. It could have been from damage to the EFS partition or something else benign. You'll want to flash complete stock Odin, reboot to recovery and wipe data, and reboot. This should fix your issue, but if it doesn't, let me know and we'll cross that bridge.
In response to OscarKernel not saving WiFi passwords, it's an issue related to ROMs and not my kernel. It does not use secure_storage, so setting ro.secure_storage=false is necessary, and once done, everything will go back to normal and save fine.
ryanbg said:
Verizon devices do not have the typical Samsung serial number. The only serial number your device uses in the last 32 bits of your eMMC CID. The EFS serial number is supposed to be 00000000, and will not affect any functionality of your device. You had your DRK (Device Root Key) erased. It could have been from damage to the EFS partition or something else benign. You'll want to flash complete stock Odin, reboot to recovery and wipe data, and reboot. This should fix your issue, but if it doesn't, let me know and we'll cross that bridge.
Click to expand...
Click to collapse
The tutorial I was following was for the SM-N910C not the SM-N910V . For that device, magix01 has a tutorial to fix DRK. I was working on the premise that if I could repair the serial number, I could then use emergency software recovery. Thanks for straightening me out about the serial number. Put that aside for now.
I did Odin N910VVRU2BPA1_N910VVZW2BPA1_N910VVRU2BPA1_HOME.tar several times downloaded directly from SamMobile and did the data wipe and rebooted every way possible I think. I still get the dm-verity failure and more importantly, It still has the lag bug. I have in my possession another SM-N910V that does not have any issues. I was wondering if I could take a file from the good phone and use it to fix the defective phone. Thanks, for your help, I am ready to cross that bridge.
I already opened an RMA for the phone but they have no stock so I figured I'll take another shot at it.
The short version is that my gf messed up and updated the system while transferring her data from her old phone with the tapNgo thing.
I've done multiple facory resets, downloaded the rom from ZTE support, put it on SD, flashed it from recovery and deleted cache and nothing helps.
I don't have the exact error log anymore since I don't have the phone with me now but it reads something along the lines of
loading /proc/devices/audio/sound------ cannot find file/directory.
I looked it up and after a lot of Googling it seems like the symlink to the actual driver folder is missing and I have no idea why.
Does anyone know if i can fix this with an ADB shell?
Alternatively, I tried to follow some of the many guides out there to put the phone in EDL mode and relfash it with XiamiFlash utility but after trying 3-4 downloads and 900 versions of misflash all I ever get is "reading hello packet... unable to communicate to com4"
Haaaalp please?
*edit* this is pretty much exactly the same as what I'm getting: https://forum.xda-developers.com/android/help/sound-card-detected-t3379736
The problem with the phone is it makes no sounds?
gpz1100 said:
The problem with the phone is it makes no sounds?
Click to expand...
Click to collapse
the sound drivers for the OS is missing completely, no sound no microphone.
The syslog looks like this(this is from another phone its its the exact same problem):
AudioDaemon: Opening sound card state : /proc/asound/card---/state
AudioDaemon: Open /proc/asound/card---/state failed : No such file or directory
AudioDaemon: Sleeping for 100 ms
Strange issue indeed. Which model do you have? Which specific firmware file are you flashing to it?
I would think flashing the full unmodified factory firmware using the stock recovery will wipe the phone completely, including the /data partition.
Everything worked before? Help me understand the order of events. What is tapngo?
While in the midst of transferring information to or from the phone, a software update appeared and she accepted/installed it?
Its the A2017U model.
I had tried the 1.1.0 B15 firmware from SD card as well as the 1.0.0 B29 older firmware.
Right now its on B17 Nougat 7.1.1, the phone runs and works perfectly just has no audio hardware.
I wasn't there for the exact procedure but basically she powered it on, it asked for sim, she inserted that, tapped the "transfer my data" and then held the two phones together to get the NFC process started. That starts the bluetooth transfer process and it takes a really long time where it transfers all data and apps from the old phone.
At this point the phone still made sounds when adjusting the volume etc.
Somewhere in that process the "update available" notification came up and she pressed the option to install it.
After I got home I tried to figure out what is wrong, first i thought the phone wasn't registered on the cellphone network but then after a bit i figured out the audio is the issue, then i did a factory reset both from the phone UI and tried again from recovery mode, both times chose the "erase all data" option but neither time did it help at all.
I don't really know enough about phones but i think its the bootloader/something very early on thats messed up. Either that or the audio chip really just did fry.
My hope was to get the full factory image for everything that you need to install with the EDL mode thing but I can't find any good reliable guides for that.
It's the first thread in the development section.. Stickied even.
https://forum.xda-developers.com/axon-7/development/edl-emergency-dl-mode-twrp-unlock-t3553514
Get this package - B15-NEW_FULL (Nougat)
I really don't understand zte's numbering scheme. Newer versions get lower numbers. Makes no sense. That's the full firmware except for the fastboot which passes commands. At this point it's a non issue given the issue you're having.
So I don't need to load TWRP on it, I can still keep it just stock with unlocked bootloader?
I tried that miflash thing before, i had it connected un usb download mode but nothing worked for me, I'll try doing this guide when i get home step by step again.
Their firmware numbers is based on numbers and letters 1.0a-z and then 1.1a-z so 1.0z1 is less that 1.1a1
Ok I have an update
Did miflash, nothing changed.
Ulocked bootloader and miflashed the bootloader from the sticky thread.
The phone made the startup sound and audio worked for a few seconds after android started up and then stopped again
*edit*
ok so after it showed signs of life i re-locked the bootloader, and did the OTA updates to 7.1.1 and the audio seems to be working for good now!!
Conclusion seems to be the bootloader was the key to get it working again. Hope this helps others if it comes to it.
Okay, so I've been trying to get some answers regarding custom ROMs for the past few days but I haven't even got one...and it seems I'm not the only one looking for them. So...lay it in this thread maybe we can start something up.
I am on stock OREO B04, phone's software has never been tampered with anything, TWRP, BL unlock and so on.
This is the premise of the thread, not only for me but for other users who find themselves in the same situation.
Oreo seems to be a bit of a hassle right now for migrating to custom ROMs, and this is not helped by the fact guides in the A7 section are all over the place as well, some may be outdated and there's no clear "Don't use this on x.x version" warning.
I am not even going to attempt to unlock the BL until I clear answer on wether it's possible or not. So let's start with this:
-Is it possible to unlock the BL on OREO?
-If not, what stock official ROM should we install in order to successfuly attempt to unlock the bl?
-Which guide or method is the best for doing so? I've found 2, one from 2016 on MM ROMs and one provided by TurkDevs that seems to work on some Nougat ROMs.
Then comes the recovery section:
-What TWRP should we install on a freshly unlocked device, the official releases, or the Nfound custom ones?
-Also, what are the prerequisites for installing TWRP...I hear that fastboot commands are gone since Nougat and that some flashing methods don't work, then I hear somehow you can do it by bringing back fastboot. How? There's only replies saying "type that command in fastboot" but nobody says if they had it or reinstalled it somehow.
Then comes the ROMs section:
-All custom ROMs seem to require a vendor partition as most if not all of them are Treble based. How do we get that to work?
- I am aware of the fact that the ROM threads have a prerequisites section, but none of them redirect you to a guide on how to get those prerequisites working. I understand that it's not the dev's responsability, I am not bashing anyone here, but a little bit of info cleaning and structuring should be in order in this section.
What I want for me and others in my situation is a clear answer on how to proceed, not a "flash this flash that". There's no secret that the A7 still has life in it especially with the new PIE ROMs.
I've recently seen a reply in one of the threads, encouraging the dev of one of this ROMs to not be disappointed by the seemingly low interest in PIE ROMs. I don't think there's a low interest in them, I think there are users that don't want to risk a bricked phone because of outdated guides and unlcear steps.
There's a lot of confusion going around here so I hope this thread will become a source of updated info on what's possible and what not. Thanks in advance!
Hi, I'm not the best person to help you with this since i've unlocked my Axon 7 a long time ago and I can't remember everything but I will try to help you based on my experience and on what I can remember.
Let's go
Starting with the bootloader, I unlocked mine on stock Nougat B09 using EDL Tool (Oreo wasn't even out when I unlocked my bootloader so I don't know if you can do it while running Oreo but just to be safe you should downgrade to Nougat)
It should be quite easy to unlock the bootloader, here's a simple step by step (please anyone correct me if I'm wrong)
- Download the EDL tool from the link above
- Downgrade your phone to Nougat (Using the updater on the phone itself or an EDL Package with EDL Tool or MiFlash - you can find the stock ROMs on @raystef66 's Download Center
- Once running Stock Nougat, turn on USB Debugging and Allow OEM Unlocking on Developer Settings
- Plug the phone to your computer and open EDL Tool (that should reboot the phone into EDL mode automatically)
- Navigate through the EDL Tool using the number keys on the keyboard, and it should be easy to find the Unlock Bootloader option. Unlock it and you should be done.
Once again that's the way I did it, I don't know if this is the easiest one available. You have more methods available like this one
Now onto the recovery situation, I think each developer recommends a specific TWRP version for their ROM's, like for example
@raystef66 likes NFound's TWRP 3.2.1-8 as you can see on his ROM's posts (check the first line in the installation guide)
@OrdenKrieger likes the official TWRP as you can see on Lineage OS 16.0 post
Generally, official TWRP should work just fine with any ROM.
On a recently unlocked Nougat Stock ROM, I recommend maybe an older version of TWRP, like 3.2.1 for example and you can flash it also using EDL Tool.
But when moving to Pie I recommend you use the latest TWRP version or the version that the ROM developer recommends. You probably know this but you can update your TWRP version by flashing it over the current version you have.
Now about the ROM's, the new ones have a Vendor partition so you have to create it when you're coming from Stock (because our Axon 7 doesn't support Project Treble) and to do that you can use @Oki 's PARTY Tool and after that you can flash the ROM normally, using the proper Bootstack and Modem files.
You could also try GSI's but I can't help you with that because I never tried them.
And this should be all.
I tried to keep it simple for now but i can help you further
I'm not the best person to guide you but at least I tried Feel free to ask me something and good luck!
@joaocandeias Well, dang it worked. Everything you described:
-going back to Nougat
-unlocking the bootloader with the EDL tool
-flashing TWRP-
creating the Vendor partition, and installing the new ROMs.
There were a few hiccups on the road, mostly driver related from my previous attempt, but nothing severe or something that would cause the device to brick.
I just installed @raystef66 's ResRemix ROM and it works fine. I'll start testing more of them in daily use and see which suits my needs best.
Thanks for the assistance!
TorqueSsS said:
@joaocandeias Well, dang it worked. Everything you described:
-going back to Nougat
-unlocking the bootloader with the EDL tool
-flashing TWRP-
creating the Vendor partition, and installing the new ROMs.
There were a few hiccups on the road, mostly driver related from my previous attempt, but nothing severe or something that would cause the device to brick.
I just installed @raystef66 's ResRemix ROM and it works fine. I'll start testing more of them in daily use and see which suits my needs best.
Thanks for the assistance!
Click to expand...
Click to collapse
I'm glad I could help
Since you're not the only person with questions on how to migrate from stock to custom, I'm thinking about writing a full post so more people can see it.
Btw what method did you use to downgrade to nougat?
@joaocandeias Sorry for the delayed response, I've got a really f'd up sleeping schedule these days. I'll write the exact steps I've done.
1. So, I first downloaded the B09 Nougat full stock ROM from the download center and tried to downgrade using the normal software updater in the phone (OTA window, local option).
It didn't work at first, I received a compatibility error, saying that the update is for "ailsa_ii" devices, while the device is not(or to be more exact, my device was " " ), which I found odd.
But, I thought that maybe I need the linked versions(like the last Nougat ROM before Oreo) so I downloaded the B10 Nougat ROM, and used the same procedure.
2. I set up the phone as a dud(skip everything, no Google account), turned USB debugging and OEM unlocking on, installed the original ZTE drivers straight from the phone and rebooted it into EDL to proceed with unlocking the BL.
At this point, I had the QUSB_BULK driver stick from my previous use of Zadig, so one quick "uninstall device software" and relpuging the phone go me the Qualcom 9008 driver in order.
3. I started the EDL tool, navigated through it and started the BL unlock procedure.
Once the phone rebooted I was greeted by the password screen.
One factory reset later and repeating the procedure greeted me with the "Bootloader unlocked" message. Sucess!
4.Now for TWRP, Vendor and ROM, got all the files onto the SD card, I flashedTWRP 3.2.1-8 NFound, then, from TWRP, I used the party tool, then flashed the UBv2(at which point it reverted TWRP to 3.2.3, flashed the 3.2.1-8 again with EDL ), modem, ROM, GApps, rebooted, set it up, then flashed Magisk...and everything seems fine.
The only issue I have now seems to be the camera, both stock app and GCam.
Open camera works , has the correct photo and video res, 60FPS doesn't work and the flash seems a bit laggy, but for me it's ok.
The DAC however is there, alive and kicking, Neutron detected the Hi-Res codec at launch and switched to it. It sounds the same as stock OREO to me so it is great, as this was my greatest fear when migrating to PIE. The DAC-AMP combo is like 60% of the reason I bought this phone in the first place.
TorqueSsS said:
@joaocandeias Sorry for the delayed response, I've got a really f'd up sleeping schedule these days. I'll write the exact steps I've done.
1. So, I first downloaded the B09 Nougat full stock ROM from the download center and tried to downgrade using the normal software updater in the phone (OTA window, local option).
It didn't work at first, I received a compatibility error, saying that the update is for "ailsa_ii" devices, while the device is not(or to be more exact, my device was " " ), which I found odd.
But, I thought that maybe I need the linked versions(like the last Nougat ROM before Oreo) so I downloaded the B10 Nougat ROM, and used the same procedure.
2. I set up the phone as a dud(skip everything, no Google account), turned USB debugging and OEM unlocking on, installed the original ZTE drivers straight from the phone and rebooted it into EDL to proceed with unlocking the BL.
At this point, I had the QUSB_BULK driver stick from my previous use of Zadig, so one quick "uninstall device software" and relpuging the phone go me the Qualcom 9008 driver in order.
3. I started the EDL tool, navigated through it and started the BL unlock procedure.
Once the phone rebooted I was greeted by the password screen.
One factory reset later and repeating the procedure greeted me with the "Bootloader unlocked" message. Sucess!
4.Now for TWRP, Vendor and ROM, got all the files onto the SD card, I flashedTWRP 3.2.1-8 NFound, then, from TWRP, I used the party tool, then flashed the UBv2(at which point it reverted TWRP to 3.2.3, flashed the 3.2.1-8 again with EDL ), modem, ROM, GApps, rebooted, set it up, then flashed Magisk...and everything seems fine.
The only issue I have now seems to be the camera, both stock app and GCam.
Open camera works , has the correct photo and video res, 60FPS doesn't work and the flash seems a bit laggy, but for me it's ok.
The DAC however is there, alive and kicking, Neutron detected the Hi-Res codec at launch and switched to it. It sounds the same as stock OREO to me so it is great, as this was my greatest fear when migrating to PIE. The DAC-AMP combo is like 60% of the reason I bought this phone in the first place.
Click to expand...
Click to collapse
Thanks! That will help me a lot to write a full guide. You'll be credited, don't worry
And yeah, when you migrate to custom roms you'll have to sacrifice camera quality and functionality and also a bit of speakers sound quality (all dolby atmos ports I tried are quite buggy and don't work well ; i only use atmos with the speakers). Headphones sound quality is great though.
If you don't use camera that much (not my case) and you're okay with the speakers sound quality then custom roms are probably the best option out there.
@joaocandeias
I was fully aware of the camera issues I might encounter, this has been the case with my old Mediatek devices when going to custom as well, same camera issues, but at least...it works here. Yeah, I lost some functionality, but to me it's a good trade-off. It can still take snaps and film properly so it's enough for me.
I am kind of going to miss Dolby on speakers (never liked it on headphones though), as it did a really good job for podcast style videos on YT, but it still sounds way better than a lot of phones without it so it's fine. I just need to crank the volume up a little more than usual.
I've heard that treble Pie Roms require a oreo bootloader, is this true? I am still confused how to install on my A2017G. In which order would I install bootloader and vendor partition?
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 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)!