Rooting a dual boot tablet with no cwm !! - Android Q&A, Help & Troubleshooting

Hi guys hope someone can help, i found a guide on dual booting my tablet its a linx 7
32 gb win 8.1 , I've spent the past two days reading and flashing having all sorts of problems lol but at least now ive managed to get it into a workable state.
At the minute its only booting android 4.4.4 as i deleted the windows.old folder and will probably have to do a full reinstall.
The problem with rooting android it seems is due to the usb otg part of the tablet and the ported version of the android version comes from the cube i7. The usb debugging is disabled due to the tablet only being designed for usbotg but there seems to be other versions of the android with root available from the manufacturer but due to using google translate and dead links im having no joy.
I found this using translate and google cache
You try to disguise iWork7 to Nexus7
Famous place in Arigasu such Pazudora is is, the domestic application There are many apps that limit such as carrier restrictions and ROOT limit is provided. Do not be able to start these apps from iWork7 it is currently being adjusted.
1. Look at the source
[GitHub]
2. Check item
the following values ​​of the defualt.prop is NG
ro.secure = 0
ro.allow.mock.location = 1
ro.debuggable = 1
persist.sys.usb.config = adb
↓
Replaced iodide
ro.secure = 1
ro.allow.mock.location = 0
ro.debuggable = 0
persist.sys.usb.config = mtp
When the following exists NG (compatible with root switching of SuperSu)
· /system/app/Superuser.apk
· / System / bin / su
· / System / xbin / su
· / Sbin / su
You want to Nexus7 beetle the build.prop
Tablet classic [Nexus Factory Image
· Au of IntelAtom machine [ASUS MemoPad 8]
ro.build.id = KTU84P
# Ro.build.display.id = U67GT_v1.0__20150117
ro.build.display.id = KTU84P
# Ro.build.version.incremental = user.jim.20150117.113528
ro.build.version.incremental = 1227136
ro.build.version.sdk = 19
ro.build.version.codename = REL
ro.build.version.release = 4.4.4
# Ro.build.date = Sat Jan 17 11:37:11 CST 2015
ro.build.date = Fri Jun 13 07:23:23 UTC 2014
# Ro.build.date.utc = 1421465831
ro.build.date.utc = 1402644203
ro.build.type = user
# Ro.build.user = jim
ro.build.user = android-build
# Ro.build.host = build-168
ro.build.host = vpbs2.mtv.corp.google.com
# Ro.build.tags = dev-keys
ro.build.tags = release-keys
# Ro.product.model = U67GT
ro.product.model = Nexus 7
# Ro.product.brand = intel
ro.product.brand = google
# Ro.product.name = CUBE
ro.product.name = razor
# Ro.product.device = U67GT
ro.product.device = flo
# Ro.product.board = baylake
ro.product.board = flo
ro.product.cpu.abi = x86
ro.product.cpu.abi2 = armeabi-v7a
# Ro.product.manufacturer = intel
ro.product.manufacturer = asus
ro.product.locale.language = ja
persist.sys.language = ja
persist.sys.country = JP
ro.product.locale.region = JP
persist.sys.timezone = Asia / Tokyo
ro.wifi.channels =
ro.board.platform = baytrail
# Ro.build.product is obsolete; use ro.product.device
# Ro.build.product = CUBE
ro.build.product = flo
# Do not try to parse ro.build.description or .fingerprint
# Ro.build.description = em_i8270_64-user 4.4.4 KTU84P user.jim.20150117.113528 dev-keys
ro.build.description = razor-user 4.4.4 KTU84P 1227136 release-keys
# Ro.build.fingerprint = intel / em_i8270_64 / em_i8270: 4.4.4 / KTU84P / user.jim.20150117.113528: user / dev-keys
ro.build.fingerprint = google / razor / flo: 4.4.4 / KTU84P / 1227136: user / release-keys
ro.build.characteristics = nosdcard, tablet
*
| 2015-04-28 |
Mobile
*| Comments: 0
*|
Dynamically edit the Defualt.prop on Android
It seems possible to edit the defualt.prop under Android-root environment when you use the setpropex, quite amazing tool ,,,. (On reboot)
----------------------------------------
su -c "setpropex ro.secure 1"
---------------------------------------
(Ro.allow.mock.location = also the same format 1 and ro.debuggable = 1)
*
| 2015-04-28 |
Mobile
*| Comments: 0
*|
iWork7 without deleting the Windows area, to rewrite the image of Android !!
The standard recovery procedures, it is the initialization of the inescapable Windows, but it became a rewritable only favorite area of ​​Android by step on this procedure. (Mr. SpecialThanks dia-sea)
Download the required files
· XDA bootimg_tools_7.8.13.zip [HP] [Download]
As basic knowledge, organize the recovery boot order
1. BIOS -> Lanch EFI Shell file filesystem device
2. Shell.efi (Shellx64.efi can not move because it does not correspond to 64bitEFI)
3. startup.nsh -> efilinux.efi -f droidboot.img
4. installer.cmd
※ seemed to make re-partition is performed when you run the droidboot.img, require modification of droidboot.img.
modification of droidboot.img
Information display
# ./boot_info Droidboot.img
PAGE SIZE: 2048
BASE ADDRESS: 0x80000000
RAMDISK ADDRESS: 0x81000000
CMDLINE: 'loglevel = 0 androidboot.bootmedia = sdcard androidboot.hardware = em_i8270 watchdog.watchdog_thresh = 60 androidboot.spid = xxxx: xxxx: xxxx: xxxx: xxxx: xxxx androidboot.serialno = 01234567890123456789 oops = panic panic = 40 vmalloc = 172M slub_max_order = 2 vga = current i915.modeset = 1 drm.vblankoffdelay = 1 acpi_backlight = vendor g_android.fastboot = 1 droidboot.minbatt = 0 droidboot.use_installer = 1 droidboot.installer_usb = / dev / block / sda1 droidboot.installer_file = installer. cmd '
dismantling of droidboot.img
# Split_boot droidboot.img
Editing of partition table
# Cp /droidboot/ramdisk/system/etc/partition.tbl /droidboot/ramdisk/system/etc/partition.tbl.bk
# Vi /droidboot/ramdisk/system/etc/partition.tbl
We want to only two lines
partition_table = gpt
reload / dev / block / mmcblk0
repack of ramdisk
# .././repack_ramdisk Ramdisk /
Creating droidboot.img
# .././mkbootimg --kernel Droidboot.img-kernel --ramdisk new-ramdisk.cpio.gz --cmdline "loglevel = 0 androidboot.bootmedia = sdcard androidboot.hardware = em_i8270 watchdog.watchdog_thresh = 60 androidboot.spid = xxxx: xxxx: xxxx: xxxx: xxxx: xxxx androidboot.serialno = 01234567890123456789 oops = panic panic = 40 vmalloc = 172M slub_max_order = 2 vga = current i915.modeset = 1 drm.vblankoffdelay = 1 acpi_backlight = vendor g_android.fastboot = 0 droidboot.minbatt = 0 droidboot.use_installer = 1 droidboot.installer_usb = / dev / block / sda1 droidboot.installer_file = installer.cmd "--base 0x80000000 --pagesize 2048 --ramdiskaddr 0x81000000 --output droidboot_not_clear.img
Creating a Boot USB
Prepare a USB memory that was formatted with FAT32, to copy the contents of AnTaku folder of the USB memory to the root.
You have created so far, system_rootja.img the system.img, boot_adbon.img the boot.img, and rename and droidboot_not_clear.img the droidboot.img,, with the same copy of the USB memory to the root.
and it rewrites the partition.tbl the same content as the droidboot.img you just created.
partition_table = gpt
reload / dev / block / mmcblk0
editing of startup.nsh, change to start the droidboot_not_clear.img.
efilinux.efi -f droidboot_not_clear.img
modification of installer.cmd
And comment out the partition fix part
factory, cache, system, config, logs, the data is initialized,
Fixed boot.img, recovery.img, droidboot.img, the writing of system.img appropriate.
Below, mount the / system in rw, boot_adbon.img the adb effectiveness of boot.img
root of, example of Japanese, as system_rootja.img unwanted apps deleted system.img, it has saved to a USB memory.
oem start_partitioning
REM oem partition /installer/partition.tbl
erase: factory
erase: cache
erase: system
erase: config
erase: logs
erase: data
oem stop_partitioning
REM oem wipe ESP
REM flash: ESP # / installer / esp.img
REM flash: boot # / installer / boot.img
flash: boot # / installer / boot_adbon.img
flash: recovery # / installer / recovery.img
flash: fastboot # / installer / droidboot.img
REM flash: system # / installer / system.img
flash: system # / installer / system_rootja.img
continue
Now, without initialization of Android image the Widnows became the all-you-can-****. Hail and Hail.
Incidentally is the recovery manual wrote by making full use of the translation site. [DL]
*
| 2015-04-28 |
Mobile
*| Comments: 0
*|
iWork7 Rooted !! full version!
We were successful in perfect Root acquired in iWork7. Correct the previous steps and re-published as a full version. (Mr. SpecialThanks dia-sea)
1. Download the necessary environment and file
Windows7 and (even 8.1) in a virtual environment we will proceed in the Linux (VMPalyer & Ubuntu14.10).
· Ubuntu14.10 Japanese 64bit [HP] [Download]
· VMWare Player [HP] [Download]
· IWork7 factory image [HP] [Download]
· Ext4_utils_cygwin_fixed [HP] [Download]
· SuperSu 2.46 [HP] [Download]
· Busybox [HP] [Download]
· Sgs2toext4 [HP] [Download] for people who system.ext4.img does not make well. (JAVA)
· USB memory space is available formatted with NTFS of about 8GB
· USB memory space is available formatted with FAT32 of more than 2GB
· USB keyboard, OTGHUB
2. Building a home directory
Once you start the ubuntu, to make a [iwork7] directory to the home directory,
and rename ext4_utils_cygwin_fixed.zip, system.img, copy the busybox, the directory name to unzip the UPDATE-SuperSU-v2.46.zip [updatesu].
After this it will be operation in the linux console.
In order to comfortable operation with the administrative authority, operation and after you to live do not put sudo passwords many times is easy.
$ Sudo $ {SHELL}
[Sudo] password for username:
Or, it will switch to the root user with su.
$ Sudo su -
3. Mount of system.img
System.img of factory image because it is a file that was cut wasteful part (0?) At the simg format, you will need to convert it to the format of the raw image ext4.
It wants to install the zlib1g-dev necessary to ext4_utils of make.
# Apt-get install zlib1g-dev
ext4_utils of thawing
# Unzip ext4_utils_cygwin_fixed.zip
make of ext4_utils
# Cd ext4_utils
# Make
to copy to make to the finished file to iwork7 directory.
The ones where you unzipped the SuperSu to updatesu directory, to just below iwork7 your own build.prop.
Examples of Japanese correspondence build.prop
ro.product.locale.language = ja
ro.product.locale.region = JP
persist.sys.language = ja
persist.sys.country = JP
persist.sys.timezone = Asia / Tokyo
Creating system.ext4.img
# Simg2img system.img system.ext4.img
System.img remove because it is unnecessary at this point
iWorkt-Root02.png
copy of busybox
# Cp busybox-x86_64 sys / xbin / busybox
# Chown root: root sys / xbin / busybox
# Chmod 0755 sys / xbin / busybox
4. Mount of system.img
# Umount msys
# Rm -f system.img
# Rm -rf msys
# Rm -rf sys
# Mkdir msys
# Mkdir sys
# Mount -o loop system.ext4.img msys
# Cp -a msys /. Sys
# Umount msys
5. root setting
Clear root
# Rm -rf sys / bin / .ext
# Rm -rf sys / etc / init.d
# Rm -f sys / bin / su
# Rm -f sys / xbin / su
# Rm -f sys / xbin / daemonsu
# Rm -f sys / bin / .ext / .su
# Rm -f sys / etc / install-recovery.sh
# Rm -f sys / etc / init.d / 99SuperSUDaemon
# Rm -f sys / etc / .installed_su_daemon
# Rm -f sys / app / Superuser.apk
# Rm -f sys / app / Superuser.odex
# Rm -f sys / app / SuperUser.apk
# Rm -f sys / app / SuperUser.odex
# Rm -f sys / app / superuser.apk
# Rm -f sys / app / superuser.odex
# Rm -f sys / app / Supersu.apk
# Rm -f sys / app / Supersu.odex
# Rm -f sys / app / SuperSU.apk
# Rm -f sys / app / SuperSU.odex
# Rm -f sys / app / supersu.apk
# Rm -f sys / app / supersu.odex
root acquisition start
# Mkdir sys / bin / .ext
# Cp updatesu / x86 / su sys / xbin / daemonsu
# Cp updatesu / x86 / su sys / xbin / su
# Cp updatesu / x86 / su sys / bin / .ext / .su
# Cp updatesu / common / Superuser.apk sys / app / Superuser.apk
# Cp updatesu / common / install-recovery.sh sys / etc / install-recovery.sh
# Mkdir sys / etc / init.d /
# Cp updatesu / common / 99SuperSUDaemon sys / etc / init.d / 99SuperSUDaemon
# Echo 1> sys / etc / .installed_su_daemon
# Chown root: root sys / bin / .ext
# Chown root: root sys / bin / .ext / .su
# Chown root: root sys / xbin / su
# Chown root: root sys / xbin / daemonsu
# Chown root: root sys / etc / install-recovery.sh
# Chown root: root sys / etc / init.d / 99SuperSUDaemon
# Chown root: root sys / etc / .installed_su_daemon
# Chown root: root sys / app / Superuser.apk
# Chmod 0777 sys / bin / .ext
# Chmod 06755 sys / bin / .ext / .su
# Chmod 06755 sys / xbin / su
# Chmod 0755 sys / xbin / daemonsu
# Chmod 0755 sys / etc / install-recovery.sh
# Chmod 0755 sys / etc / init.d / 99SuperSUDaemon
# Chmod 0644 sys / etc / .installed_su_daemon
# Chmod 0644 sys / app / Superuser.apk
Unnecessary apps (Chinese market, etc.) Delete
# Rm -f sys / preinstall / 91hiapk_AndroidPhone_1008443.apk
# Rm -f sys / preinstall / AnZhi_KuBiMoFangFuFei_V5.4_20141002.apk
# Rm -f sys / preinstall / BaiduNaviHD_d4033_20140523.apk
# Rm -f sys / preinstall / baidusearch_Android_1_3_0_7_1009249a.apk
# Rm -f sys / preinstall / cn.keyshare.course_ku_bi.apk
# Rm -f sys / preinstall / CUBE_UgameStore_V210_20141128.apk
# Rm -f sys / preinstall / Mediaplayer.apk
# Rm -f sys / preinstall / ninegameclienthd_v2.2.0_android_release.apk
# Rm -f sys / preinstall / Tudou_Android_phone_4.2_yingyue1.apk
# Rm -f sys / preinstall / wandoujia_kubimofang_oem_fa.apk
One line below if unnecessary copy your own bulid.prop may not run
# Cp build.prop sys / build.prop
Root, installation of busybox
# Mv sys / system
# Rm / system / bin / cp
# Rm / system / bin / mv
# / System / xbin / su --install
# / System / xbin / busybox --install -s / system / bin
# Mv / system sys
6. writing of system.img
When you root reduction, to create the following command implantation system.img. (Note the space)
# ./mkuserimg.sh -s Sys system.img ext4 system 896M
Copy the file to Windows, it will overwrite the system.img to where you copied the Android system to a USB memory that was formatted with FAT32.
6. Rooted !!
To complete the installation of the Android system open the BIOS menu from the ESC key to turn on the power. All after the completion of Android has become the Root state.
iWork7-BootBIOS.png
Finally, Do not you forget the installation of Windows.
Windows will cause is initialized in the above procedure.
In the next section we will learn the steps to rewrite only Android, leaving the Windows.
*
| 2015-04-28 |
Mobile
*| Comments: 0
*|
iWork7 adb daemon configuration of (tcp)
It is iWork7 ~ is the first place impossible to connect with adb in USB debugging on, but can be connected by TCP.
If editing the /ramdsik/default.prop I may, but does not use the ramdisk.img, it uses the ramdisk in the boot.img. (Mr. SpecialThanks dia-sea)
1. File downloading
· XDA bootimg_tools_7.8.13.zip [HP] [Download]
2. It will copy the necessary files
Unzip the bootimg_tools_7.8.13.zip, is located in the following
Home directory / iwork7 / bootimg_tools
Copy the boot.img to bootimg_tools.
3. information display of boot.img
# Cd boot
# Boot_info boot.img
PAGE SIZE: 2048
BASE ADDRESS: 0x80000000
RAMDISK ADDRESS: 0x81000000
CMDLINE: 'loglevel = 0 androidboot.bootmedia = sdcard androidboot.hardware = em_i8270 watchdog.watchdog_thresh = 60 androidboot.spid = xxxx: xxxx: xxxx: xxxx: xxxx: xxxx androidboot.serialno = 01234567890123456789 oops = panic panic = 40 vmalloc = 172M slub_max_order = 2 vga = current i915.modeset = 1 drm.vblankoffdelay = 1 acpi_backlight = vendor '
4. dismantling of boot.img
# Split_boot boot.img
5. adb setting
# Cd boot / ramdisk
# Vi default.prop
persist.nomodem_ui = 1
ro.arch = x86
ro.com.google.clientidbase = android-google
ro.secure = 0
ro.adb.secure = 0
ro.allow.mock.location = 1
ro.debuggable = 1
persist.sys.usb.config = adb
Creating 6.boot.img
# Cd boot
# .././repack_ramdisk Ramdisk /
# .././mkbootimg --kernel Boot.img-kernel --ramdisk new-ramdisk.cpio.gz --cmdline "loglevel = 0 androidboot.bootmedia = sdcard androidboot.hardware = em_i8270 watchdog.watchdog_thresh = 60 androidboot.spid = xxxx: xxxx: xxxx: xxxx: xxxx: xxxx androidboot.serialno = 01234567890123456789 oops = panic panic = 40 vmalloc = 172M slub_max_order = 2 vga = current i915.modeset = 1 drm.vblankoffdelay = 1 acpi_backlight = vendor "--base 0x80000000 --pagesize 2048 --ramdiskaddr 0x81000000 --output boot.img
# Mv boot.img ../.
iwork7 to the connected with tcp / ip after adb Enable
on the command prompt of windows
# Adb connect "iwork7 of ip address"
# Adb shell
# Su - (Since root permission prompt SuperSU exits click allowed on the tablet!)
# Ps
# Root @ U67GT: / # ps
*
| 2015-04-28 |
Mobile
*| Comments: 0
And im not sure if this helps or not.
Am i able to add root to the rom myself ?
Just to add the usb-debugging is not enabled from the way the rom is designed, when you click the build/ model number to enable it then dev options it only offers the option to revoke the rights .

Bump!
Anyone? is there a way to add superuser to the system.img by decompiling / recompling?

crickyo said:
Bump!
Anyone? is there a way to add superuser to the system.img by decompiling / recompling?
Click to expand...
Click to collapse
Check these:
http://forum.xda-developers.com/showthread.php?t=2294909
http://forum.xda-developers.com/showthread.php?t=2665283

sdeepb said:
Check these:
http://forum.xda-developers.com/showthread.php?t=2294909
http://forum.xda-developers.com/showthread.php?t=2665283
Click to expand...
Click to collapse
Hi thanks for the reply i tried those the other night , but from what i remember it was asking for ext 4 and the files i have are system.img, I read through that thread and i think it said to try open the .img in the second program when i tried this it hung and crashed.
Is it really as simple as unpacking it and repacking it?
Im a long time android tinkerer but never knew what ive been doing just following guides

crickyo said:
Hi thanks for the reply i tried those the other night , but from what i remember it was asking for ext 4 and the files i have are system.img, I read through that thread and i think it said to try open the .img in the second program when i tried this it hung and crashed.
Is it really as simple as unpacking it and repacking it?
Im a long time android tinkerer but never knew what ive been doing just following guides
Click to expand...
Click to collapse
Sorry I don't have experience with this, asking in the thread would be your best bet

Hi , I managed to find a link on a chinese site to a modified system.img the two programs dont work and the thread says as much.
Mods can close this thread if they want.

OK guys if you are still after root I can help I have a linx 7 with the dual boot I used some files I found around the internet also my android partition is 8g instead of 4g it works like a charm if you guys still want I can upload and post a link

[email protected] said:
OK guys if you are still after root I can help I have a linx 7 with the dual boot I used some files I found around the internet also my android partition is 8g instead of 4g it works like a charm if you guys still want I can upload and post a link
Click to expand...
Click to collapse
can you post tutorial or links? is there chance to root device without touching windows partition?

marcindh said:
can you post tutorial or links? is there chance to root device without touching windows partition?
Click to expand...
Click to collapse
http://linxtablet.co.uk/viewtopic.php?f=4&t=2096
Unfortunately it does wipe your windows installation and you will be flashing the bios with a Chinese dual boot but it does 100% work

[email protected] thank you for very fast reply I have dualboot but android is not rooted (tutorial from reddit). Android from your link is already rooted?

marcindh said:
[email protected] thank you for very fast reply I have dualboot but android is not rooted (tutorial from reddit). Android from your link is already rooted?
Click to expand...
Click to collapse
No i don't think it is but if you download supersu.zip file search it on xda and download it to your memory card in your tablet then turn your tablet off.... holding the volume down button in while turning on and keeping the volume down pressed it will boot to a screen where you can select recovery and install from .zip in recovery when installed reboot all done ...:good:

[email protected] said:
No i don't think it is but if you download supersu.zip file search it on xda and download it to your memory card in your tablet then turn your tablet off.... holding the volume down button in while turning on and keeping the volume down pressed it will boot to a screen where you can select recovery and install from .zip in recovery when installed reboot all done ...:good:
Click to expand...
Click to collapse
I almost forgot my copy of the dual boot has a different recovery so you might have to reinstall

Related

[Q] Has anybody know how to root GT-I9001

Hi,
Is there some way to root I9001 now or I have to wait.
Firmware I9001XXKE8
Android 2.3.3
Kernel 2.6.35.7
I tried several methods (Superoneclick 1.7, 1.9.1, Gingerbreak 1.2) available for I9000 but nothing positive.
If someone can guide me in this process will be very appreciated.
Go here for step by step instructions: http://androidhogger.com/how-to-root-samsung-galaxy-s2-heres-the-tutorial.html.
Hi,
It is guide for I9100 but I have I9001 it is completely different hardware, so I doubt that the same guide can be applied to I9001.
Any news on rooting? Have you sucseeded?
No, still waiting, but it starts to sell to mass in Russia so soon will get news.
Since yesterday the new 2.3.4 firmware is out:
http://netload.in/datei5X4ZyAkNkO/I9001XXKP4_v2.3.4.rar.htm
(edit: maybe its not 2.3.4 ... samfirmware write 2.3.3)
... but we wait still for the root...
SPOOKY
afaik 2.3.x cannot be rooted. only 2.2.x
sweetnsour said:
afaik 2.3.x cannot be rooted. only 2.2.x
Click to expand...
Click to collapse
Say what? Ofcourse 2.3.x can be rooted. We just have to get more attention to the 9001 so that the rom builders actively start devving this device.
Any one knows how to root this device?
Sent from my GT-I9001 using XDA Premium App
I'm looking for a solution as well, please don't make me use Touchwiz..
Have tried to look into ways to root this phone. It looks like it'll need to be root in similar way to i9100. So guess will need to wait for dev to come up with a special kernel for rooting.
İ hope they they ll come up with new karnel as soon.as possible
Sent from my GT-I9001 using Tapatalk
sweetnsour said:
afaik 2.3.x cannot be rooted. only 2.2.x
Click to expand...
Click to collapse
Here http://forum.xda-developers.com/archive/index.php/t-1136781.html is afaik 2.3.3 rotted. I think there is a posibility to root I9001.
I hope so ....! Did u try this method?
Sent from my GT-I9001 using Tapatalk
westcrip said:
I hope so ....! Did u try this method?
Sent from my GT-I9001 using Tapatalk
Click to expand...
Click to collapse
Nope but I will try in this weekend. I found how to restore phone when you brick it (if something happen) , and it's not so hard. That's why I will use different method to root it. I just wonder if one of brick is avilable or more. I only know how to unbrick by this method http://www.youtube.com/watch?v=2qB4RNoXTd8 . Its very simple just install software downoladed from http://www.samfirmware.com/WEBPROTECT-i9001.htm our software is in the middle I9001XXKF8 ##. Odin as well recognize my phone.
I have managed it to root the i9001. So far it is very complicated, and the detailed guide as well as the analysis of SMD archives is only in German available:
http://www.android-hilfe.de/samsung...g-galaxy-s-plus-i9001-rooten.html#post1911955
As always: You are responsible for your Phone! If someone bricks his device using this guide, I am not responsible for that! Bad Luck, I have warned you! Its a dangerous job! You really shouldn't do it.
In short:
- extract the PDA SMD File
- mount system.ext4
- copy su binary and Superuser.apk into the mounted image
- adjust the file permissions (especially the suid bit for su)
- umount system.ext4
- repack the PDA SMD.
I have created two Linux bash scripts for extracting and packing SMD Archives. Warning: I'm not very experienced in bash scripting. If someone is here who is capable of making a nice script of it, feel free! The scripts are working, that's all so far. They won't win a price in a beauty contest.
First the extract.sh:
Code:
#!/bin/bash
base=0
length=1
while (( length > 0 ))
do
# calculate Length
let "skip = base + 18"
length=`hexdump -e '"%d"' -s ${skip} -n 2 ${1}`
let "length = length * 65536"
let "skip = base + 16"
length2=`hexdump -e '"%d"' -s ${skip} -n 2 ${1}`
let "length += length2"
let "length = length / 512" # Number of 512-Byte blocks
# calculate offset
let "skip = base + 22"
offset=`hexdump -e '"%d"' -s ${skip} -n 2 ${1}`
let "offset = offset * 65536"
let "skip = base + 20"
offset2=`hexdump -e '"%d"' -s ${skip} -n 2 ${1}`
let "offset += offset2"
let "offset = offset / 512" # Number of 512-Byte blocks
# save header in case of first loop
if (( base == 0 ))
then
dd if=${1} bs=512 of=header count=${offset}
fi
# extract filename
let "skip = base + 32"
filename=`dd if=${1} skip=${skip} count=16 bs=1 2>/dev/null`
# and finally: extract image
if (( length > 0 ))
then
echo "Length: ${length}"
echo "Offset: ${offset}"
echo "Filename: ${filename}"
dd if=${1} bs=512 of=${filename} skip=${offset} count=${length} 2>/dev/null
fi
# next header
let "base += 64"
done
Syntax: ./extract.sh Archive.smd
The script will extract the archive and create a lot of local files (system.ext, boot.img and so on). Well, the content of the Archive obviously.
Root the system.ext4:
I have used the newest su and Superuser.apk from here (3.0-beta4 at the moment. Newer ones should be ok):
http://goo-inside.me/superuser
The steps for rooting a system.ext4:
Code:
mkdir system
sudo mount -o loop system.ext4 system
sudo cp su system/xbin/
sudo chown 0.0 system/xbin/su
sudo chmod 4755 system/xbin/su
sudo cp Superuser.apk system/app/
sudo chown 0.0 system/app/Superuser.apk
sudo chmod 644 system/app/Superuser.apk
sudo umount system
And the pack.sh. Note: The pack.sh so far expects an existing "header" file created from an extract action and all files to be added into the archive. The resulting archive will have the same contents, as the starting archive (of course with a modified system.ext4). MD5 Checksums in the archive are calculated automatically.
Code:
#!/bin/bash
base=16
length=0
filename=dummy
# save the beginning
dd if=header of=newheader bs=1 count=16 2>/dev/null
# First create the MD5 checksums of all included (and maybe modified) files and generate the new header
while [ ! -z "${filename}" ]
do
# Length, offset, etc. is unchanged, just copy it.
let "skip = base"
dd if=header of=newheadertmp bs=1 skip=${skip} count=32 2>/dev/null
cat newheadertmp >> newheader
rm newheadertmp
# extract filename
let "skip = base + 16"
filename=`dd if=header skip=${skip} count=16 bs=1 2>/dev/null`
if [ ! -z "${filename}" ]
then
echo "creating MD5Sum of: ${filename}"
checksum=`md5sum ${filename} | tr '[a-z]' '[A-Z]'`
echo -n ${checksum:0:32} >> newheader
fi
# next header
let "base += 64"
done
# save the rest of the old header.
filesize=$(stat -c%s header)
let "base -= 32"
let "size = filesize - base"
dd if=header of=newheadertmp bs=1 skip=${base} count=${size} 2>/dev/null
cat newheadertmp >> newheader
rm newheadertmp
# the new header is the first content of the new archive.
cat newheader > ${1}
# now add all files to the archive.
filename=dummy
base=16
while [ ! -z "${filename}" ]
do
# extract filename
let "skip = base + 16"
filename=`dd if=header skip=${skip} count=16 bs=1 2>/dev/null`
if [ ! -z "${filename}" ]
then
echo "Adding: ${filename}"
cat ${filename} >> ${1}
fi
# next header
let "base += 64"
done
rm newheader
Syntax: ./pack.sh Archive.smd
Flash the resulting .smd files using Odin Multi Downloader an be happy about a rooted SGS Plus.
Note: The procedure has been tested with European KF6 and KP4 firmware. the scripts are capable of extracting and packing other SMD Archives as well, like Modem or CSC SMDs. But you don't need it for rooting (but maybe for debranding or customizing ROMs).
I'm thinking about an simpler root method like a modified kernel with a "magic" initramfs (like CF Root is working). This would make rooting of course much easier. But I have to investigate a lot of things handling boot.imgs.
Nice one RiverSource! Let's hope this is the start of more to come (ie. easier root, custom roms..).
Hello,
ok, next step for rooting the SGS Plus: The FMROOT (hehe). FMROOT is the original untouched Samsung Kernel with a modified init.rc. The init.rc calls a script which places the su binary and the Superuser.apk into the /system partition.
As always: You are responsible for your Phone! If someone bricks his device using this guide, I am not responsible for that! Bad Luck, I have warned you! Its a dangerous job! You really shouldn't do it.
Howto:
Download the appropriate file for your firmware.
Extract it
There should be 2 Files: AriesVE.ops and FMROOT_?????.smd
Use Odin Multi Downloader
Put "AriesVE.ops" in OPS
Put "FMROOT_?????.smd" in PDA
Flash. Wait 5 Seconds. Phone reboots. Phone is rooted. Normally without loosing data or settings.
Please ask here, if your Firmware is not available. It should be possible to create an appropriate FMROOT Kernel.
Credits:
astuermer for pointing me to the correct su and Superuser binaries.
Chainfire here from XDA Developers. My script is based on the CF-Root
Paul from Madaco. I had a closer look into his "superboot".
Lots and Lots of Custom ROM Developers for i9000 and i9100. I have learned a lot about Android Images on Samsung phones from them.
For the developers: the FMBOOT Script called by init.rc:
Code:
mount -o rw,remount -t ext4 /dev/block/mmcblk0p15 /system
rm /system/xbin/su
rm /system/bin/su
mkdir /system/xbin
cat /fmboot/su > /system/xbin/su
chmod 4755 /system/xbin/su
cat /fmboot/Superuser.apk > /system/app/Superuser.apk
mount -o ro,remount -t ext4 /dev/block/mmcblk0p15 /system
And the calling code inside the init.rc:
Code:
start fmboot
class_start default
## Daemon processes to be run by init.
##
service fmboot /system/bin/sh /fmboot/fmboot.sh
user root
group root
oneshot
If someone is interested, I can post a howto on modifying boot.imgs for SGS Plus. Don't hesitate to ask. BTW, i have also coded a script which is capable of generating SMD archives with any content (not based on a previous SMD archive). I can also post it, if someone is interested.
I think, I will optimize the script in the future. Checking if the phone is already rooted and skip the thing for example. Or adding busybox. Are there any additional ideas?
Thank you very [email protected]@@@ Come on!
THX, THX,..
It works, rooted..!!

[Q] How to root Fujitsu Arrows X F-10D? I cannot understand the guide

Hello, I am wondering deciding whether or not I will buy the Fujitsu Arrows X, and it depends on whether I can have root on the phone or not.
I read on the internet that Goroh_Kun got root on the phone, but I am not experienced at rooting phones and ADB, so I cannot understand the source code and binary posted online, nor can I understand a guide of how he got root.
All I could tell was that root was gained for the phone through a vulnerability in "aeswipe" aka the fingerprint scanning thing. However, I cannot follow along with the steps, because I cannot understand it.
I don't know how to use the source code or binary for anything.
Will someone read the pages and summarize the steps for rooting the phone so I can understand it?
I cannot post URLs, so please reply if you need the URLs.
Sarcasticphoenix
Bump
Bumped post, need a reply.
!!!!!!!!!! Caution rooting can be risk your devices. !!!!!!!!!!!
!!!!!!!!!! CAUTION ROOTING CAN BE RISK YOUR DEVICES. !!!!!!!!!!!
YOU MUST HAVE TO KNOW WHAT YOU DO. BEFORE YOU MAKE A THING.
obtain root privileges on the f-10d
Things Require
1. Root Kit
2. ADB Driver For F-10D
3. PC With android SDK
4. Little Knowledge with linux command line
Things to do
Right click on folded you save extract of root kit. that you download
(1) On command prompt put command "adb restore f-10d_2.ab" without "…"
Press OK certification will appear on the screen
(2) You must verify that
(3) after restore is finished. Put command
> adb shell
$ cd / data / data / com.android.settings / a /
$ ls -l-d
drwxrwxrwx system system a
⇒ a directory that exists and is world readable, writable to
$ ls -l
⇒ up to file00 ~ file99 directory exists
(4) Once removed file00 ~ file99
> adb shell
$ cd /data/data/com.android.settings/
$ rm -r a
(Please go but out ※ error)
(5) Make /data permissions to 777. Input command.
$ while:; do ln -s /data a/file99; done
On your screen should infinite run.While doing this, open new command line. Don't closed running windows.
Now input command in new windows
>adb restore f-10d_2.ab
Confirm on your f-10d to complete the restore
After you have finished, exit the old infinite running windows
(6) Check the permissions on the /data
> adb shell
$ ls -l-d /data
drwxrwxrwx system system data
(7) Execute the following command
> adb push mkdevsh /data/local.org/tmp/mkdevsh
> adb shell chmod 777 /data/local.org/tmp/mkdevsh
(8) On or Off Wifi, and then execute
> echo /data/local.org/tmp/mkdevsh>/sys/kernel/uevent_helper
> adb shell
$ ls -l /dev/sh
-rwsr-sr-x root root 151964 2012-08-06 19:34 sh
$ /Dev/sh
# ************ Tempolary insecure root shell ************
(9) Copy lsm_disabler.ko and f10dunlock to /data/local
>adb push f10dunlock /sdcard
>adb push lsm_disabler.ko /sdcard
>dab shell
# dd if=/mnt/sdcard/f10dunlock of=/data/local/f10dunlock
# dd if=/mnt/sdcard/lsm_disabler.ko of=/data/local/lsm_disabler.ko
(10) release LSM lock
********* "x" and "y" is option for f10dunlock
For x=0 if you're on F-10D Build number V16R45C
x=1 if you're ISW13D Device
x=2 if you're on F-10D Build number V18R46F
IF you can't insert module lsm_disabler.ko after execute f10dunlock "x" you can add option "y" at last one example f10dunlock 0 2 or f10dunlock 0 1 and then try to insert module lsm_disabler.ko **********
# cd /data/local
# chmod 777 f10dunlock
# chown root.root / data/local/f10dunlock
# /data/local/f10dunlock x y
/data/local/f10dunlock
fdaes = -1
open aeswipe error, so try to disable LSM without recovery g_lptsAuthContext
fdaes2 = 3
use new F-10D address
# /data/local/f10dunlock 2
/data/local/f10dunlock 2
fdaes = -1
open aeswipe error, so try to disable LSM without recovery g_lptsAuthContext
fdaes2 = 3
# ./f10dunlock
./f10dunlock
fdaes = -1
open aeswipe error, so try to disable LSM without recovery g_lptsAuthContext
fdaes2 = 3
# lsmod
# mount-o rw, remount / system
mount-o rw, remount / system
# cd /system
cd /system
# chmod 777 / system
chmod 777 / system
# mkdir test
mkdir test
# ls-al
(11) Set su busybox
# sync; sync; sync
sync; sync; sync
# dd if=/mnt/sdcard/su of=/system/bin/su
dd if=/mnt/sdcard/su of=/system/bin/su
743 +1 records in
743 +1 records out
380532 bytes transferred in 0.079 secs (4816860 bytes / sec)
# chown root.shell /system/bin/su
chown root.shell /system/bin/su
# chmod 06755 /system/bin/su
chmod 06755 /system/bin/su
# sync; sync; sync
sync; sync; sync
# dd if=/mnt/sdcard/su of=/system/xbin/su
dd if=/mnt/sdcard/su of=/system/xbin/su
743 +1 records in
743 +1 records out
380532 bytes transferred in 0.034 secs (11192117 bytes / sec)
# chown root.shell /system/xbin/su
chown root.shell /system/xbin/su
# chmod 06755 /system/xbin/su
chmod 06755 /system/xbin/su
# sync; sync; sync
sync; sync; sync
# dd if = /data/local.org/tmp/busybox of=/system/xbin/busybox
dd if=/data/local.org/tmp/busybox of=/system/xbin/busybox
2099 +1 records in
2099 +1 records out
1075144 bytes transferred in 0.085 secs (12648752 bytes / sec)
# chown root.shell /system/xbin/busybox
chown root.shell /system/xbin/busybox
# chmod 04755 /system/xbin/busybox
chmod 04755 /system/xbin/busybox
# ls-al
ls-al
drwxr-xr-x root root 2012-09-01 03:31 app
drwxrwxrwx root shell 2012-09-01 23:59 bin
-rw-r - r - root root 4093 2012-09-01 03:31 build.prop
drwxr-xr-x root shell 2012-09-02 01:05 xbin
# cd /system/xbin
cd /system/xbin
# ls -al
ls -al
-rwxr-xr-x root shell 10028 2012-07-07 21:17 agent
-rwsr-xr-x root shell 1075144 2012-09-02 01:05 busybox
-rwxr-xr-x root shell 9780 2012-07-07 21:17 dbus-monitor
-rwxr-xr-x root shell 5708 2012-07-07 21:17 sdptest
-rwsr-sr-x root shell 380532 2012-09-02 01:03 su
#
(12) Set up SuperUser
Install from the market SuperSU etc..
k you must have permission to launch the app root, root authorization confirmation screen will appear if
Remark form me(yes, me not goroh_kun) : if you reboot your device. It's has re-lock /system. Even you have root access you can't remount /system to r/o until you re-execute f10dunlock. So you should think and plan by carefully that you want to move SuperSU.apk form /data/app to/system/app for more safer factory reset in future or not.
Thank you for the dear goroh_kun.
Ugh...what a convoluted process... I'm really on the edge about doing this.
I also heard that this causes the fingerprint reader to stop working. Can anyone confirm this? I use the fingerprint reader a lot so I'd hate to lose that functionality.
Hi,
thanks for the explanation.
But I am stuck at some point:
A. step (8) says on or off WiFi - what does this mean?
B. next, cannot output from mkdevsh to /sys/kernel/udev_helper: permission denied
mkdevsh cannot be executed, says error "syntax error: '^A' unexpected and /bin/sh is not available
C. lsm_disabler.ko is not supplied in ZIP file
Can you please help?`
Thanks
tuxsurfer said:
Hi,
thanks for the explanation.
But I am stuck at some point:
A. step (8) says on or off WiFi - what does this mean?
B. next, cannot output from mkdevsh to /sys/kernel/udev_helper: permission denied
mkdevsh cannot be executed, says error "syntax error: '^A' unexpected and /bin/sh is not available
C. lsm_disabler.ko is not supplied in ZIP file
Can you please help?`
Thanks
Click to expand...
Click to collapse
You manage to get this working? Just wondering as I have an F-10D on the way. I know you can disable a decent bit of bloatware with the ICS disable feature, but I want to disable all of the bloat, if possible.
Anyway, the process does seem simple enough, but the things pointed out above will keep me hesitant on this matter. Does "on or off WiFi", mean turn on and then off?
Thanks
tuxsurfer said:
Hi,
thanks for the explanation.
But I am stuck at some point:
A. step (8) says on or off WiFi - what does this mean?
Ohhhh, Excuse me right thing is " ON and then OFF WIFI" this the hole on android from Sony Ericsson X10
B. next, cannot output from mkdevsh to /sys/kernel/udev_helper: permission denied
mkdevsh cannot be executed, says error "syntax error: '^A' unexpected and /bin/sh is not available
Make sure "echo /data/local.org/tmp/mkdevsh > /sys/kernel/uevent_helper" without quote " " and this can operate after WIFI Hole step
C. lsm_disabler.ko is not supplied in ZIP file
for lsm_disabler.ko not required for the new method just unlocked
Can you please help?`
Thanks
Click to expand...
Click to collapse
I'm So Busy,Sorry for late answer.
tum.osx said:
!!!!!!!!!! CAUTION ROOTING CAN BE RISK YOUR DEVICES. !!!!!!!!!!!
YOU MUST HAVE TO KNOW WHAT YOU DO. BEFORE YOU MAKE A THING.
obtain root privileges on the f-10d
Things Require
1. Root Kit
2. ADB Driver For F-10D
3. PC With android SDK
4. Little Knowledge with linux command line
Things to do
Right click on folded you save extract of root kit. that you download
(1) On command prompt put command "adb restore f-10d_2.ab" without "…"
Press OK certification will appear on the screen
(2) You must verify that
(3) after restore is finished. Put command
> adb shell
$ cd / data / data / com.android.settings / a /
$ ls -l-d
drwxrwxrwx system system a
⇒ a directory that exists and is world readable, writable to
$ ls -l
⇒ up to file00 ~ file99 directory exists
(4) Once removed file00 ~ file99
> adb shell
$ cd /data/data/com.android.settings/
$ rm -r a
(Please go but out ※ error)
(5) Make /data permissions to 777. Input command.
$ while:; do ln -s /data a/file99; done
On your screen should infinite run.While doing this, open new command line. Don't closed running windows.
Now input command in new windows
>adb restore f-10d_2.ab
Confirm on your f-10d to complete the restore
After you have finished, exit the old infinite running windows
(6) Check the permissions on the /data
> adb shell
$ ls -l-d /data
drwxrwxrwx system system data
(7) Execute the following command
> adb push mkdevsh /data/local.org/tmp/mkdevsh
> adb shell chmod 777 /data/local.org/tmp/mkdevsh
(8) On or Off Wifi, and then execute
> echo /data/local.org/tmp/mkdevsh>/sys/kernel/uevent_helper
> adb shell
$ ls -l /dev/sh
-rwsr-sr-x root root 151964 2012-08-06 19:34 sh
$ /Dev/sh
# ************ Tempolary insecure root shell ************
(9) Copy lsm_disabler.ko and f10dunlock to /data/local
>adb push f10dunlock /sdcard
>adb push lsm_disabler.ko /sdcard
>dab shell
# dd if=/mnt/sdcard/f10dunlock of=/data/local/f10dunlock
# dd if=/mnt/sdcard/lsm_disabler.ko of=/data/local/lsm_disabler.ko
(10) release LSM lock
********* "x" and "y" is option for f10dunlock
For x=0 if you're on F-10D Build number V16R45C
x=1 if you're ISW13D Device
x=2 if you're on F-10D Build number V18R46F
IF you can't insert module lsm_disabler.ko after execute f10dunlock "x" you can add option "y" at last one example f10dunlock 0 2 or f10dunlock 0 1 and then try to insert module lsm_disabler.ko **********
# cd /data/local
# chmod 777 f10dunlock
# chown root.root / data/local/f10dunlock
# /data/local/f10dunlock x y
/data/local/f10dunlock
fdaes = -1
open aeswipe error, so try to disable LSM without recovery g_lptsAuthContext
fdaes2 = 3
use new F-10D address
# /data/local/f10dunlock 2
/data/local/f10dunlock 2
fdaes = -1
open aeswipe error, so try to disable LSM without recovery g_lptsAuthContext
fdaes2 = 3
# ./f10dunlock
./f10dunlock
fdaes = -1
open aeswipe error, so try to disable LSM without recovery g_lptsAuthContext
fdaes2 = 3
# lsmod
# mount-o rw, remount / system
mount-o rw, remount / system
# cd /system
cd /system
# chmod 777 / system
chmod 777 / system
# mkdir test
mkdir test
# ls-al
(11) Set su busybox
# sync; sync; sync
sync; sync; sync
# dd if=/mnt/sdcard/su of=/system/bin/su
dd if=/mnt/sdcard/su of=/system/bin/su
743 +1 records in
743 +1 records out
380532 bytes transferred in 0.079 secs (4816860 bytes / sec)
# chown root.shell /system/bin/su
chown root.shell /system/bin/su
# chmod 06755 /system/bin/su
chmod 06755 /system/bin/su
# sync; sync; sync
sync; sync; sync
# dd if=/mnt/sdcard/su of=/system/xbin/su
dd if=/mnt/sdcard/su of=/system/xbin/su
743 +1 records in
743 +1 records out
380532 bytes transferred in 0.034 secs (11192117 bytes / sec)
# chown root.shell /system/xbin/su
chown root.shell /system/xbin/su
# chmod 06755 /system/xbin/su
chmod 06755 /system/xbin/su
# sync; sync; sync
sync; sync; sync
# dd if = /data/local.org/tmp/busybox of=/system/xbin/busybox
dd if=/data/local.org/tmp/busybox of=/system/xbin/busybox
2099 +1 records in
2099 +1 records out
1075144 bytes transferred in 0.085 secs (12648752 bytes / sec)
# chown root.shell /system/xbin/busybox
chown root.shell /system/xbin/busybox
# chmod 04755 /system/xbin/busybox
chmod 04755 /system/xbin/busybox
# ls-al
ls-al
drwxr-xr-x root root 2012-09-01 03:31 app
drwxrwxrwx root shell 2012-09-01 23:59 bin
-rw-r - r - root root 4093 2012-09-01 03:31 build.prop
drwxr-xr-x root shell 2012-09-02 01:05 xbin
# cd /system/xbin
cd /system/xbin
# ls -al
ls -al
-rwxr-xr-x root shell 10028 2012-07-07 21:17 agent
-rwsr-xr-x root shell 1075144 2012-09-02 01:05 busybox
-rwxr-xr-x root shell 9780 2012-07-07 21:17 dbus-monitor
-rwxr-xr-x root shell 5708 2012-07-07 21:17 sdptest
-rwsr-sr-x root shell 380532 2012-09-02 01:03 su
#
(12) Set up SuperUser
Install from the market SuperSU etc..
k you must have permission to launch the app root, root authorization confirmation screen will appear if
Remark form me(yes, me not goroh_kun) : if you reboot your device. It's has re-lock /system. Even you have root access you can't remount /system to r/o until you re-execute f10dunlock. So you should think and plan by carefully that you want to move SuperSU.apk form /data/app to/system/app for more safer factory reset in future or not.
Thank you for the dear goroh_kun.
Click to expand...
Click to collapse
Anything for F-02E??
the same problem
Rudeyllah said:
Anything for F-02E??
Click to expand...
Click to collapse
I have the same problem with the same phone model,i tried to root but i'm stuck at 7.-permision denied and 8.-on and off wifi...i try all but i can't pass this steps......maybe the tutorial need more detail or maybe it is about diferences between versions of phone.
Build
The Root for F-10D has different Command for Rooting,depending BUILD on Device..
Option is different depending on the version and model.
F-10D build number V16R45C: → 0
ISW13D: → 1
F-10D build number V18R46F: → 2
F-10D build number V20R47F: → 3
My Device is V20R47F and the Following Command for V16R45C ... Cannot be use on V20R47F.. i always get Error after -7 ..
Can anyone help for V20R47F ?
CMD
C:> adb restore f-10d_2.ab
~ ~ ~ To allow restore ~ ​​~ ~ Android terminal
C:> adb shell
shell @ android :/ $ cd / data / data / com.android.settings / a /
cd / data / data / com.android.settings / a /
shell @ android :/ data / data / com.android.settings / a $ ls-l-d
ls-l-d
drwxrwxrwx system system 2011-01-01 09:09.
shell @ android :/ data / data / com.android.settings / a $ ls-l
ls-l
drwxrwxrwx system system 2011-01-01 09:09 file00
drwxrwxrwx system system 2011-01-01 09:09 file01
drwxrwxrwx system system 2011-01-01 09:09 file02
~ ~ ~ ~ ~ ~ Omitted
~ ~ ~ ~ ~ ~ Omitted
drwxrwxrwx system system 2011-01-01 09:09 file97
drwxrwxrwx system system 2011-01-01 09:09 file98
drwxrwxrwx system system 2011-01-01 09:09 file99
shell @ android :/ data / data / com.android.settings / a $ cd / data / data / com.android.settings /
com.android.settings / <
shell @ android :/ data / data / com.android.settings $ ls-l
ls-l
drwxrwxrwx system system 2011-01-01 09:09 a
drwxr-xr-x system system 2011-01-01 09:00 lib
shell @ android :/ data / data / com.android.settings $ rm-ra
rm-r a
rm failed for a, Permission denied
255 | shell @ android :/ data / data / com.android.settings $ while:; do ln-s / data a/file99; done
ln-s / data a/file99; done <
link failed File exists
link failed File exists
link failed File exists
~ ~ ~ Leaving the ~ ~ ~ endlessly
~ ~ ~ Leaving the ~ ~ ~ endlessly
~ ~ ~ ↓ ↓ ↓ ~ ~ ~ to open and run one more command line
C:> adb restore f-10d_2.ab
~ ~ ~ To allow restore ~ ​​~ ~ Android terminal
~ ~ ~ ↑ ↑ ↑ ~ ~ ~ to open and run one more command line
I made a restore link failed No such file or directory ← here
link failed No such file or directory
link failed No such file or directory
link failed No such file or directory
link failed No such file or directory
link failed No such file or directory
link failed No such file or directory
link failed No such file or directory
link failed No such file or directory
link failed No such file or directory
link failed No such file or directory
link failed No such file or directory
link failed No such file or directory
link failed File exists
link failed File exists
link failed File exists
~ ~ ~ Leaving the ~ ~ ~ endlessly
~ ~ ~ Leaving the ~ ~ ~ endlessly
^ I interrupted by C ← CTRL + C.
C:>
C:> adb shell
shell @ android :/ $ ls-l-d / data
ls-l-d / data
drwxrwxrwx system system 2011-01-01 09:11 data
shell @ android :/ $ exit
exit
C:> adb push mkdevsh / data / local / tmp /
2702 KB / s (648486 bytes in 0.234s)
C:> adb shell
shell @ android :/ $ ls-l-d / data / local
ls-l-d / data / local
drwxr-x - x root root 2011-01-01 09:00 local
shell @ android :/ $ ls-l-d / data / local / tmp
ls-l-d / data / local / tmp
drwxrwx - x shell shell 2011-01-01 09:12 tmp
shell @ android :/ $ ls-l / data / local / tmp
ls-l / data / local / tmp
-Rw-rw-rw-shell shell 648486 2012-09-01 03:47 mkdevsh
shell @ android :/ $ chmod 777 / data / local / tmp / mkdevsh
chmod 777 / data / local / tmp / mkdevsh
shell @ android :/ $ ls-l / data / local / tmp /
ls-l / data / local / tmp /
-Rwxrwxrwx shell shell 648486 2012-09-01 03:47 mkdevsh
shell @ android :/ $ mv / data / local / data / local.org
mv / data / local / data / local.org
shell @ android :/ $ ls-l / data / local.org / tmp
ls-l / data / local.org / tmp
-Rwxrwxrwx shell shell 648486 2012-09-01 03:47 mkdevsh
shell @ android :/ $ mkdir / data / local
mkdir / data / local
shell @ android :/ $ ls-l-d / data / local /
ls-l-d / data / local /
drwxrwxrwx shell shell 2011-01-01 09:12
shell @ android :/ $ ln-s / sys / kernel / uevent_helper / data / local / tmp
ln-s / sys / kernel / uevent_helper / data / local / tmp
shell @ android :/ $ ls-l / data / local / tmp
ls-l / data / local / tmp
lrwxrwxrwx shell shell 2011-01-01 09:12 tmp -> / sys / kernel / uevent_helper
shell @ android :/ $ exit
exit
C:> adb push su / data /
2972 KB / s (380532 bytes in 0.125s)
C:> adb reboot
C:> adb wait-for-device shell
echo / data / local.org / tmp / mkdevsh> / sys / kernel / uevent_helper
echo / data / local.org / tmp / mkdevsh> / sys / kernel / uevent_helper
sh> / sys / kernel / uevent_helper <
shell @ android :/ $
shell @ android :/ $ ls-l / sys / kernel / uevent_helper
ls-l / sys / kernel / uevent_helper
-Rwxrwx - x shell shell 4096 2011-01-01 09:00 uevent_helper
shell @ android :/ $ ls-l / dev / sh
ls-l / dev / sh
-Rwsr-sr-x root root 151964 2011-01-01 09:00 sh
shell @ android :/ $ ls-l / data / su
ls-l / data / su
-Rw-rw-rw-shell shell 380532 2008-02-29 02:33 su
shell @ android :/ $ / dev / sh
/ Dev / sh
# ← root Kita! (It takes a permanent root in the rewritable system area by the mount rw)
# Mount-o rw, remount / system / system
mount-o rw, remount / system / system
# Ls-l / system / bin / su
ls-l / system / bin / su
/ System / xbin / su: No such file or directory
# Dd if = / data / su of = / system / bin / su
dd if = / data / su of = / system / bin / su
743 +1 records in
743 +1 records out
380532 bytes transferred in 0.047 secs (8096425 bytes / sec)
# Chown root.root / system / bin / su
chown root.root / system / bin / su
# Chmod 06755 / system / bin / su
chmod 06755 / system / bin / su
# Ls-l / system / bin / su
ls-l / system / bin / su
-Rwsr-sr-x root root 380532 2011-01-01 09:01 su
# Ls-l / system / xbin / su
ls-l / system / xbin / su
/ System / xbin / su: No such file or directory
# Dd if = / data / su of = / system / xbin / su
dd if = / data / su of = / system / xbin / su
743 +1 records in
743 +1 records out
380532 bytes transferred in 0.045 secs (8456266 bytes / sec)
# Chown root.root / system / xbin / su
chown root.root / system / xbin / su
# Chmod 06755 / system / xbin / su
chmod 06755 / system / xbin / su
# Ls-l / system / xbin / su
ls-l / system / xbin / su
-Rwsr-sr-x root root 380532 2011-01-01 09:02 su
# Mount-o ro, remount / system / system
mount-o ro, remount / system / system
# Dd if = / data / su of = / system / bin / su
dd if = / data / su of = / system / bin / su
/ System / bin / su: cannot open for write: Read-only file system
# Rm / data / local / tmp
rm / data / local / tmp
# Mv / data / local / data / local.ln
mv / data / local / data / local.ln
# Mv / data / local.org / data / local
mv / data / local.org / data / local
# Ls-l-d / data / local *
ls-l-d / data / local *
drwxr-x - x root root 2011-01-01 09:00 local
drwxr-x - x root root 2011-01-01 09:02 local.ln
# Sync; sync; sync
sync; sync; sync
# Reboot
reboot
Click to expand...
Click to collapse
any significant improvements in battery life after rooting?
spec-wise it is a very good phone but i really regret the decision of buying this phone cos it heats up so fast and battery life is non-existent.
Rudeyllah said:
Anything for F-02E??
Click to expand...
Click to collapse
Can you please review this phone F-02E? I am really thinking of buying it.
How is the camera, battery life, screen, is the processor capable of working smoothly even with the full HD display, does it get unneccesarily hot, how is the build quality?
lapucele said:
any significant improvements in battery life after rooting?
spec-wise it is a very good phone but i really regret the decision of buying this phone cos it heats up so fast and battery life is non-existent.
Click to expand...
Click to collapse
I am in the same shoe as you with my F-02E, heat so fast and it restarts from 44 degrees centigrade.
Booting Fujitsu F-10D not powering on
My phone suddenly dosent power on. I tested the battery with a tester and it's fully charged. Anyone had a power problem with an Arrows X? Please help me!
The weird thing is I bought my phone at the same time as a friend and his phone stopped working a week ago also!!
When I press the power button, the red charging light blinks 3 time. Any debugging idea?Help me
Thanks
lythekhang said:
My phone suddenly dosent power on. I tested the battery with a tester and it's fully charged. Anyone had a power problem with an Arrows X? Please help me!
The weird thing is I bought my phone at the same time as a friend and his phone stopped working a week ago also!!
When I press the power button, the red charging light blinks 3 time. Any debugging idea?Help me
Thanks
Click to expand...
Click to collapse
I have the same problem too, mobile doesn't start.
When I press the power button, the red charging light blinks 3 time too.
Don't know what a problem, and how this fix.
can anyone confirm if this is working?
Using F-02E ones may work but don't do this. You can never get back when system files go wrong. I already turned mine to paperweight after reboot.
try this
Hi folks
I have Arrows X F-10D , I tried all methods to root it but no hope, I think the build number V22R49C is unrootable
Anyway I suggest to try this lovely program which I found in this site. http://www.mgyun.com/vroot
I have already attached the program, you can download it and give it a try if your build number is lower than above
try this too
Here is another program I have download it from here
help please
Guys help me please
I need DoCoMo apps system
I lost one app by mistake which is for DoCoMo account numbers
When I create new contact it shows me only Google account to save in, but no phone contacts
Please help
Somebody upload this app for me

Installing SuperSU root on Mi 5c

Here's a guide + script for installing SuperSU root on the Mi 5c.
I haven't yet managed to build a TWRP recovery image for it (I haven't really tried) - so this can be used to get root in the mean-time. (I also saw a Chinese TWRP ROM on the MIUI forums, but I haven't tried it myself)
Obviously modifying the phone system is risky, you may void the warranty, break it etc. I take no responsibility for that, and you use the instructions below at your own risk.
The script, and a few other tools I'm using for the Mi 5c can be found in my git repo: github.com/usedbytes/meri_tools
To use the script, you'll need a linux (or Mac, probably) computer with gcc and git installed, as well as a new-ish version of adb and fastboot. I'm running it on Arch Linux fine.
First get the phone into developer mode (tap on the MIUI version in About Phone 7 times), and enable adb debugging, and approve your computer to access debugging.
Then you need to download and extract the SuperSU "Installable Recovery" zip, and the Xiaomi stock ROM, which we will use for the install files.
Then, run the script below (meri_root.sh in the git repo).
The script installs all the bits needed, then reboots the phone with a rooted boot image. To make the root persistent, you need to flash the boot.supersu.img to the boot partition with fastboot (it just boots it by default).
Code:
#!/bin/bash
#
# Script to root the Xiaomi Mi 5c, by manually installing SuperSU
#
# Copyright 2017 Brian Starkey
#
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the "Software"),
# to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
# OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
# DEALINGS IN THE SOFTWARE.
#
# -- Disclaimer
#
# Obviously modifying your phone can be dangerous, void the warranty etc. etc.
# Use this script and the instructions within it at your own risk.
#
# -- Description
#
# The SuperSU installer seems to assume you already have root, and is intended
# to be run from a custom recovery (like TWRP). We don't have that, so we'll do
# some funny dances to do a systemless root without having root to begin with.
#
# The crux of the matter is using SuperSU's tools to patch the ramdisk and
# sepolciy (in /data/local/tmp, without root), then building a ramdisk with
# those components
#
# -- Usage
#
# Plug in the phone, make sure you have (persistent) adb debugging permissions
# and run this script like so:
# meri_root.sh SUPERSU_DIR ROM_DIR
# Where SUPERSU_DIR is a directory where you have downloaded and extracted the
# SuperSU "Recovery Flashable" zip file: http://www.supersu.com/download
# and ROM_DIR is a directory where you have downloaded and extracted the ROM
# from Xiaomi's download page: http://en.miui.com/download-322.html
#
# The script will make and boot a boot.img which enacts a systemless root.
# To make it persisent, you must flash it instead:
# fastboot flash boot.supersu.img
#
# By default, SuperSU removes dm-verity from /system and encryption from /data
# To prevent this, set PRESERVE_VERITY=1 before running the script:
# PRESERVE_VERITY=1 ./meri_root.sh ...
if [ $# -ne 2 ];
then
cat >&2 <<EOM
Usage: $(basename $0) SUPERSU_DIR ROM_DIR
Extract SuperSU zip file into SUPERSU_DIR, and the Xiaomi ROM into ROM_DIR,
then run this script.
EOM
exit 1
fi
SUPERSU_DIR=$1
echo ${SUPERSU_DIR}/arm64/su
if [ ! -f ${SUPERSU_DIR}/arm64/su ]
then
echo "Invalid SUPERSU_DIR" >&2
exit 1
fi
ROM_DIR=$2
if [ ! -f ${ROM_DIR}/boot.img ]
then
echo "Invalid ROM_DIR" >&2
exit 1
fi
# 1. Get mkbootimg and build it
git clone --depth 1 https://github.com/osm0sis/mkbootimg.git || exit 1
cd mkbootimg
make || ( cd .. && exit 1 )
cd ..
# 2. Copy the SuperSU binaries to the device
echo "Waiting for device..."
adb wait-for-usb-device
adb push ${SUPERSU_DIR}/arm64/*su* /data/local/tmp/ || exit 1
adb shell chmod +x /data/local/tmp/su*
# 3. Create the SuperSU systemless root image
# Ideally we'd set up security contexts too, but then you need to be running
# on an SELinux-enabled kernel in permissive mode.
# Instead, we will fix it on first boot.
dd if=/dev/zero bs=1M count=96 of=su.img
mkfs.ext4 su.img
mkdir mnt
sudo mount su.img mnt
sudo mkdir mnt/{bin,xbin,lib,etc,su.d}
sudo chmod 0751 mnt/bin
sudo chmod 0755 mnt/{xbin,lib,etc}
sudo chmod 0700 mnt/su.d
sudo cp ${SUPERSU_DIR}/arm64/{su,sukernel} mnt/bin/
sudo cp ${SUPERSU_DIR}/arm64/su mnt/bin/daemonsu
sudo cp ${SUPERSU_DIR}/arm64/supolicy mnt/bin/supolicy_wrapped
sudo ln -s /su/bin/su mnt/bin/supolicy
sudo chown root:root mnt/bin/{su,daemonsu,sukernel,supolicy_wrapped}
sudo chmod 0755 mnt/bin/{su,daemonsu,sukernel,supolicy_wrapped}
sudo cp ${SUPERSU_DIR}/arm64/libsupol.so mnt/lib/libsupol.so
sudo chown root:root mnt/lib/libsupol.so
sudo chmod 0644 mnt/lib/libsupol.so
# Run a script at first-boot to fix up the SELinux contexts on the image
# It will remove itself after running
sudo bash -c "cat > mnt/su.d/firstboot.rc" <<EOF
#/system/bin/sh
chcon -hR u:object_r:system_data_file:s0 /su /data/local/tmp/su.img
rm /su/su.d/firstboot.rc
sync
EOF
sudo chmod 0750 mnt/su.d/firstboot.rc
sync
sudo umount mnt
# 4. Copy the systemless root image to the device
adb push su.img /data/local/tmp/su.img
# 5. Extract boot.img
mkdir bootimg
mkbootimg/unpackbootimg -o bootimg -i ${ROM_DIR}/boot.img
# 6. Unzip the ramdisk
cat bootimg/boot.img-ramdisk.gz | gunzip > ramdisk
# 7. Copy the ramdisk to the device, for patching
adb push ramdisk /data/local/tmp
# 8. Patch sepolicy and the ramdisk, using the SuperSU tools we copied over
# earlier
adb shell "
cd /data/local/tmp
LD_LIBRARY_PATH=. ./supolicy --file /sepolicy ./sepolicy.patched
LD_LIBRARY_PATH=. ./sukernel --patch ./ramdisk ramdisk.patched
"
# 9. Pull back the patched files
adb pull /data/local/tmp/sepolicy.patched /data/local/tmp/ramdisk.patched .
# 10. Extract the patched ramdisk, and install the patched sepolicy into it
mkdir ramdir
cat ramdisk.patched | sudo cpio --no-absolute-filenames -D ramdir -i
sudo cp sepolicy.patched ramdir/sepolicy
sudo chown root:root ramdir/sepolicy
sudo chmod 0644 ramdir/sepolicy
# 11. Install the SuperSU init scripts
sudo mkdir ramdir/su
sudo chmod 755 ramdir/su
sudo cp ${SUPERSU_DIR}/common/launch_daemonsu.sh ramdir/sbin
sudo chmod 744 ramdir/sbin/launch_daemonsu.sh
sudo chown root:root ramdir/sbin/launch_daemonsu.sh
sudo cp ${SUPERSU_DIR}/common/init.supersu.rc ramdir
sudo chmod 750 ramdir/init.supersu.rc
sudo chown root:root ramdir/init.supersu.rc
# 12. Patch the initscript for our img location and set the su.img context
sudo sed -i 's;/data/su.img;/data/local/tmp/su.img;' ramdir/init.supersu.rc
sudo sed -i '\;on property:sukernel.mount=1;a\ \ \ \ restorecon /data/local/tmp/su.img' ramdir/init.supersu.rc
sudo bash -c "echo /data/local/tmp/su.img u:object_r:system_data_file:s0 >> ramdir/file_contexts"
# Optional: Preserve dm-verity on /system, encryption on /data
if [ ! -z "$PRESERVE_VERITY" ] && [ $PRESERVE_VERITY -ne 0 ]
then
echo "Preserving dm-verity"
mkdir ramdir-stock
cat ramdisk | sudo cpio --no-absolute-filenames -D ramdir-stock -i
sudo cp ramdir-stock/{fstab.song,verity_key} ramdir/
sudo rm -rf ramdir-stock
fi
# 13. Repack the ramdisk
cd ramdir
sudo find . ! -path . | sudo cpio -H newc -o | gzip > ../ramdisk.gz
cd ..
# 14. Repack the boot image
mkbootimg/mkbootimg \
--kernel bootimg/boot.img-zImage \
--ramdisk ramdisk.gz \
--cmdline "console=ttyS0,115200 earlyprintk=uart8250-32bit,0xF900B000 androidboot.hardware=song no_console_suspend debug user_debug=31 loglevel=8" \
--base 0x0 \
--pagesize 4096 \
--kernel_offset 0x0a080000 \
--ramdisk_offset 0x0c400000 \
--dt bootimg/boot.img-dtb \
--tags_offset 0xc200000 \
--os_version 0.0.0 \
--os_patch_level 0 \
--second_offset 0x00f00000 \
--hash sha256 \
--id \
-o boot.supersu.img
# 15. Boot it! (flash it if you want to make it persistent)
adb reboot-bootloader
fastboot boot boot.supersu.img
echo "Waiting for device..."
adb wait-for-usb-device
Hi ,
Can you give me some advice on how to run this on Windows? I can get a adb shell but thats as far as I can get. I don't know how I am supposed to run the script.
Thanks
Stewart
Hello,
I am trying to root my mi 5c with your script, but I can't find sepolicy file on my phone, so for example this line can't be executed:
Code:
LD_LIBRARY_PATH=. ./supolicy --file /sepolicy ./sepolicy.patched
Do you know where I could find this file? I am using xiaomi.eu_multi_MI5c_7.4.6_v8-7.1 rom.
Hello,
I've had exactly the same issue on a multirom and on xiaomi.eu_multi_MI5c_7.4.20(although i'm not sure if installed rom has something to do with it)
blagon said:
...I am trying to root my mi 5c with your script, but I can't find sepolicy file on my phone...
Click to expand...
Click to collapse

Help including SuperSU and su binaries in stock ROM.

I would like some help in modifying my stock rom to include the SuperSU apk and all five su binaries (su, daemonsu, sukernel, supolicy and suinit).
I am aware that there are multiple tutorials out there for this kind of thing but what I'm trying to do requires the system be repacked into a sparse image to flash through fastboot as the phone has no TWRP build available.
Thank You.
Bythos73 said:
I would like some help in modifying my stock rom to include the SuperSU apk and all five su binaries (su, daemonsu, sukernel, supolicy and suinit).
I am aware that there are multiple tutorials out there for this kind of thing but what I'm trying to do requires the system be repacked into a sparse image to flash through fastboot as the phone has no TWRP build available.
Thank You.
Click to expand...
Click to collapse
Hello, you can unzip the flashable SuperSu zip and take a look at the update-binary script, this will shed some light on how the installation works, for example this is an excerpt taken from version 2.82:
Code:
#!/sbin/sh
#
# SuperSU installer ZIP
# Copyright (c) 2012-2017 - Chainfire, CCMT
#
# ----- GENERIC INFO ------
#
# The following su binary versions are included in the full package. Each
# should be installed only if the system has the same or newer API level
# as listed. The script may fall back to a different binary on older API
# levels. supolicy are all ndk/pie/19+ for 32 bit, ndk/pie/20+ for 64 bit.
#
# binary ARCH/path build type API
#
# arm-v5te arm ndk non-pie 7+
# x86 x86 ndk non-pie 7+
#
# x86 x86 ndk pie 17+ (su.pie, naming exception)
# arm-v7a armv7 ndk pie 17+
# mips mips ndk pie 17+
#
# arm64-v8a arm64 ndk pie 20+
# mips64 mips64 ndk pie 20+
# x86_64 x64 ndk pie 20+
#
# Non-static binaries are supported to be PIE (Position Independent
# Executable) from API level 16, and required from API level 20 (which will
# refuse to execute non-static non-PIE).
#
# The script performs several actions in various ways, sometimes
# multiple times, due to different recoveries and firmwares behaving
# differently, and it thus being required for the correct result.
#
# Overridable variables (shell):
# BIN - Location of architecture specific files (native folder)
# COM - Location of common files (APK folder)
# LESSLOGGING - Reduce ui_print logging (true/false)
# NOOVERRIDE - Do not read variables from /system/.supersu or
# /data/.supersu
#
# Overridable variables (shell, /system/.supersu, /cache/.supersu,
# /data/.supersu):
# SYSTEMLESS - Do a system-less install? (true/false, 6.0+ only)
# PATCHBOOTIMAGE - Automatically patch boot image? (true/false,
# SYSTEMLESS only)
# BOOTIMAGE - Boot image location (PATCHBOOTIMAGE only)
# STOCKBOOTIMAGE - Stock boot image location (PATCHBOOTIMAGE only)
# BINDSYSTEMXBIN - Poor man's overlay on /system/xbin (true/false,
# SYSTEMLESS only)
# PERMISSIVE - Set sepolicy to fake-permissive (true/false, PATCHBOOTIMAGE
# only)
# KEEPVERITY - Do not remove dm-verity (true/false, PATCHBOOTIMAGE only)
# KEEPFORCEENCRYPT - Do not replace forceencrypt with encryptable (true/
# false, PATCHBOOTIMAGE only)
# REMOVEENCRYPTABLE - Remove the encryptable flag, needed on newer
# Samsung devices to disable forced encryption
# (true/false, PATCHBOOTIMAGE only)
# FRP - Place files in boot image that allow root to survive a factory
# reset (true/false, PATCHBOOTIMAGE only). Reverts to su binaries
# from the time the ZIP was originall flashed, updates are lost.
# Shell overrides all, /data/.supersu overrides /cache/.supersu overrides
# /system/.supersu
#
# Note that if SELinux is set to enforcing, the daemonsu binary expects
# to be run at startup (usually from install-recovery.sh, 99SuperSUDaemon,
# app_process, or init.supersu.rc) from u:r:supersu:s0 (7.0+), u:r:init:s0 or
# u:r:kernel:s0 contexts. Depending on the current policies, it can also
# deal with u:r:init_shell:s0 and u:r:toolbox:s0 contexts. Any other context
# will lead to issues eventually.
#
# ----- "SYSTEM" INSTALL -----
#
# "System" install puts all the files needed in /system and does not need
# any boot image modifications. Default install method pre-Android-6.0
# (excluding Samsung-5.1).
#
# Even on Android-6.0+, the script attempts to detect if the current
# firmware is compatible with a system-only installation (see the
# "detect_systemless_required" function), and will prefer that
# (unless the SYSTEMLESS variable is set) if so. This will catch the
# case of several custom ROMs that users like to use custom boot images
# with - SuperSU will not need to patch these. It can also catch some
# locked bootloader cases that do allow security policy updates.
#
# To install SuperSU properly, aside from cleaning old versions and
# other superuser-type apps from the system, the following files need to
# be installed:
#
# API source target chmod chcon required
#
# 7-19 common/Superuser.apk /system/app/Superuser.apk 0644 u:object_r:system_file:s0 gui
# 20+ common/Superuser.apk /system/app/SuperSU/SuperSU.apk 0644 u:object_r:system_file:s0 gui
#
# 17+ common/install-recovery.sh /system/etc/install-recovery.sh 0755 *1 required
# 17+ /system/bin/install-recovery.sh (symlink to /system/etc/...) required
# *1: same as /system/bin/toolbox: u:object_r:system_file:s0 if API < 20, u:object_r:toolbox_exec:s0 if API >= 20
#
# 7+ ARCH/su *2 /system/xbin/su *3 u:object_r:system_file:s0 required
# 7+ /system/bin/.ext/.su *3 u:object_r:system_file:s0 gui
# 17+ /system/xbin/daemonsu 0755 u:object_r:system_file:s0 required
# *2: su.pie for 17+ x86(_32) only
# *3: 06755 if API < 18, 0755 if API >= 18
#
# 19+ ARCH/supolicy /system/xbin/supolicy 0755 u:object_r:system_file:s0 required
# 19+ ARCH/libsupol.so /system/lib(64)/libsupol.so 0644 u:object_r:system_file:s0 required
#
# 21+ /system/bin/app_process32 *5 /system/bin/app_process32_original 0755 u:object_r:zygote_exec:s0 required
# 21+ /system/bin/app_process64 *5 /system/bin/app_process64_original 0755 u:object_r:zygote_exec:s0 required
# 21+ /system/bin/app_processXX *5 /system/bin/app_process_init 0755 u:object_r:system_file:s0 required
# 21+ /system/bin/app_process (symlink to /system/xbin/daemonsu) required
# 21+ *5 /system/bin/app_process32 (symlink to /system/xbin/daemonsu) required
# 21+ *5 /system/bin/app_process64 (symlink to /system/xbin/daemonsu) required
# *5: Only do this for the relevant bits. On a 64 bits system, leave the 32 bits files alone, or dynamic linker errors
# will prevent the system from fully working in subtle ways. The bits of the su binary must also match!
#
# 17+ common/99SuperSUDaemon *6 /system/etc/init.d/99SuperSUDaemon 0755 u:object_r:system_file:s0 optional
# *6: only place this file if /system/etc/init.d is present
#
# 17+ 'echo 1 >' or 'touch' *7 /system/etc/.installed_su_daemon 0644 u:object_r:system_file:s0 optional
# *7: the file just needs to exist or some recoveries will nag you. Even with it there, it may still happen.
#
# It may seem some files are installed multiple times needlessly, but
# it only seems that way. Installing files differently or symlinking
# instead of copying (unless specified) will lead to issues eventually.
#
# After installation, run '/system/xbin/su --install', which may need to
# perform some additional installation steps. Ideally, at one point,
# a lot of this script will be moved there.
#
# The included chattr(.pie) binaries are used to remove ext2's immutable
# flag on some files. This flag is no longer set by SuperSU's OTA
# survival since API level 18, so there is no need for the 64 bit versions.
# Note that chattr does not need to be installed to the system, it's just
# used by this script, and not supported by the busybox used in older
# recoveries.
#
# ----- "SYSTEM-LESS" INSTALL -----
#
# "System-less" install requires a modified boot image (the script can patch
# many boot images on-the-fly), but does not touch /system at all. Instead
# it keeps all the needed files in an image (/data/su.img) which is mounted
# to /su. Default install method on all Android-6.0+ and Samsung-5.1+
# devices.
#
# Note that even on 6.0+, system compatibility is checked. See the "SYSTEM"
# install section above.
#
# An ext4 image is created as /data/su.img, or /cache/su.img if /data could
# not be mounted. Similarly, the APK is placed as either /data/SuperSU.apk
# or /cache/SuperSU.apk. This is so we are not dependent on /data decryption
# working in recovery, which in the past has proved an issue on brand-new
# Android versions and devices.
#
# /sbin/launch_daemonsu.sh, which is added a service to init.rc, will mount
# the image at /su, and launch daemonsu from /su/bin/daemonsu. But before it
# does that, it will try to merge /data/su.img and /cache/su.img (leading),
# if both are present. It will also try to install the SuperSU APK.
#
# Files are expected at the following places (/su being the mountpoint of
# the ext4 image):
#
# API source target chmod chcon required
#
# 22+ common/Superuser.apk /[data|cache]/SuperSU.apk 0644 u:object_r:system_file:s0 gui
#
# 22+ ARCH/su *1 /su/bin/su 0755 u:object_r:system_file:s0 required
# 22+ /su/bin/daemonsu 0755 u:object_r:system_file:s0 required
# *1: su.pie for 17+ x86(_32) only
#
# 22+ ARCH/supolicy /su/bin/supolicy_wrapped 0755 u:object_r:system_file:s0 required
# 22+ /su/bin/su (symlink) *2 /su/bin/supolicy 0755 u:object_r:system_file:s0 required
# 22+ ARCH/libsupol.so /su/lib/libsupol.so 0644 u:object_r:system_file:s0 required
# *2: when called this way, su sets the correct LD_LIBRARY_PATH and calls supolicy_wrapped
#
# 22+ ARCH/sukernel /su/bin/sukernel 0755 u:object_r:system_file:s0 required
#
# These files are automatically created on launch by daemonsu as needed:
# 22+ /system/bin/sh /su/bin/sush 0755 u:object_r:system_file:s0 required
# 22+ /system/bin/app_process[64] /su/bin/app_process 0755 u:object_r:system_file:s0 required
#
# These files are injected into the boot image ramdisk:
# 22+ common/launch_daemonsu.sh /sbin/launch_daemonsu.sh 0700 u:object_r:rootfs:s0 required
#
# On devices where / is in the system partition:
# 22+ ARCH/suinit /init 0750 u:object_r:rootfs:s0 required
#
# The automated boot image patcher included makes the following modifications
# to the ramdisk:
#
# - Uses the supolicy tool to patch the sepolicy file
# - Injects /sbin/launch_daemon.sh
# - Creates /su
# - Removes /verity_key
# - Patches /*fstab*
# --- Removes support_scfs and verify flags
# --- Changes forceencrypt/forcefdeorfbe into encryptable
# --- Set ro mounts to use noatime
# - Patches /init.rc
# --- Removes 'setprop selinux.reload_policy' occurences
# --- Adds a SuperSU:PATCH marker with the version of the sukernel tool
# --- Adds a SuperSU:STOCK marker listed the SHA1 of the original boot image
# - Adds /init.supersu.rc
# --- Adds a sukernel.mount property trigger that mounts /data/su.img to /su
# --- Adds the daemonsu service that launches /sbin/launch_daemon.sh
# --- Adds exec /sbin/launch_daemonsu.sh on post-fs-data
# - Patches /init.environ.rc
# --- Adds PATH variable if it does not exist
# --- Prepends /su/bin to the PATH variable
# - Patches /*.rc
# --- Adds a seclabel to services and execs that are missing one
# - In case the device has the root directory inside the system partition:
# --- /system_root contents are copied to /boot
# --- All files mentioned above are modified in /boot instead of /
# --- /boot/*fstab* is modified to mount / to /system_root, and
# bind-mount /system to /system_root/system
# --- Kernel binary is patched to load from initramfs instead of system
#
# In case this documentation becomes outdated, please note that the sukernel
# tool is very chatty, and its output tells you exactly what it is doing
# and how. In TWRP, you can view this output by catting /tmp/recovery.log
# after flashing the ZIP.
#
# The boot image patcher creates a backup of the boot image it patches, for
# future restoration. It cannot re-patch a patched boot image, it will restore
# the previous boot image first. /[data|cache]/stock_boot_*.gz
#
# The boot image patcher currently only supports GZIP compressed ramdisks, and
# boot images in the standard Android boot image format.
#
# During boot image patch, /data/custom_ramdisk_patch.sh will be called,
# with the name of the ramdisk cpio file as parameter. The script must
# replace the input file and return a 0 exit code.
#
# Just before flashing, the boot image patcher will call
# /data/custom_boot_image_patch.sh with the name of the patched boot image
# as parameter. A device-specific patcher can further patch the boot image
# if needed. It must replace the input file and return a 0 exit code.
OUTFD=$2
ZIP=$3
getvar() {
local VARNAME=$1
local VALUE=$(eval echo \$"$VARNAME");
for FILE in /data/.supersu /cache/.supersu /system/.supersu; do
if [ -z "$VALUE" ]; then
LINE=$(cat $FILE 2>/dev/null | grep "$VARNAME=")
if [ ! -z "$LINE" ]; then
VALUE=${LINE#*=}
fi
fi
done
eval $VARNAME=\$VALUE
}
readlink /proc/$$/fd/$OUTFD 2>/dev/null | grep /tmp >/dev/null
if [ "$?" -eq "0" ]; then
# rerouted to log file, we don't want our ui_print commands going there
OUTFD=0
# we are probably running in embedded mode, see if we can find the right fd
# we know the fd is a pipe and that the parent updater may have been started as
# 'update-binary 3 fd zipfile'
for FD in `ls /proc/$$/fd`; do
readlink /proc/$$/fd/$FD 2>/dev/null | grep pipe >/dev/null
if [ "$?" -eq "0" ]; then
ps | grep " 3 $FD " | grep -v grep >/dev/null
if [ "$?" -eq "0" ]; then
OUTFD=$FD
break
fi
fi
done
fi
ui_print_always() {
echo -n -e "ui_print $1\n" >> /proc/self/fd/$OUTFD
echo -n -e "ui_print\n" >> /proc/self/fd/$OUTFD
}
if [ -z "$LESSLOGGING" ]; then
LESSLOGGING=false
fi
UI_PRINT_LAST=""
ui_print() {
if (! $LESSLOGGING); then
UI_PRINT_LAST="$1"
ui_print_always "$1"
fi
}
ui_print_less() {
if ($LESSLOGGING); then
ui_print_always "$1"
fi
}
ch_con() {
LD_LIBRARY_PATH=$SYSTEMLIB /system/bin/toybox chcon -h u:object_r:system_file:s0 $1 1>/dev/null 2>/dev/null
LD_LIBRARY_PATH=$SYSTEMLIB /system/toolbox chcon -h u:object_r:system_file:s0 $1 1>/dev/null 2>/dev/null
LD_LIBRARY_PATH=$SYSTEMLIB /system/bin/toolbox chcon -h u:object_r:system_file:s0 $1 1>/dev/null 2>/dev/null
chcon -h u:object_r:system_file:s0 $1 1>/dev/null 2>/dev/null
LD_LIBRARY_PATH=$SYSTEMLIB /system/bin/toybox chcon u:object_r:system_file:s0 $1 1>/dev/null 2>/dev/null
LD_LIBRARY_PATH=$SYSTEMLIB /system/toolbox chcon u:object_r:system_file:s0 $1 1>/dev/null 2>/dev/null
LD_LIBRARY_PATH=$SYSTEMLIB /system/bin/toolbox chcon u:object_r:system_file:s0 $1 1>/dev/null 2>/dev/null
chcon u:object_r:system_file:s0 $1 1>/dev/null 2>/dev/null
}
ch_con_ext() {
LD_LIBRARY_PATH=$SYSTEMLIB /system/bin/toybox chcon $2 $1 1>/dev/null 2>/dev/null
LD_LIBRARY_PATH=$SYSTEMLIB /system/toolbox chcon $2 $1 1>/dev/null 2>/dev/null
LD_LIBRARY_PATH=$SYSTEMLIB /system/bin/toolbox chcon $2 $1 1>/dev/null 2>/dev/null
chcon $2 $1 1>/dev/null 2>/dev/null
}
Thanks for the quick response. I have attempted to copy some of the files stated in excerpt to my system image but it seems that I might have missed a few. But I see it stating some chcon commands so I'm just wondering if it'd be possible to chcon the files needed on a linux pc and have it work.
Bythos73 said:
Thanks for the quick response. I have attempted to copy some of the files stated in excerpt to my system image but it seems that I might have missed a few. But I see it stating some chcon commands so I'm just wondering if it'd be possible to chcon the files needed on a linux pc and have it work.
Click to expand...
Click to collapse
I'm not sure what will happen if you run those chcon commands, what happened when you tried it?
Yup, this manual way may be a bit tricky
http://su.chainfire.eu/#embed said:
6. Embedding
6.1. Files
All the files you need are in the latest SuperSU flashable ZIP. The latest 'stable' build can always be retrieved from my server, for the latest 'beta' release you need to check the beta thread in the SuperSU forums.
The installation script inside the ZIP is META-INF/com/google/android/update-binary. This is not a binary as the name suggests, but a shell script, and the standard update ZIP's updater-script file is just a dummy.
This script has comments which document which files go where on which API level, and what their file permissions, ownerhips, and security labels must be. If you have done this exactly right, SuperSU will not complain when you open the app after booting.
6.2. Custom ROMs
It is non-trivial to include SuperSU exactly right on your own. It is therefore often easiest to include the latest SuperSU ZIP inside your own flashable ZIP, and chain its installation.
Click to expand...
Click to collapse
Can you tell us a bit more about your device model & android version, and which files you copied/commands you ran so far?
What errors if any do you get after flashing your modified img?
I secretly hope a custom recovery exists for your device, or porting one proves easier :fingers-crossed:
I'm repacking the image now using img2simg for my first boot attempt.
I have an Alcatel 3 5052A, Device CodeName A3A running Android Oreo 8.1.0. So far I don't believe I can get a custom recovery for this device as the line of devices that this phone was released with seem to have a bootloader which doesn't boot unsigned images, nevermind the fact that it's impossible to flash any partition other than system through fastboot. It's a real pain. Thankfully it does boot GSIs like Phh-Treble so not all hope is lost on that front.
I've copied the su and supolicy binaries, I got daemonsu by copying the su bin, I also copied the SuperSU apk and the libsupol.so library into all of their respective directories.
It has booted but no su, and SuperSU was not in the Launcher so I'm gonna retry it.
Don't give up! there are lots of avenues yet to explore if you want to give the manual method a rest for a while.
What do you get when you try unlocking the bootloader from fastboot?
Are you familiar with SP Flash tools? This is an alternative way to flash images onto various MTK devices.

[xperia 1/5] temp root exploit via CVE-2020-0041 including magisk setup

temp root exploit for sony XPERIA 1 and XPERIA 5 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.
This is a modification of the Pixel 3 specific exploit to be compatible with kernel 4.14 that is used with xperia 1/5 phones.
This work has been done in collaboration with @bb-qq, who has implemented support of JP model of xperia 1.
The exploit is extended in a way allowing setup of magisk v20.4 from the temp root, including working su permission asking notification support.
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 android service.
There are also many extensions implemented to make the exploit stable with kernel 4.14.
SUPPORTED TARGETS
802SO-55.1.B.0.202 (xperia 1 Japan model)
J8110-55.1.A.0.748 (xperia 1 single sim)
J8170-55.1.A.0.748 (xperia 1 US model)
J9110-55.1.A.0.748 (xperia 1 dual sim)
J9110-55.1.A.3.107 (xperia 1 dual sim)
J9150-55.1.A.3.107 (xperia 1 Japan dual sim)
J9180-55.1.A.0.748 (xperia 1 China model)
J9180-55.1.A.3.107 (xperia 1 China model)
J8210-55.1.A.0.748 (xperia 5 single sim)
J9210-55.1.A.0.748 (xperia 5 dual sim)
J9210-55.1.A.3.112 (xperia 5 dual sim)
The exploit has been tested only with the JP model of xperia 1 (the 802SO-55.1.B.0.202 target), but support for other targets have been implemented based on static 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 x1x5-mroot.zip with the exploit attached in this post
download Magisk-v20.4.zip from magisk releases page on github here
use 'adb push x1x5-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 x1x5-mroot.zip
chmod 755 x1x5-mroot magisk-setup.sh magisk-start.sh
./magisk-setup.sh
get temp root and start magisk up with following commands in 'adb shell' - do not copy paste them all at once, but enter (or copy&paste) each line separately one by one:
Code:
cd /data/local/tmp
./x1x5-mroot
./magisk-start.sh -1
./magisk-start.sh -2
./magisk-start.sh -3
If it worked, you should see something like this:
Code:
802SO:/ $ cd /data/local/tmp
802SO:/data/local/tmp $ ./x1x5-mroot
[+] factoryversion = '802SO-55.1.B.0.202'
[+] Mapped 200000
[+] selinux_enforcing before exploit: 1
[+] pipe file: 0xffffffe5cd6e3b00
[+] file epitem at ffffffe54d87eb00
[+] Reallocating content of 'write8_inode' with controlled data..[DONE]
[+] Overwriting 0xffffffe5cd6e3b20 with 0xffffffe54d87eb50...[DONE]
[+] Write done, should have arbitrary read now.
[+] file operations: ffffff90392212d0
[+] kernel base: ffffff9037e80000
[+] init_cred: ffffff903a02d808
[+] memstart_addr: 0xffffffdbc0000000
[+] First level entry: 145437003 -> next table at ffffffe585437000
[+] Second level entry: 1e6b41003 -> next table at ffffffe626b41000
[+] sysctl_table_root = ffffff903a05d380
[+] Reallocating content of 'write8_sysctl' with controlled data.[DONE]
[+] Overwriting 0xffffffe6352bcb68 with 0xffffffe54b8a3000...[DONE]
[+] Injected sysctl node!
[+] Reallocating content of 'write8_selinux' with controlled data.[DONE]
[+] Overwriting 0xffffff903a772ffc with 0x0...[DONE]
[+] Node write8_inode, pid 10824, kaddr ffffffe4e3d18c00
[+] Replaced sendmmsg dangling reference
[+] Replaced sendmmsg dangling reference
[+] Node write8_selinux, pid 11452, kaddr ffffffe58324c400
[+] Replaced sendmmsg dangling reference
[+] Replaced sendmmsg dangling reference
[+] Node write8_sysctl, pid 11338, kaddr ffffffe4e3c05980
[+] Replaced sendmmsg dangling reference
[+] Replaced sendmmsg dangling reference
[+] Cleaned up sendmsg threads
[+] epitem.next = ffffffe5cd6e3b20
[+] epitem.prev = ffffffe5cd6e3bd0
[+] Launching privileged shell
root_by_cve-2020-0041:/data/local/tmp # ./magisk-start.sh -1
+ FRESH=false
+ '[' -1 '=' --fresh ']'
+ '[' ! -e /data/adb/magisk/busybox ']'
+ FRESH=true
+ ./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 ']'
+ FRESH=true
+ 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
+ true
+ rm -rf /data/adb/magisk.db /data/adb/magisk
+ mkdir -p /data/adb/magisk
+ chmod 700 /data/adb
+ cp -a busybox /data/adb/magisk
+ cp -a magisk /data/adb/magisk
+ cp -a magiskboot /data/adb/magisk
+ cp -a magiskinit /data/adb/magisk
+ cp -a util_functions.sh /data/adb/magisk
+ cp -a boot_patch.sh /data/adb/magisk
+ chmod -R 755 /data/adb/magisk
+ chown -R root:root /data/adb/magisk
+ 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=14100
+ '[' -z 14100 ']'
+ >/sbin/.magisk/escalate
+ echo 14100
+ '[' -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=14131
+ '[' -n 14131 ']'
+ 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.14.117-perf+ #1 SMP PREEMPT Wed Jan 15 23:36:28 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 should work now.
Please be sure to use 'exit' command to cleanly end the temp root shell. Do not close the window instead. It is needed for proper cleanup.
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.
DRM KEY / TA PARTITION BACKUP POSSIBILITY
Please note, this exploit will get you a root shell with still locked xperia 1 and 5 phones that could allow to backup TA partition in still locked state, having drm keys (the device key) still there.
Even though xperia 1 and 5 allows to relock bootloader after unlock, possibly returning drm functionalities, it is very probable that a device key (device specific drm key residing in 66667 ta unit) is still erased on bootloader unlock (and re-lock), so backing up and restoring TA with the key present may actually be useful.
This is something to be tested - anybody considering bootloader unlock of xperia 1 or 5, please be sure to backup TA from still locked state via this exploit and also TA after unlock for comparison.
For more details see here and following post.
SOURCES
Exploit sources are available at my github here.
CREDITS
Big thanks to Blue Frost Security for the excellent writeup and the exploit itself.
Thanks to @bb-qq for initial xperia 1 support and testing.
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
reserved
factoryversion = '802SO-55.1.B.0.300'
target is not supported.
Testr=ed yesterday on J9210-55.1.A.0.748
But had to enter these
cd /data/local/tmp
./x1x5-mroot
./magisk-start.sh -1
./magisk-start.sh -2
./magisk-start.sh -3
Click to expand...
Click to collapse
with an interval of several seconds to avoid reboot
@Coolty, you need to run one of the listed firmware versions in order for the exploit to work. You may need to downgrade.
@nos1609, yes, it may be like that. You should enter (or copy&paste) each line separatelly one by one, not all of them at once to have it more stable. It does not work from a script or pasted as a block of commands.
Also be sure to use 'exit' command to end the temp root shell. Do not just close the adb shell window without using the 'exit' command. The 'exit' command is needed to finish proper cleanup after the exploit.
You can disconnect from usb after terminating adb shell with 'exit' command, do not disconnect before exiting it.
@j4nn boss xperia 10 please it is the only new model of xperia that hasn't had temp root yet
@nitrams, xperia 10 kernel is not vulnerable to CVE-2019-2215, at least the two kernel source packages (53.1.A.2.2 and 53.0.A.2.139) released by sony contain the fix for it.
These two kernels are not vulnerable to CVE-2020-0041 either.
j4nn said:
@nitrams, xperia 10 kernel is not vulnerable to CVE-2019-2215, at least the two kernel source packages (53.1.A.2.2 and 53.0.A.2.139) released by sony contain the fix for it.
These two kernels are not vulnerable to CVE-2020-0041 either.
Click to expand...
Click to collapse
If i can flash back to older build like android 9 53.0.A.14.47 is there a possibility?
@nitrams, I have no idea how it is with other fw versions or other possible vulnerabilities. Sources are released only for the two I have mentioned above (and one of them is even corrupted, so it cannot be fully unpacked). I would assume that 53.0.A.2.139 is android 9.
Thank you for publishing this!
Here is all FTFs for Japanese models:
https://ftf.andro.plus/
any possible use CVE-2020-0041 exploit temp root for mi10pro?
@aolaol, you need to check kernel source to see if or which kernel is vulnerable first.
See The patch overview here:
https://www.synacktiv.com/en/publications/binder-analysis-and-exploitation-of-cve-2020-0041.html
This is great. But a functional twrp would be amazing
@TrustAugustus, with a functional twrp it would not be a temp root any more, would be?
Just backup TA partition and then unlock the bootloader.
You can re-lock with xperia 1/5 if you need.
After re-lock, use the temp root again and restore the locked state TA backup.
j4nn said:
@aolaol, you need to check kernel source to see if or which kernel is vulnerable first.
See The patch overview here:
https://www.synacktiv.com/en/publications/binder-analysis-and-exploitation-of-cve-2020-0041.html
Click to expand...
Click to collapse
Do you want to develop it for mi10pro
can anyone report this as 100% working and when relocking the bootloader and restoring the TA, does the phone go back completely to manufacturer state?
j4nn said:
Just backup TA partition and then unlock the bootloader.
You can re-lock with xperia 1/5 if you need.
After re-lock, use the temp root again and restore the locked state TA backup.
Click to expand...
Click to collapse
Could you please give me a hint how to backup the TA area, preferably from the command line ?
Regards,
RV.
Dear folks,
lack of some precise details of using this method ...
Can somebody please tell me the exact procedure to do after the
Code:
cd /data/local/tmp
unzip x1x5-mroot.zip
chmod 755 x1x5-mroot magisk-setup.sh magisk-start.sh
./magisk-setup.sh
just to avoid painfil errors ...?
I have all my prerequisites together and I'm on J9210-55.1.A.3.112 stock, bootloader locked.
1. After the magisk-setup.sh has finished, can/should I directly proceed in the same adb shell with
Code:
./x1x5-mroot
./magisk-start.sh -1
./magisk-start.sh -2
./magisk-start.sh -3
?
2. Where to enter the "su" ?
3. I want to install some apps that require root (titanium backup, greenify, afwall+ ...). Using the proposed method, at what point and in which way am I able to do so?
4. I want to backup the TA with the script by devshaft. Can I do this when the temp root shell is still open ?
The section od Post 1 that confuses me most is
j4nn said:
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 should work now.
Please be sure to use 'exit' command to cleanly end the temp root shell. Do not close the window instead. It is needed for proper cleanup.
Click to expand...
Click to collapse
Best regards,
RV.
Okay, Update:
I followed the steps from post 1 an am stuck now.
Everything went okay regarding the run of the scripts, then I typed "exit" in tthe adb shell. Now my phone is dead after getting slower and slower over a minute.
Some hints what to do ?
Edit: After hard reset (volume up + power few seconds) and a second run now all works fine.
Thanks for support.
Okay, a few last questions:
I was able to install apps that need root. What to do if an app needs permanent root ? Is there a way with the magisk manager ?

Categories

Resources