Hello,
So I did something stupid. Not sure what, but I managed to get my phone into a state where NO shell commands work other than cd and su.
./adb shell
$ su
# ls
# top
# free
free: not found
# cat
# df
# more
more: not found
# less
less: not found
# busybox
busybox: not found
# sh
# ssh
ssh: not found
# vi
vi: not found
#
The phone is a Motorola MB502 (Charm), rooted using Universal Androot 1.63.
Currently running the stock Telus ROM (don't really have a choice there...)
Any way I can get this working ?
There is a market app that will attempt to install busybox, if you want to try that.
Do you mean
stericson.busybox ?
because I can't seem to find it on the market, and can't use MarketEnabler since my shell is broken.
With a bit of searching I noticed that all the files in /system/bin seem to be 0-byte files. Perhaps someone who has a Charm could post these files?
$adb pull /system/bin/top
$ls -l
total 0
-rw-r--r-- 1 root root 0 2011-01-18 17:25 top
$
On 4.1.1 completely stock. I used OTA Root Keeper to retain root successfully.
TiBu and Root Explorer were already running as root and still get root access.
Any new apps never prompt for superuser authority??
Root Checker Pro says I'm rooted,
OTA Root Keeper says:
x Superuser app installed
x Device rooted
Root permission granted
x /system supports root protection
x Protected su copy available
I tried to install SuperSU but that also failed, it doesn't
prompt for superuser rights so it can't write the su
binary.
I'm confused, what changed? how do I fix it?
I can't go into details now but your su binary is the problem. Do not uninstall anything that still has root as you will lose it. I can go into more details when I get to the office later this morning.
Sent from my SCH-I510 using xda app-developers app
su binary issues?
Reilly1812 said:
I can't go into details now but your su binary is the problem. Do not uninstall anything that still has root as you will lose it. I can go into more details when I get to the office later this morning.
Sent from my SCH-I510 using xda app-developers app
Click to expand...
Click to collapse
Thanks, I do have root access from adb I should be able to push a new binary
then set its perms, from adb shell.
Where would I find the binary I need?
I was using Superuser.apk and its binary.
Shouldn't OTA rootkeeper have saved a copy?
it says I have root, and it has copy somewhere.
--> Root Checker output
Congratulations! You have root access!
Super User Applications Status:
Superuser application - version 3.1.3 - is installed!
SuperSU application - is NOT installed.
System File Properties for Root Access:
Standard Location
Check Command: ls -l /system/xbin/su:
Result: /system/xbin/su: No such file or directory
Analysis: File /system/xbin/su does not exist.
Standard Location
Check Command: ls -l /system/bin/su:
Result: -rwsr-sr-x root root 22364 2013-01-29 02:14 su
Analysis: Setuid attribute present and root user ownership present. Root access is correctly configured for this file! Executing this file can grant root access!
Alternative Location
Check Command: ls -l /sbin/su:
Result: /sbin/su: Permission denied
Analysis: File system permissions restricted and denied access.
Alternative Location
Check Command: ls -l /system/xbin/sudo:
Result: /system/xbin/sudo: No such file or directory
Analysis: File /system/xbin/sudo does not exist.
Root User ID and Group ID Status:
Root user id:
uid=0(root)
Root group id:
gid=0(root)
System Environment PATH: /sbin /vendor/bin /system/sbin /system/bin /system/xbin
ADB Shell Default User:
ADB shell setting for standard access, stored in default.prop, is configured as: shell (non root) user - ro.secure=1
Results provided on your ASUS Transformer Pad TF300T device by Root Checker Pro version 1.3.1 from joeykrim in the Android Market - http://goo.gl/NcnHn
I had exactly the same problem when I first upgraded from ICS to JB. Thought I had root until I decided to try AdAway. I uninstalled AdFree and attempted to install AdAway. The install failed stating that I did not have root. Of course I did since AdFree worked, ES File Explorer worked, Terminal Emulator worked, etc. Searched and searched and found discussion which highlighted the su binary to be the issue. Attempted to use the app to update the binary and it failed. I believe (and watch how fast I get corrected!) that the implementation of multiuser support in android is what requires the new versions of superuser and the binary. I documented the permissions of the existing su in /system/bin/ and ensured that I did not have another in /system/xbin/. Using ES File Explorer I copied and pasted on top of the existing su in /system/bin, checking to ensure permissions were good. You should then be able to download the latest and greatest binary using the app. This was all done with superuser. I have not worked with SuperSU. I crossed my fingers and restarted the tablet. I was good to go and have full root.
Please note that others have come back and stated that it did not work for them. I can tell you what worked for me and why I believe it did. I will add the link to the post discussing this problem as soon as I find it again.
Check out this thread which worked using adb.
http://forum.xda-developers.com/showthread.php?t=2183105
[Solved] that seems to have worked
downloaded updated su binary
adb pushed to /sdcard
adb shell
Code:
/system/bin/su
mount -o remount,rw /system
mv /system/su /system/su.bak
cat /sdcard/su > /system/bin/su
chmod 6755 /system/bin/su
exit
adb reboot
Hi,
I'm having an issue with all terminal emulators (Android Terminal Emulator, ConnectBot, ...) after upgrading my Nexus 10 from Android 4.2.2 to 4.3.
The terminal is not recognizing the actual size of the screen and it is fixed to 80 columns and 20 rows. I can temporarily fix it typing "stty cols 180 rows 35", but those values depend on the screen rotation, font size, etc.
This is really weird, and I wasn't having this issue before the upgrade.
Anyone else has this problem or know how to solve it?
Thanks!
Ok, i've been doing some tests.
It seems to be a 'su' bug, it is not receiving the SIGWINCH signal.
If I type without su:
trap 'echo sigwinch' SIGWINCH
It is executed every time I rotate the tablet or popup the keyboard.
But, under su, the same command is not working.
It may be a permission issue.
Any ideas?
I can confirm having the same issue with my Nexus 10 and android 4.3. As soon as I run su - from the terminal (Android Terminal Emulator) the lines start wrapping at 80 characters.
Hi,
i've been working on this trying to find a solution.
Here is what I saw:
Every time I enter su or enter chroot (i have a chrooted debian), the tty number is changed to another one. That isn't the usual tty behavior!
So, if the normal user is in /dev/pts/0 , root could be in /dev/pts/1 and chroot in /dev/pts/2.
If I rotate the screen /dev/pts/0 cols and rows are changed even if I am as root, I can verify that by typing:
stty -F /dev/pts/0 -a
But, if I am at /dev/pts/1 i'm not receiving that SIGWINCH signal. In common linux distributions, that is not happening as pts number doesn't change.
Here is my (not so perfect) solution for the chrooted debian:
Write a fix_stty.sh script as root:
#!/bin/bash
sttypath=/bin
tty0=$(ls --sort time /dev/pts/ | head -n 1 | awk '{print $1}')
stty0=$($sttypath/stty -F /dev/pts/$tty0 -a | head -n1)
rows=$(echo $stty0 | sed -e 's:.*rows\ \([0-9]\+\).*:\1:g')
cols=$(echo $stty0 | sed -e 's:.*columns\ \([0-9]\+\).*:\1:g')
$sttypath/stty rows $rows cols $cols
Save it in /usr/local/bin
Make it executable:
chmod +rx /usr/local/bin/fix_stty.sh
Add to ~/.bashrc this line:
trap '/usr/local/bin/fix_stty.sh' DEBUG
Or if you use non-root users:
trap 'sudo /usr/local/bin/fix_stty.sh' DEBUG
And add to sudoers file:
%sudo ALL = (ALL) NOPASSWD: /usr/local/bin/fix_stty.sh
Logout and login again, and it will fix the rows and columns before each command.
----
For su, outside the chrooted linux write a script fix_stty.sh:
sttypath=/system/xbin
tty0=$(/system/xbin/busybox ls -t /dev/pts | head -n1)
stty0=$($sttypath/stty -F /dev/pts/$tty0 -a | head -n1)
rows=$(echo $stty0 | sed -e 's:.*rows\ \([0-9]\+\).*:\1:g')
cols=$(echo $stty0 | sed -e 's:.*columns\ \([0-9]\+\).*:\1:g')
$sttypath/stty rows $rows cols $cols
Save it to /system/xbin
(You should remount /system as rw: mount --remount -orw /system)
Then, make it exec:
chmod 755 /system/xbin/fix_stty.sh
And, finally you should type at each su login:
trap '/system/xbin/fin_stty.sh' SIGINT
(i don't know why DEBUG isn't here)
So you have to press Ctrl+C to fix it.
----
Alternatively, you can write an infinite loop or a simple daemon to fix it, but i don't like daemons on my tablet.
If anyone has a better solutions, please post it.
Hi all. I've been mulling over this problem as well. I believe the issue is because in 4.3, SuperSU now uses a "proxy", where commands are sent form the process which called su to daemonsu, which is launched at system startup. Chainfire explains a bit more in his G+ posts the reasons for doing this, but I think the key here is that root processes are now launched on a different tty, because they are launched by a different process (namely, daemonsu). Starting a root shell (whether system shell or ubuntu/debian chroot) now results in the creation of three pts devices, as opposed to the usual one. However, other shells not launched locally are fine. For example, starting the SSH server in my chroot and logging in via SSH is always fine.
I'm still trying to figure out a permanent solution to this problem. I still don't have a full understanding of the problem as I'm still trying to wrap my head around how Linux handles terminals and TTYs. I do have a few ideas floating around my head, though:
Change daemonsu and su to support full termios/line-discipline/whatever-we-need through the "pts bridge" that he is using
Create TTY(pts) pairs on demand, and have a modified Terminal Emulator connect to those directly when we want a shell
Have a background-ed process in the original terminal catch SIGWINCH and pass it to the root terminal
Still quite a bit a figure out though. I may just go through Terminal Emulator's source code to see how it work to get a better picture too. But that's gonna take time. I've also created a little native utility which creates two pts pseudo-TTYs and shuffles data between them. I'm still experimenting. Will post more as I learn more.
Just to let you all know that I've got a system working for myself: http://blog.tan-ce.com/android-root-shell/
The way I'm doing it uses a daemon, much like the su daemons ChainFire and Koush are using. The benefit of doing it this way is that I'm not confined by the application container, which is good for security when used by applications, but is annoying when you are using the terminal itself. I remember having to do hacks with adb servers to get around those.
But if you don't want a daemon, you can still set one up manually, just look at the last section of the README on how to use pts-wrap and pts-exec.
I gave this a try.
First, I've noticed that pts-wrap and pts-exec symbolic links were missing.
And I don't think the line '/system/etc/install-recovery-2.sh' in pts-daemon-start file is needed at all.
I'm using ChainFire SuperSU and pts-shell is not working as expected or catching SIGWINCH signals. I just don't see any difference with the standard shell. Maybe I misunderstood how it works.
alf_tux said:
I gave this a try.
First, I've noticed that pts-wrap and pts-exec symbolic links were missing.
And I don't think the line '/system/etc/install-recovery-2.sh' in pts-daemon-start file is needed at all.
Click to expand...
Click to collapse
My mistake, I forgot to create the symlinks for those two.
install-recovery-2.sh is an idea I took from CharinFire's SuperSU. Basically, it seems as if people are using install-recovery.sh to install startup scripts, and having the script try to call install-recovery-2.sh allows you to chain recovery scripts. For example, if you install this on a system with SuperSU, it will be installed as install-recovery-2.sh. If the system doesn't already have an install-recovery.sh, it'll install itself as install-recovery.sh.
Anyway, I've fixed and uploaded a new zip.
alf_tux said:
I'm using ChainFire SuperSU and pts-shell is not working as expected or catching SIGWINCH signals. I just don't see any difference with the standard shell. Maybe I misunderstood how it works.
Click to expand...
Click to collapse
Are you running pts-shell from a regular (non-root) shell, or from a root shell? It should be run from a non-root shell. (It will give you a root shell once it runs.) Only pts-passwd and pts-daemon is meant to be run as root.
tan-ce said:
Are you running pts-shell from a regular (non-root) shell, or from a root shell? It should be run from a non-root shell. (It will give you a root shell once it runs.) Only pts-passwd and pts-daemon is meant to be run as root.
Click to expand...
Click to collapse
Yes, here is my the terminal output:
[email protected]:/ $ ps | grep pts
root 136 1 760 180 ffffffff 00000000 S /system/xbin/pts-daemon
[email protected]:/ $ pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
Could not connect to socket: Permission denied
255|[email protected]:/ $ su pts-shell /system/bin/sh
[email protected]:/ #
As you see, I can only run pts-shell as root.
alf_tux said:
Yes, here is my the terminal output:
[email protected]:/ $ ps | grep pts
root 136 1 760 180 ffffffff 00000000 S /system/xbin/pts-daemon
[email protected]:/ $ pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
Could not connect to socket: Permission denied
255|[email protected]:/ $ su pts-shell /system/bin/sh
[email protected]:/ #
As you see, I can only run pts-shell as root.
Click to expand...
Click to collapse
Sorry, I realized that the correct command should be:
[email protected]:/ $ su -c pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
(pts-shell) Enter your password:
[email protected]:/ #
Anyway I can only run this as root.
Oh yeah, I found the bug. Sorry, my bad. I've fixed it and uploaded a new copy of the update ZIP, but you don't have to upgrade if you don't want to. Running
Code:
# chmod 0701 /data/pts
should be sufficient to fix the problem. Then you should be able to run pts-shell from a regular (non-root) shell.
tan-ce said:
Oh yeah, I found the bug. Sorry, my bad. I've fixed it and uploaded a new copy of the update ZIP, but you don't have to upgrade if you don't want to. Running
Code:
# chmod 0701 /data/pts
should be sufficient to fix the problem. Then you should be able to run pts-shell from a regular (non-root) shell.
Click to expand...
Click to collapse
I don't think that was the the bug:
[email protected]:/ $ su
[email protected]:/ # ls -l /data/pts
-rw------- root root 61 2013-08-28 19:09 passwd
srw-rw-rw- root root 2013-08-28 18:59 pts
[email protected]:/ # chmod 0701 /data/pts
[email protected]:/ # ls -l /data/pts
-rw------- root root 61 2013-08-28 19:09 passwd
srw-rw-rw- root root 2013-08-28 18:59 pts
[email protected]:/ # ^D
[email protected]:/ $ pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
Could not connect to socket: Connection refused
255|[email protected]:/ $
I have also tried:
chmod 0701 /data/pts/pts
And
chmod 0701 /data/pts/*
I'm getting the same connection refused. Maybe you can send me a debug version, I can run it just to find what is going on.
alf_tux said:
I'm getting the same connection refused. Maybe you can send me a debug version, I can run it just to find what is going on.
Click to expand...
Click to collapse
That's strange. Could you show me the output of ls -la? (The "a" is needed to see the permissions for /data and /data/pts itself)
After that, perhaps you could try "chmod 0711 /data/pts"
There isn't a debug version. The error message comes from the part of the code which tries to open a unix socket located at /data/pts/pts. For this to work, /data and /data/pts must have the execute bit set, and /data/pts/pts needs to have the readable and writable bit set for you. Otherwise you'll get a "permission denied".
Perhaps it might be easier for me to just move the socket to /dev like what koush does for Superuser... it's possible the permissions on my /data is non-standard.
On a side note, I'm also currently trying to contribute to koush's Superuser project to fix terminal handling. With any luck, I (or someone else?) will succeed and we won't really need my pts-multi tools anymore.
tan-ce said:
That's strange. Could you show me the output of ls -la? (The "a" is needed to see the permissions for /data and /data/pts itself)
After that, perhaps you could try "chmod 0711 /data/pts"
There isn't a debug version. The error message comes from the part of the code which tries to open a unix socket located at /data/pts/pts. For this to work, /data and /data/pts must have the execute bit set, and /data/pts/pts needs to have the readable and writable bit set for you. Otherwise you'll get a "permission denied".
Perhaps it might be easier for me to just move the socket to /dev like what koush does for Superuser... it's possible the permissions on my /data is non-standard.
On a side note, I'm also currently trying to contribute to koush's Superuser project to fix terminal handling. With any luck, I (or someone else?) will succeed and we won't really need my pts-multi tools anymore.
Click to expand...
Click to collapse
Yes, I agree that fixing su would be better.
I don't have my tablet right know, i don't remember well /data /data/pts and /data/pts/pts read and exec bits. I will see better whan I have my tablet with me.
Here is the output:
/data:
drwxrwx--x system system 2013-08-28 18:59 data
/data/pts:
drwxr-xr-x root root 2013-08-28 19:06 pts
[email protected]:/ $ ls -la /data/pts
-rwxrwxrwx root root 61 2013-08-28 19:09 passwd
srwxrwxrwx root root 2013-08-28 18:59 pts
[email protected]:/ $ pts-shell /system/bin/sh
(pts-shell) /system/bin/sh
Could not connect to socket: Connection refused
255|[email protected]:/ $
I suppose it isn't a permission problem.
alf_tux said:
I suppose it isn't a permission problem.
Click to expand...
Click to collapse
You're probably right, my Nexus 10 could be a bit different because of the semi-botched update I went through. Well, good news on two fronts: First, I updated pts-multi (latest update zip here) to use /dev/pts-daemon as the socket instead of /data... It works on mine, and I think it should work on yours, because Superuser puts its socket there too.
Second, I finished some modifications to the su binary in Superuser (source code here), and I've submitted a pull request to Koush. He says he'll do a code review of my changes, and we'll see how it goes.
tan-ce said:
You're probably right, my Nexus 10 could be a bit different because of the semi-botched update I went through. Well, good news on two fronts: First, I updated pts-multi (latest update zip here) to use /dev/pts-daemon as the socket instead of /data... It works on mine, and I think it should work on yours, because Superuser puts its socket there too.
Second, I finished some modifications to the su binary in Superuser (source code here), and I've submitted a pull request to Koush. He says he'll do a code review of my changes, and we'll see how it goes.
Click to expand...
Click to collapse
T/hanks! I tried your new update and I think it's working!
Can you add a passwordless option? Or if password is blank just don't ask for it
alf_tux said:
T/hanks! I tried your new update and I think it's working!
Can you add a passwordless option? Or if password is blank just don't ask for it
Click to expand...
Click to collapse
Ok, but I took the easiest way out... If you set the environment variable PTS_AUTH, pts-shell will read the password from there instead of prompting you for it. So, if you're writing a script to spawn a root shell, do:
Code:
#!/system/bin/sh
export PTS_AUTH="your password here"
pts-shell /system/bin/sh
The latest update zip is here.
Thanks a lot tan-ce!!
It's working just as I expected!
Glad to hear it.