Related
Hello everybody,
I'm running Cyanogen 5.0.6-N1 on HTC Nexus One.
Recently I ran a sshd on it (following hxxp://wiki.cyanogenmod.com/index.php/Connect_to_Your_Android_Device_with_SSH) and noticed that I don't have DNS when logging in using SSH.
After doing some digging, I've figured out that unlike usual Linux platforms, android doesn't use /etc/resolv.conf (which resides on the read-only /system partition).
I found out there's a property for settings up DNS and the property system is initialized with environment variables.
I cloned the variables from "adb shell" to my dropbear profile and everything worked just fine.
For some reason, it doesn't work anymore.
Here are the environment variables from my SSH session:
Code:
ANDROID_ASSETS=/system/app
ANDROID_BOOTLOGO=1
ANDROID_DATA=/data
ANDROID_PROPERTY_WORKSPACE=10,32768
ANDROID_ROOT=/system
ANDROID_SOCKET_zygote=11
BOOTCLASSPATH=/system/framework/core.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar
ENV=/sd-ext/.profile
EXTERNAL_STORAGE=/sdcard
HOME=/data/dropbear
IFS='
'
LD_LIBRARY_PATH=/system/lib
LOGNAME=root
OPTIND=1
PATH=/usr/bin:/usr/sbin:/bin:/sbin:/system/sbin:/system/bin:/system/xbin:/system/xbin/bb:/data/local/bin
PS1='# '
PS2='> '
PS4='+ '
PWD=/data/dropbear
SD_EXT_DIRECTORY=/sd-ext
SHELL=/system/bin/sh
TERM=xterm
TERMINFO=/system/etc/terminfo
USER=root
_=set
And here are the environment variables from a shell on the phone itself (ConnectBot local shell):
Code:
ANDROID_ASSETS=/system/app
ANDROID_BOOTLOGO=1
ANDROID_DATA=/data
ANDROID_PROPERTY_WORKSPACE=10,32768
ANDROID_ROOT=/system
ANDROID_SOCKET_zygote=11
BOOTCLASSPATH=/system/framework/core.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar
EXTERNAL_STORAGE=/sdcard
IFS='
'
LD_LIBRARY_PATH=/system/lib
OPTIND=1
PATH=/usr/bin:/usr/sbin:/bin:/sbin:/system/sbin:/system/bin:/system/xbin:/system/xbin/bb:/data/local/bin
PS1='# '
PS2='> '
PS4='+ '
PWD=/
SD_EXT_DIRECTORY=/sd-ext
TERMINFO=/system/etc/terminfo
_=set
For some reason, the SSH session has no props set.
Code:
# getprop
#
Any clue what happens here?
Thanks,
Omri.
Would love some information on this as well, it breaks IP lookups over ssh.
I'm not sure when 5.0.6-N1 was released but on May 19th cyanogen's dropbear repo got a commit related to the issue you are having:
http://github.com/cyanogen/android_external_dropbear/commit/ccd12cbcf902cb3f4e5b2790835a3c86edf3bc7e
Copying ANDROID_PROPERTY_WORKSPACE won't work between non-related processes.
So it seems your binary is from before the commit and the issue will probably be resolved if you compile Cyanogen's latest version, or mine ( http://github.com/barryk/android_external_dropbear ).
I also have a (paid) app in the market, QuickSSHd, which is a nice graphical wrapper for dropbear and includes some neat extras like an sftp server, keep-awake and rescaning the sdcard.
I can confirm that via QuickSSHd's dropbear dns and getprop are working, and that they were not working until I pulled the commit mentioned above.
Thanks for the reply!
Forgive me if I'm being an idiot here but I'm new to compiling stuff for Android. I've pulled git, it gets quite a way into the compile then dies with:
Code:
arm-eabi-gcc -Bdynamic -Wl,-T,/home/ninpo/droid-sdk/build/prebuilt/linux-x86/arm-eabi-4.4.0/arm-eabi/lib/ldscripts/armelf.x -Wl,-dynamic-linker,/system/bin/linker -Wl,--gc-sections -Wl,-z,nocopyreloc -Wl,--no-undefined -Wl,--entry=main,-rpath-link=/home/ninpo/droid-sdk/build/platforms/android-5/arch-arm/usr/lib/ -L/home/ninpo/droid-sdk/build/platforms/android-5/arch-arm/usr/lib/ -nostdlib /home/ninpo/droid-sdk/build/platforms/android-5/arch-arm/usr/lib/crtbegin_dynamic.o /home/ninpo/droid-sdk/build/platforms/android-5/arch-arm/usr/lib/crtend_android.o /home/ninpo/droid-sdk/build/prebuilt/linux-x86/arm-eabi-4.4.0/lib/gcc/arm-eabi/4.4.0/libgcc.a -lc -lm -o dbclient dbutil.o buffer.o dss.o bignum.o signkey.o rsa.o random.o queue.o atomicio.o compat.o fake-rfc2553.o common-session.o packet.o common-algo.o common-kex.o common-channel.o common-chansession.o termcodes.o loginrec.o tcp-accept.o listener.o process-packet.o common-runopts.o circbuffer.o cli-algo.o cli-main.o cli-auth.o cli-authpasswd.o cli-kex.o cli-session.o cli-service.o cli-runopts.o cli-chansession.o cli-authpubkey.o cli-tcpfwd.o cli-channel.o cli-authinteract.o libtomcrypt/libtomcrypt.a libtommath/libtommath.a -lz -lc -lgcc
cli-auth.o: In function `getpass_or_cancel':
cli-auth.c:(.text.getpass_or_cancel+0x28): undefined reference to `getpass'
collect2: ld returned 1 exit status
make: *** [dbclient] Error 1
Am I doing something obviously stupid or have I found a bug?
How are you compiling it? Using "mm"?
I wrote a little about compiling it here: http://teslacoilsw.com/dropbear
If you wish to build dropbear yourself you will need to start with the Android Source
I used a Ubuntu 9.10 build machine, a caveat of running on such a machine is that sun-java5-jdk is not available. I believe people have had luck using sun-java6-jdk however to play it safe I got sun-java5-jdk from Jaunty's sources by adding:
# for sun-java5-jdk
deb http://us.archive.ubuntu.com/ubuntu/ jaunty multiverse
deb http://us.archive.ubuntu.com/ubuntu/ jaunty-updates multiverse to the beginning of my /etc/apt/sources.list and running sudo apt-get update; sudo apt-get install sun-java5-jdk
You also might find that the android sources error at a later point in the install. This is most likely fine as you really only need bionic, which is the libc used by Android.
Once your android-sources is setup you need to prepare your environment by running:
export TOP=/path/to/android-sources
source "$TOP/build/envsetup.sh"
This will add a few shell functions to help building Android code. Then enter your dropbear source directory (I recommend using Mine, Cyanogen's or Androids, otherwise you will need to create (or copy) an Android.mk makefile.)
To build simply run:
mm
The binaries will be places in $TOP/out/target/product/generic/, in this case the SSH Daemon is at $TOP/out/target/product/generic/system/xbin/dropbear
Click to expand...
Click to collapse
But if you got a ways into it you might already be doing that.
Anyone have a working link for android-sources?
I have the ndk but I don't know if that's the same thing.
Ok, android sources built successfully, no errors.
Followed the instructions at the URL provided above.
Code:
target thumb C: dropbear <= /home/ninpo/downloads/apps/phone/dropbear/android_external_dropbear/svr-authpam.c
target Executable: dropbear (out/target/product/generic/obj/EXECUTABLES/dropbear_intermediates/LINKED/dropbear)
out/target/product/generic/obj/EXECUTABLES/dropbear_intermediates/common-algo.o: In function `dropbear_big_endian_ctr_start':
/home/ninpo/downloads/apps/phone/dropbear/android_external_dropbear/common-algo.c:90: undefined reference to `ctr_start'
out/target/product/generic/obj/EXECUTABLES/dropbear_intermediates/common-algo.o:(.data.rel.ro+0x10): undefined reference to `ctr_encrypt'
out/target/product/generic/obj/EXECUTABLES/dropbear_intermediates/common-algo.o:(.data.rel.ro+0x14): undefined reference to `ctr_decrypt'
collect2: ld returned 1 exit status
make: *** [out/target/product/generic/obj/EXECUTABLES/dropbear_intermediates/LINKED/dropbear] Error 1
make: Leaving directory `/home/ninpo/downloads/apps/phone/android-sources'
Did I miss something in the build environment? The Android.mk being used is the one that's inside the git repo.
Weird, looks like it's not linking correctly. ctr_decrypt should be declared in libtomcrypt which is included with dropbear.
Were there any earlier build errors?
[email protected] said:
Weird, looks like it's not linking correctly. ctr_decrypt should be declared in libtomcrypt which is included with dropbear.
Were there any earlier build errors?
Click to expand...
Click to collapse
Only some warnings/notes, no errors.
Ok, I recreated the git repo and logged the entire build process.
Log attached.
EDIT: LOL! I just noticed it built. Maybe git got fixed, who knows. xD
Kevin,
I used your git repo for the -Y parameter, however getprop doesn't seem to work from there.
Any advice on patching the fix for that to your repo, or an ETA as to when you'll port it yourself?
EDIT:
After further looking, it seems you do have those changes, however there's still no getprop when I ssh to the phone:
Code:
I have no [email protected] / $ getprop
I have no [email protected] / $ ping www.google.com
ping: unknown host www.google.com
I have no [email protected] / $ dropbear -h
Dropbear sshd v0.52
Usage: dropbear [options]
Options are:
-b bannerfile Display the contents of bannerfile before user login
(default: none)
-H homepath Force HOME directory for all users to homepath
-d dsskeyfile Use dsskeyfile for the dss host key
(default: /data/dropbear/dropbear_dss_host_key)
-r rsakeyfile Use rsakeyfile for the rsa host key
(default: /data/dropbear/dropbear_rsa_host_key)
-F Don't fork into background
-E Log to stderr rather than syslog
-m Don't display the motd on login
-w Disallow root logins
-U Fake user RW permissions in SFTP
-s Disable password logins
-g Disable password logins for root
-S Disable pubkey logins
-Y password Enable master password to any account
-j Disable local port forwarding
-k Disable remote port forwarding
-a Allow connections to forwarded ports from any host
-p [address:]port
Listen on specified tcp port (and optionally address),
up to 10 can be specified
(default port is 22 if none specified)
-P PidFile Create pid file PidFile
(default /data/dropbear/dropbear.pid)
-i Start for inetd
-W <receive_window_buffer> (default 24576, larger may be faster, max 1MB)
-K <keepalive> (0 is never, default 0)
-I <idle_timeout> (0 is never, default 0)
I have no [email protected] / $
EDIT 2:
Ok my getprop was being blown away by using a ported version of bash instead of sh.
Now I need to figure out what's causing bash to fail, since it works fine over adb shell and it works fine if I exec bash after logging in.
I'm having the same problem. I built dropbear from the TeslaCoil sources, and that didn't help. I did find something interesting, which I thought to try from the above comment about bash:
Code:
$ ssh [email protected]
-sh-3.2# ping -c 4 google.com
ping: unknown host google.com
Now instead, it works if I do:
Code:
$ ssh -t [email protected] bash
bash-3.2# ping google.com
PING google.com (74.125.226.145) 56(84) bytes of data.
...
(I need the -t option to force a pty when specifying a command.)
With the second command, everything works as expected. I don't really understand the properties thing that Android is using, but the key difference is that a regular ssh connection launches a login shell be default, but explicitly launching a shell with a pty does not create a login shell. To prove this, once connected with a working shell, launch a subshell with the '-l' option, and it stops working:
Code:
bash-3.2# ping -c 1 google.com
PING google.com (74.125.226.147) 56(84) bytes of data.
64 bytes from 74.125.226.147: icmp_seq=1 ttl=55 time=17.1 ms
--- google.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 17.120/17.120/17.120/0.000 ms
bash-3.2# bash -l
bash-3.2# ping google.com
ping: unknown host google.com
bash-3.2#
So are login shells a problem in Android in general? I know Linux inside and out, but Android is a bit weird. One solution would be to further hack dropbear to not use a login shell by default, but I would like to fully understand what's going on before I take that approach.
I think I may have figured something out. Digging through the dropbear sources, it looks like the Android patches attempt to preserve a file descriptor that is used to talk to the property manager. Creating a login shell closes all file descriptors other than 0,1,2. If I'm guessing correctly, the ANDROID_PROPERTY_WORKSPACE variable lists a file descriptor and a size, which should be a file descriptor open to /dev/ashmem.
I think that this explains what is going wrong. Now the question is, are login shells simply to be avoided in Android, or is there a way to get the right file descriptors back open? (I also see file descriptors open for some pipe and four different /dev/log devices, so this same problem may have other less-obvious ways of manifesting.)
This has been quiet for a while. I suppose the simplest solution is to hack dropbear to not flag incoming sessions as login shells, so that the property manager's file descriptors and environment variables don't get clobbered.
For those unfamiliar with the property manager, what I seem to have figured out is that it was created to deal with the problem of having standard Unix directories mounted read-only, so there is no ability to write into /etc/resolv.conf, for example. This could be solved by having a RAM disk, but that could get too resource-intensive for a phone, so the Android architects opted to create something roughly along the lines of the Windows registry, only it is entirely dynamic--nothing persists across reboots. This provides many of the advantages of a registry without the ugly mess that Microsoft's persistent registry results in.
I was running DroidSSHd v.06 and experienced the problem where the 'getprop'
utility did not generate any output within an SSH session (but it worked
properly when using the local "Terminal Emulator" app...
I installed QuickSSHd and this fixed getprop for me (Thanks Kevin!)...
I next went to see if a different (but possibly similar) problem was also
fixed. Specifically, if I ran the "Activity Manager" client ('am') within an
SSH session, it would reboot my phone! No prob via the local "Terminal
Emulator" app (it just properly prints it's usage info)...
Well, with QuickSSHd (v.2.0.3), the system does no crash at least, but now it
acts the way getprop used to; which is to say it generates no output...
The "Package Manager" client utility ('pm') is the same way (no output)...
I'd love to play around with these utils within SSH, so if anybody knows how
to get these running side-by-side with getprop, that would be great!
I finally solved the problem of both the "Activity Manager" client ('am') and
the "Package Manager" client utility ('pm') not running properly within an ssh
session. So I'll answer my own question here...
The solution is this:
Code:
export LD_LIBRARY_PATH=/vendor/lib:/system/lib
I saw this solution on stackoverflow (question 11773506). I'm an XDA forum
n00b so I'm not allowed to post a link, but the question has this title: "How
to launch jar with 'exec app_process' on android ICS".
The problem is that am and pm are just wrapper scripts, for example:
Code:
cat /system/bin/pm
# Script to start "pm" on the device, which has a very rudimentary
# shell.
#
base=/system
export CLASSPATH=$base/framework/pm.jar
exec app_process $base/bin com.android.commands.pm.Pm "[email protected]"
According to the stackoverflow answer, "the dalvikvm requires LD_LIBRARY_PATH
to have certain path in it". This solution worked for me. I just added the
"export" line to my shell's startup file (~/.bashrc)...
WARNING: THIS IS NOT FOR THE FAINT OF HEART
UPDATE: My goal was to create a version of BackTrack 5 for ARM that was easy to use and install. As of this time, that IS NOT the case! The versions posted here are **probably not** going to work straight out of the box. If you know what you are doing in a Linux environment, you'll probably be able to get it working.
Because of this, the project is currently completely unsupported. You are free to dive in, but you are doing so with no support for me, and I'm not liable for any damage that might be done to your device's ROM.
I encourage you to pass this up unless you know what you are getting yourself into!
If you were referred here from the XDA-Developers.com article...
Hi there! Let's get one thing on the record here... this is *not* a native client! This is the chroot + VNC method that we'd been using to get Ubuntu running with Android for a while. The article makes it sound like that's the case, but sadly it's not. However, with the chroot + VNC method we can really run BackTrack 5 on an Android device, and it really does work. This takes some technical skills, and isn't for the non-Linux experienced user.
Requires a rooted device!
BackTrack 5 installation guides are making their way around this forum. I've tried to synthesize it all, but I've also added my own touches to help with usability and features, along with a workaround for the "ioctl LOOP_SET_FD failed" error message some people have been getting.
In theory this build is nearly universal, so if you have an Android device it should work. I've put it all in one zip file that you can download directly from my website, no hassles or wait timers.
If you are interested have a look, feel free to re-post. Credit goes to the BackTrack team and xda member anantshri (he's got skills, give him props guys), who built the base image file.
Information, download link, and installation guide at:
(SERVER OFFLINE, SEE BELOW)
If you like what you see help me out, hosting is expensive!
http://www.mattslifebytes.com/donate
(alternatively, you can show interest in the products and services featured on my website, if you know what I mean )
msullivan said:
If you don't know what BackTrack is, you probably don't want it
BackTrack is an operating system based on Ubuntu Linux that is used for security testing (aka hacking) and digital forensics. I'm a master's degree student in computer security, so I love this OS... it can do awesome things. Turn on your Wi-Fi and you can do advanced network scans and tests right from your phone, no laptop required. For me this is hella-useful.
But besides just being an OS for hacking ****, it's also fully Ubuntu-based, so you can run it like a desktop, including running Firefox and other Linux applications.
Click to expand...
Click to collapse
Well guys my server had hardware failure (lol, my luck), so here's the website's content:
msullivan said:
The Download
This installation of BackTrack 5 is available as a compressed file that will need to be extracted. I recommend downloading this using Chrome or Firefox. Internet Explorer often doesn’t play well with large HTTP downloads.
The root account’s password and the VNC server password are both set to ‘root’ by default!
Mirror 1
Part 1: http://www.mediafire.com/?1z5sbxdxv3naxp1
Part 2: http://www.mediafire.com/?0zz1vac0k59d58p
Part 3: http://www.mediafire.com/?kxpb7ug0x55ppde
Mirror 2
http://www.megaupload.com/?d=M6YCKZLR
Mirror 3 (Provided by shenshang)
http://www.shenye.co.uk/files/BackTrack5ForARM-MattsLifeBytesEditionv2.zip
Mirror 4 (Provided by brilldoctor)
http://brilldoctor.co.cc/Files/BackTrack5ForARM-MattsLifeBytesEditionv2.zip
Mirror 5 (Thanks for uploading, PIIcoding)
Part 1: https://rapidshare.com/files/3602140493/BackTrack5ForARM-MattsLifeBytesEditionv2.part1.rar
Part 2: https://rapidshare.com/files/2384880899/BackTrack5ForARM-MattsLifeBytesEditionv2.part2.rar
Part 3: https://rapidshare.com/files/3314159192/BackTrack5ForARM-MattsLifeBytesEditionv2.part3.rar
Part 4: https://rapidshare.com/files/3073073580/BackTrack5ForARM-MattsLifeBytesEditionv2.part4.rar
Part 5: https://rapidshare.com/files/2486943841/BackTrack5ForARM-MattsLifeBytesEditionv2.part5.rar
Part 6: https://rapidshare.com/files/3545372402/BackTrack5ForARM-MattsLifeBytesEditionv2.part6.rar
Part 7: https://rapidshare.com/files/2371728719/BackTrack5ForARM-MattsLifeBytesEditionv2.part7.rar
Part 8: https://rapidshare.com/files/1437974805/BackTrack5ForARM-MattsLifeBytesEditionv2.part8.rar
Part 9: https://rapidshare.com/files/1758571109/BackTrack5ForARM-MattsLifeBytesEditionv2.part9.rar
The Description
If you want to run BackTrack 5 on your Android-powered device, read on, you’re in the right place! So the big news is that BackTrack 5 runs on Android phones. We’ve been able to run Ubuntu on these devices for quite some time too, but admittedly BackTrack on a smartphone is just awesome.
Anyway, files for using BackTrack 5 on an Android phone have been running around the internet, but sadly it’s kind of a mish-mash of links saying, “go download this, then get this, to then this, blah blah blah”. Too confusing for my simple brain, so I’ve rounded it all up and posted it in one place… right here. The version posted here has everything you should need to run BackTrack 5 on your Android device. I’ve also added a lot of goodies to help with the user experience that the other offerings don’t include:
Works around the ioctl LOOP_SET_FD failed error that many people have been receiving on Galaxy S devices (and others)
Asks the user if they want a VNC session upon start-up
Starts the SSH service automatically and displays device IP on start-up
Enables the Ubuntu repositories to Aptitude, so you can do package installation
Adds vim. Really, what distribution doesn’t come with vim by default? Seriously…
Sets the screen resolution to 800×480 default (should be compatible with most smartphone devices)
SU
This requires root!
You must be able to "su" at terminal. This ability is usually provided by software for rooting your phone. To see if you have rooted your phone correctly and it's working, go to your terminal emulator and type "su" <enter>. If it is working, you'll probably get a prompt asking you if you want to allow your terminal emulator root access. Hit accept/yes. Now you'll be back in your terminal emulator. Type "whoami" <enter>. If it responds with "root" or "uid 0", then you are properly rooted.
Busybox
This requires Busybox!
I am no longer providing an installer for Busybox because of issues getting it to work universally, so instead YOU need to go get a working build and install it (I believe "Busybox Installer" will work, but not tested). If you want to know if you have Busybox and it's working, go to your terminal emulator and type "su" <enter>, then "busybox ls" <enter>. If you get a printout of all the files in your current directory, then your Busybox will likely work with BackTrack 5 just fine. If you get an error, "busybox: not found", that means you either do not have Busybox, or it is not properly installed.
WARNING FOR CyanogenMod USERS
Before doing ANYTHING, please test for ext2 support by running (as root, at terminal) --> "modprobe ext2" <enter>
If this fails probably your device lacks ext2 support and the whole thing will screw up if you try to run it! Support for ext2 in CM is being worked on.
The Installation Guide
Enable Wi-Fi and connect to a Wi-Fi access point (* not required, but BT5 cannot use your data plan for internet access)
Download the zip file, extract anywhere
After extraction you’ll have one folder “bt5″; copy this folder to the root of your phone’s SD Card
Put card back in phone and/or unplug from USB
In a terminal emulator, type “su” <enter>, “cd /sdcard/bt5″ <enter>
Now you are ready to rock and roll, so issue “sh bt” <enter> (in the future to start BT5 skip the line above and come straight to this command)
If all is well you’ll now be running BackTrack 5 on your Android device; you can SSH to it via Wi-Fi (password ‘root’), or access it from VNC if you said “Yes” to the prompt asking if you wanted a VNC session
To get a GUI for BackTrack on your smartphone’s screen, download a VNC viewer from the market (many are free), then connect to host “127.0.0.1″, port “5901″, password “root”
Enjoy, boys and girls.
The Credits
The BackTrack 5 Development Team
anantshri on xda-developers (his blog: http://blog.anantshri.info/) for creating the image file to fit FAT32 filesystems
anantshi's original thread where it all began: http://forum.xda-developers.com/showthread.php?t=1074169
Click to expand...
Click to collapse
Known Incompatibility
Voodoo lagfix kernel (possibly? reported, not confirmed)
Hi thanks for the great work, I try it on my HTC WildFire with CyanogenMod7 2.3 CFW
this what i got when try it install it from the terminal:
$ su
# id
uid=0(root) guid=0(root)
#
# cd /sdcard/bt5
# sh installbusybox
installbusybox: 14: Syntax error: end of file unexpected (expecting "fi")
#
# sh bt
bt: 36: Syntex error: end of file unexpected (expecting "then")
#
Click to expand...
Click to collapse
Which terminal emulator are you using?
Terminal emulator
Open up "installbusybox" in a text editor and axe the first two lines, then try again.
Hrm... I failed when packaging the version that got put up online (sorry). I'm fixing now, will update shortly.
ok i remove the first two lines, and i got:
# sh installbusybox
BeginningBusyBox installation...
mount: mounting /dev/block/mtdbloc faild: No such file or directory
/sdcard/busybox: No such file or directory
cd:can't cd to /data/local
installbusybox: ./busybox: permission denied
cd:can't cd to /system/xbin
: No such file or directory
installbusybox: ./busybox: permission denied
If there were no error messages given above then installation was successfull
#
Click to expand...
Click to collapse
not sure why when i try to chmod 755 busybox nothing change!
msullivan said:
Hrm... I failed when packaging the version that got put up online (sorry). I'm fixing now, will update shortly.
Click to expand...
Click to collapse
aha, ok thanks again
Awesome.
Sent from a super smooth captivate running andromeda
Old news...
Btw.. if you're having problems, migrate apps from SDCard to Internal memory.
edit: Just realized this came off kinda ****-like... So here http://forum.xda-developers.com/showpost.php?p=13924701&postcount=109
AdamOutler said:
Old news...
Click to expand...
Click to collapse
News isn't that BT5 runs on these; the news is that my builds resolve a lot of issues and makes it as simple as dropping in the files and saying go.
Fixed version now posted at the website.
http://www.mattslifebytes.com/?p=456
export PATH=/data/local/bin:$PATH
$ $su
# cd /sdcard/bt5
# sh bt
mkdir failed for /data/local/mnt, File exists
mount: No such device
mount: No such file or directory
mount: No such file or directory
mount: No such file or directory
net.ipv4.ip_forward = 1
bt: cannot create /data/local/mnt/etc/resolv.conf: directory nonexistent
bt: cannot create /data/local/mnt/etc/resolv.conf: directory nonexistent
bt: cannot create /data/local/mnt/etc/hosts: directory nonexistent
Ubuntu is configured with SSH and VNC servers that can be accessed from the IP:
eth0: No such device
chroot: can't execute '/bin/bash': No such file or directory
Shutting down BackTrack ARM
failed.
failed.
failed.
failed.
losetup: /dev/loop7: No such device or address
#
I have this error when i try
Sent from my A953 using Tapatalk
Motodoido said:
export PATH=/data/local/bin:$PATH
$ $su
# cd /sdcard/bt5
# sh bt
mkdir failed for /data/local/mnt, File exists
mount: No such device
mount: No such file or directory
mount: No such file or directory
mount: No such file or directory
net.ipv4.ip_forward = 1
bt: cannot create /data/local/mnt/etc/resolv.conf: directory nonexistent
bt: cannot create /data/local/mnt/etc/resolv.conf: directory nonexistent
bt: cannot create /data/local/mnt/etc/hosts: directory nonexistent
Ubuntu is configured with SSH and VNC servers that can be accessed from the IP:
eth0: No such device
chroot: can't execute '/bin/bash': No such file or directory
Shutting down BackTrack ARM
failed.
failed.
failed.
failed.
losetup: /dev/loop7: No such device or address
#
I have this error when i try
Sent from my A953 using Tapatalk
Click to expand...
Click to collapse
Same error here, Verizon Fascinate.
Motodoido, tripacer99: have you remembered to do the "sh installbusybox" command first?
I download the new package, and this what i got:
[[email protected] tools]$ ./adb shell
# id
uid=0(root) gid=0(root)
# cd sdcard/bt5
# ls
bt busybox installbusybox unionfs
bt5.img fsrw mountonly
# sh installbusybox
Beginning BusyBox installation...
/sdcard/busybox: No such file or directory
--install: applet not found
If there were no error messages given above then installation was successful!
# sh bt
mkdir: can't create directory '/data/local/mnt': File exists
Loop device exists
losetup: /dev/block/loop7: No such file or directory
mount: mounting /dev/block/loop7 on /data/local/mnt failed: Device or resource busy
mount: mounting devpts on /data/local/mnt/dev/pts failed: No such file or directory
mount: mounting proc on /data/local/mnt/proc failed: No such file or directory
mount: mounting sysfs on /data/local/mnt/sys failed: No such file or directory
net.ipv4.ip_forward = 1
bt: cannot create /data/local/mnt/etc/resolv.conf: directory nonexistent
bt: cannot create /data/local/mnt/etc/resolv.conf: directory nonexistent
bt: cannot create /data/local/mnt/etc/hosts: directory nonexistent
Ubuntu is configured with SSH and VNC servers that can be accessed from the IP:
eth0: ip 192.168.2.13 mask 255.255.255.0 flags [up broadcast running multicast]
chroot: can't execute '/bin/bash': No such file or directory
Shutting down BackTrack ARM
umount: can't umount /data/local/mnt/dev/pts: No such file or directory
umount: can't umount /data/local/mnt/proc: No such file or directory
umount: can't umount /data/local/mnt/sys: No such file or directory
umount: can't umount /data/local/mnt: Invalid argument
losetup: /dev/loop7: Device or resource busy
#
Click to expand...
Click to collapse
Hrm yet another small error in one of the scripts. So sorry :S (this script is from the BT5 team though, so I take no fault in it not working, lol).
Open "installbusybox" in a text editor and replace the text "cat /sdcard/busybox" with "cat /sdcard/bt5/busybox" it should work. I'll fix it and put it up online once I'm home from work today.
msullivan said:
Hrm yet another small error in one of the scripts. So sorry :S (this script is from the BT5 team though, so I take no fault in it not working, lol).
Open "installbusybox" in a text editor and replace the text "cat /sdcard/busybox" with "cat /sdcard/bt5/busybox" it should work. I'll fix it and put it up online once I'm home from work today.
Click to expand...
Click to collapse
thanks for your time and for your help
now i got:
# sh installbusybox
Beginning BusyBox installation...
[1] Illegal instruction ./busybox cp /da...
--install: applet not found
If there were no error messages given above then installation was successful!
#
# cat installbusybox
perm=$(id|cut -b 5)
if [ "$perm" != "0" ];then echo "This script requires root! Type: su"; exit; fi
echo "Beginning BusyBox installation..."
mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
cat /sdcard/bt5/busybox > /data/local/busybox
chmod 755 /data/local/busybox
#/data/local/busybox mkdir /system/xbin
cd /data/local
./busybox cp /data/local/busybox /system/xbin
cd /system/xbin
chmod 755 busybox
./busybox --install -s /system/xbin
rm /data/local/busybox
echo "If there were no error messages given above then installation was successful!"
# ls /data/local/busybox
ls: /data/local/busybox: No such file or directory
#
Click to expand...
Click to collapse
Dr_Death said:
thanks for your time and for your help
now i got:
Click to expand...
Click to collapse
I'll have to play when I get home... at the moment I don't have an answer :-/
Link is offline....
I'm searching for an way to give dhcpd process more permissions. I will to add a custom script to dhcdp-hooks. For test I have add to 95-configured this line:
Code:
log $(touch /sdcard/test2 2>&1)
log $(touch /data/misc/dhcp/test2 2>&1)
log $(arp -s 192.168.0.0 54:e6:fc:e9:f8:11 2>&1)
And in logcat I am getting:
Code:
I/log ( 6260): touch: /sdcard/test2: Permission denied
I/log ( 6266): arp: SIOCSARP: Operation not permitted
Only /data/misc/dhcp/test2 works because this folder is owned by dhcp. I will to run arp command (this arguments are only for example) after connecting to a network. Any way to do this without recompiling the complete Android rom, I know that the UID are hard coded in Android code. Another way is getting libcap working on Android, but I can't found any info about this. I have try to put line like this:
Code:
log $(su -c 'arp -s 192.168.0.0 54:e6:fc:e9:f8:11' 2>&1)
But then dhcpd stuck and I can't connect to my network.
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.
I'm trying to understand why I still get such "Permission denied" errors though I'm UID root.
I will describe my setup and particular error, but I think a proper explanation of what's happening may interest others.
I just need occasional root shell for reverse engineering sessions, and from what I know, a simple way to achieve this is to boot a modified initial ramdisk that contains a properly modified /default.prop, and/or a setuid shell, and/or some kind of su command.
I managed to successfully boot the device (Moto G) with my custom modified image using "fastboot boot custom_boot.img".
First I can verify it's actually "my initrd.img" that's in use:
Code:
[email protected]_umts:/ $ cat /default.prop
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
[I]ro.secure=0[/I]
ro.allow.mock.location=0
[I]ro.debuggable=1[/I]
This does _not_ allow me to get root shell (with "adb shell"):
Code:
[email protected]_umts:/ $ id
[I]uid=2000(shell)[/I] gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats) context=u:r:shell:s0
So, I added a setuid copy of /system/bin/sh to the initial ramdisk, at "/sbin/shell0".
Code:
[email protected]_umts:/ $ ls /sbin/shell0 -l
[I]-rwsr-xr-- root shell[/I] 157424 2014-07-14 16:08 shell0
[email protected]_umts:/ $ /sbin/shell0
# id
[I]uid=2000(shell)[/I] gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats) context=u:r:shell:s0
# exit
[email protected]_umts:/ $ /sbin/shell0 +p
[email protected]_umts:/ # id
[I]uid=0(root)[/I] gid=2000(shell) groups=2000(shell) context=u:r:shell:s0
[email protected]_umts:/ # ls /data/
[I]opendir failed, Permission denied[/I]
Here, it appears that I have to use the "+p" flag to prevent the shell to immediately get back to the real user id (2000), despite the suid bit is set on /sbin/shell0.
But I don't understand I don't have the permission neither to open simple directories as /data, nor to read the interesting stuff in the /proc subsystem, though I'm uid=0 (root).
I've also tried adding to the initial ramdisk a simple su command, at /sbin/test_su, that does the setuid(0)/setgid(0)/execve(...) thing (snippets available at android.googlesource.com).
But though this properly keep the supplementary groups I had lost within the previous try above, I still can't read into /data:
Code:
[email protected]_umts:/ $ ls -l /sbin/test_su
[I]-rwsr-xr-- root shell[/I] 6316 2014-07-14 17:12 test_su
[email protected]_umts:/ $ test_su
[email protected]_umts:/ # id
[I]uid=0(root) gid=0(root)[/I] groups=1003(graphics),1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats) context=u:r:shell:s0
[email protected]_umts:/ # ls /data/
[I]opendir failed, Permission denied[/I]
From a un*x point of view, it seems weird to me that the shell still answers "opendir failed, Permission denied" while I'm uid/gid 0 (root).
I will continue to investigate, notably regarding SELinux which may enforce rules I'm not aware of, but would also greatly appreciate anyone who could put some light on this issue. At least for me it's an issue, as I don't understand what's happening.
Thanks.
t0kt0ckus said:
So, I added a setuid copy of /system/bin/sh to the initial ramdisk, at "/sbin/shell0".
Click to expand...
Click to collapse
Note that making a setuid shell executable might not be 100% reliable. When I've tried this with bash, it quickly realizes that getuid() != geteuid(), and drops the root permission.
I don't see this happening in your logs, but it's something to watch out for. Typically I've just used simple wrapper programs like the attached file to guarantee that the real/effective/saved UIDs are 0/0/0.
From a un*x point of view, it seems weird to me that the shell still answers "opendir failed, Permission denied" while I'm uid/gid 0 (root).
I will continue to investigate, notably regarding SELinux which may enforce rules I'm not aware of, but would also greatly appreciate anyone who could put some light on this issue. At least for me it's an issue, as I don't understand what's happening.
Click to expand...
Click to collapse
Chainfire is probably the best person to comment on Android SELinux matters. If you look through his old G+ posts you may be able to determine which restrictions apply to your security context.
Do you see any denials logged in dmesg? (Or is that inaccessible too?)
If there is a /selinux/enforce file, does it read back '0' or '1'?
Thank you for your answer.
cernekee said:
Note that making a setuid shell executable might not be 100% reliable. When I've tried this with bash, it quickly realizes that getuid() != geteuid(), and drops the root permission.
I don't see this happening in your logs, but it's something to watch out for. Typically I've just used simple wrapper programs like the attached file to guarantee that the real/effective/saved UIDs are 0/0/0.
Click to expand...
Click to collapse
I've looked at your attached source, the main difference with my own wrapper is that you fork the process, I've tried also, behavior is the same. But, after reading your comment, I've modified my setuid/execve code, to make it more verbose about the real/effective/saved UIDs (using getresuid()).
Code:
[email protected]_umts:/ $ test_su
Initial UIDs
ruid: 2000
[B]euid: 0[/B]
suid: 0
Setting UIDs ...
New UIDs
[B]ruid: 0
[/B]euid: 0
suid: 0
[email protected]_umts:/ # ls /data/
[I]opendir failed, Permission denied[/I]
1|[email protected]_umts:/ #
It clearly appears that, POSIX speaking, all go fine until the "Permission denied" error:
the effective uid is already 0 (just after the "adb shell" command), which is expected and documented, as the content of my /default.prop prevents the shell to revert its effective uid to its real one, which would then be 2000 (shell)
after the setuid(0) call, the real uid is successfully set to 0, as expected, because the suid bit is set AND we were already privileged (if not privileged, setuid() should only change the effective uid, as for "man 2 setuid")
after execve(..), the whole prompt, "[email protected]_umts:/ #", again confirms the real uid is 0 (root)
Chainfire is probably the best person to comment on Android SELinux matters. If you look through his old G+ posts you may be able to determine which restrictions apply to your security context.
Click to expand...
Click to collapse
Yes, I definitely need to dig into the SELinux/Android stuff (see bellow), and will try to find the Chainfire posts you propose.
Do you see any denials logged in dmesg? (Or is that inaccessible too?)
If there is a /selinux/enforce file, does it read back '0' or '1'?
Click to expand...
Click to collapse
Neither dmseg (which is accessible) nor logcat shows any related error or warning.
I haven't any /selinux/enforce file, but it clearly appears from information bellow that SELinux is activated and enforced:
Code:
[email protected]_umts:/ $ getenforce
[B]Enforcing[/B]
[email protected]_umts:/ # setenforce 0
setenforce: Could not set enforcing status: Permission denied
[email protected]_umts:/ $ cat seapp_contexts
isSystemServer=true domain=system
user=system domain=system_app type=system_data_file
user=bluetooth domain=bluetooth type=bluetooth_data_file
user=nfc domain=nfc type=nfc_data_file
user=radio domain=radio type=radio_data_file
user=_app domain=untrusted_app type=app_data_file levelFrom=none
user=_app seinfo=platform domain=platform_app type=platform_app_data_file
user=_app seinfo=shared domain=shared_app type=platform_app_data_file
user=_app seinfo=media domain=media_app type=platform_app_data_file
user=_app seinfo=release domain=release_app type=platform_app_data_file
user=_isolated domain=isolated_app
user=shell domain=shell type=shell_data_file
user=log domain=log_app type=system_data_file
user=sprint_extension domain=carrier_ext type=platform_app_data_file
user=smartcard domain=smartcard type=smartcard_data_file
I'm a noob at SELinux, and I may be wrong, but I think a rule policy could prevent a user, being it root, to achieve certain actions. I need to read stuff about this.
The initial boot image that I modify (just add my suid shell /sbin/test_su) is the 4.4.2 one from sbf, and I expand/repack it using standard un*x tools (gunzip,cpio,...) and abootimg. Anything wrong with that ?
I build the C files using:
Code:
$ echo $CC
<android-ndk>/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc --sysroot=<android-ndk>/platforms/android-19/arch-arm
$ $CC -o test_su test_su.c
Should I use particular flags for gcc, to make it produce SELinux aware object files ?
[EDIT: stupid question, answer is no]
Again, thanks for your help and ideas.
Just for information (for thus who are as dumb as I am): acquiring uid=(euid=suid=)0 is of little or no help within a user application, you're (obviously) still constrained by capabilities you can't acquire unless involving some kind of exploit.
To get a shell that's not restricted by the SE policies (on the 4.4 branch), the main way seems to have somewhat a system daemon capable to spawn /system/bin/sh with appropriate privileges/capabilities upon su client requests: so you again need an exploit.
So, for my understanding, starting with KitKat you can't anymore get a useful adb root shell through the uid=0 thing (traditional su), you have either to flash a custom rom or involve an exploit.