Database Users

Backup EFS

Can someone post how one can backup efs? I did it thru adb on my one. Just want to make sure how to do it on the two. Thank you

From TWRP recovery choosing into backup only EFS

damsolu said:
From TWRP recovery choosing into backup only EFS
Click to expand...
Click to collapse
Thanks, had already done that and the files that it created didnt say modem.bin etc like it did when I backed up one my One a few months ago. Just want to make sure that what twrp created will be all i need to do? Thanks again

i lost my efs with no backup anyhelp?

godzulu said:
Thanks, had already done that and the files that it created didnt say modem.bin etc like it did when I backed up one my One a few months ago. Just want to make sure that what twrp created will be all i need to do? Thanks again
Click to expand...
Click to collapse
The last time I looked, the EFS backup option in TWRP didn't actually backup the two EFS partitions, so don't rely on it.
There's a flashable zip here that will backup your EFS partitions (modemst1 & modemst2). It also includes a Restore_EFS.bat file that can restore your EFS via fastboot.

Spannaa said:
The last time I looked, the EFS backup option in TWRP didn't actually backup the two EFS partitions, so don't rely on it.
There's a flashable zip here that will backup your EFS partitions (modemst1 & modemst1). It also includes a Restore_EFS.bat file that can restore your EFS via fastboot.
Click to expand...
Click to collapse
yeah..i have backup EFS from twrp but only realize that the EFS backup from TWRP is not EFS, now my IMEI2 lost & i dont know how to solve it. really head ache

I've done a complete device backup and could you tell me which files indicate efs has been backed up ? Is it modem.emmc.win or sbl1.emmc.win or some other file ?

akashpopat21 said:
I've done a complete device backup and could you tell me which files indicate efs has been backed up ? Is it modem.emmc.win or sbl1.emmc.win or some other file ?
Click to expand...
Click to collapse
Did you read the last few posts?

there is one more option, you can backup via flashfire

On creating a back up using TWRP it makes a file named "oem_stanvbk.emmc.win".... Maybe it is having two modems.....any idea how to explore this file? @Spannaa

Droidlover123 said:
On creating a back up using TWRP it makes a file named "oem_stanvbk.emmc.win".... Maybe it is having two modems.....any idea how to explore this file? @Spannaa
Click to expand...
Click to collapse
The oem_stanvbk partition contains the modem (static_nvbk.bin) which is included in OOS roms.
Not sure why you'd want to explore it...

I guess they lost the imei2 (h2o/erase modemst) and they are trying to find out, if this twrp backup file contains the imei2.

pryggi said:
I guess they lost the imei2 (h2o/erase modemst) and they are trying to find out, if this twrp backup file contains the imei2.
Click to expand...
Click to collapse
It doesn't, it's just the modem/radio.
AFAIK, the IMEIs are in modemst1 & modemst2 (The two modem firmware data partitions).

Yep, this is my understanding too. On op2 the modem firmware is in
oneplus2:/ # ls -l /dev/block/platform/soc.0/f9824900.sdhci/by-name
..
lrwxrwxrwx 1 root root 20 1970-08-26 21:51 modem -> /dev/block/mmcblk0p1
And the modem settings/imeis are in:
lrwxrwxrwx 1 root root 21 1970-08-26 21:51 modemst1 -> /dev/block/mmcblk0p17
lrwxrwxrwx 1 root root 21 1970-08-26 21:51 modemst2 -> /dev/block/mmcblk0p18
The question is, if it is possible to figure out the format of the data on p17/p18 and edit it by adding the imei2 back.
It doesn't seem to be a file system:
Oneplus2:/ # fdisk -l /dev/block/mmcblk0p17
Disk /dev/block/mmcblk0p17: 1 MB, 1572864 bytes
4 heads, 16 sectors/track, 48 cylinders
Units = cylinders of 64 * 512 = 32768 bytes
Device /dev/block/mmcblk0p17: doesn't contain a valid partition table
file -L /dev/block/mmcblk0p17
/dev/block/mmcblk0p17: block special
and
blkid -o value -s TYPE /dev/block/mmcblk0p17
does not return anything.
And if you open the modemst1/2.bin files it seems to be binary data, which does not make sense even in hex editor.
I wonder if oneplus staff could help the poor souls who have lost the imei2 and disclose this info how to get imei2 back...

[TOOL][BETA][LB][ROOT] Backup TA v9.2 for Windows

status: BETA Version 9.2
thread is taken from here
Backup TA for Sony Xperia​Backup TA is tool created by @DevShaft that can backup and restore the TA partition (DRM Keys) of the device. When you create a backup before unlocking for the first time, then you will be able to restore to full factory state (including a locked bootloader). This means all DRM keys intact, Bravia Engine working in Album and last but not least your warranty when needed
NOTE:
Due to some newer devices can't modify on system partition in cause of verified boot (dm-verity)
it's kernel feature for checking block devices so any modification on system partition will let you in bootloop
--thanks to @zxz0O0 for this tool iovyroot,this tool give us chance to get root shell to backup DRM Keys (A.K.A TA Partition)
this is still in beta state that mean you mainly could get problem while Backup or Restore (this is only for [Testing] Devices)
but it safe to use with compatible devices in previous thread but you could get problem too
=COMPATIBLE DEVICES
=DOWNLOADS
=SOURCE (under MIT license)
GUIDE
1. Download the latest version of Backup TA.
2. Extract the ZIP file to a folder location of your choosing.
3. Navigate to the folder location of Backup TA.
4. Make sure no other script or application which is using ADB is running (Kill ADB from Task Manager).
5. Make sure the device is booted in normal mode (the way you normally use it).
6. Run Backup-TA.bat
7. Read the last paragraph of the license before continuing.
8. Read the information and follow the instructions given by the tool.
FAQ
Q: Is my device supported?
A: Look at the supported devices list. When it is not listed, try to make a backup it will tell you if your device is supported. as well as your device rooted try it or use temp root provided in the tool
Q: Do I need root for this?
A: YES, it's very important to be rooted before backup and restore (for z3+ and later devices use temp root)
Q: Have "Can't Detect root"?
A: your device can't give root access to adb look at your screen and grant it (in SuperSU --> Change ADB Shell to Grant)
for newer devices click (1) for test iovyroot tool
Q: Can I use someone else's backup?
A: Don't ever try to do this , only what you get is bricked device (your TA is unique for your device)
Q: Can I restore my TA while running a ROM with a non-stock kernel?
A: Yes, but it will soft-brick your device and you need Sony PC Companion or Flashtool to fix it by flashing stock firmware. Best is to first return to a complete stock ROM or at least flash a stock kernel (do not confuse with stock based kernel!) before restoring the TA, this prevents the soft-brick.
=you check all FAQ here
please report if [Testing] Devices backup TA successfully, also you can try it on unlocked bootloader to only test so you don't need to restore TA to test this tool just use it but be aware of playing with this Partition
Thanks to
 @DevShaft for give us this tool
 @zxz0O0 for allowing to use his tool binary here

reserved

Universal (Dirtycow-based) TA Backup v2

Dirtycow-based TA Dumper for Sony Xperia Devices. (v2.0)
Author:
Jens Andersen
Xda: rayman
Twitter: https://twitter.com/EnJens
GitHub: EnJens
Source can be found on https://github.com/EnJens/backupTA.
Must be built within AOSP (e.g. checkout to external/backupTA)
Changelog:
More devices supported. The dreaded "Permission denied" should be long gone
Stability improved
TA dump is now verified before pulling
An error message is correctly shown when the process fails.
Requirements:
Phone running a dirtycow capable OS (E.g. recent N builds won't work).
If you have already upgraded, downgrading (temporarily) should be possible.
It should work on all recent xperia phones, but there might be exceptions.
It works on Linux, Windows and Mac (OS X)
Instructions:
Ensure you have adb access (e.g. drivers installed, enabled etc)
Run backupTA.sh (linux) or backupTA.cmd (windows) in the root directory.
TA will be saved as TA-ModelNumber-Serial-Timestamp.img in
the backupTA.sh directory.
On failure, the TA file should be missing, but please check that the file is 2.097.152 bytes
Download:
backupTA.zip
Credits:
rayman
Bumble-Bee (Testing)
Myself5 (Testing and some scripts)
oshmoun (Testing)
Androxyde (Testing)
munjeni (checkta source)
Tested on:
Xperia Z1
Xperia ZL
Xperia Z2
Xperia Z3
Xperia Z5
Xperia Z5 Compact
Xperia E5
Xperia M5
Xperia M4 Aqua
Xperia C5
Xperia X
Xperia XA
Xperia XA Ultra
Xperia X Performance
Xperia X Compact
Xperia XZ
XDA:DevDB Information
Universal (Dirtycow-based) TA Backup, Tool/Utility for the OEM Cross Device Development
Contributors
rayman, rayman
Source Code: https://github.com/EnJens/backupTA
Version Information
Status: Stable
Created 2016-12-07
Last Updated 2020-07-27

FAQ:
Q: Why is the backup different between reboots?
A: There is other data stored in the TA partition than just the TA Units. On some devices, the bootloader bootlog is stored there along with other pieces of data.

How it works
A very quick primer on how backupTA works now the source is out:
Sony's devices are extremely locked down with SELinux, and even getting root (with dirtycow) leaves you with very little access to the system.
Other than true root (which is rather difficult to get, although not impossible), only the Sony TA daemon has access to the partition required. But the TA daemon has no access to write any files anywhere on the device where we can pull them...
The basic approach is:
* Overwrite run-as binary with a custom binary
* When executed it switches to root and sets platform_app permissions, which for some bizarre reason is allowed from run-as explicitly. (See note 1)
* Once it has these privileges, it has access to dirtycow /sbin/tad_static
* It overwrites tad_static with a special daemon that allows reading the entire TA partition over the tad socket already used by the system. (See note 2)
* The run-as replacement reads the TA dump over the tad socket and pipes it to stdout to write to a file. (See note 3)
Note 1:
Dirtycow cannot increase the size of any binaries on the system, so to make things actually work, this solution also overwrites screenrecord binary (which is significantly bigger). run-as then executes this after setting up root and does all the fancy things. On some devices the platform-app context with root does not allow reading or writing files anywhere. To get around this, it reads the replacement tad_static from stdin and writes the dump to stdout. The script that runs run-as handles the piping.
Note 2:
When tad_static is first executes during boot, it's cached by linux. For efficiency reasons and because it's on a read-only filesystem, it's executed from this cache in memory. When dirtycow replaces the binary on /sbin, it actually replaces the running binary's code in memory, forcing it to crash. Init automatically restarts it, but now it's the replaced binary running which allows us to dump what we need.
Note 3:
The tad socket is actually quite limited permission-wise too. Only a limited subset of selinux contexts are allowed to read/write to it and the same goes for users. Luckily, root user with some supplementary groups, and the platform_app selinux context does have access to it, so we abuse that fact to talk to the replaced TA daemon.

Awesome. was waiting for this.thanks

Second!

wow nice find! I'm a bit bumped out I allready unlocked my booloader but this is great news!

Awesome... Congrats!!
XP F8131 output :good:
Code:
Picking 64-bit version
Running on F8131 on 64-bit platform
Pushing files
886 KB/s (9984 bytes in 0.010s)
743 KB/s (6088 bytes in 0.008s)
1072 KB/s (14280 bytes in 0.013s)
901 KB/s (10184 bytes in 0.011s)
122 KB/s (876 bytes in 0.006s)
Running scripts to dump ta to "TAIMG" on device
Overwriting run-as
Attempting to dirtycow
Done dirtycowing
Overwriting secondary payload (screenrecord)
Attempting to dirtycow
dirtycow failed
Attempting to dirtycow
Attempting to dirtycow
Done dirtycowing
Attempting exploit
Attempting to dirtycow
dirtycow failed
Waiting for result....
Bad reply received, failing...
Attempting exploit
Attempting to dirtycow
Attempting to dirtycow
dirtycow failed
Waiting for result....
Got a total of 2097152 bytes
Exploit successful!
Dumped TA as TA_F8131_CB512AD0TJ_06122016-2207.img
Pulling image
735 KB/s (2097152 bytes in 2.784s)
Cleaning up
TA Sucessfully pulled to TA_F8131_CB512AD0TJ_06122016-2207.img
****NOTE: Please verify filesize is 2MB ****
Pressione qualquer tecla para continuar. . .
Just a quick heads up. The first attempt failed because /data/local/tmp was not empty! It has two "flat..." files inside it (Stock fw).
Fix can be to change .sh and .cmd scripts to chmod each pushed file separately (instead of *), or even clear that folder.
Code:
Picking 64-bit version
Running on F8131 on 64-bit platform
Pushing files
180 KB/s (9984 bytes in 0.054s)
742 KB/s (6088 bytes in 0.008s)
1983 KB/s (14280 bytes in 0.007s)
1421 KB/s (10184 bytes in 0.006s)
213 KB/s (876 bytes in 0.004s)
[COLOR="DarkRed"]chmod: chmod '/data/local/tmp/flatland' to 100755: Operation not permitted
chmod: chmod '/data/local/tmp/flatland64' to 100755: Operation not permitted[/COLOR]
Running scripts to dump ta to "TAIMG" on device
...
Anyways... It did work like a charm! Respect!!

rayman said:
Dirtycow-based TA Dumper for Sony Xperia Devices.
Author:
Jens Andersen
Xda: rayman
Twitter: @droidray
GitHub: EnJens
Source will follow later this week.
Requirements:
Phone running a dirtycow capable OS (E.g. recent N builds won't work).
If you have already upgraded, downgrading (temporarily) should be possible.
It should work on all recent xperia phones, but there might be exceptions.
Instructions:
Ensure you have adb access (e.g. drivers installed, enabled etc)
Run backupTA.sh (linux) or backupTA.cmd (windows) in the root directory.
TA will be saved as TA-ModelNumber-Serial-Timestamp.img in
the backupTA.sh directory.
Download (Temporary. Will be moved, so please don't link to it):
https://skumler.net/backupTA.zip
Credits:
rayman
Bumble-Bee
Myself5 (Testing and some scripts)
oshmoun
Tested on:
Xperia Z3
Xperia Z5
Xperia Z5 Compact
Xperia X
Xperia XP
Xperia XC
Xperia XZ
Click to expand...
Click to collapse
So just to confirm, this fully backs up the TA partition including DRM keys on the Xperia XZ. So it's okay for me to now unlock the bootloader and restore everything with this? If so this is just what I've been waiting for!

Just to confirm, after TA (including DRMs) is backed up, I can unlock -> root -> then relock + restoring TA so I can have both root and DRMs working flawlessly? including OTA updates?

I don't think root with locked bootloader is possible. But if you got TA backup you can restore whenever you want and relock bootloader. Maybe important if you want to sell phone or if you need guarantee. @rayman
Will it be possible to create. ftf to flash drm key just like in Z5 line?

Whats the difference?

Difference to what? Your in German "android-hilfe", right?

serajr said:
Awesome... Congrats!!
Just a quick heads up. The first attempt failed because /data/local/tmp was not empty! It has two "flat..." files inside it (Stock fw).
Fix can be to change .sh and .cmd scripts to chmod each pushed file separately (instead of *), or even clear that folder.
Anyways... It did work like a charm! Respect!!
Click to expand...
Click to collapse
Good point. I went lazy-mode and just chmod'ed it all and assumed everything there would be shell-user owned...I guess that doesn't always stand true. I'll fix it up.
Sonic Dash said:
So just to confirm, this fully backs up the TA partition including DRM keys on the Xperia XZ. So it's okay for me to now unlock the bootloader and restore everything with this? If so this is just what I've been waiting for!
Click to expand...
Click to collapse
In theory. I've verified it makes a 100% accurate copy of the TA Partition. I can't realistically guarantee anything else, but yes, it *should* work like that. That's kind of the point.
boydzethuong said:
Just to confirm, after TA (including DRMs) is backed up, I can unlock -> root -> then relock + restoring TA so I can have both root and DRMs working flawlessly? including OTA updates?
Click to expand...
Click to collapse
Probably not... The second you flash back the locked TA, signed boot images will be required again and signed boot images mean dm-verity, meaning verified /system partitions, so it wouldn't boot anymore without 100% stock firmware.
DannyWilde said:
I don't think root with locked bootloader is possible. But if you got TA backup you can restore whenever you want and relock bootloader. Maybe important if you want to sell phone or if you need guarantee. @rayman
Will it be possible to create. ftf to flash drm key just like in Z5 line?
Click to expand...
Click to collapse
I don't see why not, but YMMV. It's certainly possible to extract the DRM key from the backup created by this tool and if Flashtool/bootloader allows flashing the data to a TA unit, it'll be possible.

Aaskereija said:
Whats the difference?
Click to expand...
Click to collapse
Difference to what? As of now, there is no tool to backup the TA on Android Versions above 5.1.1 (last Version where iovyroot worked on), exept this one
rayman said:
Good point. I went lazy-mode and just chmod'ed it all and assumed everything there would be shell-user owned...I guess that doesn't always stand true. I'll fix it up.
Click to expand...
Click to collapse
But shouldn't it just go on? I had the chmod failure during the final tests yesterday too, but I'm pretty sure it was just going on at that time.

How can I restore TA? I Backed up TA.

Heesue said:
How can I restore TA? I Backed up TA.
Click to expand...
Click to collapse
Unlock bootloader, flash TWRP, boot to TWRP, adb shell and use dd command to flash TA image back. Then power off and flash stock system, fotakernel and kernel with flashtool.

thanks great work friend, tested in xperia z5 premium

shoey63 said:
Unlock bootloader, flash TWRP, boot to TWRP, adb shell and use dd command to flash TA image back. Then power off and flash stock system, fotakernel and kernel with flashtool.
Click to expand...
Click to collapse
Thanks a lot!

AWESOME!!!
Very Good Job Guys!
BIG THANKS

Xperia X Compact
Seemed to work on Xperia X Compact:
Running 34.1.A.1.198 firmware
Really nice work
Output
Code:
Running on F5321 on 64-bit platform
Pushing files
[100%] /data/local/tmp/dirtycow
[100%] /data/local/tmp/run-as
[100%] /data/local/tmp/exploitta
[100%] /sdcard/dumpta
[100%] /data/local/tmp/backupTA.sh
Running scripts to dump ta to "TA_F5321_QV705K140B_20161207-1151.img" on device
Overwriting run-as
Attempting to dirtycow
Done dirtycowing
Overwriting secondary payload (screenrecord)
Attempting to dirtycow
dirtycow failed
Attempting to dirtycow
Attempting to dirtycow
Done dirtycowing
Attempting exploit
Attempting to dirtycow
dirtycow failed
Waiting for result....
Bad reply received, failing...
Attempting exploit
Attempting to dirtycow
Attempting to dirtycow
Attempting to dirtycow
Attempting to dirtycow
Done dirtycowing
Waiting for result....
Error connecting to unix socket: No such file or directory
Attempting exploit
Attempting to dirtycow
Attempting to dirtycow
Attempting to dirtycow
Attempting to dirtycow
Done dirtycowing
Waiting for result....
Error connecting to unix socket: No such file or directory
Attempting exploit
Attempting to dirtycow
Attempting to dirtycow
Attempting to dirtycow
Attempting to dirtycow
Done dirtycowing
Waiting for result....
Got a total of 2097152 bytes
Exploit successful!
Dumped TA as TA_F5321_QV705K140B_20161207-1151.img
Pulling image
[100%] /data/local/tmp/TA_F5321_QV705K140B_20161207-1151.img
Cleaning up
TA Sucessfully pulled to TA_F5321_QV705K140B_20161207-1151.img
****NOTE: Please verify filesize is 2MB ****

[PoC][Work in progress] Trim Area Proof Of Concept

Disclaimer:
PoC was made for testing and educational purposes, ME is not responsible for what you do on/with your device using PoC, you must agree that you using PoC on your own risk, I am not responsible if you brick your device, you lost your personal data or anything else!
Hello!
First of all this tool fully replaces DRM fix! So do not use our tool with DRM fix!!! I'm going to explain what is this, how it working. Everybody know what drm fix doing and everybody know whats happening when bootloader is unlocked. Ok. This PoC is designed for unlocked devices and makes things identic to having bootloader never unlocked! Which mean this is for peoples who have backup of the trim area BEFORE unlocking bootloader! This PoC mounts your trim area backup (TA.img) to the kernel loop5 device which makes your trim area like real trim area partition (in our case it mounts your backup TA.img and uses it instead of unlocked trim area partition) so everything after android boot up is like having locked bootloader which mean all drm keys, widevine keys and etc is fully functional! And most better thing, we can use PoC with AOSP, CM or whatever for having trim area fully functional!!!
Do in mind this is for stock roms only! Only nougat and marchmallow by now, some of before marchmalow too.
Supported kernel images:
- SIN (kernel.sin)
- ELF (kernel.elf)
- IMG (boot.img)
So you no need to extract elf from kernel since our tool extract any sony format, sin,img,elf autodetection.
Credits:
- I must give big creadits to @steom since he tested things very deeply on his xperia x compact, he tested things more than 7 days, he tested it very frequently and I must say... big respect to him! Thanks man!
- Also respect to @tobias.waldvogel ! His mkinitfs source code (idea about #perm appended to file names) helped me a lot making our tool for windows. His scripts helped me a lot figuring out all things! Thanks man! Original forum thread for tobias.waldvogel great work -> https://forum.xda-developers.com/xp...oot-automatic-repack-stock-kernel-dm-t3301605
- Uhh sorry, forgot to give credit to @osm0sis for great extended version of the boot image tools https://github.com/osm0sis/mkbootimg
- @serajr mate sorry, forgot your great scripts!
- @the_laser for figuring out that poc is working by directly using TA.img, no need to mount to loop, thanks man!
- @mbc07 for this post https://forum.xda-developers.com/showpost.php?p=73232574&postcount=1547

How to extend our tool:
I have reserved some spaces for everybody who need to extend our tool (tool looks for user script.sh or script.bat), so if tool found user script tool will execute that scipt which mean everybody can make own scipt to extend ramdisk patching mechanism (e.g. to add su... etc). If tool didn't find user script, tool pause so you have enough time to modify everything you need manualy and continue tool by pressing any key on your keyboard. Tool didn't delete output folder so you can use for example something from unmodified boot.img-ramdisk.gz if you need. Also sepolicy binary file have a backup (backupsepolicy) so you can use it too if you need.
How to fix byself denials from dmesg:
This explains how: https://forum.xda-developers.com/showpost.php?p=70955889&postcount=47
And finaly this is a tool: https://forum.xda-developers.com/showpost.php?p=70973513&postcount=120

Everybody and every device is involved! You need at least good knownledge in getting logcat and dmesg if you want to help here! You can suggest, speak whatewer you want in this thread since this thread is for everybody! Need your words about tool and suggestions! Please if you want to post logcat or dmesg please use http://www.pastebin.com for it! If you need tool working for your device please get involved here!

. .

munjeni said:
That mean we can use stock camera blobs finaly with AOSP, CM or whatewer!!!
Click to expand...
Click to collapse
This will change everything regarding (not stock based) custom ROMs... If this is proved to work...
Outstanding job! Even if this post has no logcat/dmesg attached I felt like that I have to say some respectful words! :good:

Bootloop on nougat is solved now! New version is out! Soo close to get it working on nougat

I officially declare that the @munjeni PoC work! also with Nougat!
A new era is begun!

Does it mean, that camera will now work well on Xperias with Nougat AOSP?
Anyway it's big success.

haha was thinking of the same thing some weeks ago
tad_static can be cheated easily but what about suntrold and rmt_storage?
Where are your sources please?

steom said:
I officially declare that the @munjeni PoC work! also with Nougat!
A new era is begun!
Click to expand...
Click to collapse
Bro i want to test on my z5 dual but dont know what should i do it
can you explain clearly?
thanks

having problems
Code:
hash:0x54288A7A calc_hash:0x54288A7A
hash:0x4CBAA939 calc_hash:0x4CBAA939
hash:0x9B8793E3 calc_hash:0x9B8793E3
hash:0x482AF9EB calc_hash:0x482AF9EB
device: F8331
serial number: CB512BEE32
drm key: 0001046B 0010 44 98 8A 61 A3 B2 10 48 02 19 38 59 73 7F 7E 52
Trim area dump is a valid.
Locked bootloader.
Deleting old folder ramdisk if exist...
if exist ramdisk (rd ramdisk /s/q)
returned: 0.
New directory ramdisk created.
Created ouput folder "out"
opening kernelX.sin
unable to open kernelX.sin
Kernel dump tool returned an error!
Mmm.... rename kernel.sin to kerlelX.sin helped

Using EliteKernelV3 (Z3C) did not work with following output:
Code:
------------------------------------------------------------------------
Nougat Trim Area PoC kernel image patcher by Munjeni @ 2017
------------------------------------------------------------------------
hash:0x037C9C1E calc_hash:0x037C9C1E
hash:0x90A0164B calc_hash:0x90A0164B
hash:0x04E5A139 calc_hash:0x04E5A139
device: D5803
serial number: YT911BPNF7
drm key: 0001046B 0010 ED EE 37 63 7B D8 AD 8B 03 C4 8C 1C 2A 3C 61 B0
Trim area dump is a valid.
Locked bootloader.
Deleting old folder ramdisk if exist...
if exist ramdisk (rd ramdisk /s/q)
returned: 0.
New directory ramdisk created.
Created ouput folder "out"
opening boot_Z3c.img
boot_Z3c.img is Android image format.
Dumping to out...
BOARD_KERNEL_CMDLINE androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x3b7 ehci-hcd.park=3 androidboot.bootdevice=msm_sdcc.1 vmalloc=400M dwc3.
maximum_speed=high dwc3_msm.prop_chg_detect=Y androidboot.selinux=permissive
BOARD_KERNEL_BASE 00000000
BOARD_NAME
BOARD_PAGE_SIZE 2048
BOARD_KERNEL_OFFSET 00008000
BOARD_RAMDISK_OFFSET 02000000
BOARD_TAGS_OFFSET 01e00000
BOARD_DT_SIZE 284672
Done.
Gunziping...
setting up infflate...
infflating...
infflate returned: -3
gzpipe: invalid or incomplete deflate data
Error gunziping boot_Z3c.img!
Drücken Sie eine beliebige Taste . . .
I compared the the files in folder "out" with the one of osmosis' Android Image Kitchen:
This is TA Tool: boot.img-ramdisk.gz
And this AIK: boot_Z3c.img-ramdisk.cpio.gz
But both with exact the same file size...
Ramdisk is not decompressed successfully.... Looks for me like an mismatch while decompressing cpio and gunzip.
My thought: Your tool is expecting gzip files - But EliteKernelV3 was compressed first with cpio and then with gzip.
kernel.sin and kernel.elf are working fine!

Is lollipop in progress or?
for z1 that would be great

maksim_kw said:
Mmm.... rename kernel.sin to kerlelX.sin helped
Click to expand...
Click to collapse
Come one! You have to adjust the starting batch file according to your kernel file name

fluffi444 said:
Using EliteKernelV3 (Z3C) did not work with following output:
I compared the the files in folder "out" with the one of osmosis' Android Image Kitchen:
This is TA Tool: boot.img-ramdisk.gz
And this AIK: boot_Z3c.img-ramdisk.cpio.gz
But both with exact the same file size...
Ramdisk is not decompressed successfully.... Looks for me like an mismatch while decompressing cpio and gunzip.
My thought: Your tool is expecting gzip files - But EliteKernelV3 was compressed first with cpio and then with gzip.
kernel.sin and kernel.elf are working fine!
Click to expand...
Click to collapse
It's for stock kernel. EliteKernel has own fix method.

nailyk said:
haha was thinking of the same thing some weeks ago
tad_static can be cheated easily but what about suntrold and rmt_storage?
Where are your sources please?
Click to expand...
Click to collapse
Hi! Till after ta is mounted whole things working like real trim area on locked bootloader! Things which might not work (untested curently) is fota and other things, but I realy not going to mess with it, you guys can make your own scripts for fine tune purpose! Source code as I promised after my ban not going to be public available because my ban.

vato4001 said:
Is lollipop in progress or?
for z1 that would be great
Click to expand...
Click to collapse
I didn't tried, probably it will work or error during compilation.

x_one said:
EliteKernel has own fix method.
Click to expand...
Click to collapse
You know that I know that - But I really prefer this TA solution than DRM fix which I removed from Kernel as soon as I got the manual TA mod working on EliteKernel.
You know that I have an working EliteKernel with TA mount... But it would also be nice to get this tool working for such custom kernel as well.
Anyway - I really appreciate @munjeni 's work. And if the answers is ONLY for stock kernel than it's fine for me as well (the manual way works - as I said)

fluffi444 said:
You know that I know that - But I really prefer this TA solution than DRM fix which I removed from Kernel as soon as I got the manual TA mod working on EliteKernel.
You know that I have an working EliteKernel with TA mount... But it would also be nice to get this tool working for such custom kernel as well.
Anyway - I really appreciate @munjeni 's work. And if the answers is ONLY for stock kernel than it's fine for me as well (the manual way works - as I said)
Click to expand...
Click to collapse
In general it will work on any kernel since I have made some free space for userscripts! It will come later till after poc starts working!

New version is out and finaly it is a first one working for nougat! Only one problem thought is tool have an bug which I need to figure our (you must copy TA.img to the /data/local/tmp) folder to get poc working! I will solve that soon!

[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