Database Users

Root Exploit

Hey guys,
I was looking at the newly patched (for 4.4.3) exploit.
It is patched in our .402 firmware but is exploitable in .69.
Update: Exploit is released, see primary thread: http://forum.xda-developers.com/showthread.php?t=2781109
-----------------------------------------------------------------------------------------
With it me and a friend have managed to take out SELinux:
Code:
[email protected]:/data/local/tmp $ getenforce
Permissive
Edit: And now, my device is rooted! Sweet Time to backup TA.
Edit#2
I/sh (12494): I am running as..
I/sh (12494): uid=0(root) gid=0(root) context=u:r:vold:s0
I/sh (12494): Backing up TA..
I/sh (12494): lrwxrwxrwx root root 1970-03-20 09:35 TA -> /dev/block/mmcblk0p1
I/sh (12494): 4096+0 records in
I/sh (12494): 4096+0 records out
I/sh (12494): 2097152 bytes transferred in 0.065 secs (32263876 bytes/sec)
I/sh (12494): Created /data/local/tmp/TA.img -- Checking MD5..
I/sh (12494): 215c7526bb9abea4ae6363c25987bbd0 /dev/block/platform/msm_sdcc.1/by-name/TA
I/SemcPhoneInterfaceManager(12500): QcSemcService is connected.
I/sh (12494): 215c7526bb9abea4ae6363c25987bbd0 /data/local/tmp/TA.img
Click to expand...
Click to collapse

WOW! this is the most exciting news on this forum yet! Do you have a link to a guide for this exploit?
Sent from my MI 2S using Tapatalk

I would really like to make it a simple process. Right now it is *VERY* ugly!
You have to take out selinux and then replace some files (specific to .69) that let you run root commands from a bash file.
Right now it's just a collection of scripts, an apk and a tar.gz. No checks at all to make sure they are being run correctly.
From what I can tell, this method I am using will work for ALL phones using Android 4.4.2 (unpatched) or earlier.
Although it is using Sony files for the exploit for no other reason than I only cared about rooting my device.

Nice. Hope you can get it polished enough to share soon! Maybe ask for donations too. I'm ordering one soon and I would love root without killing my warranty.
Sent from my MI 2S using Tapatalk

SANGER_A2 said:
Nice. Hope you can get it polished enough to share soon! Maybe ask for donations too. I'm ordering one soon and I would love root without killing my warranty.
Click to expand...
Click to collapse
Is this good enough?
https://mega.co.nz/#!zBZVnDTZ!tajRYy0F3_lgYDITHlqj3UTPv3bDiEQBUW-bj6JqMKQ

xsacha said:
Is this good enough?
https://mega.co.nz/#!zBZVnDTZ!tajRYy0F3_lgYDITHlqj3UTPv3bDiEQBUW-bj6JqMKQ
Click to expand...
Click to collapse
Cool. Can't wait to try it out. Will be a while as I'm not ordering the tablet for about a week. I'm fine with linux, but ADB looks like a complete PITA to install on it, plus having to mess around configuring the USB to talk to the tablet. I've used ADB lots on Windows with no issues and will probably run the commands from there instead. I don't quite understand the "&& \" at the end of each adb command. Is that needed if using ADB in windows?
I'm trying to figure out how it all works and I can understand most of what you have done. I assume the exploit.apk gives su. Is this temporary until a reboot or permanent? And does it mean we have to have the app installed permanently or can it be uninstalled afterwards? Then, you copy and make the scripts & binaries executable. But you don't seem to run the scripts? Do the scripts need to be run on the device in a terminal emulator to backup the TA partition and mount the new volume with vold?

Damn, already updated to .402. Is there anyway to go back to .69?
Greato work btw.

star85 said:
Damn, already updated to .402. Is there anyway to go back to .69?
Greato work btw.
Click to expand...
Click to collapse
Yes, just flash .69. I was on .402 as well and found the exploit patched.
SANGER_A2 said:
Cool. Can't wait to try it out. Will be a while as I'm not ordering the tablet for about a week. I'm fine with linux, but ADB looks like a complete PITA to install on it, plus having to mess around configuring the USB to talk to the tablet. I've used ADB lots on Windows with no issues and will probably run the commands from there instead. I don't quite understand the "&& \" at the end of each adb command. Is that needed if using ADB in windows?
I'm trying to figure out how it all works and I can understand most of what you have done. I assume the exploit.apk gives su. Is this temporary until a reboot or permanent? And does it mean we have to have the app installed permanently or can it be uninstalled afterwards? Then, you copy and make the scripts & binaries executable. But you don't seem to run the scripts? Do the scripts need to be run on the device in a terminal emulator to backup the TA partition and mount the new volume with vold?
Click to expand...
Click to collapse
There was absolutely zero configuration on my Linux distro. In Ubuntu, adb comes in the repos. You don't need drivers on Linux because they are detected as usbnet by default. It literally just works out of the box.
The "&& \" is actually for bash. The && only continues if the previous command succeeds. The \ breaks to next line.
On Windows, you'd use a caret (^) instead of a backslash.
The exploit.apk is used to deploy a shared library owned by system because when a system app tries to load its library, it needs to be owned by system and this is the only way I know how to achieve that.
The exploit is all in vdc (a shell command), which allows us to overwrite files anywhere on the system. So in this instance, ServiceMenu is used. Its library is overwritten with one from exploit.apk. The library simply turns off selinux and then runs whatever is in 'log.command' prop which is in this instance, a shell script. In the script it continues on to the root.
Basically: All apps have system libraries but they can't execute system code unless a system app runs it. System user can turn off selinux. Turning off selinux is required to run as root.
Yes, the scripts get run indirectly. You don't run them yourself because you are only a mere shell user. Vold is not used for anything. It's simply the vehicle for running as root.

Sonny, you win the internets. If I had donation money it would go straight to you.

Thanks for the explanation Sacha. Can't wait to try it. So this let's us backup TA. Does it also provide permanent root or do we still need to unlock the bootloader and break the warranty to get that?
I'll have a play putting adb on Linux tonight. All the guides I found were pretty old!
Sent from my MI 2S using Tapatalk

SANGER_A2 said:
Thanks for the explanation Sacha. Can't wait to try it. So this let's us backup TA. Does it also provide permanent root or do we still need to unlock the bootloader and break the warranty to get that?
I'll have a play putting adb on Linux tonight. All the guides I found were pretty old!
Sent from my MI 2S using Tapatalk
Click to expand...
Click to collapse
Definitely not permanent. Resets on reboot.
I couldn't find anywhere to stick the su binary. /system can't be remounted rw by root. All the other partitions don't let me setuid. If anyone knows where to stick, that would be appreciated.
Afaik unlocking bootloader shouldn't void warranty? Isn't that one of the reasons for TA. When we flash it back, warranty is valid again?

SANGER_A2 said:
Thanks for the explanation Sacha. Can't wait to try it. So this let's us backup TA. Does it also provide permanent root or do we still need to unlock the bootloader and break the warranty to get that?
I'll have a play putting adb on Linux tonight. All the guides I found were pretty old!
Click to expand...
Click to collapse
If your distro doesn't have it in the repos just download and install the official Android SDK. There you only install the "platform-tools".

Thank you very much for this, that's really great news!! As soon as I have time and found out how to flash back to .69 I will try it out. Is there a way to donate to you for your work?
Nevertheless if I understood it right, this persists only until a reboot so if I root it and then update back to .402 it will be gone, so there is no way to have root on .402 with locked bootloader?
Or is it possible to root and backup ta, flash .402 restore ta and lock bootloader AND keep root? That would be awesome!
Thanks
Fleckdalm

fleckdalm said:
Thank you very much for this, that's really great news!! As soon as I have time and found out how to flash back to .69 I will try it out. Is there a way to donate to you for your work?
Nevertheless if I understood it right, this persists only until a reboot so if I root it and then update back to .402 it will be gone, so there is no way to have root on .402 with locked bootloader?
Click to expand...
Click to collapse
I guess you can donate if you want I didn't put much time in to this and I didn't discover the Android exploit. Most my projects (like Dingleberry for rooting) have a full UI and everything. I have a donate link on my blog: http://www.qtness.com/blog/
That's correct. if you upgrade to 402, you will not be able to do it. It's a tethered root but being able to backup TA means you can unlock bootloader and lock it again with everything preserved.

xsacha said:
I guess you can donate if you want I didn't put much time in to this and I didn't discover the Android exploit. Most my projects (like Dingleberry for rooting) have a full UI and everything. I have a donate link on my blog: http://www.qtness.com/blog/
That's correct. if you upgrade to 402, you will not be able to do it. It's a tethered root but being able to backup TA means you can unlock bootloader and lock it again with everything preserved.
Click to expand...
Click to collapse
Yeah I will support your good work!
So that means I can flash 69 using flash tool and backup ta using your script, then i can flash 402, unlock bootloader, flash cwm and root? But how should I continue then? How can I relock bootloader and restore ta? And are you sure that root and cwm isn't lost during this process? Is there really no way to find out if bootloader was unlocked after doing this (for warranty reasons)? Has somebody successfully tried out this procedure?
Oh and an other problem, I can't find a 69 ftf anywhere for the Wifi only model sgp511?
BTW I have just donated to you

fleckdalm said:
Yeah I will support your good work!
So that means I can flash 69 using flash tool and backup ta using your script, then i can flash 402, unlock bootloader, flash cwm and root? But how should I continue then? How can I relock bootloader and restore ta? And are you sure that root and cwm isn't lost during this process? Is there really no way to find out if bootloader was unlocked after doing this (for warranty reasons)? Has somebody successfully tried out this procedure?
Oh and an other problem, I can't find a 69 ftf anywhere for the Wifi only model sgp511?
BTW I have just donated to you
Click to expand...
Click to collapse
For the bootloader locking questions, I'm not the best to ask. I am asking about warranty myself on another thread. This is my first sony device so not sure how they operate.
Don't know. I use sgp521.
Technically anything before firmware .402 should work.

Success!
xsacha, GREAT work!
Successfuly unlocked my bootloader and restored DRM keys! Thanks a lot! really appreciate your work:good:
And about the warranty: if you lock the bootloader before bringing the device to the service center the won't be able to find any traces of bootloader unlock! So with your help we don't need to void our warranty.

nos1609 said:
xsacha, GREAT work!
Successfuly unlocked my bootloader and restored DRM keys! Thanks a lot! really appreciate your work:good:
Click to expand...
Click to collapse
So you have done it like this?
flash 69 using flash tool and backup ta using the script, then flash 402, unlock bootloader, flash cwm and root.
But how should I continue then? How can I relock bootloader and restore ta?

fleckdalm said:
But how should I continue then? How can I relock bootloader and restore ta?
Click to expand...
Click to collapse
Just put the backup on your INTERNAL sdcard and then from adb under su type: "dd if=/sdcard/TA.img of=/dev/block/platform/msm_sdcc.1/by-name/TA"

nos1609 said:
Just put the backup on your INTERNAL sdcard and then from adb under su type: "dd if=/sdcard/TA.img of=/dev/block/platform/msm_sdcc.1/by-name/TA"
Click to expand...
Click to collapse
Thanks! I will try it out as soon as I get a 69 ftf for my model...

[Tool] [Unmaintained] dd Flasher (v2.0 beta)

Due to new security measures added on recent Android versions (mainly dm-verity), using dd Flasher on newer devices or recent firmwares (Marshmallow, Nougat, etc) will certainly result in a bootloop. dd Flasher probably still works if you have a unlocked bootloader and a modified kernel disabling dm-verity, but due lack of free time and other priorities, this tool is currently unmaintained.
Introduction
This tool is a new version of Nicki Root (originally released for Xperia M), but now compatible with almost any device. The purpose of dd Flasher is keeping root access in any firmware version assuming your device already have an exploitable firmware...
How it works?
Sony updates are packed in .sin files, generally stored in FTF packages. Using FlashTool, you can get an image of the system partition (system.ext4) of the latest firmware available, which is sideloaded into your device by dd Flasher. Next, it'll mount the update image (system.ext4) in a loop device, place SuperSU binaries (and when needed, disable RIC protection) and after that, stop all running processes and "flash" the modified image back into your device by using dd binary.
After dd Flasher finishes its work, all you need to do is rebooting your device into flash mode in order to flash the rest of the FTF file (excluding system partition, of course) with FlashTool. In the end, your device will be running the latest available firmware with full root access, making dd Flasher extremely useful for devices with locked bootloader that have exploitable firmwares but lack recoveries or other means to get root access.
Requirements
• Your device must already have root access. You can downgrade to an older firmware and root it with some known exploit, if needed. Also, if you don't have root access, dd Flasher won't work at all.
• You will need FlashTool and an FTF file of the firmware version you want to upgrade your device to.
• Your device should have enough free space to store system partition image of the update temporarily (around 1.5-2.5GB, depending of the device/firmware). At the moment you can store the image either on its Internal Storage or in external SD Card (when possible). USB OTG support is planned too.
• If pushing system image to SD Card, make sure your phone is connected in MTP mode (in Mass Storage mode only Internal Storage is accessible and dd Flasher will fail)
Instructions
Getting system partition image: FTF files are just ordinary .zip files with lots of .sin files inside, format commonly used by Sony in their firmwares for Xperia devices. We are interested in system.sin (it's the one with the partition image), to use it with dd Flasher, so:
• Open the FTF file with WinRAR or 7-Zip (or any other program compatible with .zip files);
• Extract system.sin somewhere you have easy access;
• Open FlashTool and go to Tools => SIN editor;
• A new window will open. Locate system.sin we extracted before, click in "Extract Data" and wait until FlashTool finishes extracting it
• If everything went well, now you should have a system.ext4 file in the same place you extracted system.sin before (you can already delete system.sin -- we won't need it anymore).
Using dd Flasher: now that we got our system partition image, we can move on to dd Flasher:
• If you didn't already have extracted dd Flasher somewhere, do it now (DUH!). Make sure FlashTool isn't running as well -- it's known to interfere with ADB interface;
• Move system.ext4 extracted previously to the same folder you've extracted dd Flasher (where dd_flasher.bat/dd_flasher.sh is located);
• Open dd_flasher.bat (or start dd_flasher.sh from a Terminal if you're on Linux) and follow the instructions. After selecting a storage device, dd Flasher will do its work;
• Please note some steps take a while to complete (mainly pushing the system image and flashing it), your device will look like it's dead and won't respond but don't worry, it's normal (on compatible devices the notification LED will pulse in different colors to indicate the the script is running);
• If everything went well, dd Flasher will notify you (and your notification light will be green, if compatible). After that, you'll need to power cycle the device, disconnect the USB cable and pull your battery off (if your battery is non-removable, use the Off/Reset microswitch). Wait some seconds and put your battery back but don't turn your device on yet.
Flashing the remaining with FlashTool: at this stage, your device have the latest firmware from the FTF you used and full root access but still have old versions of kernel, baseband, etc., so, trying to start your device now will probably result in a boot loop or something like that, so, let's finish it:
• Open FlashTool again and flash the FTF you used to extract system.ext4 in flash mode, however, make sure you've excluded SYSTEM, if you forget to do so, everything the tool did will be lost and you'll need to restart from the beginning;
• After flashing ends, disconnect the USB cable and start your phone. The first boot may take several minutes but if everything went well you should be now running the latest firmware, with full root access!
Compatibility
This tool uses an internal database to automatically set up everything needed in the officially supported devices, with at the moment are:
• Xperia E series (C1504, C1505, C1604, C1605)
• Xperia E3 series (D2202, D2203, D2206, D2212, D2243)
• Xperia M series (C1904, C1905, C2004, C2005)
What to do if my device isn't officially supported? dd Flasher also comes with a "default" config which is automatically selected when used in a unknown device. It should work by default in any Xperia (and may even work in devices from other brands), but if dd Flasher still refuses to work, PM me your device model and firmware version, I'll try to support it
FAQ
Soon
Credits
Although I wrote this script from scratch, it uses some pieces of code written originally by @zxz0O0, @[NUT] and @Chainfire, so, credits to them. I would like to thank also everyone who helped directly or indirectly in the conception of the original Nicki Root script, which became what we know today as dd Flasher
Changelog
Soon
Download
All currently released versions available in downloads tab.
XDA:DevDB Information
dd Flasher, Tool/Utility for the OEM Cross Device Development
Contributors
mbc07
Version Information
Status: Beta
Current Beta Version: 2.0
Beta Release Date: 2015-03-19
Created 2015-03-19
Last Updated 2015-03-19

Awesome!
Incredible!
Thanks for sharing this with the community.

Nice
Thanks for everything

Amazing
Thank you so much!

Who try it with android 5.0.2 of z2,z3,z3c,??? And is is full root, isn't it????

nhoc_huhu said:
Who try it with android 5.0.2 of z2,z3,z3c,??? And is is full root, isn't it????
Click to expand...
Click to collapse
Not ready yet =/
The current SuperSU package included in this beta version is unlikely to work in Lollipop -- I was working into that but it didn't made it into this beta. I'll try to get it ready for the stable version...

Error: can't stat '/data/local/tmp/ddFlasher/system/bin/sh':
Hallo,
i tried this on a xperia m (C1905) and get this error:
---------------------------------------------------
Initializing ADB [DONE]
Waiting for device [DONE]
Waiting root access [DONE]
Preparing script [DONE]
Pushing system image [DONE]
Stopping device [DONE]
Mounting system image [DONE]
Installing packages...
- SuperSU v2.46 (SELinux) cp: can't stat '/data/local/tmp/ddFlasher/system/bin/sh': No such file or directory
[DONE]
- Disable RIC (RAM Disk) [DONE]
Saving changes [DONE]
Flashing image [DONE]
System partition updated.
Reboot your phone into flash mode to finish.
NOTE: device won't respond in current state, that's
normal, pull your battery or use Off/Reset switch.
Press any key to exit...
--------------------------------------------
I used C1905_15.4.A.1.9_CE.ftf for the system.sin.
rootchecker says everything is fine but "folderMount", for example, dosnt work, it does a "hard" restart without request.... the screen went black and then reboots.
Before the rooting i also had 15.4.A.1.9 on the phone.
for "prerooting" i used towlroot v3
Could someone please help me with this.
I like to get more space for apps on the xperia m. with something like folderMount or swapinternal 2 external SD and i really tried a lot rooting technics and rootfixer and so on but nothing works.
its really frustrating.
kind regards
Oliver

olliD said:
rootchecker says everything is fine but "folderMount", for example, dosnt work, it does a "hard" restart without request.... the screen went black and then reboots.
Click to expand...
Click to collapse
You have partial root access, that's why the device reboots. I added that in to-do list, should be fixed in the stable release of dd Flasher. Since you have Xperia M, it's much easier and quicker to root it with TowelRoot and then applying the root fixer (there's a tutorial in Xperia M forums). In the meantime, if TowelRoot still fails, you can try again with the old Nicki Root, although old and not supported anymore, they should still work, at least with Xperia M...

What is the difference with the prfcreator tool?.cheers

juanpirulo said:
What is the difference with the prfcreator tool?.cheers
Click to expand...
Click to collapse
PRF Creator generates a flashable ZIP, you'll need a recovery to use it, differing from dd Flasher that archive this through ADB bridge, so, it works even if there's no recovery for your device...

Hi mbc07,
thanks for the reply.
I did this (with TowelRoot and then applying the root fixer (there's a tutorial in Xperia M forums).) several times. I have 2 Versions of the rootfixer on my pc in the moment, tried both but dosent work. I also looked for the tutorial you mentioned, but i didnt find it, sorry.
Could you please link to the tutorial or the correct rootfixer.
I just saw that i dont tell you that i have a locked bootloader, just for info.
kind regards
Oliver

Try this tutorial @olliD...

Got SuperSU v2.46 (SELinux) cp: can't stat '/data/local/tmp/ddFlasher/system/bin/sh': No such file or directory
and some related errors

iovyroot - (temp) root tool

Today I present you
iovyroot - (temp) root tool
based on CVE-2015-1805​
Requirements
USB debugging enabled
Settings => About phone => Click 7 times on Android Build to unlock developer options
adb drivers installed
LP Kernel <= Dec 2015
Components
Binary to get root shell
root/iovyroot
Simple TA Backup / Restore script
The author takes no responsibility
tabackup.bat & tarestore.bat (read second post for restore)
Download v0.4
If you found this tool useful, please consider donating (click here)
Supported models:
Code:
- M5 (all variants) (30.0.A.1.23 & 30.1.A.1.33)
- M5 Dual (all variants) (30.0.B.1.23 & 30.1.B.1.33)
- E5803 (32.0.A.6.200)
- E5823 (32.0.A.6.200)
- E6533 (28.0.A.8.266)
- E6553 (28.0.A.8.266)
- E6603 (32.0.A.6.152)
- E6633 (32.0.A.6.152)
- E6653 (32.0.A.6.152 & 32.0.A.6.200)
- E6683 (32.0.A.6.152)
- E6833 (32.0.A.6.170)
- E6853 (32.0.A.6.170 & 32.0.A.6.200)
- E6883 (32.0.A.6.160 & 32.0.A.6.170 & 32.0.A.6.209)
- SGP771 (28.0.A.8.260)
- SGP712 (28.0.A.8.260)
- LG G Flex 2 (5.1.1 LMY47S)
- Possibly all other devices with LP kernel from Dec 2015 or older
Credits:
- @idler1984 for his poc and great help
- @ninestarkoko and @rimmeda for testing
- @ipromeh for fixing ta scripts
XDA:DevDB Information
iovyroot - (temp) root tool, Tool/Utility for the Sony Xperia Z5 Compact
Contributors
zxz0O0, idler1984
Source Code: https://github.com/dosomder/iovyroot
Version Information
Status: Beta
Created 2016-04-01
Last Updated 2016-04-01

Reserved
Questions
Is it possible to get full root without bootloader unlock?
No, dm-verity prevents write access to system
Can we disable dm-verity?
Temporarily yes, but it will be enabled again at next reboot. Any modification to /system would thus result in a bootloop. dm-verity resides in the kernel which we can't modify on locked bootloader.
Can we restore TA partition after unlocking bootloader?
Yes but this will also relock the bootloader. To keep bootloader unlocked and get DRM features back you can use this: http://forum.xda-developers.com/xperia-z5/development/sony-credentials-restore-unlocking-t3296383
A step by step guide by @koonkii can be found at: http://twigstechtips.blogspot.ch/2016/04/sony-z5-compact-root-without-losing-ta.html
How to restore TA partition?
Method 1:
Flash stock firmware from flashtool (supported by iovyroot) (you are now unrooted)
Use tarestore.bat from iovyroot
Method 2 (fully rooted & unlocked bootloader):
Use BackupTA and option "Convert v4 backup"
Restore backup with BackupTA
Flash stock firmware with flashtool

Couldn't download

nice job! reserved for something else..
Please download the latest version by zxz0O0
E5803 (32.0.A.6.200) Malaysia Firmware (FTF)
Google drive link: https://drive.google.com/file/d/0B_uYldsE-h2sRmNlUjZOQVgwQlU/view?usp=sharing
<-- Outdated fixes for v0.1 -->
Fixes:
This file will fix "TA.img" not found issue (backup script fix)
https://drive.google.com/file/d/0B_uYldsE-h2sb1FKM19HMi02TzQ/view?usp=sharing
This file will fix Z5C E5803 malaysia firmware "device not supported" issue and also included TA fix
https://drive.google.com/file/d/0B_uYldsE-h2sTnQ1cUVGX2xfSTg/view?usp=sharing
Older post:
Edit:
E5803 (32.0.A.6.200) Malaysia Firmware (FTF)
Google drive link: https://drive.google.com/file/d/0B_uYldsE-h2sRmNlUjZOQVgwQlU/view?usp=sharing
Edit 2:
@zxz0O0 , there's something wrong with the binary device verification with the E5803 (32.0.A.6.200) Malaysia Firmware. It says "Error: Device not supported"
This modified binary file will work with this firmware:
https://drive.google.com/file/d/0B_uYldsE-h2sMTZKUi1VcjFjM3c/view?usp=sharing
Edit 3:
The backup TA script is not working, looks like the /dev partition style is different with the previous Z series
here is the dir list of the /dev/block
Code:
[email protected]:/dev/block $ ls
ls
bootdevice
dm-0
loop0
loop1
loop2
loop3
loop4
loop5
loop6
loop7
mmcblk0
mmcblk0p1
mmcblk0p10
mmcblk0p11
mmcblk0p12
mmcblk0p13
mmcblk0p14
mmcblk0p15
mmcblk0p16
mmcblk0p17
mmcblk0p18
mmcblk0p19
mmcblk0p2
mmcblk0p20
mmcblk0p21
mmcblk0p22
mmcblk0p23
mmcblk0p24
mmcblk0p25
mmcblk0p26
mmcblk0p27
mmcblk0p28
mmcblk0p29
mmcblk0p3
mmcblk0p30
mmcblk0p31
mmcblk0p32
mmcblk0p33
mmcblk0p34
mmcblk0p35
mmcblk0p36
mmcblk0p37
mmcblk0p38
mmcblk0p39
mmcblk0p4
mmcblk0p40
mmcblk0p41
mmcblk0p42
mmcblk0p43
mmcblk0p5
mmcblk0p6
mmcblk0p7
mmcblk0p8
mmcblk0p9
mmcblk0rpmb
mmcblk1
mmcblk1p1
platform
ram0
ram1
ram10
ram11
ram12
ram13
ram14
ram15
ram2
ram3
ram4
ram5
ram6
ram7
ram8
ram9
vold
zram0
Code:
[email protected]:/dev/block/platform $ ls
f9824900.sdhci
f98a4900.sdhci
anyway, it's confirmed that i got temp root access with this. Great job!
Edit 4:
Okay guys, confirmed that the TA partition for Z5 Compact is located at /dev/block/platform/f9824900.sdhci/by-name/TA
output of the terminal with fix
Code:
iovyroot by zxz0O0
poc by idler1984
[+] Changing fd limit from 1024 to 4096
[+] Changing process priority to highest
[+] Getting pipes
[+] Allocating memory
[+] Installing JOP
[+] Patching address 0xffffffc00194f630
[+] Start map/unmap thread
[+] Start write thread
[+] Spraying kernel heap
[+] Start read thread
[+] Done
[+] Patching addr_limit
[+] Patching address 0xffffffc05b324008
[+] Start map/unmap thread
[+] Start write thread
[+] Spraying kernel heap
[+] Start read thread
[+] Done
[+] Removing JOP
got root lmao
TA.img copied successfully
Press any key to continue . . .
Have a nice day!

Since this is a temp root, presumably we cannot root then upgrade the firmware (to MM) as root will stop working? Correct?

Couldn't download

Here is a mirror in my Google Drive for people struggling to download: https://drive.google.com/open?id=0B3WEA4Yi_XRaeXV0MzdNOHMySE0

devilmaycry2020 said:
Couldn't download
Click to expand...
Click to collapse
anjelz2012 said:
Couldn't download
Click to expand...
Click to collapse
Refresh and try again
3Shirts said:
Since this is a temp root, presumably we cannot root then upgrade the firmware (to MM) as root will stop working? Correct?
Click to expand...
Click to collapse
The exploit here permits to gain temporary Root Command Shell # and backup/restore TA partition using it.
This has nothing to do with SuperSU: you cannot install it and phone apps cannot gain root access using this package. Installing SuperSU (nowadays) involves /system or /boot partition modification, that are prevented by dm-verity, as stated in the 2nd post.

I see, sorry for the dumb question.
So we back up TA partition with this, then unlock the bootloader and get root that way. This just means we can then restore the device later, thanks to backed up TA?
Presumably you cannot restore the TA partition with the bootloader unlocked? Again, sorry if this seems dumb.

Thanks!
Enviado desde mi E6653 usando Tapatalk 2

ipromeh said:
nice job! reserved for something else..
Edit 3:
The backup TA script is not working, looks like the /dev partition style is different with the previous Z series
here is the dir list of the /dev/block
Code:
[email protected]:/dev/block/platform $ ls
f9824900.sdhci
f98a4900.sdhci
anyway, it's confirmed that i got temp root access with this. Great job!
Edit 4:
Okay guys, confirmed that the TA partition for Z5 Compact is located at /dev/block/platform/f9824900.sdhci/by-name/TA
Have a nice day!
Click to expand...
Click to collapse
I do agree, Z5 compact E5823 here.
TA backup script not working NOW: please wait for an update from Zxz0O0 or if you want to correct the backup script yourself, just run the exploit iovyroot and use the command " ls -l /dev/block/platform "
EDIT: fix in the third post thanks to ipromeh

ninestarkoko said:
I do agree, Z5 compact E5823 here.
TA backup script not working NOW: please wait for an update from Zxz0O0 or if you want to correct the backup script yourself, just run the exploit iovyroot and use the command " ls -l /dev/block/platform "
Click to expand...
Click to collapse
You'll have to modify backup.sh to change the command (as root user)
Anyway, I've uploaded a fix at post #4 in case someone need it. I hope zxz0O0 can update his op too :victory:

@ipromeh So did you get backup image and try to restore it?

ipromeh said:
You'll have to modify backup.sh to change the command (as root user)
Anyway, I've uploaded a fix at post #4 in case someone need it. I hope zxz0O0 can update his op too :victory:
Click to expand...
Click to collapse
Thanks for the fix. I changed the script to use the first folder in "/dev/block/platform". This way there is also compatibility for those with msm_sdcc.1

thank you for the great work...
So,
1) backup TA partition with temp root,
2) unlock the bootloader and root the device permanently
3) then we can use DRM restore to have all that SONY stuff working while having root
So the question is in case of re-locking the bootloader and restoring factory condition...is it how it should work?
flash stock firmware, restore TA partition and then re-locking bootloader

3Shirts said:
I see, sorry for the dumb question.
So we back up TA partition with this, then unlock the bootloader and get root that way. This just means we can then restore the device later, thanks to backed up TA?
Presumably you cannot restore the TA partition with the bootloader unlocked? Again, sorry if this seems dumb.
Click to expand...
Click to collapse
Please, wait for the fix in the first post before unlocking or use the fix from ipromeh in the 4th post.
No problem, that's a good question.
After you successfully backup TA partion, if you want SuperSU and root for apps you must unlock the bootloader.
If you want to restore the TA partition in the future, you must/should flash a stock original .tft firmware because if it is like previous Xperia Z phones, restoring TA backup would RELOCK the bootloader and so custom kernel (needed for root) won't boot and the phone would go in bootloop (because locked bootloader refuses to boot not-SOny-signed kernel).
So, you cannot have permanent root (SuperSU) and TA partition restored at the same time.
If you want DRM key functions and root, you must stay unlocked and use the DRM patch provided by Tobias.waldvogel.
These are my thoughts based on my knoledge and experience taken from previous Xperia Z devices.

ninestarkoko said:
Please, wait for the fix in the first post before unlocking or use the fix from ipromeh in the 4th post.
No problem, that's a good question.
After you successfully backup TA partion, if you want SuperSU and root for apps you must unlock the bootloader.
If you want to restore the TA partition in the future, you must/should flash a stock original .tft firmware because if it is like previous Xperia Z phones, restoring TA backup would RELOCK the bootloader and so custom kernel (needed for root) won't boot and the phone would go in bootloop (because locked bootloader refuses to boot not-SOny-signed kernel).
So, you cannot have permanent root (SuperSU) and TA partition restored at the same time.
If you want DRM key functions and root, you must stay unlocked and use the DRM patch provided by Tobias.waldvogel.
These are my thoughts based on my knoledge and experience taken from previous Xperia Z devices.
Click to expand...
Click to collapse
So we can't restore TA backup while using custom kernel? We must flash stock rom then restore TA, Right?

zxz0O0 said:
Supported models:
Code:
- E5803 (32.0.A.6.200)
- E5823 (32.0.A.6.200)
- E6533 (28.0.A.8.266)
- E6603 (32.0.A.6.152)
- E6633 (32.0.A.6.152)
- E6653 (32.0.A.6.152 & 32.0.A.6.200)
- E6683 (32.0.A.6.152)
- E6833 (32.0.A.6.170)
- E6853 (32.0.A.6.170 & 32.0.A.6.200)
- E6883 (32.0.A.6.160 & 32.0.A.6.170 & 32.0.A.6.209)
- Possibly all other devices with LP kernel from Dec 2015 or older
Click to expand...
Click to collapse
Is it possible to add support for Xperia Tablet Z4? And if so, what can I provide to facilitate it? Thanks in advance.

najoor said:
Is it possible to add support for Xperia Tablet Z4? And if so, what can I provide to facilitate it? Thanks in advance.
Click to expand...
Click to collapse
You can try does it work for your device or not, if it doesn't, then you give kernel.elf from LP firmware to OP.

devilmaycry2020 said:
So we can't restore TA backup while using custom kernel? We must flash stock rom then restore TA, Right?
Click to expand...
Click to collapse
If it's like previous Xperia Z devices, yes, you must restore stock pure original firmware (particularly the kernel) because TA restore would automatically relock the bootloader, thus giving device bootloop. And you cannot have permanent root on pure stock kernel (kernel signed by Sony, i'm not talking about stock-based custom kernels), as stated before, so No permanent root and restored TA partition at the same time.
Though, until someone tests it, we cannot be 100% sure that restoring TA partition relocks the bootloader on Z5 devices like it happens on Xperia Z2, Z3,,..

[Guide] How to restore DRM key from backupTA img!

Hello guys
If you have unlocked bootloader and TA.img backup and want to restore it, This thread is for you​
Storytime ( It's not important, you can jump to instruction)
I search a lot of forums for restoring these bad guys (DRM keys) for our phone, but not of them work!
so after some struggling with them, I figure out that why these methods like this not working!
The problem is that Xperia XA doesn't have "/dev/block/bootdevice/by-name/TA" directory! so ADB gives us "No such file or directory" error (we expect that).
The right directory is "/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/ta"! that's it.
Enough story lets do it.
1. Take a full backup from your data, they will be erased soon. :cyclops:
2. Copy your TA.img to /data/local/tmp/TA.img ( Manually or with ADB)
3. Now reboot into TWRP and be sure that phone is connected to pc ( Please check with "ADB devices" command)
4. Just run this command line : adb shell dd if=/data/local/tmp/TA.img of=/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/ta
The result should look like this:
4096+0 records in
4096+0 records out
2097152 bytes (2.0MB) copied, 0.186238 seconds, 10.7MB/s
5. Turn off the phone (DO NOT REBOOT) and flash a stock ROM.
6. TADA, DRM back, and the bootloader relocked.​
Test on Sony Xperia XA Dual ( F3112 )

thankyou(Y)

stock rom how to flash ?

yek26119 said:
stock rom how to flash ?
Click to expand...
Click to collapse
Use Fashtools to flash FTF ROM, and if you don't have ROM, you can download it from XperiFrim!

where can i find data/local/tmp?

hello how can i get to twrp mode?
adb reboot bootloader?

sid.1375 said:
Hello guys
If you have unlocked bootloader and TA.img backup and want to restore it, This thread is for you​
Storytime ( It's not important, you can jump to instruction)
I search a lot of forums for restoring these bad guys (DRM keys) for our phone, but not of them work!
so after some struggling with them, I figure out that why these methods like this not working!
The problem is that Xperia XA doesn't have "/dev/block/bootdevice/by-name/TA" directory! so ADB gives us "No such file or directory" error (we expect that).
The right directory is "/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/ta"! that's it.
Enough story lets do it.
1. Take a full backup from your data, they will be erased soon. :cyclops:​2. Copy your TA.img to /data/local/tmp/TA.img ( Manually or with ADB)​3. Now reboot into TWRP and be sure that phone is connected to pc ( Please check with "ADB devices" command)​​4. Just run this command line : adb shell dd if=/data/local/tmp/TA.img of=/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/ta​​The result should look like this:​4096+0 records in​ 4096+0 records out​ 2097152 bytes (2.0MB) copied, 0.186238 seconds, 10.7MB/s​​​5. Turn off the phone (DO NOT REBOOT) and flash a stock ROM.​6. TADA, DRM back, and the bootloader relocked.​​
Test on Sony Xperia XA Dual ( F3112 )
Click to expand...
Click to collapse
what is twrp mode and how can i go there with adb?

[XZ1c/XZ1/XZp] temp root exploit via CVE-2019-2215 including magisk setup [Locked BL]

temp root exploit for sony xperia XZ1c/XZ1/XZp with oreo firmware
by j4nn
https://j4nn.github.io/​
Let me present you a temp root exploit for sony xperia XZ1 Compact / XZ1 / XZ Premium phones running android oreo firmware.
The exploit uses CVE-2019-2215, which can get you a temporal root shell very quickly and reliably (it's nearly instant).
SUPPORTED TARGETS
XZ1 Compact
G8441_47.1.A.8.49 (tested myself)
G8441_47.1.A.16.20 (tested myself)
XZ1
G8341_47.1.A.16.20
G8342_47.1.A.16.20
XZ Premium
G8141_47.1.A.16.20
G8142_47.1.A.16.20
with bindershell-v2 following targets added:
Xperia XZ1
G8343_47.1.A.12.150 (Freedom Canada)
G8343_47.1.A.12.205 (Freedom Canada)
SO-01K_47.1.F.1.105 (Docomo Japan)
SOV36_47.1.C.9.106 (AU Japan)
Xperia XZ1 Compact
SO-02K_47.1.F.1.105 (Docomo Japan)
XZ Premium
SO-04J_47.1.F.1.105 (Docomo Japan)
with bindershell-v2x following target added:
Xperia XZ1
701SO_47.1.D.11.32 (Softbank Japan)
This is an alternative method to my renoroot exploit release before, to get a temp root shell for TA (drm keys) backup .
I've also implemented a script to start up magisk from the temp root shell, so this can be used nicely with still locked phones to enable magisk root without unlocking bootloader with the latest oreo fw. You still cannot modify anything in /system or /vendor partitions due to dm-verity, but you could use it for other useful stuff, like iptables based firewall for example.
Listed firmware versions may be found for example here:
https://www.xperiasite.pl/forum/221-firmware/
https://boycracked.com/?s=xperia+xz1
USAGE HOWTO
to get a simple temp root shell
just download bindershell.zip, unzip, 'adb push bindershell /data/local/tmp' and get temp root:
Code:
G8441:/ $ cd /data/local/tmp
G8441:/data/local/tmp $ chmod 755 ./bindershell
G8441:/data/local/tmp $ ./bindershell
bindershell - temp root shell for xperia XZ1c/XZ1/XZp using CVE-2019-2215
https://github.com/j4nn/renoshell/tree/CVE-2019-2215
MAIN: starting exploit for devices with waitqueue at 0x98
PARENT: Reading leaked data
PARENT: leaking successful
MAIN: thread_info should be in stack
MAIN: parsing kernel stack to find thread_info
PARENT: Reading leaked data
PARENT: Reading extra leaked data
PARENT: leaking successful
MAIN: task_struct_ptr = ffffffecc9691b00
MAIN: thread_info_ptr = ffffffecc4c34000
MAIN: Clobbering addr_limit
MAIN: should have stable kernel R/W now
kaslr slide 0x1d35200000
selinux set to permissive
current task credentials patched
got root, start shell...
G8441:/data/local/tmp #
for temp root with magisk setup
do as in previous option and download also the magisk-setup-from-exploit.zip and Magisk-v19.3-Manager-v7.1.2.zip, unzip both and use following commands in addition (skip starting the bindershell in previous section):
Code:
adb install MagiskManager-v7.1.2.apk
adb push Magisk-v19.3 /data/local/tmp
adb shell 'cd /data/local/tmp/Magisk-v19.3 ; chmod 755 * ; /system/bin/sh ./update-binary -x ; ./magiskinit -x magisk magisk'
adb push magisk-setup.sh /data/local/tmp
adb shell chmod 755 /data/local/tmp/magisk-setup.sh
(also present in the included magisk-push.sh script, which you can simply execute in linux or possibly rename to a .bat file and execute it in windows too /not tested though/)
The above would copy the needed stuff to your phone.
Then after each boot you can use following command to startup magisk via the exploit:
Code:
adb shell 'cd /data/local/tmp ; ./bindershell -c ./magisk-setup.sh'
see post#41 for a possibility to start this exploit again after reboot without use of adb, thanks to @Tifs
SOURCES
Source code for the exploit (bindershell) is available here:
https://github.com/j4nn/renoshell/tree/CVE-2019-2215
Magisk startup script is obviously already in source form inside the magisk-setup-from-exploit.zip archive attached.
Magisk binaries packed in the Magisk-v19.3-Manager-v7.1.2.zip are not modified upstream released Magisk-v19.3.zip and MagiskManager-v7.1.2.apk, extracted only needed components and combined into single archive.
It might be possible to use other versions (v19.3+), but that has not been tested and is not supported in any way.
CREDITS
thanks to @arpruss for the su98 exploit variant (where binder_thread wait queue is at 0x98 offset instead of 0xa0, needed completely different approach than the original exploit) - the core of the exploit up to kernel space r/w primitives has been used
DOWNLOAD

Hi @j4nn, it's done for my XZ1 DUAL. Many thanks. But when I unplug the phone from computer, then temp root will be reset, it is normal?
Ps: Do I need to worry/care about dm-verity?

I can permanently uninstall bloatware, install adaway and other applications that need root..
I think it's said. But I need to ask.
Thank you
Sent from my [device_name] using XDA-Developers Legacy app

[email protected] said:
I can permanently uninstall bloatware, install adaway and other applications that need root..
I think it's said. But I need to ask.
Thank you
Click to expand...
Click to collapse
Yes, you can install and use e.g. adaway, AFWall+ etc.
But - as already mentioned in the op - it's not possible to modify /system and /vendor, due to dm-verity, which is still present with a locked bl. Therefore you can't get rid of bloatware, which is placed in /system or /vendor

Actually you can remove bloatware permanently, but without gaining any storage space.
It is possible to do that via oem partition - there you can make modifications, dm-verity does not check oem partition.
It is possible to define which applications would be "removed", then even factory reset would not enable them again.
This way of bloatware removal is quite tricky, as you may need to test factory reset to see if the phone boots or not.
Such debloating can be done via early_config.xml in oem partition - there you can permanently blacklist apps with entries like this:
Code:
<string-array name="config_packagesBlacklist">
<item>com.amazon.mShop.android.shopping</item>
</string-array>
<string-array name="config_packagesFullBlacklist">
<item>com.amazon.mShop.android.shopping</item>
</string-array>

temp root for new targets available with bindershell-v2 - following targets added:
Xperia XZ1
G8343_47.1.A.12.150 (Freedom Canada)
G8343_47.1.A.12.205 (Freedom Canada)
SO-01K_47.1.F.1.105 (Docomo Japan)
SOV36_47.1.C.9.106 (AU Japan)
Xperia XZ1 Compact
SO-02K_47.1.F.1.105 (Docomo Japan)
XZ Premium
SO-04J_47.1.F.1.105 (Docomo Japan)
(offsets extracted from kernels from fully downloaded firmwares)

j4nn said:
temp root exploit for sony xperia XZ1c/XZ1/XZp with oreo firmware
by j4nn
Click to expand...
Click to collapse
Nice work j4nn :good:

@j4nn
Thank you very much for the possibilities you give us due to your great work.
Once TA backup has been carried out, Magisk installed and changes made using root example install adaway, some Magisk module, etc.
These changes are maintained if we update firmware to Pie?
Can we continue using root with Magisk in Pie?
Thanks in advance
Sent from my [device_name] using XDA-Developers Legacy app

@[email protected], it's only a temp root. Once you power off / reboot, it is not rooted anymore, you would need to start the exploit again - just the last command starting magisk. Using magisk modules might work or not, it depends - magisk is used in a way here that it has not been designed in (normally it should be started from kernel's ramdisk before the original init).
You need to unlock and restore ta backup in order to get possibilities like custom kernels or full roms, pie or whatever...
The only permanent customizations may be done in oem partition. You could tune the blacklisted apps there in an oem version from pie firmware to prepare it for pie upgrade and then manually flash the rest of the pie fw skipping oem to keep the modded/debloated seetup in oem while running pie with still locked BL, obviously without root.
Or stick with the exploitable fw version (latest oreo) to be able to startup magisk after each boot, if you cannot unlock your BL.

Klaus N. said:
Yes, you can install and use e.g. adaway, AFWall+ etc.
But - as already mentioned in the op - it's not possible to modify /system and /vendor, due to dm-verity, which is still present with a locked bl. Therefore you can't get rid of bloatware, which is placed in /system or /vendor
Click to expand...
Click to collapse
Hi @j4nn, can we modify /etc or /cache? Of course we cannot with /system /vendor, but I have no idea about another place.

@anaconda875, I believe /etc is a symlink to /system/etc. You could redirect it somewhere else and make changes there. But it would be only temporal, because content of / is coming from kernel's initramfs, that is not possible to modify persistently with just a temp root. You can modify /cache, but I am afraid there is not that interesting stuff to change there.
In my opinion, the most interesting stuff you can modify is the content in /oem, where you can permanently block apps (debloat) or change stuff related to wifi/lte calling.

Many thanks @j4nn

not works sov36 LB .
Solved
Realle work thanks j4nn

@Aviv_Gopax, please do not full quote the very big opening post for no reason at all.
Instead you could provide some details from your test - what fw version do you have and a log from your test.

j4nn said:
@Aviv_Gopax, please do not full quote the very big opening post for no reason at all.
Instead you could provide some details from your test - what fw version do you have and a log from your test.
Click to expand...
Click to collapse
Sorry hehe , Im Using Fw Oreo Build 106

@Aviv_Gopax, I did recheck the SOV36 target offsets and I do not see a reason why it would not work.
Please post the log from the run of ./bindershell as shown in the OP in usage howto section - is not any error there?

downgraded to supported fw (G8342_47.1.A.16.20), and also followed all procedures on both old and new temp root posts, but only showed:
my bad, eventually learned how to backup TA with new method, thank you j4nn!
but I'm gonna unlock and restore some other day.

@j4nn how did you find the offsets? from the stock kernel source code? I'm btw also interested in extracting the keys from the trustzone exploit before upgrading my device

@tombbb, thank you for your donation, really appreciated.

@tb_, cannot get to my PC for some more days to provide the details, but in the case of this cve the most important thing is the offset of the wait queue inside the binder_thread struct - the original poc assumes 0xa0 offset, while for yoshino 0x98 offset is used. That fundamentally changes the core of the exploit. I tried to adapt it similarly for XZ2,there 0xa0 is used,so original poc needs to be adapted. It would never work though, because of hw based mitigation - see my post here:
https://forum.xda-developers.com/showpost.php?p=81689337&postcount=1528