Related
This is hack for the userinit.sh script that allows to override
system programs with different binaries or just add some new
executable programs to your rom as you can use your ext3 partition
as storage. One more advantage is that your customizations
will be persistent even after a update.
For this to work you have to add this lines to your /system/sd/userinit.sh script:
Code:
mount -o remount,rw /dev/rootfs /
mkdir /usr
chown root.root /usr
chmod 755 /usr
mkdir /system/sd/bin
chown root.shell /system/sd/bin
chmod 755 /system/sd/bin
ln -s /system/sd/bin /usr/bin
mount -o remount,ro /dev/rootfs /
After a reboot, you'll find a newly created bin
directory in /system/sd/ linked to /usr/bin.
/usr/bin is the first directory to be searched
in path in CM-mod ROMs so any program dropped
there will be found and executed before others with
same name in the system. So you can simply:
Code:
adb push new_program /usr/bin
adb shell
cd /usr/bin
chmod 755 new_program
chown root.shell new_program
This is experimental stuff and therefore USE IT AT YOUR OWN RISK.
Tested on CM-mod-3.6.7.2 and CM-mod-3.6.8 and works fine for me.
So if I were to use this method. I could 'truely' replace the home screen with one of the 3rd party ones. ie aHome or dxTop? As it is now, I've noticed that even setting aHome as default, Home still runs in the background. Using Advanced Task Manager to confirm this btw.
If this is the case, I'll be using this shortly. As I'm tired of just running 3rd party programs in addition to the programs they are suppose to replace.
Its like using windowblinds in windows, instead of just replacing the whole shell. lol
followinginsanity said:
So if I were to use this method. I could 'truely' replace the home screen with one of the 3rd party ones. ie aHome or dxTop? As it is now, I've noticed that even setting aHome as default, Home still runs in the background. Using Advanced Task Manager to confirm this btw.
If this is the case, I'll be using this shortly. As I'm tired of just running 3rd party programs in addition to the programs they are suppose to replace.
Its like using windowblinds in windows, instead of just replacing the whole shell. lol
Click to expand...
Click to collapse
This only lets your run cli programs. This is below the dalvik system so it won't help you change the launcher.apk for ahome or dxtop.
Ok I see what your saying now. Misunderstood the exact intent of the changes
Cool trick, thanks. I already had a /system/sd/bin, so I modified it a little to skip creating it and doing the chmod etc on it.
Slight mod to avoid the whole thing if /usr is already there.. .
Code:
if ! [ -d /usr ]
then
mount -o remount,rw /dev/rootfs /;
mkdir /usr;
chown root.root /usr;
chmod 755 /usr;
ln -s /system/sd/bin /usr/bin;
mount -o remount,ro /dev/rootfs /;
fi
This is useful to me as my userinit.sh is the new one from the compcache thread and can be run to get status info on compcache after boot. No need to remount the filesystem and all that when what we need is already there.
I don't think you can skip the creation of /usr as it is lost
after a reboot at least on cm-mod, you can skip the creation
of system/sd/bin if it already exists tough. OTOH running:
Code:
mkdir /usr
chown root.root /usr
chmod 755 /usr
mkdir /system/sd/bin
chown root.shell /system/sd/bin
chmod 755 /system/sd/bin
ln -s /system/sd/bin /usr/bin
will do no harm as mkdir and ln will fail if the targets already exist
and chown and chmod will just ensure that you can run your
programs.To be on the safe side i would suggest:
Code:
mount -o remount,rw /dev/rootfs /
mkdir /usr
chown root.root /usr
chmod 755 /usr
# we should check if /system/sd is mounted
if [ ! -d /system/sd/bin ] ; then
mkdir /system/sd/bin
chown root.root /system/sd/bin
chmod 755 /system/sd/bin
fi
ln -s /system/sd/bin /usr/bin
mount -o remount,ro /dev/rootfs /
This would be a great place to put a set of the GNU utilities like ls, ln, cp, mv, etc to go along with bash. Busybox is great and all, but there are some advanced options in the GNU versions that aren't available in Busybox. Has anyone compiled them for Android? I might try copying the Debian ones over and see if they work without the rest of the chroot. I'm thinking I'll need at least some of /lib from debian for them to work though.
ttabbal said:
This would be a great place to put a set of the GNU utilities like ls, ln, cp, mv, etc to go along with bash. Busybox is great and all, but there are some advanced options in the GNU versions that aren't available in Busybox. Has anyone compiled them for Android? I might try copying the Debian ones over and see if they work without the rest of the chroot. I'm thinking I'll need at least some of /lib from debian for them to work though.
Click to expand...
Click to collapse
Have you tried a fully configured busybox with desktop options enabled?
Attached just for reference my .config.
farmatito said:
Have you tried a fully configured busybox with desktop options enabled?
Attached just for reference my .config.
Click to expand...
Click to collapse
Nope. Is there a binary available? I don't have a cross compiler set up right now.
Try this, You can create all the symlinks with this command:
Code:
adb push busybox /usr/bin
adb shell
cd /usr/bin
./busybox --install .
For full functionality you should also add /etc/passwd, /etc/shadow, /etc/group, /etc/gshadow. I link them to /system/sd/etc/ to have them rw
Code:
mkdir /system/sd/etc
chmod 644 /system/sd/etc
/system/bin/chown root.root /system/sd/etc
/system/bin/chown root.root /system/sd/etc/passwd
/system/bin/chown root.root /system/sd/etc/group
/system/bin/chown root.root /system/sd/etc/shadow
/system/bin/chown root.root /system/sd/etc/gshadow
/system/bin/chown root.root /system/sd/etc/fstab
chmod 644 /system/sd/etc/passwd
chmod 644 /system/sd/etc/group
chmod 600 /system/sd/etc/shadow
chmod 600 /system/sd/etc/gshadow
ln -s /system/sd/etc/passwd /etc/passwd
ln -s /system/sd/etc/shadow /etc/shadow
ln -s /system/sd/etc/group /etc/group
ln -s /system/sd/etc/gshadow /etc/gshadow
Remove the su link to busybox for now as it interferes with
the superuser app (otoh you could set a root passwd and
use busybox's su BUT ONLY FROM A SHELL)
Code:
rm /usr/bin/su
You should also:
Code:
passwd root
addgroup -g 65534 nogroup
You can even use ash as your default shell by doing:
Code:
if [ -e /usr/bin/busybox ] ; then
mount --bind /usr/bin/sh /system/bin/sh
fi
# Fix scripts in /system/bin
for i in am ime input monkey pm svc
do
if [ `grep -c "#!/system/bin/sh" /system/bin/$i` -eq 0 ] ; then
echo "#!/system/bin/sh" > /system/bin/$i.tmp
cat /system/bin/$i >> /system/bin/$i.tmp
mv /system/bin/$i.tmp /system/bin/$i
chown root.shell /system/bin/$i
chmod 755 /system/bin/$i
fi
done
Thanks! That worked great.
farmatito said:
Try this, You can create all the symlinks with this command:Remove the su link to busybox for now as it interferes with
the superuser app (otoh you could set a root passwd and
use busybox's su BUT ONLY FROM A SHELL)
Click to expand...
Click to collapse
Hey farmatito - just stumbled onto this thread and am going to follow this but I am unclear on how to remove the su link to busybox? Any direction would be appreciated! Thanks.
Edit: I realize you mean to just rm it from /system/sd/bin - duh. thanks for this thread! I like having the full busybox bin.
cd /usr/bin
rm su
farmatito said:
cd /usr/bin
rm su
Click to expand...
Click to collapse
Yeah, I figured that out - thanks. I had edited my above post saying such.
another question for you - I was going through your busybox config file - and am wondering which directory you store it in so that it is used when installing busybox?
prscott1 said:
Yeah, I figured that out - thanks. I had edited my above post saying such.
another question for you - I was going through your busybox config file - and am wondering which directory you store it in so that it is used when installing busybox?
Click to expand...
Click to collapse
Download the source code from www.busybox.net
extract it
cd busybox
cp my_config .config
make oldconfig
make
You need a cross compiler to build it
you can download one at
http://www.codesourcery.com/sgpp/lite/arm/portal/release830
or
http://www.codesourcery.com/sgpp/lite/arm/portal/release827
Quick stupid question please... tried searching but haven't found much.
After doing the userinit.sh mod shown here and using the new busybox (thanks for that, btw!), I noticed that a lot of the commands (including 'ls' which is now using /usr/bin/ls) show ansi colors in a terminal that supports them (i.e. 'Terminal' or 'Better Terminal' app) which is awesome but 'adb shell' looks mostly horrible with escape sequences instead of colors, like this:
Code:
# cd /system/sd
cd /system/sd
# ls -l
ls -l
drwxrwx--x 2 system system 2048 Aug 19 16:04 ←[1;34mapp←[0m
drwxrwx--x 2 system system 1024 Aug 16 02:12 ←[1;34mapp-private←[0m
drwxr-xr-x 2 root root 4096 Aug 19 20:40 ←[1;34mbin←[0m
drwxrwx--x 2 system system 7168 Aug 19 16:04 ←[1;34mdalvik-cache←[0m
drw-r--r-- 2 root root 1024 Aug 19 20:39 ←[1;34metc←[0m
drwxr-xr-x 2 root root 12288 Jul 10 02:29 ←[1;34mlost+found←[0m
drwxrwxrwx 2 root root 1024 Jul 22 18:15 ←[1;34mmedia←[0m
-rwxr-xr-x 1 root root 331 Aug 19 20:28 ←[1;32muserinit.sh←[0m
Do you guys set your $TERM variable to something that makes the adb terminal more "sane" or is not possible because adb is limited and I should just ssh or telnet in, etc.?
I've tried setting $TERM to various standard things (ansi/vt100/xterm/etc.) but the dumb adb terminal remains.. well.. dumb.
rub1k said:
Quick stupid question please... tried searching but haven't found much.
After doing the userinit.sh mod shown here and using the new busybox (thanks for that, btw!), I noticed that a lot of the commands (including 'ls' which is now using /usr/bin/ls) show ansi colors in a terminal that supports them (i.e. 'Terminal' or 'Better Terminal' app) which is awesome but 'adb shell' looks mostly horrible with escape sequences instead of colors, like this:
Code:
# cd /system/sd
cd /system/sd
# ls -l
ls -l
drwxrwx--x 2 system system 2048 Aug 19 16:04 ←[1;34mapp←[0m
drwxrwx--x 2 system system 1024 Aug 16 02:12 ←[1;34mapp-private←[0m
drwxr-xr-x 2 root root 4096 Aug 19 20:40 ←[1;34mbin←[0m
drwxrwx--x 2 system system 7168 Aug 19 16:04 ←[1;34mdalvik-cache←[0m
drw-r--r-- 2 root root 1024 Aug 19 20:39 ←[1;34metc←[0m
drwxr-xr-x 2 root root 12288 Jul 10 02:29 ←[1;34mlost+found←[0m
drwxrwxrwx 2 root root 1024 Jul 22 18:15 ←[1;34mmedia←[0m
-rwxr-xr-x 1 root root 331 Aug 19 20:28 ←[1;32muserinit.sh←[0m
Do you guys set your $TERM variable to something that makes the adb terminal more "sane" or is not possible because adb is limited and I should just ssh or telnet in, etc.?
I've tried setting $TERM to various standard things (ansi/vt100/xterm/etc.) but the dumb adb terminal remains.. well.. dumb.
Click to expand...
Click to collapse
What terminal are you using?
I use konsole on linux and everything looks fine.
Cannot say if there is a suitable terminal for windows,
maybe the one that comes with the mingw compiler.
If nothing works you can just:
Code:
cd /usr/bin
rm ls
farmatito said:
Download the source code from www.busybox.net
extract it
cd busybox
cp my_config .config
make oldconfig
make
You need a cross compiler to build it
you can download one at
http://www.codesourcery.com/sgpp/lite/arm/portal/release830
or
http://www.codesourcery.com/sgpp/lite/arm/portal/release827
Click to expand...
Click to collapse
Many thanks!
Oh, sorry, I should have specified that.
This was using adb from my Vista x64 laptop (yeah, sorry, stuck with win32 for using adb so terminal choices rather limited).
So, basically, it was just running "adb[.exe] shell" from a Windows command prompt.
Tried bash under cygwin and even though it has full ansi coloring support, it looks like adb.exe isn't very terminal friendly because extended/escaped ansi still don't translate.
No big deal; I'll remove /usr/bin/ls for now or temporarily alias 'ls' to /system/xbin/bb/ls while I'm in an adb shell.
Wondering what else I could be using via the USB connection to get a shell prompt within my G1... easiest way is to turn on the wifi and telnet/ssh in, I guess?
EDIT: Duh, just started telnetd and forwarded the port using adb and problem solved (using putty to telnet in as described here and it works very nicely).
rub1k said:
Quick stupid question please... tried searching but haven't found much.
After doing the userinit.sh mod shown here and using the new busybox (thanks for that, btw!), I noticed that a lot of the commands (including 'ls' which is now using /usr/bin/ls) show ansi colors in a terminal that supports them (i.e. 'Terminal' or 'Better Terminal' app) which is awesome but 'adb shell' looks mostly horrible with escape sequences instead of colors, like this:
Code:
# cd /system/sd
cd /system/sd
# ls -l
ls -l
drwxrwx--x 2 system system 2048 Aug 19 16:04 ←[1;34mapp←[0m
drwxrwx--x 2 system system 1024 Aug 16 02:12 ←[1;34mapp-private←[0m
drwxr-xr-x 2 root root 4096 Aug 19 20:40 ←[1;34mbin←[0m
drwxrwx--x 2 system system 7168 Aug 19 16:04 ←[1;34mdalvik-cache←[0m
drw-r--r-- 2 root root 1024 Aug 19 20:39 ←[1;34metc←[0m
drwxr-xr-x 2 root root 12288 Jul 10 02:29 ←[1;34mlost+found←[0m
drwxrwxrwx 2 root root 1024 Jul 22 18:15 ←[1;34mmedia←[0m
-rwxr-xr-x 1 root root 331 Aug 19 20:28 ←[1;32muserinit.sh←[0m
Do you guys set your $TERM variable to something that makes the adb terminal more "sane" or is not possible because adb is limited and I should just ssh or telnet in, etc.?
I've tried setting $TERM to various standard things (ansi/vt100/xterm/etc.) but the dumb adb terminal remains.. well.. dumb.
Click to expand...
Click to collapse
If you are on a windows pc, try using cygwin - works great.
I'm posting this in order to show how to use Super Tool under Linux (for Windows & Mac users, changes should be minimal) and also to show some weird results when rooting HTC Desire Z (aka Vision or G2) phones, which may lead to enhancements in the tool.
Also, the Super Tool thread is already over 90 pages long, and has to do with several phones; I thought that a separate thread about these HTC phones would be useful; I hope this won't be against the forum rules, but please accept my apologies in advance if I'm wrong about this!
A summary:
To sum everything up in advance, results are sort of weird... you can get root using the ZergRush exploit, then install "su", "SuperUser", and "BusyBox", but after a while they just disappear. This makes me suspect that there is some kind of "behind the lines" software running, which sets things back to normal, but I don't know the solution yet.
Some experiments
I set up an Android development environment. I'm working in its platform-tools directory, where the "adb" command resides. I extracted the Super Tool files in the root of the Android directory, two levels up, so they are found at the ../../htcsupertoolv2 directory.
I set my phone for USB Debugging, and then, working from the Linux shell:
Code:
$ ./adb kill-server
$ ./adb start-server
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
$ ./adb devices
List of devices attached
HT0B9RT01278 device
OK, my device is attached and ready. Let's see if we already had root:
Code:
$ ./adb shell
$ su
su: permission denied
$ exit
The device is in its basic state, and we haven't got root. Let's install the ZergRush code.
Code:
$ ./adb shell "rm /data/local/tmp/*"
$ ./adb push ../../htcsupertoolv2/root/zergRush /data/local/tmp/.
451 KB/s (23056 bytes in 0.049s)
$ ./adb shell "chmod 777 /data/local/tmp/zergRush"
$ ./adb shell "./data/local/tmp/zergRush"
[**] Zerg rush - Android 2.2/2.3 local root
[**] (C) 2011 Revolutionary. All rights reserved.
[**] Parts of code from Gingerbreak, (C) 2010-2011 The Android Exploid Crew.
[+] Found a GingerBread ! 0x00015118
[*] Scooting ...
[*] Sending 149 zerglings ...
[+] Zerglings found a way to enter ! 0x10
[+] Overseer found a path ! 0x000151e0
[*] Sending 149 zerglings ...
[+] Zerglings caused crash (good news): 0x401219d4 0x0054
[*] Researching Metabolic Boost ...
[+] Speedlings on the go ! 0xafd194d3 0xafd395bf
[*] Popping 24 more zerglings
[*] Sending 173 zerglings ...
[+] Rush did it ! It's a GG, man !
[+] Killing ADB and restarting as root... enjoy!
$ ./adb shell
# exit
Nice, it managed to get root, at least for the time being! Now, let's set the system R/W.
Code:
./adb remount
remount succeeded
./adb shell
# mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
[COLOR="Red"]/dev/block/mmcblk0p25 /system ext3 rw,relatime,errors=continue,barrier=0,data=ordered 0 0[/COLOR]
/dev/block/mmcblk0p26 /data ext3 rw,relatime,errors=continue,barrier=0,data=ordered 0 0
/dev/block/mmcblk0p27 /cache ext3 rw,nosuid,nodev,relatime,errors=continue,barrier=0,data=ordered 0 0
/dev/block/mmcblk0p28 /devlog ext3 rw,nosuid,nodev,relatime,errors=continue,barrier=0,data=ordered 0 0
[I][...many lines snipped out...][/I]
# exit
So, /system is now r/w. Let's push "su".
Code:
./adb push ../../htcsupertoolv2/root/su /system/bin/su
411 KB/s (22228 bytes in 0.052s)
./adb shell "chown root.shell /system/bin/su"
./adb shell "chmod 06755 /system/bin/su"
./adb shell "rm /system/xbin/su"
rm failed for /system/xbin/su, No such file or directory
./adb shell "ln -s /system/bin/su /system/xbin/su"
./adb push ../../htcsupertoolv2/root/Superuser.apk /system/app/.
2861 KB/s (785801 bytes in 0.268s)
$ ./adb push ../../htcsupertoolv2/root/su /system/bin/su
516 KB/s (22228 bytes in 0.041s)
$ ./adb shell
# cd /system/bin
# ls -l s*
-rwxr-xr-x root shell 5392 2011-08-02 01:09 schedtest
[I][...many lines snipped out...][/I]
lrwxrwxrwx root shell 2010-10-26 09:02 stop -> toolbox
[COLOR="Red"]-rw-rw-rw- root root 22228 2011-11-10 12:53 su[/COLOR]
-rwxr-xr-x root shell 5456 2011-08-02 01:09 surfaceflinger
-rwxr-xr-x root shell 192 2010-09-23 06:51 svc
lrwxrwxrwx root shell 2010-10-26 09:02 sync -> toolbox
-rwxr-xr-x root shell 5480 2011-08-02 01:09 system_server
# chmod 755 su
# chown root.shell su
# ls -l su
-rwxr-xr-x root shell 22228 2011-11-10 12:53 su
As we see, "su" is installed, with the same owner/group/permissions as the other commands. Let's add a symlink in /system/xbin to "su".
Code:
# cd /system/xbin/
# ls -l *
-rwxr-xr-x root shell 5536 2011-08-02 01:11 crasher
-rwxr-xr-x root shell 60276 2008-08-01 09:00 dexdump
-rwxr-xr-x root shell 22256 2011-08-02 01:11 wireless_modem
# ln -s /system/bin/su /system/xbin/su
# cd /system/xbin/
# ls -l *
-rwxr-xr-x root shell 5536 2011-08-02 01:11 crasher
-rwxr-xr-x root shell 60276 2008-08-01 09:00 dexdump
[COLOR="Red"]lrwxrwxrwx root root 2011-12-30 16:48 su -> /system/bin/su[/COLOR]
-rwxr-xr-x root shell 22256 2011-08-02 01:11 wireless_modem
# exit
There's the symlink, all right. Now, let's push "Superuser.apk".
Code:
$ ./adb push ../../htcsupertoolv2/root/Superuser.apk /system/app/.
2689 KB/s (785801 bytes in 0.285s)
$ ./adb shell
# cd /system/app
# ls -l S*
-rw-r--r-- root root 7221765 2011-08-02 01:08 Settings.apk
[I][...many lines snipped out...][/I]
-rw-r--r-- root root 296419 2011-08-02 01:09 Street.apk
-rw-rw-rw- root root 785801 2011-11-10 12:54 Superuser.apk
-rw-r--r-- root root 551020 2008-08-01 09:00 SystemUI.apk
-rw-r--r-- root root 255720 2008-08-01 09:00 SystemUI.odex
# chmod 644 Superuser.apk
# ls -l Super*
[COLOR="Red"]-rw-r--r-- root root 785801 2011-11-10 12:54 Superuser.apk
[/COLOR]# exit
So, there is Superuser.apk, with appropriate user/group/permissions. It's time for a reboot!
Code:
$ ./adb remount
remount succeeded
$ ./adb reboot
A short while afterwards...
Code:
$ ./adb shell
$ su
[B][COLOR="Red"]su: permission denied[/COLOR][/B]
$ cd /system/bin/
$ ls -l s*
-rwxr-xr-x root shell 5392 2011-08-02 01:09 schedtest
[I][...many lines snipped out...][/I]
lrwxrwxrwx root shell 2010-10-26 09:02 stop -> toolbox
-rwxr-xr-x root shell 5456 2011-08-02 01:09 surfaceflinger
-rwxr-xr-x root shell 192 2010-09-23 06:51 svc
lrwxrwxrwx root shell 2010-10-26 09:02 sync -> toolbox
-rwxr-xr-x root shell 5480 2011-08-02 01:09 system_server
$ cd /system/xbin/
$ ls -l *
-rwxr-xr-x root shell 5536 2011-08-02 01:11 crasher
-rwxr-xr-x root shell 60276 2008-08-01 09:00 dexdump
-rwxr-xr-x root shell 22256 2011-08-02 01:11 wireless_modem
So, "su" is gone?! The exploit managed a temp root, but after the reboot, something set things back to standard, removing "su" and "Superuser.apk".
Doing this with scripts
I set up a pair of scripts to automate the previous work (and included BusyBox installation, by the way) but the results are the same.
The first script, htc1.sh, is:
Code:
#!/bin/sh
./adb shell "rm /data/local/tmp/*"
./adb push ../../htcsupertoolv2/root/zergRush /data/local/tmp/.
./adb shell "chmod 777 /data/local/tmp/zergRush"
./adb shell "./data/local/tmp/zergRush"
The second script, htc2.sh, to be run afterwards, when (temp) root has been achieved, is:
Code:
#!/bin/sh
./adb remount
./adb push ../../htcsupertoolv2/root/busybox /data/local/tmp/.
./adb shell "chmod 755 /data/local/tmp/busybox"
./adb shell "dd if=/data/local/tmp/busybox of=/system/xbin/busybox"
./adb shell "cd /system/xbin; chown root.shell busybox; chmod 04755 busybox"
./adb shell "/system/xbin/busybox --install -s /system/xbin"
./adb shell "rm -r /data/local/tmp/busybox"
./adb push ../../htcsupertoolv2/root/su /system/bin/su
./adb shell "cd /system/bin; chown root.shell su; chmod 06755 su"
./adb shell "rm /system/xbin/su; ln -s /system/bin/su /system/xbin/su"
./adb push ../../htcsupertoolv2/root/Superuser.apk /system/app/.
./adb shell "cd /system/app; chmod 644 Superuser.apk"
If you run ./htc1.sh and then ./htc2.sh results will be the same; the added commands will be gone, and you won't be able to "su" no more.
The attached scripts should help Linux users to root other phones (which are known to work) but the Desire Z question still remains; there seems to be something missing, at least for the time being.
G2 Temp Root
Hi, I got a tmo g2 2.3.4
i used the superhtctoolv2 on win7, and htcdrivers linked in the original thread.
i performed the option 1 and 2, and was able to gain temp root, but just like every1 else it goes away with a reboot, or even after prolong period of inactivity, it works as long as i keep messing with Titanium backup or other root apps.
Any way to combine this temp root with older options to gain a perm root?
Cool man! Thanks!
HTC security measure?
Looking around, I found this page about a security method by HTC... to quote:
The HTC software implementation on the G2 stores some components in read-only memory as a security measure to prevent key operating system software from becoming corrupted and rendering the device inoperable. There is a small subset of highly technical users who may want to modify and re-engineer their devices at the code level, known as rooting, but a side effect of HTCs security measure is that these modifications are temporary and cannot be saved to permanent memory. As a result the original code is restored.
Click to expand...
Click to collapse
This sure looks like the problem we are having with the HTC DESIRE Z/G2/VISION...
Cannot get S-OFF
I tried adapting the third script (get S-OFF) for Linux but it didn't work out.
I first tried everything by hand. I ran ht1.sh first (to get root) and then went on to:
Code:
$ ./adb push ../../htcsupertoolv2/root/gfree /data/local
2127 KB/s (134401 bytes in 0.061s)
followed by
Code:
$ ./adb shell
# chmod 777 /data/local/gfree
# ./data/local/gfree -f
--secu_flag off set
--cid set. CID will be changed to: 11111111
--sim_unlock. SIMLOCK will be removed
Section header entry size: 40
Number of section headers: 44
Total section header table size: 1760
Section header file offset: 0x000138b4 (80052)
Section index for section name string table: 41
String table offset: 0x000136fb (79611)
Searching for .modinfo section...
- Section[16]: .modinfo
-- offset: 0x00000a14 (2580)
-- size: 0x000000cc (204)
Kernel release: 2.6.35.10-g7b95729
New .modinfo section size: 204
Attempting to power cycle eMMC... [B][COLOR="Red"]Failed.
Module failed to load: No such file or directory[/COLOR][/B]
So I'm guessing the DESIRE Z/G2/VISION cannot be perm rooted with Super Tool, at least "as is" --- I'll possibly be trying backdating the firmware next.
fkereki said:
I tried adapting the third script (get S-OFF) for Linux but it didn't work out.
I first tried everything by hand. I ran ht1.sh first (to get root) and then went on to:
Code:
$ ./adb push ../../htcsupertoolv2/root/gfree /data/local
2127 KB/s (134401 bytes in 0.061s)
followed by
Code:
$ ./adb shell
# chmod 777 /data/local/gfree
# ./data/local/gfree -f
--secu_flag off set
--cid set. CID will be changed to: 11111111
--sim_unlock. SIMLOCK will be removed
Section header entry size: 40
Number of section headers: 44
Total section header table size: 1760
Section header file offset: 0x000138b4 (80052)
Section index for section name string table: 41
String table offset: 0x000136fb (79611)
Searching for .modinfo section...
- Section[16]: .modinfo
-- offset: 0x00000a14 (2580)
-- size: 0x000000cc (204)
Kernel release: 2.6.35.10-g7b95729
New .modinfo section size: 204
Attempting to power cycle eMMC... [B][COLOR="Red"]Failed.
Module failed to load: No such file or directory[/COLOR][/B]
So I'm guessing the DESIRE Z/G2/VISION cannot be perm rooted with Super Tool, at least "as is" --- I'll possibly be trying backdating the firmware next.
Click to expand...
Click to collapse
well that sucks!
Hello everyone ... I am new here
I have this Docomo Panasonic Eluga V P-06D .... practically I need to unlock the SIM but I found this possible solution to ROOT - Docomo Panasonic Eluga P-07D here [japanese language]:
手順メモ（先日やった記憶なので間違いあるかも）くれぐれも自己責任で
root取得をめざす方はAndroid SDKはわかっていると思うので省略。
① PanasonicのADBドライバを入手 インストール
② goroh_kun氏作成のキットを入手
左上のp07dunlock.zipと書いてあるすぐ下の[file]をクリックしてダウンロード
③ p07dunlock.zipの中にあるReadme.txtに書いてある事柄をすべて実行
手順書内の
(9) tomoyo解除
>adb shell
$cat /data/local/tmp/p07dgetroot > /tmp/xsh
$ls -l /tmp/xsh
-rw-rw-rw- shell shell xsh
無線LANをON/OFF/ONする
$ls -l /tmp/xsh
-rwsr-sr-x root root xsh
$/tmp/xsh
/tmp/xsh
/tmp/.mem fd=3
read ret = 256
write ret = 256
この段階で、tomoyoが解除できている
$rm /tmp/xsh
$cat /data/local/tmp/xsh > /tmp/xsh
無線LANをON/OFF/ONする
$ls -l /tmp/xsh
-rwsr-sr-x root root xsh
$/tmp/xsh
ここで、root権限のシェルが立ち上がるので、色々な動作ができる。suのインストールも可能
↑の最後までくると
[email protected]:/ $ /tmp/xsh
$(precmd)[email protected]$HOSTNAME:${PWD:-?} $
こういった表記になればroot権限ありのShellになっているのでまずは成功。
ここまで来れない場合はFactory Resetなりを考えよう。
④ su busybox superuser.apkの設置
ダウンロードkey：p07d
上記をダウンロードしておく
⑤ インストール前にsystemを読み書きできるよう設定
$ mount -o remount,rw /system /system (shellから操作している場合$はつけなくてよい)
パーミッション変更
$ chmod 777 /system/app/
$ chmod 777 /system/bin/
$ chmod 777 /system/xbin/
⑥ ④でダウンロードした su busybox superuser.apkを送り込む
別窓でコマンドプロンプトをひらき
adb push Superuser.apk /system/app/
adb push su /system/bin/
adb push busybox /system/xbin/
前のshellの窓に戻り
chown root.root /system/bin/su
su所有者を管理者に設定
chmod 6755 /system/bin/su
suの実行権限付与
chmod 644 /system/app/Superuser.apk
Superuser.apk の実行権限付与
chown root.shell /system/xbin/busybox
busybox の所有者を Shellにする
chmod 755 /system/xbin/busybox
busybox の実行権限付与
⑦ ⑤で設定したパーミッションを戻す
$ chmod 755 /system/app/
$ chmod 755 /system/bin/
$ chmod 755 /system/xbin/
これでroot checkerなどでroot accessができたとなれば完了。
ちなみに端末を再起動するたびにroot権がきれるので
Android Terminal Emulator などで
------------------------------
(9) tomoyo解除
>adb shell
$cat /data/local/tmp/p07dgetroot > /tmp/xsh
$ls -l /tmp/xsh
-rw-rw-rw- shell shell xsh
無線LANをON/OFF/ONする
$ls -l /tmp/xsh
-rwsr-sr-x root root xsh
$/tmp/xsh
/tmp/xsh
/tmp/.mem fd=3
read ret = 256
write ret = 256
この段階で、tomoyoが解除できている
--------------------------------
をしてTomoyoだけ解除しなければならないが、うまくやればいちいち手入力しなくても端末立ち上げてターミナルでコマンドを自動入力することも可能なのでいい方法を考えよう。
これで使いもしないのに裏で動いているdocomoアプリを粛清することができるようになった。
ちなみに再起動してTomoyo解除前にVideoストアをやってみましたが
やはり「端末が不正変更されています」とでて視聴はできず。
というわけで今月で解約。
Is there any possibility that this ROOT method to be compatible with Docomo Panasonic Eluga P-06D?
I have the link for those interested but i cannot post it yet.
I'd love to hear good things from you !!!!!
PS: I translated with Google translate README.TXT included in this tutorial
goroh_kun
2012/10/18
experimental version released & tomoyo get root privileges in p-07d
things to do
(1) adb restore p-07d.ab
Press OK certification will appear on the screen
(2) You can verify that: after
(3) restore is finished
> 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
Once removed until file00 ~ file99 (4)
> Adb shell
$ Cd / data / data / com.android.settings /
$ Rm-r a / *
It permissions to 777 (5) / persist
More (4)
$ While:; do ln-s / persist a/file99; done
While doing this, in a separate command line
adb restore p-07d.ab
Run to complete the restore
After you have finished, exit the adb shell
Check the permissions on the (6) / persist
> Adb shell
$ Ls-l-d / persist
drwxrwxrwx system system persist
Execute the following command (7)
> Adb push init.cne.rc / data / local / tmp
> Adb push p07dgetroot / data / local / tmp
> Adb push xsh / data / local / tmp /
> Adb push libQ.so / persist
> Adb shell rm / persist / init.cne.rc
> Adb shell ln-s / data / local / tmp / init.cne.rc / persist / init.cne.rc
> Adb reboot
? / persist directory should only put a symbolic link to the / persist because no recovery will be restored at startup,
Was changed to put in / data / local / tmp is basically
================================================== ==
(Ensure that you have become a LD_PRELOAD = / presist / libQ.so) confirmation that the environment variable has changed after the move again (8)
> Adb shell
$ Echo $ LD_PRELOAD
/ Presist / libQ.so
Release (9) tomoyo
> Adb shell
$ Cat / data/local/tmp/p07dgetroot> / tmp / xsh
$ Ls-l / tmp / xsh
-Rw-rw-rw-shell shell xsh
The ON / OFF / ON the wireless LAN
$ Ls-l / tmp / xsh
-Rwsr-sr-x root root xsh
$ / Tmp / xsh
/ Tmp / xsh
/ Tmp / .mem fd = 3
read ret = 256
write ret = 256
At this stage, tomoyo is can be released
$ Rm / tmp / xsh
$ Cat / data / local / tmp / xsh> / tmp / xsh
The ON / OFF / ON the wireless LAN
$ Ls-l / tmp / xsh
-Rwsr-sr-x root root xsh
$ / Tmp / xsh
Here, the shell of the root authority to rise, I can operate a variety. can also be installed in the su
Panasonic p-06d
I'm new around here and I don't really understand what u said in the post , but I have the same phone , and I would love to know how to unlock the sim.. some said that I should reinstall my android on it , but I have no idea how to do that or where to get it. So if u find something please update here cuz i would love to unlock my phone:good:
Me too
diablotor said:
I'm new around here and I don't really understand what u said in the post , but I have the same phone , and I would love to know how to unlock the sim.. some said that I should reinstall my android on it , but I have no idea how to do that or where to get it. So if u find something please update here cuz i would love to unlock my phone:good:
Click to expand...
Click to collapse
First of all please excuse my english.
In previous post i said that i have found some japanese guy who managed to ROOT Panasonic Eluga P-07D [NTT Docomo]. It isn't our phone but is very similar. I posted the way he did all the things. I didn't find a way to SIM unlock the phone that is what i am looking for too but once ROOTED i presume it is much easier to unlock. Anyway i am still searching and if i will find something i will post here. Regards
I have screen captures and downloads on my phone that I want to move to my SD card.
When I mount the phone on my Linux computer, I see:
/run/user/1000/gvfs/mtp:host=%5Busb%3A010%2C018%5D$ ls -l
total 0
drwx------ 1 me me 0 Dec 31 1969 Card
drwx------ 1 me me 0 Dec 31 1969 Phone
I did: mkdir Card/DCIM/Screenshots and that worked.
cp -a Phone/Pictures/Screenshots Card/DCIM/Screenshots gives the error "Operation not supported".
I checked the permissions on all the directories in the path and they seem ok.
I tried to chmod to make everything writeable by everyone but that fails too.
I've tried to copy/move the files with a file manager on the phone but that fails too.
$ ls -l
total 0
dr-x------ 1 me me 0 Dec 31 1969 mtp:host=%5Busb%3A010%2C018%5D
$ chmod o+w *
chmod: changing permissions of 'mtp:host=%5Busb%3A010%2C018%5D': Operation not supported
bjlockie said:
I have screen captures and downloads on my phone that I want to move to my SD card.
When I mount the phone on my Linux computer, I see:
/run/user/1000/gvfs/mtp:host=%5Busb%3A010%2C018%5D$ ls -l
total 0
drwx------ 1 me me 0 Dec 31 1969 Card
drwx------ 1 me me 0 Dec 31 1969 Phone
I did: mkdir Card/DCIM/Screenshots and that worked.
cp -a Phone/Pictures/Screenshots Card/DCIM/Screenshots gives the error "Operation not supported".
I checked the permissions on all the directories in the path and they seem ok.
I tried to chmod to make everything writeable by everyone but that fails too.
I've tried to copy/move the files with a file manager on the phone but that fails too.
$ ls -l
total 0
dr-x------ 1 me me 0 Dec 31 1969 mtp:host=%5Busb%3A010%2C018%5D
$ chmod o+w *
chmod: changing permissions of 'mtp:host=%5Busb%3A010%2C018%5D': Operation not supported
Click to expand...
Click to collapse
Hi,
Try this:
Code:
/run/user/1000/gvfs/mtp:host=%5Busb%3A010%2C018%5D$ cp -R Phone/Pictures/Screenshots $HOME/Card/DCIM/Screenshots
I might have your file paths wrong but the logic should work.
I have an old Samsung Galaxy S4. It's been off the network for a while and its system clock has drifted. However, adb works and I can use the old phone as a sandbox environment to learn about low level Android fundamentals. I would like to learn how to root the phone, ideally without using any apps - I prefer to learn how to compile my own local privilege escalation exploit and run it on my old phone.
adb shell getprop ro.build.version.release
5.0.1
adb shell getprop ro.build.version.sdk
21
dumpstate:
Build: LRX22C.I337UCSGOK3
Build fingerprint: 'samsung/jflteuc/jflteatt:5.0.1/LRX22C/I337UCSGOK3:user/release-keys'
Bootloader: I337UCSGOK3
Radio: mdm
Network: (unknown)
Kernel: Linux version 3.4.0-6185444 ([email protected]) (gcc version 4.8 (GCC) ) #1 SMP PREEMPT Wed Nov 30 21:31:59 KST 2016
Command line: console=null androidboot.hardware=qcom user_debug=23 msm_rtb.filter=0x3F ehci-hcd.park=3 [email protected] [email protected] sec_debug.reset_reason=0x1a2b3c00 androidboot.warranty_bit=0 lcd_attached=1 lcd_id=0x418047 androidboot.debug_level=0x4f4c sec_debug.enable=0 sec_debug.enable_user=0 androidboot.cp_debug_level=0x55FF sec_debug.enable_cp_debug=0 cordon=a569d279d878ac52077d6cfb9721d339 connie=SGH-I337_ATT_USA_76d68869445a30d9d8d06ffe689dd803 lpj=67678 loglevel=4 samsung.hardware=SGH-I337 androidboot.emmc_checksum=3 androidboot.warranty_bit=0 androidboot.bootloader=I337UCSGOK3 androidboot.nvdata_backup=0 androidboot.boot_recovery=0 androidboot.check_recovery_condition=0x0 level=0x574f4c44 vmalloc=450m sec_pvs=0 batt_id_value=0 diag=0 androidboot.csb_val=1 androidboot.emmc=true androidboot.serialno=95e836b4 androidboot.baseband=mdm
cat /proc/cpuinfo:
Processor : ARMv7 Processor rev 0 (v7l)
processor : 0
BogoMIPS : 13.53
processor : 1
BogoMIPS : 13.53
processor : 2
BogoMIPS : 13.53
processor : 3
BogoMIPS : 13.53
Features : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4
CPU implementer : 0x51
CPU architecture: 7
CPU variant : 0x1
CPU part : 0x06f
CPU revision : 0
Hardware : SAMSUNG JF
Revision : 000a
Serial : 000095e8000036b4
Android is a ported Linux, hence rooting Android means adding su ( read: switchuser ) functionality welllknown from Linux to device's Android. That's all.
Can get achieved with ADB having a suitable su at hands.
https://forum.xda-developers.com/attachments/su-binaries-zip.5566949/
Do you have source code for that su? I believe it would still require an exploit to escalate privileges, since normally su needs to run with root permissions, and I don't have a way of elevating to root without it.
What you believe ist totally wrong: su doesn't need root permissions to run a shell command, su is what in general is called root.
Code:
su -c "<SHELL-COMMAND-HERE>"
Become familiar with Linux shell commands.
I can already run shell commands using adb shell. However, I cannot run privileged commands because the adb shell process does not run with root privileges. Can you please elaborate further?
OMG.
Code:
adb shell
simply opens a remote Android terminal what doesn't require any elevated privileges per se.
To run shell commands what require elevated privileges ( e.g. mount ) is achieved as follows
Code:
adb shell "<PATH-OF-SU-BINARY-HERE> -c '<SHELL-COMMAND-HERE>'"
Example:
Code:
adb shell "/data/local/tmp/su -c 'mount -o rw,remount /data'"
The adb shell allows running unprivileged commands but there are numerous things which cannot be done without the root privilege, such as remounting filesystems, changing permissions, accessing directories which require elevated privileges, etc. This is what I am asking about. Am I misunderstanding you - are you trying to say that adb shell can be used by an unprivileged user to run privileged commands?
See my revised post above yours.
@jf80dEf
The Samsung Galaxy S4 variant you have is from AT&T (model number SGH-I337) and it's running the final software release (OK3).
For this model, you need to downgrade to a lower firmware (NB1) and achieve root access by exploiting the vulnerability formally known as CVE-2014-3153. More details can be found here.
Thank you @SkandaH for answering my question! I believe the method you suggest involves using Odin to wipe the phone to make it vulnerable to the towelroot exploit. Reading between the lines, am I interpreting correctly that there is no known (at least to you) exploit that runs on the OK3 software?
jf80dEf said:
... am I interpreting correctly that there is no known (at least to you) exploit that runs on the OK3 software?
Click to expand...
Click to collapse
Yes, that's correct.
just for fun, I tried that method on rooted device, it doesn't work for Android 5+
Code:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.
C:\Android>adb devices
List of devices attached
ca1296db7d29 device
C:\Android>adb push su /data/local/tmp
su: 1 file pushed. 0.7 MB/s (75344 bytes in 0.105s)
C:\Android>adb shell
cereus:/ $ cd /data/local/tmp
cereus:/data/local/tmp $ chmod 6775 ./su
cereus:/data/local/tmp $ ls -la
total 84
drwxrwx--x 2 shell shell 4096 2022-12-27 15:22 .
drwxr-x--x 4 root root 4096 2022-07-24 14:19 ..
-rwsrwsr-x 1 shell shell 75344 2022-12-27 15:22 su
cereus:/data/local/tmp $ ./su
"./su": error: Android 5.0 and later only support position-independent executables (-fPIE).
1|cereus:/data/local/tmp $ rm ./su
cereus:/data/local/tmp $ exit
C:\Android>
copied another su binary from stock rooted android tv box (no superuser app required, permissions granted automatically.
Code:
C:\Android>adb push su /data/local/tmp
adb: error: failed to get feature set: more than one device/emulator
C:\Android>adb -s ca1296db7d29 push su /data/local/tmp
su: 1 file pushed. 1.4 MB/s (100068 bytes in 0.070s)
C:\Android>adb shell
error: more than one device/emulator
C:\Android>adb -s ca1296db7d29 shell
cereus:/ $ cd /data/local/tmp
cereus:/data/local/tmp $ chmod 6775 ./su
cereus:/data/local/tmp $ ls -la
total 108
drwxrwx--x 2 shell shell 4096 2022-12-27 15:39 .
drwxr-x--x 4 root root 4096 2022-07-24 14:19 ..
-rwsrwsr-x 1 shell shell 100068 2022-12-27 15:38 su
cereus:/data/local/tmp $ ./su
255|cereus:/data/local/tmp $ ./su --help
Usage: su [options] [--] [-] [LOGIN] [--] [args...]
Options:
--daemon start the su daemon agent
-c, --command COMMAND pass COMMAND to the invoked shell
-h, --help display this help message and exit
-, -l, --login pretend the shell to be a login shell
-m, -p,
--preserve-environment do not change environment variables
-s, --shell SHELL use SHELL instead of the default /system/bin/sh
-u display the multiuser mode and exit
-v, --version display version number and exit
-V display version code and exit,
this is used almost exclusively by Superuser.apk
cereus:/data/local/tmp $ ./su --version
16 com.thirdparty.superuser
cereus:/data/local/tmp $
still it doesn't work from /data/local/tmp as the uid is 2000 (shell) so tried from /data/local where uid is 0 (root)
but I had to use Magisk /sbin/su for this already
Code:
cereus:/data/local/tmp $ ls -la /data/local
ls: /data/local: Permission denied
1|cereus:/data/local/tmp $ ls -la /data/local/tmp
total 108
drwxrwx--x 2 shell shell 4096 2022-12-27 15:39 .
drwxr-x--x 4 root root 4096 2022-07-24 14:19 ..
-rwsrwsr-x 1 shell shell 100068 2022-12-27 15:38 su
cereus:/data/local/tmp $ cp ./su ..
cp: ../su: Permission denied
1|cereus:/data/local/tmp $ which su
/sbin/su
cereus:/data/local/tmp $ /sbin/su -c 'cp ./su ..'
cereus:/data/local/tmp $ cd ..
cereus:/data/local $ ls -la
ls: .: Permission denied
1|cereus:/data/local $ /sbin/su -c 'chmod 6775 ./su'
cereus:/data/local $ /sbin/su -c 'ls -la'
total 120
drwxr-x--x 4 root root 4096 2022-12-27 15:45 .
drwxrwx--x 48 system system 4096 2022-07-24 20:32 ..
-rwsrwsr-x 1 root root 100068 2022-12-27 15:45 su
drwxrwx--x 2 shell shell 4096 2022-12-27 15:39 tmp
drwxrwxrwx 2 shell shell 4096 2022-07-24 14:19 traces
cereus:/data/local $ ./su
255|cereus:/data/local $
despites the SUID bit is set correctly still it doesn't work. so I removed the nosuid mount flag for /data partition and double checked selinux isn't the problem
Code:
255|cereus:/data/local $ grep ' /data ' /proc/mounts
/dev/block/dm-1 /data ext4 rw,seclabel,nosuid,nodev,noatime,noauto_da_alloc,resuid=10010,resgid=1065,errors=panic,data=ordered 0 0
cereus:/data/local $ /sbin/su -c 'busybox mount -o remount,rw,suid /data'
cereus:/data/local $ grep ' /data ' /proc/mounts
/dev/block/dm-1 /data ext4 rw,seclabel,nodev,noatime,noauto_da_alloc,resuid=10010,resgid=1065,errors=panic,data=ordered 0 0
cereus:/data/local $ ./su
255|cereus:/data/local $ getenforce
Permissive
cereus:/data/local $
still no way to get the root shell with that su binary, maybe prevented to run from /data at all. decided to try from other partition but there was no way. although permissions 2000 (shell) should at least see the file, but that wasn't the case. Magisk mount namespaces are set to global, no idea why the file is invisible in /cache
Code:
cereus:/data/local $ grep ' /cache ' /proc/mounts
/dev/block/platform/bootdevice/by-name/cache /cache ext4 rw,seclabel,nosuid,nodev,noatime,discard,noauto_da_alloc,data=ordered 0 0
cereus:/data/local $ /sbin/su -c 'busybox mount -o remount,rw,suid /cache'
cereus:/data/local $ grep ' /cache ' /proc/mounts
/dev/block/platform/bootdevice/by-name/cache /cache ext4 rw,seclabel,nodev,noatime,discard,noauto_da_alloc,data=ordered 0 0
cereus:/data/local $ /sbin/su -c 'cp ./su /cache'
cereus:/data/local $ cd /cache
/system/bin/sh: cd: /cache: Permission denied
2|cereus:/data/local $ /sbin/su -c 'cd /cache'
cereus:/data/local $ /sbin/su -c 'mkdir /cache/tmp'
cereus:/data/local $ /sbin/su -c 'chown 0.2000 /cache/tmp'
cereus:/data/local $ cd /cache/tmp
/system/bin/sh: cd: /cache/tmp: Permission denied
2|cereus:/data/local $ /sbin/su -c 'chown 2000.2000 /cache/tmp'
cereus:/data/local $ cd /cache/tmp
/system/bin/sh: cd: /cache/tmp: Permission denied
2|cereus:/data/local $ /sbin/su -c 'ls -la /cache/tmp'
total 16
drwxr-xr-x 2 shell shell 4096 2022-12-27 15:54 .
drwxrwx--- 8 system cache 4096 2022-12-27 15:54 ..
cereus:/data/local $ /sbin/su
cereus:/data/local # cd /cache/tmp
cereus:/cache/tmp # cp /cache/su .
cereus:/cache/tmp # chmod 6775 ./su
cereus:/cache/tmp # exit
cereus:/data/local $ /cache/tmp/su
/system/bin/sh: /cache/tmp/su: not found
127|cereus:/data/local $ /sbin/su
cereus:/data/local # cd /cache/tmp
cereus:/cache/tmp # ls -la
total 120
drwxr-xr-x 2 shell shell 4096 2022-12-27 15:58 .
drwxrwx--- 8 system cache 4096 2022-12-27 15:54 ..
-rwsrwsr-x 1 root root 100068 2022-12-27 15:58 su
cereus:/cache/tmp # ./su
255|cereus:/cache/tmp # chown -R 0.2000 .
cereus:/cache/tmp # ls -la
total 120
drwxr-xr-x 2 root shell 4096 2022-12-27 15:58 .
drwxrwx--- 8 system cache 4096 2022-12-27 15:54 ..
-rwxrwxr-x 1 root shell 100068 2022-12-27 15:58 su
cereus:/cache/tmp # ./su
255|cereus:/cache/tmp # exit
255|cereus:/data/local $ /cache/tmp/su
/system/bin/sh: /cache/tmp/su: not found
127|cereus:/data/local $ /sbin/su -c 'chmod 6775 /cache/tmp/su'
cereus:/data/local $ /cache/tmp/su
/system/bin/sh: /cache/tmp/su: not found
127|cereus:/data/local $
finally, even tried from within Magisk root shell. still the binary throws error 255. as you can see the su binary owns the sticky bit and uid 0 (root)
Code:
127|cereus:/data/local $ /sbin/su
cereus:/data/local # /cache/tmp/su --version
16 com.thirdparty.superuser
cereus:/data/local # /cache/tmp/su
255|cereus:/data/local # exit
255|cereus:/data/local $ /cache/tmp/su
/system/bin/sh: /cache/tmp/su: not found
127|cereus:/data/local $ /sbin/su -c 'ls -la /cache/tmp'
total 120
drwxr-xr-x 2 root shell 4096 2022-12-27 15:58 .
drwxrwx--- 8 system cache 4096 2022-12-27 15:54 ..
-rwsrwsr-x 1 root shell 100068 2022-12-27 15:58 su
cereus:/data/local $
to confirm the binary is working at least, I wanted to install in /system. Because of systemless-root and avb/dm-verity i can't place file /system partition directly, so I used Magisk bind mount overlay
Code:
cereus:/data/local $ /sbin/su
cereus:/data/local # cd /data/adb/modules
cereus:/data/adb/modules # mkdir su_test
cereus:/data/adb/modules # cd su_test/
cereus:/data/adb/modules/su_test # mkdir -p system/xbin
cereus:/data/adb/modules/su_test # cp /cache/tmp/su system/xbin
cereus:/data/adb/modules/su_test # chown -R 0.2000 system
cereus:/data/adb/modules/su_test # chmod 6775 system/xbin/su
cereus:/data/adb/modules/su_test # ls -la system/xbin
total 108
drwxr-xr-x 2 root shell 4096 2022-12-27 16:10 .
drwxr-xr-x 3 root shell 4096 2022-12-27 16:10 ..
-rwsrwsr-x 1 root shell 100068 2022-12-27 16:10 su
cereus:/data/adb/modules/su_test # echo 'id=su_test' > module.prop
cereus:/data/adb/modules/su_test # echo 'name=su_test' >> module.prop
cereus:/data/adb/modules/su_test # echo 'version=0.0.1' >> module.prop
cereus:/data/adb/modules/su_test # echo 'versionCode=001' >> module.prop
cereus:/data/adb/modules/su_test # echo 'author=aIecxs @ XDA' >> module.prop
cereus:/data/adb/modules/su_test # echo 'description=proof that su binary is "suitable" >> module.prop
cereus:/data/adb/modules/su_test # cat module.prop
id=su_test
name=su_test
version=0.0.1
versionCode=001
author=aIecxs @ XDA
description=proof that su binary is "suitable"
cereus:/data/adb/modules/su_test # ./system/xbin/su --version
16 com.thirdparty.superuser
cereus:/data/adb/modules/su_test # exit
cereus:/data/local $ exit
C:\Android>
after installing the magisk module, rebooted the phone and confirmed su binary works when running from system.
Code:
C:\Android>adb -s ca1296db7d29 shell
cereus:/ $ which su
/sbin/su
cereus:/ $ ls -l /system/xbin/su
-rwsrwsr-x 1 root shell 100068 2022-12-27 16:10 /system/xbin/su
cereus:/ $ /system/xbin/su --version
16 com.thirdparty.superuser
cereus:/ $ /system/xbin/su
cereus:/ #
(note the /sbin/su binary is Magisk while the /system/xbin/su binary is the file copied from android tv box)
as on stock android device user/release-keys build adb root cannot work, there is no way to use the chown command. because it is impossible to place the file into /system or any proper location with directory owner 0 (root) from adb, it's not possible to get root shell from adb.
conclusion: an additional exploit (like mtk-su) is required to achieve this.
edit: fun fact. Magisk complains the foreign su binary that is provided by Magisk module xD