Universal (Dirtycow-based) TA Backup v2

Search This thread

rayman

Senior Recognized Developer
May 1, 2008
278
1,397
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:
  1. Ensure you have adb access (e.g. drivers installed, enabled etc)
  2. Run backupTA.sh (linux) or backupTA.cmd (windows) in the root directory.
  3. TA will be saved as TA-ModelNumber-Serial-Timestamp.img in
    the backupTA.sh directory.
  4. On failure, the TA file should be missing, but please check that the file is 2.097.152 bytes

Download:

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
 
Last edited:

rayman

Senior Recognized Developer
May 1, 2008
278
1,397
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.
 
Last edited:

rayman

Senior Recognized Developer
May 1, 2008
278
1,397
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.
 
Last edited:

serajr

Recognized Developer / Recognized Themer
Apr 21, 2011
5,065
18,692
São Paulo - SP
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!!
 
Last edited:

Sonic Dash

Member
Nov 6, 2016
24
4
Manchester
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:
  1. Ensure you have adb access (e.g. drivers installed, enabled etc)
  2. Run backupTA.sh (linux) or backupTA.cmd (windows) in the root directory.
  3. 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):

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

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!
 
  • Like
Reactions: KWOKSFUNG

DannyWilde

Senior Member
Nov 1, 2016
105
15
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?
 

rayman

Senior Recognized Developer
May 1, 2008
278
1,397
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!!

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.

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!
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.

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?
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.

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?
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.
 

Myself5

Recognized Developer
Mar 17, 2011
3,437
9,824
25
myself5.de
Sony Xperia Z3 Compact
Sony Xperia Z3v
Whats the difference?

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 ;)

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.

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.
 

ggow

Recognized Developer
Feb 28, 2014
4,108
10,969
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 ****
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 1
    Also, how im supposed to have unotuched boot/recovery partitions if i have to use twrp to restore TA (thus, "corrupting" recovery?)
    The trick shoey and I used was to clean flash a stock build with the bootloader unlocked and then immediately boot into recovery at which point you dd the original TA.img back that you extracted before unlocking the loader. Behind all this are the loader.sin configs provided with older builds that were excluded later on when Sony discovered the vulnerabilities were able to circumvent the wipe of the original TA. My only thought is try flashing the original Oreo build and look to see if there is a loader.sin + configs included with the build. Essentially the loader is written back into a locked state and without the loader partition and it's configurations you can't. I did it with an XZs like shoey did with an X; the difference with mine was I had to apply the official stock build again after placing the original TA back so that it was detected to rewrite the loader.
  • 188
    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:
    1. Ensure you have adb access (e.g. drivers installed, enabled etc)
    2. Run backupTA.sh (linux) or backupTA.cmd (windows) in the root directory.
    3. TA will be saved as TA-ModelNumber-Serial-Timestamp.img in
      the backupTA.sh directory.
    4. On failure, the TA file should be missing, but please check that the file is 2.097.152 bytes

    Download:

    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
    37
    CONFIRMATION OF TA RESTORE!
    - Ran tool on Xperia X
    - Unlocked bootloader
    - Flashed TWRP
    - Booted to system
    - Got nag about being unsafe due to unlocked bootloader and wanted password. I don't have a pasword?? (nevermind)
    - Booted back to TWRP (Also wants a password due to encrypted data - ignored!)
    - Pushed TAbackup.img (I renamed it) to /data/local/tmp and verified md5sum is same as original backup.
    - Did
    Code:
    adb shell dd if=/data/local/tmp/TAbackup.img of=/dev/block/bootdevice/by-name/TA
    - Rebooted
    - Everything back as it was. Original TA restored and DRM keys all active:victory:

    NOTE/EDIT: Due to dm-verity, you cannot restore TA on a rooted phone (Z3+ onwards). It won't boot up. Boot and system have to be pure untouched stock.
    20
    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.
    16
    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.
    15
    Version 2 Released

    Version 2 is now released.
    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.