Database Info

[Resolved] HANNSpree HSG1279 root and recovery!!! [Updated 01/28/14]

Updated OP with solution, many thanks to @fipsy for the final solution, here is his post for those that need help rooting this device: (UPDATE: Root for 4.2.2 at the end of the post)
fipsy said:
Last week I investigated a lot of days to solve the problem: (I'm sorry for not being able to post working links in this forum because I didn't write enough here. So you have to reconstruct my links yourself into your browser)
As omegadrive supposed you just have to exchange the su binary, give the right permissions and the Superuser App from the Playstore will immediately work.
The necessary USB drivers for the device are found here: http://yadi.sk/d/54lX5c2O386XU
They only work with Windows 7!
After starting the "adb shell" you can gain root permissions on the device by typing "su". The su distributed with the device in /system/xbin is not compatible with common superuser apks. So it has to be exchanged with the version 3.1.1 binary: http://downloads.androidsu.com/superuser/su-bin-3.1.1-arm-signed.zip
Copy it to your /sdcard. Then continue with adb shell:
Code:
$ su
# cd /system/xbin
Mount the system partition read/write:
Code:
# mount -o remount,rw -t rfs /dev/block/st19 /system
Rename the original binary for later use (if something fails):
Code:
# mv su su-orig
Copy the binary to the xbin folder:
Code:
# busybox cp /sdcard/su ./su
Change the permissions:
Code:
# chmod 6755 su
Mount the system partition read-only and exit:
Code:
# mount -o remount,ro -t rfs /dev/block/st19 /system
# exit
$ exit
Now install the Superuser App from the Playstore - and have fun! Do *NOT* Update the su binary from within the Superuser App or it will be overwritten with a non-working version!
Cheers, Volker
Click to expand...
Click to collapse
CUSTOM RECOVERY FINALLY POSSIBLE!!! Again, many thanks to @fipsy, here is his post:
fipsy said:
I finally made it! :laugh: Here is a working CWM Recovery for the HANNspree HANNSpad SN1AT71 (HSG1279).
I didn't fully test it but the backup function works. Also mounting and unmounting partitions works as well as the adb shell which is very important if the device is bricked and doesn't boot anymore.
Before connecting to the device via adb shell it is necessary to mount the /system partition (menu "mounts and storage") because otherwise /system/bin/sh cannot be found by adb shell.
The CWM recovery by default stores it's backups on the external SD-Card. The benefit is that the backup can easily be plugged out and stored apart from the device. But the recovery is also able to restore backups from the internal sdcard. Those backups can be made online on a running android system by using apps like "Online Nandroid Backup" and "Nandroid Manager". The benefit is that it's not necessary to reboot the device before backing up and you can keep on working.
There is one problem when creating backups in CWM Recovery: The date/time of the backup is always set to 1st of January 1970 due to a missing backup battery in this device. Look here: http://tau.shadowchild.nl/attn1/?p=341. So if you want to make backups with accurate timestamps you would have to set the actual time of the device using adb shell: Start adb shell and enter:
Code:
/system/xbin/busybox date -s "YYYY-MM-DD hh:mm:ss"
before making the backup.
To cut a long story short: Download the CWM-Recovery here: http://yadi.sk/d/ArprqzfFFWvy4 and flash it to your (rooted) device. How to do this:
Copy the file cwm-recovery.ima to your internal sdcard.
Either connect via adb shell and enter su
or run a Terminal Emulator and enter su
then enter
Code:
cat /sdcard/cwm-recovery.ima > /dev/block/acta
and you're done! Have fun! Comments are appreciated!
Perhaps someone likes to create an update.zip from it?
Edit (01/28/2014): There is a new version 6.0.3.3. Look here: http://forum.xda-developers.com/showpost.php?p=49835135&postcount=283
Edit (05/04/2014): There is a new version 6.0.3.3.a. Look here: http://forum.xda-developers.com/showpost.php?p=52416205&postcount=492
Click to expand...
Click to collapse
ROOT for new OTA 4.2.2 update:
fipsy said:
Good news for germany: The rollout began tonight! I just got the update to Android 4.2.2! :laugh:
Some people asked for the upgrade file to manually update from the recovery. Here it is: http://yadi.sk/d/igsBGsAjFpLsL
Edit (01/13/2014): Seems this update only works on devices with special G-Sensor hardware (KIONIX 3-axis Accelerometer).
@ig6677: There you will also find the META-INF you wanted.
For your information: After my update to Android 4.2.2 root has gone on my device! I expected this. All Apps that need root don't work anymore. I don't know what you did that root was still there after the update...
Furthermore in /system/xbin there is no su file anymore. Also my CWM Recovery has gone and was replaced by the Stock HANNspree recovery!
But whats new: If you connect to the device via adb shell you immediately have superuser rights! No su is needed for this anymore. So it's possible to restore the CWM Recovery using cat.
If you adb push the 3.1.1 su binary from your pc to the /sdcard on your device and after this execute my commands in the first posting of this thread the apps have su rights with superuser.apk again. But you will not be able to add new programs to the superuser app (if a new app requests superuser rights there is no popup). So this is no solution.
The Superuser App is not able to grant superuser rights on android systems > 4.1.1, but the App SuperSu is! So download the SuperSU ZIP from here: http://download.chainfire.eu/351/SuperSU/UPDATE-SuperSU-v1.65.zip
Then copy it to your sdcard and install it using the Recovery. Voila! Everything works again!
Another issue: The Huawei E1750 Surfstick is not detected anymore. On 4.1.1 it was no problem to surf using this stick. But I think this is one of the "great features" of the new android versions...
Click to expand...
Click to collapse
New recovery version!
fipsy said:
:victory: Here it is: The new version 6.0.3.3 of CWM Recovery for the HANNspree HANNSpad SN1AT71 (HSG1279)
Beside some minor bugfixes the main benefit of this release is that there are no more errors when trying to restore the .android_secure folder. So the "dirty" workaround to restore this folder is not necessary anymore.
The .android_secure folder is also automatically restored together with the data partition when selecting "data" from the "advanced restore" options.
http://yadi.sk/d/OmsYk6TIGsBsB
Information on how to install you will find here: http://forum.xda-developers.com/showpost.php?p=49166546&postcount=133
Cheers, Volker
Click to expand...
Click to collapse
My original question:
Just bought this tablet on Cybermonday for a really good price, but can't find a way to root it for the life of me...
Main problem has been I can't see it using ADB (v1.0.31), always list no devices even with the latest generic Google ADB driver, which shows fine on device manager.
Tablet comes with Android 4.1.1 and no extras, is just a plain version of android with Play market and ES File Explorer pre installed and have access to android stock recovery.
Any ideas?
Also, just in case I start messing with the tablet, Any way I can backup the stock system just in case?
Thanks.
Update:
More info on the tablet...
Model name: SN1AT71
Hardware (According to CPU-Z): gs702a
Board: full_gs702a
Click to expand...
Click to collapse

Omegadrive said:
Just bought this tablet on Cybermonday for a really good price, but can't find a way to root it for the life of me...
Main problem has been I can't see it using ADB (v1.0.31), always list no devices even with the latest generic Google ADB driver, which shows fine on device manager.
Tablet comes with Android 4.1.1 and no extras, is just a plain version of android with Play market and ES File Explorer pre installed and have access to android stock recovery.
Any ideas?
Also, just in case I start messing with the tablet, Any way I can backup the stock system just in case?
Thanks.
Update 1:
More info on the tablet...
Model name: SN1AT71
Hardware (According to CPU-Z): gs702a
Board: full_gs702a
Click to expand...
Click to collapse
Update 2:
Found that this tablet is practically the same as the Ainol Novo 10 Hero (don't know if version 1 or 2 thou)
So looking in Google found a thread that has modded ADB drivers and following the instructions managed to get ADB to find the device.
Now to keep experimenting

Omegadrive said:
Update 2:
Found that this tablet is practically the same as the Ainol Novo 10 Hero (don't know if version 1 or 2 thou)
So looking in Google found a thread that has modded ADB drivers and following the instructions managed to get ADB to find the device.
Now to keep experimenting
Click to expand...
Click to collapse
Update 3:
After trying over 20 generic rooting methods I come back defeated, 6 hours of testing and nothing. :crying:

I also have picked up 2 of these devices (1 for me and 1 for my wife). I have tried every method I can find to root this, inclicking mutliple one click solutions, apps that are suposted to root, etc. and none of them seem to work, I think the reason why is because the device is being reconized as allready being rooted, SuperOneClick, Framaroot, and Kingo all stated that it was allready rooted ..but apps will not install as if the device was truly rooted. Also geting "access denied" when trying to access the root folder..
Applications that require root will install because they think it has root, they also will prompt stating to give root access/permissions, but when accepting, they simply lock up because they can't access the root correctly.
anyways, I'm done trying for now.. if anyone has any other ideas, please speak up and let us know. thanks!

also have one of these
Temil2006 said:
I also have picked up 2 of these devices (1 for me and 1 for my wife). I have tried every method I can find to root this, inclicking mutliple one click solutions, apps that are suposted to root, etc. and none of them seem to work, I think the reason why is because the device is being reconized as allready being rooted, SuperOneClick, Framaroot, and Kingo all stated that it was allready rooted ..but apps will not install as if the device was truly rooted. Also geting "access denied" when trying to access the root folder..
Applications that require root will install because they think it has root, they also will prompt stating to give root access/permissions, but when accepting, they simply lock up because they can't access the root correctly.
anyways, I'm done trying for now.. if anyone has any other ideas, please speak up and let us know. thanks!
Click to expand...
Click to collapse
I picked up one of these also, I tried a few of the rooting methods you guys listed before finding this post. also no sucess, Would love to get this working bit better,because stock rom is a bit sluggish when it shouldn't be given the specs.

OK, kept trying and found some interesting stuff, first of all a screenshot with the tablet info:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Second, it seems the tablet is already rooted but the root is just dummy or the interface has been disabled with deny set as default for any application.
So the trick to root it must be a way to replace de su binary or change the default permission to allow.
Any experts have any idea how to achieve this?
Sent from my HSG1279 using xda app-developers app

I thought about buying this Tab. But if there is no working root-methode or costumROM ability thats a dealbreaker for me.
You told that this tab should be identical to the "Ainol Novo 10 Hero". I dont know if that is true, because in one forum some guy told, that the HannSpee is chargeable via the USB-Port, and afaik the Ainol is not. You have the Hannspee, can you tell me if it is chargeable via USB ?
Anyway, on the german Amazon-site there is a guy that claims that costum-ROMs are working on the Ainol
I will ask him how he managed that and perhaps you can try that on you device. But I dont know if he answers, because responds on Amazon-rewievs are not like those in forums (often never answered)
hope some nerd comes up with a nice plan to break into this device......non-rooted devices are s**t!
greetz gerd
Omegadrive said:
OK, kept trying and found some interesting stuff, first of all a screenshot with the tablet info:
Second, it seems the tablet is already rooted but the root is just dummy or the interface has been disabled with deny set as default for any application.
So the trick to root it must be a way to replace de su binary or change the default permission to allow.
Any experts have any idea how to achieve this?
Sent from my HSG1279 using xda app-developers app
Click to expand...
Click to collapse

revnu said:
I thought about buying this Tab. But if there is no working root-methode or costumROM ability thats a dealbreaker for me.
You told that this tab should be identical to the "Ainol Novo 10 Hero". I dont know if that is true, because in one forum some guy told, that the HannSpee is chargeable via the USB-Port, and afaik the Ainol is not. You have the Hannspee, can you tell me if it is chargeable via USB ?
Anyway, on the german Amazon-site there is a guy that claims that costum-ROMs are working on the Ainol
I will ask him how he managed that and perhaps you can try that on you device. But I dont know if he answers, because responds on Amazon-rewievs are not like those in forums (often never answered)
hope some nerd comes up with a nice plan to break into this device......non-rooted devices are s**t!
greetz gerd
Click to expand...
Click to collapse
Well, I deduced it was identical to the Ainol Novo cause at least the hardware specs are identical and the board and CPU are reported by CPU - Z to be the same one. Tablet layout is a little different thou.
Anyway yes, this one charges through the USB port, but really slowly, good enough to have the USB connected while using it and will not drain the battery, but on my last test it barely charged 5% in 3 to 4 hours of while using it.
Crossing my fingers you can get in contact with that guy and we can figure out how to root this ****er lol
Sent from my XT910 using Tapatalk

Omegadrive said:
Well, I deduced it was identical to the Ainol Novo cause at least the hardware specs are identical and the board and CPU are reported by CPU - Z to be the same one. Tablet layout is a little different thou.
Anyway yes, this one charges through the USB port, but really slowly, good enough to have the USB connected while using it and will not drain the battery, but on my last test it barely charged 5% in 3 to 4 hours of while using it.
Crossing my fingers you can get in contact with that guy and we can figure out how to root this ****er lol
Sent from my XT910 using Tapatalk
Click to expand...
Click to collapse
He answered me, that his Hero came rooted when he bought it and that he simply had to install CWM. He posted a link with iinstructions but I bet it wont help, because the HANNSpree cames with kind of a fakeroot.

revnu said:
He answered me, that his Hero came rooted when he bought it and that he simply had to install CWM. He posted a link with iinstructions but I bet it wont help, because the HANNSpree cames with kind of a fakeroot.
Click to expand...
Click to collapse
Unfortunately it didn't worked, kept failing at validating files when it was installing from default recovery.
Anyway, going to try another method, these are the steps I followed:
1) Get ADB working and recognized.
a) Download these modded drivers and extract them.
b) Do this to install them since the drivers are not signed:
run CMD as admin
bcdedit -set TESTSIGNING ON
reboot
install driver from device manager
bcdedit -set TESTSIGNING OFF
reboot
c) Go to %userprofile%\.android folder and if it doesn't exist create a text file named "adb_usb.ini" (no quotes and make sure INI is the extension, not TXT), open it and just add "0x10D6" (no quotes), save it
d) open CMD as admin
adb devices
Your device should be recognized at this point, this is what I got:
C:\>adb devices
List of devices attached
0123456789ABCDEF device
2) Will update post with new findings here...

How to root the device
Last week I investigated a lot of days to solve the problem: (I'm sorry for not being able to post working links in this forum because I didn't write enough here. So you have to reconstruct my links yourself into your browser)
As omegadrive supposed you just have to exchange the su binary, give the right permissions and the Superuser App from the Playstore will immediately work.
The necessary USB drivers for the device are found here: http: //yadi.sk/d/54lX5c2O386XU
They only work with Windows 7!
After starting the "adb shell" you can gain root permissions on the device by typing "su". The su distributed with the device in /system/xbin is not compatible with common superuser apks. So it has to be exchanged with the version 3.1.1 binary: http: //downloads.androidsu.com/superuser/su-bin-3.1.1-arm-signed.zip
Copy it to your /sdcard. Then continue with adb shell:
Code:
$ su
# cd /system/xbin
Mount the system partition read/write:
Code:
# mount -o remount,rw -t rfs /dev/block/st19 /system
Rename the original binary for later use (if something fails):
Code:
# mv su su-orig
Copy the binary to the xbin folder:
Code:
# busybox cp /sdcard/su ./su
Change the permissions:
Code:
# chmod 6755 su
Mount the system partition read-only and exit:
Code:
# mount -o remount,ro -t rfs /dev/block/st19 /system
# exit
$ exit
Now install the Superuser App from the Playstore - and have fun! Do *NOT* Update the su binary from within the Superuser App or it will be overwritten with a non-working version!
Cheers, Volker

Omegadrive said:
Unfortunately it didn't worked, kept failing at validating files when it was installing from default recovery.
Anyway, going to try another method, these are the steps I followed:
1) Get ADB working and recognized.
a) Download modded drivers and extract them.
b) Do this to install them since the drivers are not signed:
run CMD as admin
bcdedit -set TESTSIGNING ON
reboot
install driver from device manager
bcdedit -set TESTSIGNING OFF
reboot
c) Go to %userprofile%\.android folder and if it doesn't exist create a text file named "adb_usb.ini" (no quotes and make sure INI is the extension, not TXT), open it and just add "0x10D6" (no quotes), save it
d) open CMD as admin
adb devices
Your device should be recognized at this point, this is what I got:
C:\>adb devices
List of devices attached
0123456789ABCDEF device
2) Will update post with new findings here...
Click to expand...
Click to collapse
umm, instead of using custom drivers, why not simply use the newest android Drivers? confirmed they work and device is reconized correctly, as long as you "install official droid drivers" then change the "adb_usb.ini" to only include 0x10D6 device, same as your last steps, but using official drivers, instead of custom ones. Maybe it has something to do with the failures?
---------- Post added at 08:00 PM ---------- Previous post was at 07:53 PM ----------
fipsy said:
Last week I investigated a lot of days to solve the problem: (I'm sorry for not being able to post working links in this forum because I didn't write enough here. So you have to reconstruct my links yourself into your browser)
As omegadrive supposed you just have to exchange the su binary, give the right permissions and the Superuser App from the Playstore will immediately work.
The necessary USB drivers for the device are found here: http: //yadi.sk/d/54lX5c2O386XU
They only work with Windows 7!
After starting the "adb shell" you can gain root permissions on the device by typing "su". The su distributed with the device in /system/xbin is not compatible with common superuser apks. So it has to be exchanged with the version 3.1.1 binary: http: //downloads.androidsu.com/superuser/su-bin-3.1.1-arm-signed.zip
Copy it to your /sdcard. Then continue with adb shell:
Code:
$ su
# cd /system/xbin
Mount the system partition read/write:
Code:
# mount -o remount,rw -t rfs /dev/block/st19 /system
Rename the original binary for later use (if something fails):
Code:
# mv su su-orig
Copy the binary to the xbin folder:
Code:
# busybox cp /sdcard/su ./su
Change the permissions:
Code:
# chmod 6755 su
Mount the system partition read-only and exit:
Code:
# mount -o remount,ro -t rfs /dev/block/st19 /system
# exit
$ exit
Now install the Superuser App from the Playstore - and have fun! Do *NOT* Update the su binary from within the Superuser App or it will be overwritten with a non-working version!
Cheers, Volker
Click to expand...
Click to collapse
thanks for this info. I'll test it out tonight, and let you know.
one question though.. so are you saying that future updates of SU will not work? if we do this, should we also disable auto-updates? If the software does update, will it break our system.. or simply that we need to reload the SU over again, but the OS will open, just limited to "non-rooted" ? ??

fipsy said:
Last week I investigated a lot of days to solve the problem: (I'm sorry for not being able to post working links in this forum because I didn't write enough here. So you have to reconstruct my links yourself into your browser)
As omegadrive supposed you just have to exchange the su binary, give the right permissions and the Superuser App from the Playstore will immediately work.
The necessary USB drivers for the device are found here: http: //yadi.sk/d/54lX5c2O386XU
They only work with Windows 7!
After starting the "adb shell" you can gain root permissions on the device by typing "su". The su distributed with the device in /system/xbin is not compatible with common superuser apks. So it has to be exchanged with the version 3.1.1 binary: http: //downloads.androidsu.com/superuser/su-bin-3.1.1-arm-signed.zip
Copy it to your /sdcard. Then continue with adb shell:
Code:
$ su
# cd /system/xbin
Mount the system partition read/write:
Code:
# mount -o remount,rw -t rfs /dev/block/st19 /system
Rename the original binary for later use (if something fails):
Code:
# mv su su-orig
Copy the binary to the xbin folder:
Code:
# busybox cp /sdcard/su ./su
Change the permissions:
Code:
# chmod 6755 su
Mount the system partition read-only and exit:
Code:
# mount -o remount,ro -t rfs /dev/block/st19 /system
# exit
$ exit
Now install the Superuser App from the Playstore - and have fun! Do *NOT* Update the su binary from within the Superuser App or it will be overwritten with a non-working version!
Cheers, Volker
Click to expand...
Click to collapse
OMG!!! IT WORKED!!!
MANY THANKS!!!
Now have full root privileges woot!!! Tested with Titanium backup and ES File explorer they accepted root and got permission prompts :highfive:
I will update the OP with your instructions, they worked beautifully, MANY THANKS AGAIN!!!
Btw, Do you have any idea on which custom recovery may work and if the bootloader can be unlocked? (if it is locked, I can't see anything when booting into fastboot mode and Windows doesn't recognize the tablet at that moment, only shows unknown device)
I want to make a backup of the stock rom and start testing CM builds on it.

Temil2006 said:
umm, instead of using custom drivers, why not simply use the newest android Drivers? confirmed they work and device is reconized correctly, as long as you "install official droid drivers" then change the "adb_usb.ini" to only include 0x10D6 device, same as your last steps, but using official drivers, instead of custom ones. Maybe it has something to do with the failures?
Click to expand...
Click to collapse
The original Android drivers never worked for me, used latest version 8.0 and the device was not recognized for some reason, only the modded drivers worked to recognize the ADB device. Btw, I'm using Windows 8.1 Pro and had to turn off driver signature to get the ADB drivers installed, maybe the issue was Win8.1 itself, but oh well, at least now we have a solution. :laugh:

fipsy said:
Do *NOT* Update the su binary from within the Superuser App or it will be overwritten with a non-working version!
Cheers, Volker
Click to expand...
Click to collapse
Update: After giving permissions with Superuser I went ahead and installed my SuperSU Pro license, gave it root rights (told it NOT to uninstall the other root app on prompt) and installed as a system app from within the app itself, reboot and voila! still fully rooted and binary updated (it replaced the other Superuser on reboot). So yeah, su binary updates are possible now :victory:

is there any custom recovery to install on this tablet?

Temil2006 said:
umm, instead of using custom drivers, why not simply use the newest android Drivers?
Click to expand...
Click to collapse
This also was my first attempt but it failed. So I went the same way as Omegadrive did: I identified the device as a clone of the "Ainol Novo 10 Hero" and searched for appropriate drivers. I found the same ones as Omegadrive did. And they seem to be the only ones that are working.
Temil2006 said:
one question though.. so are you saying that future updates of SU will not work? if we do this, should we also disable auto-updates? If the software does update, will it break our system.. or simply that we need to reload the SU over again, but the OS will open, just limited to "non-rooted" ? ??
Click to expand...
Click to collapse
I don't know if future binaries will work. When I manually updated the su-binary within the Superuser App it definitely didn't work anymore. Maybe because the su was exchanged with an older version (3.0.*). But Omegadrive said that updates are possible. So I don't know at the moment. Be careful anyway! Normally there is no reason for updating fully working binaries. The su binary is never updated automatically. So you don't have to deactivate any auto-updates.
Cheers, Volker
---------- Post added at 03:34 AM ---------- Previous post was at 03:04 AM ----------
Omegadrive said:
Btw, Do you have any idea on which custom recovery may work and if the bootloader can be unlocked?
Click to expand...
Click to collapse
The recovery mode is activated by pressing "Volume down -" and at the same time pressing the on/off key for about 3 seconds. Then releasing it while keep on holding down the "Volume -" until the recovery menu appears.
I think it will be possible to adapt the CWM Recovery. Perhaps we can investigate together on that!? Here the recovery file system table (for nandroid etc.). I just sent it to Ameer Dawood, the developer of "Online Nandroid Backup", so that he may integrate it into his App.
recovery filesystem table
=========================
0 /tmp ramdisk (null) (null) 0
1 /mnt/sdcard vfat /dev/block/actj (null) 0
2 /system ext4 /dev/block/actc (null) 0
3 /cache ext4 /dev/block/acte (null) 0
4 /data ext4 /dev/block/actd (null) 0
5 /data_bak vfat /dev/block/actf (null) 0
6 /boot vfat /dev/block/actb (null) 0
7 /recovery vfat /dev/block/acta (null) 0
8 /misc emmc /dev/block/actb (null) 0
9 /mnt/sd-ext vfat /dev/block/mmcblk0p1 /dev/block/mmcblk0 0

Oh nice, thanks for the help, I'm no programmer, just a tinkerer, I'm willing to test anything you throw this way lol
My main priority right now is to make a backup of the current rom and then look for a way to repartition the /data cause 1Gb for apps is way too low, specially when there are 13Gb free on /sdcard, as want to make it 4Gb for /data and rest internal. I'm assuming I have to install custom recovery for that, or can ir be done right now from ADB?
Sent from my HSG1279 using Tapatalk

If you want to store parts of the filesystem (like /data/app, /data/app-private, /data/dalvik-cache and libs) to the sd-card you probably will have to install a custom rom like cyanogenmod which supports additional partitions / filesystems on the sd-card (like ext2).
But you're right. The first thing to do before making any experiments is to make a full backup (nandroid) and be able to restore it from a recovery. So we first should investigate on that...

I just installed the CWM recovery for the Ainol Novo 10 Hero 2 for testing. The device started into the CWM recovery screen but then failed to mount some folders. The menu was working but most features were not functional. This means that the HSG1279 is *not* fully compatible with the Ainol Hero 2.
So we have to find another solution. I suppose it will be quite a lot of work to adapt the CWM recovery to this device...

Dirty Cow

Just wondering if the new Dirty Cow exploit means all those previously unrootable phones can now (or very soon) be rooted.
http://www.cyberciti.biz/faq/dirtyc...local-privilege-escalation-vulnerability-fix/

kennonk said:
Just wondering if the new Dirty Cow exploit means all those previously unrootable phones can now (or very soon) be rooted.
http://www.cyberciti.biz/faq/dirtyc...local-privilege-escalation-vulnerability-fix/
Click to expand...
Click to collapse
Based upon the early research into this, YES it would appear that this also has widespread affect into the Android Linux Kernel
https://www.nowsecure.com/blog/2016/10/21/dirty-cow-vulnerability-mobile-impact/
https://www.theguardian.com/technol...ow-linux-vulnerability-found-after-nine-years
(Bottom of Article Google confirms Android is susceptible)
PoC Code which would probably need to be slightly refactored for use in Android, but still highly relevant
https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs

The bug affects the Android Linux kernel. I already tested it, and yes, you can change any file owned by root to whatever you want.
But that doesn't mean you can actually root the phone (that is, gain root access). Maybe it is possible, but I don't think is trivial. The thing is: you can modify root owned files, yes. But you need that some process owned by root executes your file, so you can gain root access. Editing init scripts won't work since they are recreated every time you boot your phone, and after the phone boots, as far as I know, nothing else is executed by root.
I don't mean that it can't be done, maybe there's some file that is executed by root after boot out there that you can modify, but I wouldn't know which one.

Scorpius666 said:
The thing is: you can modify root owned files, yes. But you need that some process owned by root executes your file, so you can gain root access.
Click to expand...
Click to collapse
Doesn't that mean you can install a custom su binary and just execute that as any user?

This exploit only allows you to replace the content of existing files with their existing mode/permissions, and the way su operates you need the setuid (set-user-ID) bit set in the mode, and from a brief look at the system I wanted to get root on, android doesn't seem to have any setuid binaries.
I'm thinking replacing something like wpa_supplicant could let us execute the payload as root, just disable and re-enable wifi, but I can't seem to get the exploit itself to work at the moment.
On further inspection (at least on this device), wpa_supplicant isn't readable by non-root (which I think the exploit requires). app_process is, but that's an executable I'd prefer not to mess with
Update:
Got the exploit itself working.
Tried replacing /system/bin/fsck_msdos's content to trigger it to be run as root by inserting a microSD card,
but something on this device (Amazon Fire 5th gen) keeps rebooting and restoring the system partition if any file is changed.

a___ said:
This exploit only allows you to replace the content of existing files
Click to expand...
Click to collapse
Not true. This code executes su as root, spawning a root shell. It can be modified to run a script that installs su in/system etc..
The counterside is that the kernel crashes/freezes after some seconds.
https://gist.github.com/scumjr/17d91f20f73157c722ba2aea702985d2
I'd like to port that to an apk using the ndk, but my pc is too old.

The /system partition is mounted read only by default. Because of this, you can't overwrite them. But I saw a exploit which used /sys/kernel/uevent_helper to execute a shell script as root. This would probably also work with the dirty cow exploit.

KillahKiwi said:
Doesn't that mean you can install a custom su binary and just execute that as any user?
Click to expand...
Click to collapse
You can't create a new file. You can modify an existing file. The su binary needs the setuid bit and there are no files in the Android filesystem with that bit set.
The only way to root a phone with this bug is to modify an executable that will change the owner of the su binary to root and set the setuid bit on this file. This part is trivial and very easy.
The difficult part is to find a binary that will be executed as root after you have booted. If somebody knows any file in /system/bin for example that will be executed as root doing some action on the phone tell me and the phone will be rooted in seconds.
---------- Post added at 11:32 AM ---------- Previous post was at 11:28 AM ----------
a___ said:
Got the exploit itself working.
Tried replacing /system/bin/fsck_msdos's content to trigger it to be run as root by inserting a microSD card,
but something on this device (Amazon Fire 5th gen) keeps rebooting and restoring the system partition if any file is changed.
Click to expand...
Click to collapse
I copied the su binary in /data/local/tmp. I can modify files in /system/bin for example and the phone does not reboot, but i don't have fsck_msdos in my phone.
---------- Post added at 11:35 AM ---------- Previous post was at 11:32 AM ----------
DP FH said:
Not true. This code executes su as root, spawning a root shell. It can be modified to run a script that installs su in/system etc..
The counterside is that the kernel crashes/freezes after some seconds.
https://gist.github.com/scumjr/17d91f20f73157c722ba2aea702985d2
I'd like to port that to an apk using the ndk, but my pc is too old.
Click to expand...
Click to collapse
I'm compiling on the phone using UXTerm, then apt install clang, and then using gcc. It's the quickest way to compile a single .c file on it.

Scorpius666 said:
. It's the quickest way to compile a single .c file on it.
Click to expand...
Click to collapse
I'd like to create a standard Android app that uses jni to run exploit and then roots the device. I can't test on my real phone because I need warranty and Knox counter to 0.

DP FH said:
Not true. This code executes su as root, spawning a root shell. It can be modified to run a script that installs su in/system etc..
The counterside is that the kernel crashes/freezes after some seconds.
https://gist.github.com/scumjr/17d91f20f73157c722ba2aea702985d2
I'd like to port that to an apk using the ndk, but my pc is too old.
Click to expand...
Click to collapse
At first try doesn't work for me:
Code:
[email protected]:/data/local/tmp $ ./dirtyc0w-mem b6dc0000 b6dc1000
[*] range: b6dc0000-b6dc1000]
[*] getuid = b6f79b18
[*] mmap 0xb6dd5000
[*] exploiting (patch)
./dirtyc0w-mem: failed to execute "su": Permission denied
[*] exploiting (unpatch)
[*] unpatched: uid=2000 (madviseThread)
[*] unpatched: uid=2000 (procselfmemThread)
But I'll modify a little bit to see if I can get it to work.

Scorpius666 said:
doesn't work for me.
Click to expand...
Click to collapse
I don't think you have su on the phone ????
By the way I'm trying to install some emulator on my pc so I can try

DP FH said:
I don't think you have su on the phone ????
By the way I'm trying to install some emulator on my pc so I can try
Click to expand...
Click to collapse
I do have the su, in /data/local/tmp, with users permission. The idea is to do a chown root:root and a chmod 4755.
But I know what the problem is. The SHELLCODE in the file is for x86, which seems to be a XOR AX, AX and a RET. I have to do the same for an ARM v7L in THUMB I think...

DP FH said:
Not true. This code executes su as root, spawning a root shell. It can be modified to run a script that installs su in/system etc..
The counterside is that the kernel crashes/freezes after some seconds.
<URL>
I'd like to port that to an apk using the ndk, but my pc is too old.
Click to expand...
Click to collapse
Well that assumes we have a setuid su already, this variant of the exploit won't help us.
julianwi said:
The /system partition is mounted read only by default. Because of this, you can't overwrite them. But I saw a exploit which used /sys/kernel/uevent_helper to execute a shell script as root. This would probably also work with the dirty cow exploit.
Click to expand...
Click to collapse
Somehow it did manage to overwrite it, but maybe the reboot and reset are caused by it being read-only and not actually writing the changes to persistent storage.
Will look into /sys/kernel/uevent_helper though, thanks
Scorpius666 said:
...
I copied the su binary in /data/local/tmp. I can modify files in /system/bin for example and the phone does not reboot, but i don't have fsck_msdos in my phone.
...
Click to expand...
Click to collapse
Just about any would work, you probably have some other fsck or mkfs utility you could do it with, then trying to format an SD card should run mkfs

a___ said:
Just about any would work, you probably have some other fsck or mkfs utility you could do it with, then trying to format an SD card should run mkfs
Click to expand...
Click to collapse
The thing is all my fsck* files are not readable, only by root, at least in my device. The exploit needs a readable file.

a___ said:
Well that assumes we have a setuid su already, this variant of the exploit won't help us
Click to expand...
Click to collapse
Nope. The su command is executed as root, and when you execute su as root it gives you a root shell. Try to execute sh instead of su.

DP FH said:
Nope. The su command is executed as root, and when you execute su as root it gives you a root shell. Try to execute sh instead of su.
Click to expand...
Click to collapse
No, it merely makes libc report that the user is root even though it isn't, it needs su to already have setuid to switch to the real root, and then running the shell. In this case (simplified) the exploit just bypasses the password prompt.

a___ said:
No, it merely makes libc report that the user is root even though it isn't, it needs su to already have setuid to switch to the real root, and then running the shell. In this case (simplified) the exploit just bypasses the password prompt.
Click to expand...
Click to collapse
I just noticed that. Using sh instead of su, the dirtycow-mem works in the phone and it spawns a shell, but with the same privileges than the user that executed it. So it's useless at least with that libc approach.

Scorpius666 said:
I just noticed that. Using sh instead of su, the dirtycow-mem works in the phone and it spawns a shell, but with the same privileges than the user that executed it. So it's useless at least with that libc approach.
Click to expand...
Click to collapse
Strange, on normal x86 works like a charm so something needs to be fixed

DP FH said:
Strange, on normal x86 works like a charm so something needs to be fixed
Click to expand...
Click to collapse
Of course it works on x86. If you read the code you'll see that it changes the function getuid() of libc (that is already loaded in memory) to return 0. The x86 su binary uses getuid() to know if it should ask for a password or not. Since getuid() is patched, it doesn't ask a password and spawn a root shell.
So basically for dirtycow-mem to work you need:
A su binary with setuid root
That su binary should ask for a password
The Android su binary doesn't ask for a password and doesn't have the setuid root so this exploit won't work.

hey there
did anyone try the dirtycow-vdso exploit? it works on SELinux (which AOSP uses) and doesn't require a SUID see
github . com/scumjr/dirtycow-vdso

[CLOSED][SCRIPT][LINUX] Mount System as read write (Android 10+)

This Linux-only version is pretty much deprecated at this point. Please use the BRAND NEW UNIVERSAL VERSION instead! Thank you.
Ladies and gentlemen. Let me present to you my very first release here at the XDA forums:
Welcome to:
makeSystemRW v1.04
automated bash script by lebigmac for Android 10 and above​Creation date: February 2021
Updated: March 2021
Requirements:​
LINUX ONLY!
Android 10 or newer
This version only supports devices with super image.
Check if you have super by running ls -Alg /dev/block/by-name
phone must be rooted + bootloader unlocked + 10 GB free space on phone
at least 20 GB free space on computer for dumping data
adb and fastboot commands should be in your $PATH environment variable
I'm not 100% sure if this is a necessary requirement but I also disabled dm-verity and verification on my device just in case by simply booting into TWRP and then executing these 2 commands:
Code:
adb disable-verity
adb shell avbctl disable-verification
Description: A script for all Android power users that wish to make their read-only Android 10+ system read-write-able again to remove bloatware and make more thorough customizations to their device.
In a nutshell this is what the script is doing:
dumps your existing super image to your pc
extracts the embedded read-only partitions (system, vendor, product, etc...)
makes these partitions read-write-able
joins everything back together to new flashable super.img
flashes it to device
User data is not affected.
Usage: Simply call the script from the shell.
Optional arguments (replace x with your custom value) :
in=x : With this flag you can specify an existing super.img and skip the entire dumping of the super image process. Here you can use the super_original.img which you dumped earlier with makesysrw or the official super.img from your downloaded firmware. You probably have to unsparse the official super.img first using the included simg2img tool for superunpack to recognize it properly. If omitted, makesysrw will dump super image from phone to ./super_original.img
out=x : With this argument you can specify the output path. If omitted, default output value is ./super_fixed.img
size=x : With this parameter you can specify the extra free space (in megabytes) that will be added to each partition. If omitted, default extra size is 0 (shrink to minimum)
Examples:
Code:
# Run this command if you're first time user:
# Specify the extra free space in megabytes for each partition:
./makesysrw.sh size=100
# Plug an existing raw super image into the script like this:
./makesysrw.sh in=./super_original_raw.img size=100
# Specify both the input file as well as the output destination:
./makesysrw.sh in=./super_original_raw.img out=./super_fixed.img size=100
# For unsparsing the (sparse) super.img from your phone manufacturer's firmware you can do:
./tools/bin/simg2img ./super_sparse.img ./super_raw.img
NOTE: I did not come up with all this by myself. After searching for a solution for countless days without success, going even as far as learning hex editing - I coincidentally came across a couple of very interesting threads burried deep inside the new forum interface where this technique has been described and discussed by various enthousiasts (links can be found below in the credits section). So I take absolutely no credit for the underlying core mechanisms of the script. I'm only the amateur who put it all together into a compact script so that everybody can enjoy an Android system that's read-write-able again. Just like it used to be in Android 9 or earlier. Before this annoying 'shared_blocks feature' was implemented.
Credits: Big thanks to @munjeni for allowing me to use his amazing superunpack tool instead of the default lpunpack. Source code can be found here.
Also big thanks to @Brepro1 without your awesome tutorial guiding me I couldn't have created this script.
Thanks @AndyYan your interesting thread also helped me a lot for automating the script especially the lpdump part.
More thanks @gabrielfrias for his helpful comment
Thanks @YOisuPU and of course @topjohnwu for discovering the 'shared_blocks feature'
Thanks @bynarie for making available his otatools package! A part of it is now bundled with the archive
Disclaimer: This is open source software and is provided as is without any kind of warranty or support whatsoever. By using and viewing this software you agree to the following terms:
Under no circumstances shall the author be held responsible for any damages or negative consequences that may arrise from the (inappropriate) use of this software.
All responsibility and liability lies with the end-user. You hereby agree not to abuse this software for illegal purposes. Use this software at your own risk!
Please feel free to improve this script as you see fit (as long as you don't add anything malicious)
and make sure to post your feedback, suggestions and improvements in the official thread right here.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Mod Edit: Download link removed
Please click my like button below if you like it! Thanks​

It would be very helpful if you guys could please give me some feedback if the script works for you.
Which device are you using?
Your Android version?
Did you disable dm-verity and verification before running the script?
Your suggestions to enhance the script. Remember this is only version 1.0
Thanks!
@thor_1979

Great work! Your donation to the developers community is awesome.
The script works perfectly.
Consider keeping going.

Are you serious it actually works on your device? lmao
Congratulations. You are the first person to try it
The script pretty much does the same thing as your awesome tutorial describes.
Without your tutorial this script would not exist so thank you very much for making it available!

How do I use it? I'm really wanting to make my system rw again and this is perfect but how do I use it? It's a tar and Xz?

Simply extract the downloaded archive and open a terminal shell in the extracted folder by right clicking inside it and select Open in Terminal
Then run this command if you're running it for the first time
Code:
./makesysrw.sh size=100
or this command if you already have your raw super.img file
Code:
./makesysrw.sh in=./existing_super_image.img size=100
If you can't launch the script file make sure it is executable on your computer.

I really don't understand how this works why do you need the storage space is it making a system img that you than flash? I thought it just makes the current system read writable so you can install and uninstall system apps.

lebigmac said:
Simply extract the downloaded archive and open a terminal shell in the extracted folder by right clicking inside it and select Open in Terminal
Then run this command if you're running it for the first time
Code:
./makesysrw.sh
or this command if you already have your super.img file
Code:
./makesysrw.sh existing_super_image.img
If you can't launch the script file make sure it is executable on your computer.
Click to expand...
Click to collapse
Thanks I'm supposed to run the shell from my pc terminal or on the android device?

Sorry I see its for linux users. Ok now im getting it I have ubuntu 14 on my hard drive but I need to reinstall the grub menu because I deleted it or something. I have a s10 lite and tab S6 I would love to make the writable on the system so does this make a backup or dump of your system and than you flash it? Do you guys think thatll work on one ui 2.5 and im on lineage 18.1 on my s10 lite

Well in a nutshell this is what the script is doing:
dumps your existing super image to your pc
extracts the embedded read-only partitions (system, vendor, product, etc...)
makes these partitions read-write-able
joins everything back together to new flashable super.img
flashes it to device
User data is not affected.
The script is telling you exactly what's happening under the hood. You can also check out the source code if you have any doubts.
Yes this version of the script is supposed to be run on a Linux computer.
Please report back if it works for you or not.
Lineage OS? Doesn't that have a read-write-able system by default? In that case the script will likely fail.
Please keep in mind this script has been developed on Android 10 (Xiaomi X3 NFC) with a system that's read-only.

lebigmac said:
Well in a nutshell the script dumps your existing super image to your pc.
And then modifies the files to make everything read write able and then flashes back to the device. User data is not affected.
The script is telling you exactly what's happening under the hood. You can also check out the source code if you have any doubts.
Yes the script is supposed to be run on the computer
Please report back if it works for you or not.
Lineage OS? Doesn't that already come with read-write-able system by default? In that case the script will likely fail.
Please keep in mind this script has been developped on Android 10 MIUI 12 (Xiaomi X3 NFC) with a system that's read-only and embedded in a super image.
Click to expand...
Click to collapse
Honestly Im not a 100 percent sure anymore. I know it's a super img and it's really different in twrp there's a ton of new partitions and you have to wipe it off completely to flash a new system. I really haven't dug to deep into everything because I know that S6 oneui isn't writable and actually upset me because it's not like having full root access anymore.

For Windows users with TWRP.
(This is more like a reference)
From adb shell inside twrp.
X = Partition. To find out what block partition is mounted at, mount it in twrp then run 'df -h'.
e2fsck -f /dev/block/dm-x
resize2fs /dev/block/dm-x 3G
e2fsck -E unshare_blocks /dev/block/dm-x
Now reboot to fastbootd and execute:
fastboot resize-logical-partition <partition_slot> $((3*1024*1024*1024))

Thank you for the script.
When I read that I could use it with the super.img I guessed the usage was like
./makesysrw.sh image.img super_edited.img
I have a linux partition, but on a remote server and I was hoping to use it on the file and get my edited file from the server without putting the phone in the server..
Let me knowif you add something like that(-i and -o flags will be useful)
Best

Lossyx said:
For Windows users with TWRP.
(This is more like a reference)
From adb shell inside twrp.
X = Partition. To find out what block partition is mounted at, mount it in twrp then run 'df -h'.
e2fsck -f /dev/block/dm-x
resize2fs /dev/block/dm-x 3G
e2fsck -E unshare_blocks /dev/block/dm-x
Now reboot to fastbootd and execute:
fastboot resize-logical-partition <partition_slot> $((3*1024*1024*1024))
Click to expand...
Click to collapse
As much as I wish for a solution to be available to our fellow Windows users,
unfortunately your suggestion doesn't work here on my device see screenshot below.

lebigmac said:
As much as I wish for a solution to be available to our fellow Windows users,
unfortunately your suggestion doesn't work here on my device see screenshow below.
View attachment 5236719
Click to expand...
Click to collapse
Yeah. These dynamic partitions are weird, because for some reason I only managed to do this on slot A. And only did it on the vendor partition.
Also, this is the reference i was going by;
https://twitter.com/i/web/status/1260577424418488324

lebigmac said:
As much as I wish for a solution to be available to our fellow Windows users,
unfortunately your suggestion doesn't work here on my device see screenshow below.
View attachment 5236719
Click to expand...
Click to collapse
I think the problem is that you are requesting too large amount of memory try to replace 3G with smaller amount of memory

If anybody is good with creating flashable zips contact me! Need help working on universal version right now which will also be compatible with Windows and Mac users!
I am only amateur so need a real pro to give me some assistance here. Thank you.

Redmi note 9 pro. EU 12.0.2 rom. Android 10. It works. I installed WMware Workstation on a virtual machine in Windows. Thanks.(Google translate, sorry)

I can confirm that it works pềctly on my Pixel 4 XL Android 11 (coral-rq2a.210305.006) and Android 10 (coral-qq3a.200805.001), thank you for your awesome hard work!

Tried it on my Oneplus 7T Pro with Android 10. It extracted the superimage but failed at writing it back. It returned this error:
Code:
error: file_write: write: No space left on device
lpmake E 03-02 21:41:55 76867 76867 images.cpp:468] [liblp]sparse_file_write failed with code: -1
lpmake E 03-02 21:41:55 76867 76867 images.cpp:326] [liblp]Could not open image for partition: product_a
makesysrw: Error! failed to create super_fixed.img file./makesysrw.sh super_image.img 14.21s user 37.28s system 51% cpu 1:40.46 total
Any ideas? Thank you for your great work!

Creating /system/xbin on Android 9

Hoo roo,
Am currently trying to install a custom version of BusyBox to get Linux Deploy working. The installation script is slightly buggy, but you can workaround it by changing the .sh script slightly and creating the folder /system/xbin.
However, having a bit of trouble. Using su in Termux and mounting / as rw, then attempting to mkdir /system/xbin softlocks my Boox Max 3. This appears to be as a result of android 9 doing system-as-root.
I'm following the instructions mentioned in this Github issue.
Am so close to getting working Arch Linux on my eink tablet, can anyone point me in the right direction? Thank you in advance

If you want to tamper Android's system partition then
Phone's bootloader must be unlocked
AVB must be disabled
before.
Also: Android's /system partition is of fixed size. Have you checked there is enough free space to hold the BusyBox suite, too?

Why not install your BusyBox suite in /system/bin, what will overwrite Android's default ToyBox suite thus you won't have 2 more or less equal suites present in Android?

jwoegerbauer said:
If you want to tamper Android's system partition then
Phone's bootloader must be unlocked
AVB must be disabled
before.
Also: Android's /system partition is of fixed size. Have you checked there is enough free space to hold the BusyBox suite, too?
Click to expand...
Click to collapse
Thank you so much for responding jwogerbauer, using TWRP so bootloader is unlocked, and dm-verity is disabled as well. There's also most definitely enough space on /system, can't even make the folder though.
Linux Deploy needs this specific version of BusyBox installed, which is strange. The developer is a bit slack and more of a shell scripting sort of guy, so there's a heap of small hack arounds.
Was thinking there might be something possible with symlinks or something, but no idea where to start

snug.gy said:
Hoo roo,
Am currently trying to install a custom version of BusyBox to get Linux Deploy working. The installation script is slightly buggy, but you can workaround it by changing the .sh script slightly and creating the folder /system/xbin.
However, having a bit of trouble. Using su in Termux and mounting / as rw, then attempting to mkdir /system/xbin softlocks my Boox Max 3. This appears to be as a result of android 9 doing system-as-root.
I'm following the instructions mentioned in this Github issue.
Am so close to getting working Arch Linux on my eink tablet, can anyone point me in the right direction? Thank you in advance
Click to expand...
Click to collapse
How can I create xbin on android 11 please? Its rooted and unlocked thank you

Why trying to install BusyBox? Android since version 6 already comes with ToyBox - Android's official BusyBox equivalent.

xXx yYy said:
Why trying to install BusyBox? Android since version 6 already comes with ToyBox - Android's official BusyBox equivalent.
Click to expand...
Click to collapse
I have instructions to install other things that I'm following and that requires for me to put things into that specific ×bin to then give commands on terminal emulator and working with linux I think it def is for busy box @xXx yYy thanks

Joy28 said:
I have instructions to install other things that I'm following and that requires for me to put things into that specific ×bin to then give commands on terminal emulator and working with linux I think it def is for busy box @xXx yYy thanks
Click to expand...
Click to collapse
So what should I do how do I get it on there? Thx

Joy28 said:
So what should I do how do I get it on there? Thx
Click to expand...
Click to collapse
@xXx yYy

Since now almost 2 years you ( and other member ) are struggling with this problem: looks you ( both ) never correctly read the related posts here.
Same question got asked here, too
Creating /system/xbin on Android 9
Hoo roo, Am currently trying to install a custom version of BusyBox to get Linux Deploy working. The installation script is slightly buggy, but you can workaround it by changing the .sh script slightly and creating the folder /system/xbin...
forum.xda-developers.com
Note:
BusyBox binary ( current version is 1.36_0 released 3 weeks ago ) is compiled to be run on Android 8 and lower. For Android 8 and higher you've to use BusyBox as Magisk module.
My recommdation: Install Brutal BusyBox as Magisk module. Watch this video:
BTW:
Folder /system/xbin holds “Extra” binaries generated by some of 3rd-party-packages that aren’t essential to the system’s operation. To get these binaries working Android's path variable must get adjusted, too.
Folder /system/ sbin typically hold binaries essential to the system administrator, it contains only ueventd and adbd.
FYI:
TWRP times ago has started replacing Busybox with Toybox

xXx yYy said:
Since now almost 2 years you ( and other member ) are struggling with this problem: looks you ( both ) never correctly read the related posts here.
Same question got asked here, too
Creating /system/xbin on Android 9
Hoo roo, Am currently trying to install a custom version of BusyBox to get Linux Deploy working. The installation script is slightly buggy, but you can workaround it by changing the .sh script slightly and creating the folder /system/xbin...
forum.xda-developers.com
Note:
BusyBox binary ( current version is 1.36_0 released 3 weeks ago ) is compiled to be run on Android 8 and lower. For Android 8 and higher you've to use BusyBox as Magisk module.
My recommdation: Install Brutal BusyBox as Magisk module. Watch this video:
BTW:
Folder /system/xbin holds “Extra” binaries generated by some of 3rd-party-packages that aren’t essential to the system’s operation. To get these binaries working Android's path variable must get adjusted, too.
Folder /system/ sbin typically hold binaries essential to the system administrator, it contains only ueventd and adbd.
FYI:
TWRP times ago has started replacing Busybox with Toybox
Click to expand...
Click to collapse
I dont have an sbin either please in really simple terms can you please tell me how to install xbin??? Please I'm going crazy over here

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

No i need this bad please can you point me in the right direction

just install busybox from Magisk
https://github.com/Magisk-Modules-Repo/busybox-ndk

aIecxs said:
just install busybox from Magisk
https://github.com/Magisk-Modules-Repo/busybox-ndk
Click to expand...
Click to collapse
Thanks but I don't think that is the extent of it... I need to put linux file into xbin

I am using Linux Deploy app on systemless-root without any hassle

Please see pm

I don't reply pm. keep it in the threads.
what's the point, if you're rooted with Magisk, just install UPDATE-Busybox.Installer.v1.34.1-ALL-signed.zip from Magisk modules, reboot, and find "compatible BusyBox in path /system/xbin" (or /system/bin if no mount point exist)
Linux Deploy doesn't care about install location of busybox as long as it is in path.

I need help rooting my zte quest 5

Ok so i got a zte quest 5 (z3351s) though qlink. Not the phone i wanted but it was one i could afford. And it works very well just can't run amazon music and other apps at the same time.
But the bloatware is unreal. Used to in my galaxy s3&s4 days i could root and delete all apps i didn't need. I know i can disable them but i want them gone completely.
Majisk didnt work
Kingoroot same even used pc.
I am hoping someone knows of a way i can root this phone or at least delete all the un needed apps for example i have Google maps go (came stock) i put the org google maps which is better plus offers sat view.
Edit i did some math and converting and the useless apps 11 out of 58 come out to 349.72mb which is a lot if your phone only has 16gb of space. Also note i don't have hardly anything.
Worst case i can Hotspot to my note10+ for multitasking but not sure of data limit.

@TexasPride
a phone's Android can get considered "rooted" as soon as in Android the SU-binary is present. Hence you at any time at your own can install the appropriate SU-binary onto your phone's Android by means of ADB.

I heard about adb methods but i haven't messed with it in forever since apk/ios apps came out

jwoegerbauer said:
@TexasPride
a phone's Android can get considered "rooted" as soon as in Android the SU-binary is present. Hence you at any time at your own can install the appropriate SU-binary onto your phone's Android by means of ADB.
Click to expand...
Click to collapse
Are you sure it will always work?
I tried this method of installing supersu: https://github.com/spff/install-supersu-via-adb
As a result, I got my phone eternally showing the boot logo and not booting.
Not a problem to re-flash stock ROM but it is an example that there in no universal way to install SU (or SuperSU) via adb.
If you could give a link to some other method how SU could be installed, I'll give it a try of course.

vp1117 said:
Are you sure it will always work?
I tried this method of installing supersu: https://github.com/spff/install-supersu-via-adb
As a result, I got my phone eternally showing the boot logo and not booting.
Not a problem to re-flash stock ROM but it is an example that there in no universal way to install SU (or SuperSU) via adb.
If you could give a link to some other method how SU could be installed, I'll give it a try of course.
Click to expand...
Click to collapse
I spoke of SU-binary and NOT of SuperSU installer package
Example:
Code:
adb devices
adb push <location-of-matching-su-binary-on-computer> /sdcard/Downloads/ 2>nul
adb shell "chmod 0777 /sdcard/Downloads/su"
Of course you can install SuperSU package by means of ADB and this even when device is booted into Stock Recovery: but this requires to make some mods to SuperSU zip.

TexasPride, sorry I stepped in your thread.​
jwoegerbauer said:
I spoke of SU-binary and NOT of SuperSU installer package
Click to expand...
Click to collapse
I see. It is often mixed in numerous materials one can find in the net. Subject is SU-binary update, but the ultimate goal is to install supersu.
jwoegerbauer said:
Example:
Code:
adb devices
adb push <location-of-matching-su-binary-on-computer> /sdcard/Downloads/ 2>nul
adb shell "chmod 0777 /sdcard/Downloads/su"
Click to expand...
Click to collapse
What should be result of running this code? SU-binary located in Downloads with 777 permission? What is the practical sense/use of it?
What software/application would use SU in that location?
Sorry for my questions. I'm not arguing. I try to understand the idea.
jwoegerbauer said:
Of course you can install SuperSU package by means of ADB and this even when device is booted into Stock Recovery: but this requires to make some mods to SuperSU zip.
Click to expand...
Click to collapse
Somehow, with my almost zero knowledge of edify and linux command line I got the same conclusion: SuperSU zip has to be modified in order to install it via adb on devices that do not have TWRP for sideload. I failed to find any examples of SuperSU modding...

@vp1117
Answering your questions from last to first:
Installing SuperSU.zip via ADB
The SuperSU.zip doesn't come with an EDIFY coded script, but with an Android SHELL script - everyone who has knowledge of LINUX scripting can read / modify it.
Android comes with TAR-binary, but not ZIP-binary. Hence the SuperSu.zip must get repacked into SuperSU.tar thus it can get extracted on Phone. The contents of such a TAR-file would look as shown here
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Making use of SU-binary
The SU-binary ( ~110KB ) is nothing else then the root user, as known from LINUX.
Running in Android via ADB a command that requires super-user ( root ) rights is done as follows
Example:
Code:
adb devices
adb shell "/sdard/Downloads/su -c '<ommand-that-requires-root-here>'"

jwoegerbauer said:
Answering your questions from last to first:
Installing SuperSU.zip via ADB
The SuperSU.zip doesn't come with an EDIFY coded script, but with an Android SHELL script - everyone who has knowledge of LINUX scripting can read / modify it.
Android comes with TAR-binary, but not ZIP-binary. Hence the SuperSu.zip must get repacked into SuperSU.tar thus it can get extracted on Phone. The contents of such a TAR-file would look as shown here
Click to expand...
Click to collapse
OK. I guess, I can repack zip to tar.
Sorry for my silly question but why should I need to keep superSU as an archive? Could not I just upload all folders + update-binary.sh to the phone? I'm sure I can do it.
Am I right my next step would be running update-binary.sh (~60 KB) from <adb shell> command line?
jwoegerbauer said:
Making use of SU-binary
The SU-binary ( ~110KB ) is nothing else then the root user, as known from LINUX.
Running in Android via ADB a command that requires super-user ( root ) rights is done as follows
Example:
Code:
adb devices
adb shell "/sdard/Downloads/su -c '<ommand-that-requires-root-here>'"
Click to expand...
Click to collapse
Interestingly, I can execute all commands I need without having su-binary (~100 KB) uploaded to my phone. It is strange but I see #-prompt after I ran <adb shell>. This happens on my UNrooted phone, running stock ROM. I guess, it's a specifics of my phone, no need to try explain it.

I done failed trying to read i dont really understand linux all that well. But if anyone has any links so i can download it and try it

vp1117 said:
Sorry for my silly question but why should I need to keep superSU as an archive? Could not I just upload all folders + update-binary.sh to the phone? I'm sure I can do it.
Am I right my next step would be running update-binary.sh (~60 KB) from <adb shell> command line?
Click to expand...
Click to collapse
Of course it's your decision how you transfer the SuperSU package onto phone: many ways lead to Rome.
My decision was to push SuperSU package repacked as TAR-file onto phone, extract it there, and finally run the modified update-binary.sh when phone is booted into recovery mode:
Code:
adb shell "$(cat < %supersu_dir%/update-binary.sh); echo $?"

So I rebooted to stock recovery and then uploaded following from UPDATE-SuperSU-v2.82-20170528234214.zip package to my phone's folder /tmp:
/arm64
/common
/META-INF
update-binary.sh
Here is what I got:
Z:\android\adb>adb shell "$(cat < /tmp/update-binary.sh); echo $?"
127
/system/bin/sh: #!/sbin/sh: not found
And here's what I got running same command from # command line:
# $(cat < /tmp/update-binary.sh); echo $?
/system/bin/sh: #!/sbin/sh: not found
127
In response to # ls -al /sbin I get lots of lines one of them is as follows:
lrwxrwxrwx 1 root root 7 1970-01-01 00:00 sh -> busybox
I feel that I'm doing something wrong, but what exactly?
In attached txt-file I put some more details I got in command line.

jwoegerbauer said:
... and finally run the modified update-binary.sh when phone is booted into recovery mode:
Click to expand...
Click to collapse
Am I right the only modification needed is to rename update-binary to update-binary.sh ?

@vp1117
NO.
When I said modified then I didn't mean simply rename it: The contents of original update-binary file must be rewritten / deleted in some parts. Also, believe me, it makes sense to repack original SuperSU.zip to SuperSu.tar as I demonstrated above. Take also note that, if device's Android isn't rooted yet, the location for unpacked SuperSU mandatory must be /data/local/tmp.
BTW:
I can see BusyBox is installed on your device's Android. Take note that BusyBox by default comes with the SU-binary. Hence your device's Android is rooted! Wondering why you waste your time with trying to completely install SuperSU from scratch?

jwoegerbauer said:
Wondering why you waste your time with trying to completely install SuperSU from scratch?
Click to expand...
Click to collapse
Good question.
Probably, because I see this when phone restarts from recovery to normal android:

jwoegerbauer said:
Also, believe me, it makes sense to repack original SuperSU.zip to SuperSu.tar as I demonstrated above.
Click to expand...
Click to collapse
OK, no problem, I can re-pack zip into tar.
However, what you demonstrated above was a screenshot showing update-binary.sh being inside the tar. At the same time you don't tell how update-binary.sh must be amended. Is it OK?

TexasPride​
I'm very sorry I put so much spam in your thread. Please forgive me. If I knew how to delete my posts here I would deleted them.

vp1117 said:
TexasPride​
I'm very sorry I put so much spam in your thread. Please forgive me. If I knew how to delete my posts here I would deleted them.
Click to expand...
Click to collapse
Its ok, i dont mind at all.

@TexasPride
FYI: I no longer participate this hijacked thread.