[XZ1c/XZ1/XZp] temp root exploit to backup drm keys implemented

Search This thread

arslancn

Senior Member
Feb 19, 2016
120
28
Ankara
I fix volte and wifi calling on my XZ1 with this steps.
-flash twrp, make a full wipe(system,data,dalvik,cache) and format data and reboot recovery
-flash m rom from this link and reboot
-after boot, go flash mode and flash .306 firmware from newflasher and boot your phone
-after boot, setup your phone and it will work
edit: also you guys can try this :
1)extract oem folder from m rom(and delete including ''deletable-app'' folder inside)
2)download this and delete oem folder inside the zip and change with extracted from m rom and flash
 
Last edited:

styr

Senior Member
Jul 21, 2010
358
806
Hello.

Here is the patched secd for XZ1 Compact with Android 9.0 (47.2.A.0.306).

Android Attest Key shows as NOT PROVISIONED even with this patched secd, but other keys and blobs works.
Logcat shows this about it:
Code:
11-27 01:24:12.753 693 693 E KeyMasterHalDevice: Attest key send cmd failed
11-27 01:24:12.753 693 693 E KeyMasterHalDevice: ret: 0
11-27 01:24:12.753 693 693 E KeyMasterHalDevice: resp->status: -10003

You may need to restore your TA-locked.img backup after flashing this patched secd to get your keys.

This is NOT DRM Fix.
It will work only if you have TA-locked.img backup with your keys (got temporary root with renoroot and backed up your TA before unlocking bootloader).

Hello,

will this work on XZ1 Compact with Android 9.0 - 47.2.A.2.33?

L.E. Seems to be working.
 
Last edited:

kountry83

Senior Member
Mar 5, 2011
605
271
Baytown
First of all, nice work! And thank you soo much! This is exactly what I needed & I plan 2 donate on payday.
Out of the 7 or 8 times I ran this.. Lowest was 30s and highest was like 10mins (with a couple reboots). I did backup my DRM keys. But, then I realized I didn't need 2 unlock my bootloader. With this temp root, I copied the oem.sin files from the US Xz1c into my Xzp.
I now have fingerprint, VOLTE & WiFi calling (US tmobile) working on my XZP WITH LOCKED BOOTLOADER!!
AFAIK this was never possible on the XZP until you wrote this super code. Updating firmware is also possible by deleting the oem.sin file before flashing. But, I was not successful with pie YET. I did get the dsds_tmobile_ims modem loaded, but I guess the other VOLTE triggering parts are different. If the US pie update for the Xz1c ever gets released.. I will just use those oem.sin files in my pie.

That zip you posted contains the oem.sin folder from the US XZ1c firmware. That's what I am using now & it works great on Oreo. The only change I had 2 make was the text in modem.conf file that's in the modem-config/408 folder. Mine is dual sim so I had 2 change it from "tmobile_us_ims" to "dsds_tmobile_us_ims" then I copied it with temp root & set permissions. I also tried this on Pie but it would not change to the "408" overlay. I even tried forcing it 2 load the modem.conf file by copying it into the root dir of modem-config folder.
This actually loaded the modem in Pie, but still didn't trigger VOLTE settings. What MIGHT work is the Pie oem.sin files from the US XZ3. I downloaded that firmware & realized it also contains the US tmobile 408 overlay folders. But the modem-conf/408 folder structure is different & has multiple folders in it. And they all point 2 a totally diffent modem. I think if I copied my working modem.conf into all those folders in Xz3 oem/modem-config/408 & then temp rooted again, set permissions, then flashed Pie WITHOUT oem.sin file.. It might actually work. But this is time consuming for me 2 test. It would be much easier for someone with an unlocked bootloader 2 simply test this with TWRP.

Hey bud,
This is what @raven213 did with his Sony Xperia xz premium G8142 with unlocked bootloader and rooted did to get the file I posted working on pie.

flashed TMo-VoLTE-Fix-v3 after rebooting i had to go to oem/modem-config and edit modem.conf from "tmobile_us_ims" to dsds_tmobile_us_im" after that i went to system/etc/customization/modem and deleted amss_fsg_maple_dsds_tar.mbn and restarted the phone and it worked
 

mad0701

Senior Member
Nov 4, 2015
229
19
In this case I'm happy :
In Pie I can add a Sip Provider once again... In Orego only Voice over WLAN was available.... So I can add a Sip Provider of my choice and can make calls from other countries via Wlan or Mobilinternet.
 

Robin Banks

Member
Dec 11, 2018
12
16
Hey bud,
This is what @raven213 did with his Sony Xperia xz premium G8142 with unlocked bootloader and rooted did to get the file I posted working on pie.

flashed TMo-VoLTE-Fix-v3 after rebooting i had to go to oem/modem-config and edit modem.conf from "tmobile_us_ims" to dsds_tmobile_us_im" after that i went to system/etc/customization/modem and deleted amss_fsg_maple_dsds_tar.mbn and restarted the phone and it worked



That's the same files I used.. I was able 2 get dsds_tmoble_us_im modem loaded in Pie.. But, I couldn't get "408" customization to load. So the VoLte switch was grayed out. XZ1c US pie should be out soon. That should contain the easy fix
 
Last edited:

schnurzelat

Senior Member
Oct 20, 2007
53
3
Finally i got a root shell to backup my ta partition! I needed a lot of patience, turn on the flight mode and remove the sim card. I had many reboots without a root shell.

Now i tried to copy /system/sh to the oem partition. if i call /oem/sh i got the '#', but that's seems not to be root shell. I can't cat the /system/build.prop and couldn't start dmesg.

Code:
1|G8341:/data/local/tmp $ ls -lZ /oem/sh
ls -lZ /oem/sh
-rwsr-sr-x 1 root root u:object_r:oemfs:s0 298840 2018-12-14 10:49 /oem/sh
G8341:/data/local/tmp $ /oem/sh
/oem/sh
# dmesg
dmesg
dmesg: /dev/kmsg: Permission denied
# cat /system/build.prop
cat /system/build.prop
cat: /system/build.prop: Permission denied
# id
id
uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input),1007(log),1011(adb),1015(sdcard_rw),1026(drmrpc),1028(sdcard_r),2993(trimarea),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc) context=u:r:shell:s0
#

But thanks anyway! Now to the second XZ1......
 
Last edited:

j4nn

Senior Member
Jan 4, 2012
1,220
2,355
@schnurzelat, that post with su copied to /oem and making it suid binary was just an idea for developers' discussion about possibilities for further exploiting to convert the temporal root into a persistent one without unlocking bootloader. But that post contained very important (not solved) note/question, what to do about selinux security context.
The suid sh binary in /oem is persistent root shell from linux without selinux point of view (as you can check it switches to root user indicated by # even after rebooting the phone), but it is still limited by selinux.
So this is just for experimentation / further development possibilities, it is not part of the howto, it would be in the OP otherwise.
You need to use the shell provided by renoroot for TA backup or dmesg or anything you like to do with full fledged root.
 

sepzs

Member
Aug 18, 2014
10
2
Big thanks! Installed Pie 47.2.A.2.33 Customized CH, Magisk 18.0 and secd_ignore_unlock_XZ1_Compact_Android_9.0_47.2.A.0.306.zip. In that order.

Safety net pass
Video enhancement works

Suntory blobs [READY]
CKB LIVE OK [ACTIVE]
WINEVINE LIVE OK [ACTIVE]
SOMC FIDO Key PROVISIONED, ver. 4
Android Attest Key PROVISIONED

So all seems like normal? Sent a donation.
 
Last edited:
  • Like
Reactions: j4nn

mad0701

Senior Member
Nov 4, 2015
229
19
Does we have in the meantime a solution for secd_ignore_unlock_XZ1_Compact_Android_9.0_47.2
in combination with a Sony xperia premium Xz?
 

oppenbot

Member
Oct 16, 2017
5
2
I just received my new XZ1 compact (fw 47.1.A.12.179, cda 1310-7123). For the moment, I don't want to use any non-stock ROM like LineageOS yet, but seeing this fantastic work here, I thought it might be a good idea to back up my drm keys before really using the device.

Since this is all new to me and I don't want to make any silly mistake: Would performing only steps 1 to 6 from the guide in the first post be the way to go then? Not unlocking the bootloader should mean that nothing important will be lost or changed in a way that could not be reverted, right? :)

After backing up the TA partition that contains the keys, I would then flash the newest stock firmware (currently 47.1.A.16.20) for my region.
 
  • Like
Reactions: Wondow

mad0701

Senior Member
Nov 4, 2015
229
19
That was also my intension : Let the the phone on stock, but rooted for things like Adaway, Titanium Backup, use the SD card so as I want (in some apk I can not change the DL directory to the SD card without root (I can compare this one with the phone from my wife (still on stock)) and so on....
If you have downgrade the phone and try to received temporary root to save your TA partition nothing is lost. Don't worry. On one hint from my side: Ensure in front, that all (really all) driver which you need are on the PC.
Then you can concentrate your work only on the phone without any heartattacks in the case that a driver is missing or doesn't work as expected ;)

@j4nn

Thanks a lot.!
This thread wasn'tin my focus...
It's working :)
 

tonsofquestions

Senior Member
Dec 27, 2011
79
44
@mad0701: You're suggesting something different from what @oppenbot is asking. In order to root, you have to unlock the bootloader. By doing that, you've made an irreversible change. (Permanently) rooted stock is still modified.

@oppenbot: you are correct in your understanding. Temp-rooting and backing up the DRM keys will not affect anything in the system: no keys will be lost, nothing irreversible changed (be sure not to flash any of the .ta files or persist.sin!). Making the backup now (for later, just in case) is a great idea, and then you're free to do what you want later. There's a teeny chance that unlocking and then flashing the TA taken from a different ROM image might mess something, but it's mostly in the "there's a remote possibility, and we're not completely certain" category. I haven't heard of anything, and I've personally flashed the TA from twrp without incident. So the upgrade to 47.1.A.16.20 (or even PIE) and then an unlock later should be fine as well. Happy exploiting!
 
  • Like
Reactions: Wondow and oppenbot

oppenbot

Member
Oct 16, 2017
5
2
Thanks for clarifying that. ;)

be sure not to flash any of the .ta files
Is that a general advice when flashing or does it only matter in the special case of down-grading? And what about the "Lilac_XBootConfig_MiscTA.ta" in the boot folder, do I need to delete that as well?

I just found a long discussion about flashing or not flashing .ta files in the Newflasher thread - without any real conclusion. On the other hand, j4nn's guide in the first post says:

The tool [newflasher] should skip dangerous .ta files automatically
 

Yokurt815

Senior Member
Jan 25, 2013
83
14
Langenau
Hi oppenbot,

I'm waiting for my XZ1 compact and have the same in mind.
As I undestand it's a good idea and with the temp root and backup you don't loose anything.
But as j4nn mentions in the opening thread, you might loose the Android Attest key while downgrading. But as far as I read in the other thread, that's not really affecting anything (at the moment).

Is that a general advice when flashing or does it only matter in the special case of down-grading? And what about the "Lilac_XBootConfig_MiscTA.ta" in the boot folder, do I need to delete that as well?
That is a general advice, as TA partition contains YOUR device specifiv keys.
I've implemented tools that allow to backup the whole TA partition, which contains device master key needed to access sony drm keys and restore the TA after bootloader unlock in order to make the camera (among other things) working again on any sony stock firmware.
 

j4nn

Senior Member
Jan 4, 2012
1,220
2,355
Please see @munjeni's newflasher source on github newflasher.c:2076, there is following big IF clause, skipping certain TA units:
Code:
if (memcmp(unit, "000008B2", 8) == 0 || /* unlock key */
						    memcmp(unit, "000007D3", 8) == 0 || /* hardware config */
						    memcmp(unit, "000007DA", 8) == 0 || /* simlock */
						    memcmp(unit, "00000851", 8) == 0 || /* simlock signature */
						    memcmp(unit, "000008A2", 8) == 0 || /* device name */
						    memcmp(unit, "00001324", 8) == 0 || /* device id */
						    memcmp(unit, "0001046B", 8) == 0) { /* drm key */
							printf(" - Skipping unit %X\n", unit_dec);
							continue;
}
So checking .ta files from 47.1.A.8.49 fw for example, keeping or deleting simlock.ta (000007DA) would make no difference - newflasher just skips it.

The unit 0x0001046B (i.e. 66667) - device master key - which we are restoring with TA restore after bootloader unlock - cannot be flashed at all even with already unlocked device (not even with patched newflasher with the above check-skip removed).
This we have tested with @tramtrist creating a devkey.ta file with the key from locked TA backup - flashing it is denied even by unlocked phone (so that check above may not even be necessary).

I am not sure about the other .ta files, but just guessing from their file names: master-reset.ta would probably cause a factory reset, so you may skip it or use it as a last resort to get out of a boot loop for example.
The rest like auto-boot.ta, cust-reset.ta, fota-reset.ta, osv-restriction.ta, reset-kernel-cmd-debug.ta, reset-non-secure-adb.ta, reset-wipe-reason.ta - they have a hint in them, mostly look like resetting some runtime flags, probably not that important - maybe except cust-reset.ta, which in my opinion is supposed to be used when you switch customization.
The .ta in boot looks like configuring boot sequence/boot device after flashing bootloader - but that is most likely already set, so skipping it or flashing the already set value probably makes no difference.
Please note, all this are just my personal guesses - I do not know it.

Just skip flashing persist.sin as that removes the Android Attest Key for sure.
But if you unlock, even having untouched persist partition with Android Attest Key does not provide any benefit, because that key can only be used with locked bootloader to verify that state from Trust Zone. Having the key with unlocked bootloader might possibly be used to prove your phone is _unlocked_ (this state in Trust Zone cannot be faked no matter what), so that is not very useful, is it?!
 

mad0701

Senior Member
Nov 4, 2015
229
19
I've flashed the update after unlook the BL so as described in the manual...
Delete all *. ta in the directory... but leave the TA in the boot subfolder. Delete the persist file... after that I start the flash process... Yes, I've restore the TA. image.. Yes I lost??? never seen any keys as SOMC Keys (the phone was original on Pie with a telekom image) the Android Attest Key.. once repea.. I've not see the key as valid key on my phone... Yes... all things are working on Pie, except the x-... Screen... after flash the patch also the x-screen is working... In this moment I didn't see any gaps... The risk of all just be clear... after recognize what could be happen... make or leave it...
Root.. for my person... give me the possibility to change things as I want.. which are not available without root.. and this in a StockFW... (so like as in older version of Android)
 
Last edited:

j4nn

Senior Member
Jan 4, 2012
1,220
2,355
There is a reason to grab screenshorts throughout all the process - having them allows to check what keys were available in each step. The screenshots are particularly important before unlock. Checking security screen of still locked device within exploitable oreo firmware would reveal what was available before unlock...
 

ParkourPaul

Member
Jan 15, 2015
20
15
I have successfully backed up and restored .ta. OTA never came on downgraded FW so I updated to Pie manually. Suntory blobs error, SOMC FIDO not provisioned, WIDEVINE OK, Android attest key provisioned. Magisk and TWRP installed, safetynet passed, root active. Image enhancement not working.
@j4nn, thanks again for this, I've sent you some beer money. Please let us know if/when we can restore image enhancement with Pie.
 
  • Like
Reactions: SGH-i200

Top Liked Posts

  • There are no posts matching your filters.
  • 1
    Is what is said in this news article correct ?

    So i can just unlockbootloader without losing anything and flash customrom ?

    Does this mean i dont have to do what is described in this thread ?
    what for me might as well be quantum fysics ? hahaha
    I guess so, I unlocked the bootloader without knowing about the drm keys and the camera remains the same, everything the same (on pie).
  • 130
    Tools to backup TA partition (drm keys) of Xperia XZ1 Compact
    renotrap-xda-icon.png
    by j4nn
    https://j4nn.github.io/

    As everyone knows, bootloader unlock via code from sony removes drm keys. That disables certain functions, the most critical one being the camera (outputting only solid green pictures in case of oreo fw).
    I've implemented tools that allow to backup the whole TA partition, which contains device master key needed to access sony drm keys and restore the TA after bootloader unlock in order to make the camera (among other things) working again on any sony stock firmware.
    In order to be able to use the tools, you need to flash one of the supported firmwares (or be lucky to have the phone already running it).
    In case you need to downgrade, please check this thread first.

    Anybody who is about to unlock your phone, could you please do so with additional test included?
    See post#500 and post#502 for more details.
    Additional details in post#515, post#516, post#517 and post#527.
    Instructions for the test that I kindly ask anybody who is about to unlock to do are described in the post#520 -- tested already.
    Thank you.


    ABOUT THE TOOLS
    • renosploit - rename/notify exploit to get kernelspace read/write, uses multiple vulnerabilities to overcome kaslr, pxn and pan mitigations of android oreo
    • renotrap - helper application (rename/notify temp root app)
    • renoshell - get temp root shell by use of kernel space read/write primitives provided by renosploit (sources available here)
    • renoroot - a shell script to be started from adb, it starts the above tools to get temp root shell
    A preview video of the tools in action can be downloaded here: renoroot-preview.zip or watched online here.

    As an alternative to renoroot you may use 'bindershell' to get a temp root shell for TA backup - it is available here /added on 2020-02-08/

    SUPPORTED TARGETS
    (with downloadable firmware links)
    • Sony Xperia XZ1 Compact (G8441)
      47.1.A.2.324_CE1 (initial tested by @tramtrist, this release tested by @tanapoom1234 post#212)
      47.1.A.8.49_CE1 (tested by @notaz post#224 and @orsonmmz post#232)
    • Sony Xperia XZ1 (G8341/G8343)
      47.1.A.2.324_CE1 (tested by @HandyMenny post#228)
    • Sony Xperia XZ1 Dual (G8342)
      47.1.A.2.281_CE1 (tested by @Vildanoff post#230)
    • Sony Xperia XZ1 (SOV36) /added on 2019-08-22/
      this Japan version can be flashed with fw for G8431 making it exploitable as standard XZ1 (the possibility to use G8431 fw is confirmed here and also here)
      /this confirms there might be a possibility of TA backup for few yoshino platform phone models that are possible to flash with one of the above firmwares (and boot ok even though designed for other phone variant)/

    • Sony Xperia XZ Premium (G8141)
      47.1.A.3.254_CE1 (tested by @DocLM post#227, by @LinFan post#242 and by @steso90 xzp forum post#45)
    • Sony Xperia XZ Premium Dual (G8142)
      47.1.A.3.254_RU (tested by @greatpatel007 xzp forum post#31 and #39)
    • Sony Xperia XZ Premium (G8188) /added on 2019-04-24/
      this Japan version can be flashed with fw for G8141 making it exploitable as standard XZp (tested by zatsune as documented here)
      /this confirms there might be a possibility of TA backup for few yoshino platform phone models that are possible to flash with one of the above firmwares (and boot ok even though designed for other phone variant)/

    An advice: before flashing anything, enable 'OEM Unlocking' in android developer menu and if flashing a fw for different phone model, skip flashing bootloader (i.e. remove boot/ subdirectory completely before using newflasher). /added on 2019-08-27/

    Please note: the temp root exploit (all renoroot tools) are designed only for the above firmware versions (binary kernels builds in them) - there is no chance it would work on other phones or other kernel builds - do not try it, it would not work.
    Concerning portability to other targets, the exploit itself needs several vulnerabilities not fixed in a kernel, the primary one is CVE-2017-7533 (race between inotify and rename).
    This was patched by google with 2017-12-05 security patch level. That means unless you can flash a firmware with older security patch level, it would not make sense to try to adapt the exploit for a new target (like it is a case with XZ2 Compact device for example).

    USING THE TOOLS
    Please follow the steps bellow for a official and up to date guide. If something was not clear enough, you may also check post#382 from @munted for a pdf guide with screenshots possibly containing more details and windows specific hints.
    1. backup everything you need from your phone
    2. flash compatible firmware
      Before flashing, you may take a screenshot of service menu -> service tests -> security possibly together with current sw version screen for reference and copy them from the phone to your PC.
      You can use newflasher tool from @munjeni and use instructions there to flash the firmware.
      The tool should skip dangerous .ta files automatically. You may consider removing Just remove the persist_X-FLASH-ALL-42E5.sin file, which is discussed here to avoid flashing it - as tested by @tanapoom1234, not flashing the persist partition allows to keep the Android Attest Key - check his post#212. /Added on 2019-04-06: The key is not part of TA obviously, it is present in the persist partition, so never flash persist even after TA backup./
      /Added on 2019-04-09: When flashing a firmware, be sure to flash it's bootloader too (i.e. the whole 'boot' directory needs to be present with all files in it including the .ta there). You might skip appslog, diag, Qnovo and ssd./
      In case of downgrade it is needed to flash userdata (and possibly also cache) otherwise you get a boot loop.
      Just backup your stuff before downgrade as with downgrade comes a factory reset. In fact I would recommend to do a factory reset just before the downgrade in order to remove the binding to your google account. This way you can avoid going online after the downgrade if used without sim and skipping wifi configuration.
    3. prepare your phone
      When the phone boots up, try to avoid connecting to internet by selecting only wifi and not configuring any, skipping accounts setup for later.
      This may not always be possible - if persist is not flashed, android insists on setup of google account online, also starting downloads for upgrade.
      Cancel everything as soon as possible and disable wifi. You may be better not using a data enabled sim card - we try to avoid any updates.
      Disable auto updates of both apps and system. Change the theme from animated backgroud to a static one.
      Enable developer menu, enable adb and "Stay awake" option. An youtube video showing the initial setup to prepare for renoroot is available here.
      Take a screenshot of service menu -> service tests -> security for reference and copy it from the phone.
      Again be sure both wifi and mobile data connection are disabled to avoid any background internet access.
    4. install the tools
      Unzip renoroot.zip (download it bellow). Use following adb commands to get the tools to the phone:
      Code:
      adb push renoroot /data/local/tmp
      adb push renoshell /data/local/tmp
      adb push renosploit /data/local/tmp
      adb install -r renotrap.apk
    5. start the tools to get a temp root shell
      Use adb shell to get a command line terminal to the phone and use following commands:
      Code:
      cd /data/local/tmp
      chmod 755 reno*
      ./renoroot
      The last command above will start the exploit eventually resulting with a temp root shell (that should be indicated by # char before the cursor).
      It may get the phone to reboot in case an overwrite does not hit the wanted shaped heap object.
      You may wait few minutes after the phone boots to allow startup processes to settle down in order to avoid timing influence for next trial.
      There is a video for example of this step available here.
    6. backup your TA partition
      When renoroot is successful, you may use following commands in the root shell to backup the trim area partition:
      Code:
      cd /data/local/tmp
      dd if=/dev/block/bootdevice/by-name/TA of=TA-locked.img
      chown shell:shell TA-locked.img
      sync
      sync
      And then try to read it out from the phone to your PC - use another command prompt window, do not exit the root one:
      Code:
      adb pull /data/local/tmp/TA-locked.img
    7. unlock phone's bootloader using a code from sony
      When you have the TA-locked.img on your PC including screenshots, you may start the official Sony unlock procedure - follow instructions on sony website please.
      Added on 2019-04-16: please note, bootloader unlocking is not reversible - it is not possible to re-lock back (restore of TA-locked does not relock the bootloader).
      So be prepared to live with the boot up warning screen (can be seen for example in this video).

      Again be sure you have the TA-locked.img on your PC before you start unlocking the bootloader - unlock will erase you phone, so it would get lost from /data/local/tmp if not backed up.
      In case oem unlocking is grayed out (so you cannot enable it) you need to go online at least once and the option would be accessible then - video here.
      After you unlock the bootloader, do not flash anything - just boot the same unmodified fw we used for the temp root.
    8. get temp root again to restore TA
      Use the same instructions to avoid internet access and updates as described above, configure the few above mentioned options and start renoroot as before.
      With the temp root shell, backup the unlocked TA (for future comparisons) and then restore the state from the locked one. You may need to adb push the TA-locked.img back to /data/local/tmp as the unlock erased everything.
      Code:
      cd /data/local/tmp
      dd if=/dev/block/bootdevice/by-name/TA of=TA-unlocked.img
      chown shell:shell TA-unlocked.img
      sync
      sync
      And then try to read it out from the phone to your PC (and transfer the locked TA back to the phone) - use another command prompt window, do not exit the root one:
      Code:
      adb pull /data/local/tmp/TA-unlocked.img
      adb push TA-locked.img /data/local/tmp
      And using the window with renoshell temp root shell, restore the TA:
      Code:
      cd /data/local/tmp
      dd if=TA-locked.img of=/dev/block/bootdevice/by-name/TA
      sync
      sync
    9. boot up the phone with the current fw and see about the camera if it works on not
      You may also document the security screen state by taking a screenshot. Do not forget to transfer it from the phone to PC.
    10. flash twrp recovery
      Updated on 2019-08-08: please see post#1029 for the latest workflow with the kernels hiding bootloader unlock status.
      Updated on 2019-02-10:
      Instead of flashing twrp, you may just 'fastboot boot' it if you need it.
      Instead of the steps 10. to 13., you may use patched and rooted kernel hiding bootloader unlock available in following forum threads in order to be able to even install FOTA system update
      giving you back sony drm functionality that fw disables when it detects unlocked bootloader status. For more details see also post#645 of this thread.
    11. OPTIONAL step (only for XZ1c maybe XZ1)
      This step is optional and only lightly tested. The idea is that secd detects unlocked bootloader and switches to limited mode even though drm keys are available. This can be seen in the adb logcat with following message:
      Code:
      E secd    : secd_backend_credential_manager.cpp:77    the bootloader is unlocked, use limited functionality
      To workaround that, we may use a secd ripped from secd extension by modpunk - just flash attached secd-ignore-unlock.zip at bottom of this post via twrp recovery (do not flash the 'secd extension by modpunk' which is linked here only for reference).
      I've analysed, what changes were done in the secd. Also the lib which fixes the missing device key in TA is not needed from the modpunk's package as we have the real valid key there, so I've removed the lib (and the script which would preload it). Therefore it is just about making secd think that bootloader was not unlocked. Thanks to @modpunk for the patched secd and @russel5 for the flashable zip on which the secd-ignore-unlock.zip is based on.
      With this, sony updates may start to arrive.
      Please note, this would make sony think the phone runs unmodified and still locked fw. OTA updates may restore original secd or fail altogether (due to modified system/vendor/... partitions).
      You may boot the phone to see what happens (OTA updates?) - edit: OTA updates did come, but install to be done on reboot failed - tested by @Unbounded, see post#43 and #44 of the attest key thread please - this may confirm the availability of the SOMC Attest Key which may be the key needed to get sony ota updates (just a guess, not sure what exactly this key is used for).
      Again, this step is optional and very experimental, maybe better not to apply it (camera works without this step on any stock fw without any change /until sony changes that in some update/).
      Update: see post#395 for secd_ignore_unlock for XZ1c for pie from @S-trace - thank you. It works with XZ1 too (see post#396). The patch port for XZp pie is here: attest key thread post#67.
      In my opinion all these secd patch variants are hiding the unlocked state only partially. There are other components in the fw that ask about the unlock state. A proper solution for this is the unlock hiding patched kernel linked in the step 10. of this howto.
    12. flash a recent stock firmware
      In case you wanted the patched secd, flash it again over the flashed fw.
      Boot the phone, check functionality, take screenshots.
    13. install magisk if rooted phone is what you need; -)
      Follow instructions of latest magisk, it should work without any special actions.

    AUTOMATED FULL BACKUP
    These are experimental tools (and actually seem not to work in some cases getting truncated files that are useless) to extract most of the partitions from the phone after getting a temp root. It can be used for comparisons/analysis of what unlock changes (download backup-tools.zip at bottom of this post).
    You would run backup-setup.bat in windows command prompt first (you may need to adjust the PATH setting to find adb properly) to copy the tools to the phone and setup tcp forwarding for netcat based copying.
    Then using adb shell you would do:
    Code:
    cd /data/local/tmp
    ./backup-send.sh
    and in windows command prompt you would start:
    Code:
    backup-recv.bat bk-unlocked
    and partitions images would be extracted from the phone (for larger ones sparse android image format is used).
    Full depth comparison could be achieved by use of these backup tools (obviously needs to be done twice - before and after unlock, changing the target directory name argument of backup-recv.bat).

    WHAT WORKS
    Here is a quote of post#185 from @tramtrist in this thread describing the results of the initial tests - special thanks to him!
    I'd like to report in real quick on what's working.
    After following @j4nn very clear instructions and backing up/restoring my TA keys I was left with the NOT PROVISIONED messages he mentioned earlier. However this seems to be no problem as after TA-restore my camera works as it did before. I'm also able to use WIDEVINE sites which require that key as well.
    After restoring TA I went ahead and flashed the latest UK customized firmware
    I then flashed TWRP latest version 3.2.3
    I wanted to have root so I flashed Magisk 1.73 and safety net worked without me having to do anything special.
    Google Pay could be set up and seems to be using my credit cards just fine.
    I didn't flash any custom kernel as stock is just fine for me.
    Adaway is working with root without issue.
    All-in-all if you follow @j4nn instructions when he's ready to fully release them to the public then I'd say you will be in good shape.
    I'd like to thank @j4nn for giving me the chance to finally contribute something concrete to this community. If you're gonna use this you should drop him some cash.
    Update: if you follow the links added in step 10. and use "rooted kernel hiding bootloader unlock", it seems you can have all functionality restored including fota system updates while having magisk root with passed safetynet cts. Verified by @notaz in post#14 of the "[XZ1c] rooted kernel hiding bootloader unlock" thread. Thanks.

    ACKNOWLEDGEMENTS
    Many thanks to following users:
    • @moofesr - for testing initial kernel builds until proper build procedure had been found, special thanks for his patience when all tests resulted with bootloop
    • @Raz0Rfail and @moofesr - for testing timing of rename/notify vulnerability with patched kernel
    • @dosomder (aka zxz0O0) - for his iovyroot
    • @tramtrist - for initial testing of TA backup, unlock and restore, special thanks for exposing to risk of loosing drm if it did not work
    • @tonsofquestions - for a lot of testing with unlocked-ta-restored phone when I did not have an unlocked phone yet
    • ThomasKing (not a user on xda) - for his black hat ksma presentation
    • few other users in this and attest key lost thread here on xda - for some other cve possibilities, ideas and specific tests

    DONATIONS
    Please note: I had to invest enormously lot of time (as you can see throughout this thread and also summarized in progress/change log in post#2) to develop these tools, the code is extremely complex (more than 9000 lines of source code) and it was unbelievable hard to debug and get the timing usable.
    It would be kind of you if you could consider donating here please:
    https://j4nn.github.io/donate/
    I would be happy to accept any donation to me as a form of gratitude in case the software helped you to backup your TA (drm keys) before bootloader unlocking.
    Thanks.

    DOWNLOAD THE TOOLS
    See the attached renoroot.zip at bottom of this post.
    Please post your experience with using the tools, if it worked and on which phone model (and fw in case of xz1c).
    You may include info about how long it took to get a root shell, how many reboots, how many events in the last trial which succeeded with how many overwrites (just one with success is the best, more means previous overwrites did not hit wanted object in shaped heap resulting with possibly unstable system). This info is interesting for statistics, so we all know, how fast can we get a temp root on each device/firmware.
    Thanks.
    31
    permanent root with still locked xz1c preview

    Here a preview video of my current work: still locked xperia xz1c with permanent root on latest fw
    Phone since power up, no unlocked bootloader warning screen, i.e. still locked, with root / magisk right after boot, even auditor app passes the hardware attestation confirming locked state.
    fw version 47.2.A.10.107 (July 1, 2019 security patch level)
    25
    Try to flash full 47.1.A.16.20 fw with newflasher - remove *.ta, keep boot subdirectory (including the one .ta there), remove persist (and optionally Qnovo, amss*, ssd) sin files.
    Try to boot it, check camera and video enhancements. At least camera should work if TA was previously restored.
    Flash the latest twrp. Then magisk. As far as reported by other guys, these two steps were straightforward...

    Does it matter if you don't remove *.ta files or the remove persist (and optionally Qnovo, amss*, ssd) sin files??? (My Android Attest Key was NOT PROVISIONED anyway when I started.) I err just left all the files and flashed them, camera is working though and I have working root and TWRP.

    I've also attached a guide, have a look, honestly because I was fumbling around this whole process took me many hours over 3 days and I'm really glad to get responses to my questions. I hadn't done a lot of this stuff for over a year so I basically had to research from scratch on how to install TWRP etc. But I think the guide should change the degree of difficultly from, "this is quite an involved process, you need to have prior experience with installing multiple tools like TWRP, magisk etc. and know where to find the right Google and Sony drivers from as well as have some UNIX knowledge" to more like, "doable for intermediate users who can download and unzip files and can put commands into Command Prompt." It's a small contribution but I'm hoping it should make your work more accessible and more people will use it. :laugh:

    Again thanks for making this tool j4nn and thanks to tonsofquestions and j4nn for all your help and answering questions, no guarantee I won't ask more questions though! Again hopefully this guide will mean less questions from others! :D

    If anyone has tried to follow this guide and has any suggestions or found it useful let me know :)
    24
    @SXUsr, you know, my work definitely was not about making a profit.
    As mentioned in this post (my answer for a help request to exploit google pixel 2 xl locked down by verizon), just counting the time spent, I could make a better profit taking any low paid job than any bounty promised here.
    If I wanted everybody to pay, it would be a heavily protected commercial app with online license providing private keys to obtain key parts to exploit particular target.
    As already mentioned, if I did not want to get it done for myself, I would not do it, regardless possible reward.

    So thank you to all who donate.

    And so you know, there was an exceptionally generous donation recently - a person who donated even 100$ (not making any comment or any link to a nickname here).
    Thank you very much. That shows there are few who really understand how it was difficult and what value it brings.

    And so you know, your money did not get wasted - I've ordered a brand new XZ1 Compact just for testing and development work.
    This will allow me finally to use my phone for daily driver while I can develop or test anything on another one.
    I believe this phone is great, possibly one of last with such small/acceptable size, now temp-rootable to get it under full control - not sure this repeats anytime soon.
    Working on the exploit and testing downgrades and such, I did not have even a contact list in my phone for something like 9 months!
    Think about it, having such phone and instead of using it, working so long on an exploit...

    Thanks again to all who appreciate the effort, the value it brings and donate/donated something.
    22
    DEVELOPMENT PROGRESS / CHANGE LOG
    • 26-05-2018 started this thread listing vulnerabilities found during many weeks of research done right after buy of my XZ1c phone
    • 06-06-2018 post#7: managed to boot kernel from the 47.1.A.2.281 fw in qemu
    • 16-06-2018 post#25: simple out of bounds overwrite not useful, complex exploiting of use after free needed
    • 02-07-2018 post#33: explained how use after free exploit would work, but timing is impossible: kfree from rcu too late
    • 06-07-2018 post#44 and post#48: more details about exploiting use after free and kfree_rcu too late kfree timing problem
    • 17-07-2018 post#53: first kernel to test timing, did not boot when tried with unlocked xz1c
    • 27-07-2018 post#73: solved the problem with delayed kfree from kfree_rcu, basic inotify/rename proof of concept running in qemu for long filenames
    • 27-07-2018 post#75: found a way to build xz1c kernel from source which can be booted on unlocked xz1c, confirmed the delayed kfree from rcu timing problem
    • 11-08-2018 post#88: extensive testing of timing
    • 20-08-2018 post#104: inotify/rename exploit now works with long filenames, allowing kernel heap (256 bytes slub unit) overflow, overview of next phases of the exploit yet to be implemented
    • 31-08-2018 post#118: implemented mostly arbitrary kernel write _together_ with mostly arbitrary kernel read, first bypass of KASLR but we need to bypass PXN & PAN too
    • 15-09-2018 post#131: found that we will need ROP/JOP gadgets to overcome PXN & PAN oreo mitigations, more details in post#135
    • 22-09-2018 post#137: first arbitrary kernel space read and write proof of concept working in qemu
    • 22-09-2018 post#138: with great timing luck kernel space R/W poc worked on still locked xz1c
    • 05-10-2018 post#146: first backup of my xz1c locked TA done: asking for an unlock-and-TA-restore test volunteer
    • 07-10-2018 post#151: confirmed that BL unlock removed 66667 unit - device master key?
    • 18-10-2018 post#162: exploit not reliable enough for public use yet
    • 22-10-2018 post#165: renoroot preview video, send initial test version to @tramtrist
    • 22-10-2018 post#168: renoroot initial test results - after TA restore camera works, BL remains unlocked
    • 25-10-2018 post#185: more initial test results directly from @tramtrist
    • 28-10-2018 post#199: researched possible uses of various keys from security service menu
    • 03-11-2018 post#206: renoroot temp root including tools and howto for TA partition (drm keys) backup released, put everything on the first page
    • 05-11-2018 post#235: renoroot confirmed working with other phone models
    • 10-11-2018 post#287: ordered a new xz1c just for testing and development work
    • 18-11-2018 post#348: the new xz1c arrived
    • 22-11-2018 post#372: a persistent root from a temp root possibility - but not with selinux
    • 11-12-2018 post#428: possibly the fastest temp root - 6.03 seconds with just 53 events and 1 overwrite
    • 05-01-2019 post#493: explained about TA restore not re-locking bootloader - good for us!
    • 09-01-2019 post#515: intercept BL unlock of xz1c in the middle of the procedure
    • 10-01-2019 post#516: posted few videos to highlight key points when preparing for unlock with backup of TA via renoroot temproot
    • 10-01-2019 post#517: video showing xz1c bl unlock with twrp booted in the middle
    • 11-01-2019 post#520: howto for unlock with the twrp booted in the middle
    • 19-01-2019 post#602: info about test to write dev master key TA unit from the secd process
    • 30-01-2019 post#620: info about TA restore and various drm keys
    • 02-02-2019 post#623: preview of FOTA system update fully installed with unlocked and rooted XZ1c - it confirms all functionality of a locked phone have been restored
    • 05-02-2019 post#633: tested fota system update from oreo to pie - posted a video
    • 10-02-2019 post#645: kernels hiding bootloader unlock released for XZ1c/XZ1/XZp - with locked TA restored this brings root with all locked phone functionality of stock fw restored
    • 16-02-2019 post#652: ported BL unlock hiding patch to TAMA platform for testing with XZ2 (it worked, but cannot be booted via fastboot due to bug in bootloader according to sony /more details here/)
    • 19-02-2019 post#663: patched XZ2 kernel to make it boot via 'fastboot boot' command from usb (tested successfully by @serajr post#664) - shall be useful for twrp setup on TAMA platform (post#668 by @MartinX3)
    • 19-02-2019 post#672: fota system update with my rooted kernels verified with XZ2 phone by @serajr - so we may have fota system update with root on xz2/xz2c/xz2p/xz3 phones too (theoretically)

    ---->> moved the original opening post in here ----
    Downgrade XZ1 Compact to 47.1.A.2.281 firmware version (not sure if this downgrade is safe, see android-attest-key-lost thread here please). The 47.1.A.2.324_CE1 version might be better to try first.

    The 2.281 fw results with android security patch level 2017-08-05, kernel 4.4.74, android oreo.

    BlueBorne vulnerabilities are not patched yet with this firmware:
    CVE-2017-0785 Android information leak vulnerability PoC seems to work - tested myself.

    Not sure, but it seems that bluetooth service is not a 32bit process anymore, contrary the note in BlueBorne whitepaper /The​ ​Bluetooth​ ​service​ ​in​ ​Android​ ​runs​ ​under​ ​Zygote​ ​(Android​ ​service​ ​manager),​ ​and​ ​is surprisingly​ ​a​ ​32-bit​ ​process​ ​(even​ ​when​ ​the​ ​OS​ ​and​ ​CPU​ ​are​ ​ARM-64​ ​for​ ​instance/ - example of stack dump obtained:
    Code:
    000000b0  00 00 00 00  ff ff ff fd  ff ff ff ff  d8 69 f4 80  │····│····│····│·i··│
    000000c0  00 00 00 73  e8 60 0c 10  00 00 00 73  e8 60 01 40  │···s│·`··│···s│·`·@│
    000000d0  00 00 00 73  d8 6b 20 08  00 00 00 73  e8 69 06 d0  │···s│·k ·│···s│·i··│
    ...
    000007e0  00 00 00 73  2c 32 34 38  72 68 74 20  20 64 61 65  │···s│,248│rht │ dae│
    000007f0  65 6d 61 6e  5f 74 62 20  6b 72 6f 77  75 65 75 71  │eman│_tb │krow│ueuq│
    00000800  74 73 20 65  65 74 72 61  00 00 00 64  00 00 00 00  │ts e│etra│···d│····│
    Those '00 00 00 73' are often present, quite possibly the upper 32bit part of a 64bit pointer. The text at 7e8 may be something like 'thread name bt_workqueue started', possibly indicating the CVE-2017-078 PoC worked (modified so that 'n = 90' to receive more data).

    The first idea was to make the Android BlueBorne exploit working to obtain bluetooth service credentails and use that with some kernel exploit to switch to root in order to finally do TA partition backup (to save DRM keys).
    The bluetooth user seems to have the NET_ADMIN capability, that could be very useful.

    I've researched further possible kernel exploits and it seems to me that the kernel from 2.281 firmware seems to contain (at least) following vulnerabilities:

    CVE-2017-7308 AF_PACKET packet_set_ring
    This needs NET_RAW capability, that may be hard to obtain, bluetooth service seems not to have it.

    CVE-2017-7533 race between inotify_handle_event() and vfs_rename()
    https://exploit.kitploit.com/2017/08/linux-kernel-412-race-condition.html
    This may work as a standalone exploit - checked the kernel source - vulnerability is not fixed, not sure about SElinux limitations and other android security mitigations - please discuss this.
    Found only demo poc not getting root, but it may be possibly developed to full temp root standalone exploit.
    This currently seems to be the most promising.

    CVE-2017-1000112 memory corruption in UDP fragmentation offload
    https://securingtomorrow.mcafee.com...vilege-escalation-analyzing-cve-2017-1000112/
    https://ricklarabee.blogspot.cz/2017/12/adapting-poc-for-cve-2017-1000112-to.html
    https://www.exploit-db.com/exploits/43418/
    This could be used after BlueBorne done, as it needs NET_ADMIN capability.

    HELP NEEDED PLEASE - let's collaborate and develop together the needed exploits!
    For example it is hard for me to develop only with a locked device, better debugging may be possible on stock firmware with unlocked bootloader as some modifications may be flashed. My free time is quite limitted, so it would be useful to split the work.
    ----<< moved the original opening post in here ----

    It seems that 'CVE-2017-7533 race between inotify_handle_event() and vfs_rename()' is not possible to trigger from adb shell - possibly some android security mitigations/selinux limitation?
    Built exploit.c from CVE-2017-7533 with attached View attachment CVE-2017-7533-android-build.tar.gz android makefiles, adb pushed to /data/local/tmp:
    Code:
    G8441:/ $ uname -a
    Linux localhost 4.4.74-perf+ #1 SMP PREEMPT Wed Aug 9 16:09:57 2017 aarch64
    G8441:/ $ cd /data/local/tmp                                                   
    G8441:/data/local/tmp $ ./exploit 2>err.log                                    
    Listening for events.
    Listening for events.
    alloc_len : 50
    longname="test_dir/bbbb32103210321032100��1����test_dir/bbbb3210321032103210"
    alloc_len : 50
    callrename done.
    G8441:/data/local/tmp $
    the notify events seem not to be received:(
    The rename function works in the exploit (tested separately), but many errors such as
    rename1: No such file or directory
    rename2: No such file or directory
    are returned from the exploit though.
    The inotify_init1 function returns valid fd, so it looks like everything is ok, but for unknown reason, inotify events are not received.

    Running the same code in linux with vulnerable kernel results with this:
    Code:
    Linux 4.8.0 #1 SMP Tue Oct 25 09:09:01 UTC 2016 x86_64 Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz GenuineIntel GNU/Linux
    
    Listening for events.
    Listening for events.
    alloc_len : 50
    longname="test_dir/bbbb32103210321032100ÿÿ1ÿÿÿÿ"
    handle_events() event->name : bbbb32103210321032100ÿÿ1ÿÿÿÿ, event->len : 32
    handle_events() event->name : b, event->len : 16
    Detected overwrite!!!
    callrename done.
    alloc_len : 50
    Note the 'handle_events' log message presence - that indicates receive of inotify event. The rename errors are not returned in this case.

    That means even though the kernel is vulnerable (as verified in sony release source code - it is fixed since 47.1.A.12.34 version as can be seen with 'git log --stat -p origin/47.1.A.12.xxx -- fs/dcache.c' in sony's kernel git repository), it looks like we cannot trigger the bug simply from adb shell.
    This is what is configured in the kernel (using sony's build instructions):
    CONFIG_FSNOTIFY=y
    CONFIG_DNOTIFY=y
    CONFIG_INOTIFY_USER=y
    # CONFIG_FANOTIFY is not set
    Am I missing something? Any idea why the bug cannot be triggered?
    --previous edit-- 27-05-2018 at 22:58. Reason: added info about rename() on xz1c; added info about inotify_init1() on xz1c; added info about 1st fw version with a fix and relevant kernel config options
Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone