Related
does anyone know how to add new commands to shell ? or it is possible to install bash or something similiar inside, once we have root now ?
this shell inside is really "cuted" and almost all "ordinary(standart)" command I am missing
e.g: more vi and so on
maybe it works in different way , if yes just correct me
Any try to help is appreciated , but please stay on topic. because I can see it is one of the biggest problem here ..
Have you downloaded the newest version of busybox in the marked? This gives you a lot more commands then the first version posted with the initial root, one if them is vi.
thermoska said:
does anyone know how to add new commands to shell ? or it is possible to install bash or something similiar inside, once we have root now ?
this shell inside is really "cuted" and almost all "ordinary(standart)" command I am missing
e.g: more vi and so on
maybe it works in different way , if yes just correct me
Any try to help is appreciated , but please stay on topic. because I can see it is one of the biggest problem here ..
Click to expand...
Click to collapse
I did this:
Download bash binary from here: http://forum.xda-developers.com/showthread.php?t=537827
You can either replace the default "sh" with this (warning: the "sh" binary is the one that gives you root privileges in the first place, so you might loose them, I'm about to experiment with this and would post more details soon) or keep them both.
Download ASE from here: http://code.google.com/p/android-scripting/
This gives you an easy bridge to Android java using a scripting language of your preference.
When you use adb you will have VI and such available. I don't know much about the varios unix/linux shells available but I know that ADB is offering a lot of ****
Diabolico said:
When you use adb you will have VI and such available. I don't know much about the varios unix/linux shells available but I know that ADB is offering a lot of ****
Click to expand...
Click to collapse
no.. that's what busybox is for
Seriously. Why don't we have sudo on Android? Is there some technical limitation I'm missing?
Well, the first thing I'm noticing, is we don't have su under /system/xbin.
So it seems step one would be to compile a compatible binary for the phone in question, and then a method to place su into /system/xbin.
You must be new. What phone you talking about
Sent from my HERO200 using XDA App
I'm a bit new here, but I'm pretty sure I used su. Did you root your phone? If you do, you'll have su. Rooting an evo 4g isn't hard; google it(can't post links; too new).
thatguythatdid said:
You must be new. What phone you talking about
Sent from my HERO200 using XDA App
Click to expand...
Click to collapse
You must be new (to Linux).
Evo 4G, rooted, swapped for Fresh, swapped to DC, swapped to CM6, swapped back to 100% unrooted stock (current status).
In a 'normal' Linux installation, you usually log in as a normal user. Su, ie 'Switch user' or more commonly old-school 'Super user' allows you to temporarily log in as another user (we're going for 'root' here) and utilize that user without logging out and in of the current shell.
Running as root all the time is bad for security, as any Linux user can tell you.
Clearly, I have no desire to run as root on my phone ALL the time.
Also, from a development standpoint, releasing apps that ONLY work on rooted phones is ridiculous - you cut out the vast majority of users.
Which brings me back to the original topic - why don't have we su / sudo on Android yet?
Here's what I've come to this morning:
Well, su and sudo have to be compiled and compatible with the kernel. I was mistaken, in that I thought of Android similar to a normal Linux distribution (aka distro) - usually, you'll have many distros that utilize the same exact kernel, and this runs over a very large number of systems. Thinking deeper, however, I realized that even though most desktops are different, at the end of the day they are all x86 compatible - in other words, low level communication is the same between all major PCs.
On smartphones, however, you've got multiple architectures - I'm most familiar with ARM (Qualcomm) and OMAP (Texas Instruments). The kernels for the two will not be the same, unless we (the community) build a super-kernel that would run on both architectures (unlikely just from an efficiency standpoint). Android is just the framework that sits on TOP of the Linux Kernel.
In my particular case, the Evo 4G, it appears 'su' is not even on the phone. A quick 'adb shell ls -l -R -a > file_permissions.txt' show me, however, there is a hidden directory named 'sbin' on the phone, that is only accessible as root.
So my next step is to re-root my phone, flash the rooted 1.47 OTA image, and see what the hell is in that sbin directory.
The following step, I'm going to compile an ARM compatible copy of sudo, insert it into a non-rooted (stock) image, along with a proper /etc/sudoers file and see if I can develop a way to have a non-rooted image, with the ability to take root at will, on command (whether via su or sudo)
The purpose of this post is to find out if anyone's already attempted this, and if so, where they got stuck.
I have a /system/bin/su on my phone (G1 w/ CM6RC2). Any 'rooted' ROM should have the same. I don't understand why you think otherwise.
I'm the developer of QuickSSHd, an app that runs a secure shell daemon, either as root or not-root. I've also submitted (small) patches (and had them accepted) to the Superuser.apk and su.c that is used on most of the newer rooted ROMs. I've been using Linux for > 10 years.
Which brings me back to the original topic - why don't have we su / sudo on Android yet?
Click to expand...
Click to collapse
We do have su on Android. And the su we have is done in a way that it's more like sudo as it prompts the user for allow/deny and remember. But no password is needed.
http://github.com/ChainsDD/android_packages_apps_Superuser
http://github.com/ChainsDD/android_packages_apps_Superuser/blob/eclair-froyo/su.c
If for some reason you want to compile sudo you'll run into issues that Android's libc doesn't include crypt for passwords as the user system is completely different on Android. I don't think anyone has tried as it would be rather pointless with the above Superuser.apk and su (usually /system/xbin/su or /system/bin/su)
[email protected] said:
I'm the developer of QuickSSHd, an app that runs a secure shell daemon, either as root or not-root. I've also submitted (small) patches (and had them accepted) to the Superuser.apk and su.c that is used on most of the newer rooted ROMs. I've been using Linux for > 10 years.
We do have su on Android. And the su we have is done in a way that it's more like sudo as it prompts the user for allow/deny and remember. But no password is needed.
http://github.com/ChainsDD/android_packages_apps_Superuser
http://github.com/ChainsDD/android_packages_apps_Superuser/blob/eclair-froyo/su.c
If for some reason you want to compile sudo you'll run into issues that Android's libc doesn't include crypt for passwords as the user system is completely different on Android. I don't think anyone has tried as it would be rather pointless with the above Superuser.apk and su (usually /system/xbin/su or /system/bin/su)
Click to expand...
Click to collapse
Very nice, thank you for the information, Kevin. Believe it or not, I wasn't able to find anything searching here nor via Google.
Very informotive post guys, thanks.
I must ask, where can I find more on how Android is built?
Wouldn't be simple to add the possibility to ask a password while calling su binary? You can tell me it's useless, but some people may don't want anybody to access superuser powers on his phone. It would be safier if in Superuser's preferences we could add a password protection, IMHO. Of course this MUST be an option, not an imposition. But I would appreciate it veeery much.
mike.sw said:
Very informotive post guys, thanks.
I must ask, where can I find more on how Android is built?
Click to expand...
Click to collapse
There is a 2 part video which may help.
Part one is here:
http://m.youtube.com/#/watch?desktop_uri=/watch?v=1_H4AlQaNa0&v=1_H4AlQaNa0&gl=GB
Cheers
Please use the Q&A Forum for questions &
Read the Forum Rules Ref Posting
Moving to Q&A
HUGE BUMP
This was a very valid question. While the wording was.. oblique at best, it does raise a point.
Why are we not using sudo instead of su? Or at least, password protecting su. I realize SuperSu offers this feature if you.. pay for it. Seems backwards.. paying for a linux.. cough. Nevermind.....
In any event, I would think password protecting your su binary would very serious security concern for everyone... unless there's something the Android API does via some.. sandboxing that makes it a non-issue.. (please correct me.)
Side note, admins of this site..
You realize you have 6 trackers for social bullsh and allow passwords for logins to be transmitted in plain text? Better fix it.. before someone gets naughty and follows those spider webs....
Long story short because android OS is not open source like linux. They is how cell company's still make dollars
---------- Post added at 01:19 PM ---------- Previous post was at 01:10 PM ----------
Not
Doward said:
You must be new (to Linux).
Evo 4G, rooted, swapped for Fresh, swapped to DC, swapped to CM6, swapped back to 100% unrooted stock (current status).
In a 'normal' Linux installation, you usually log in as a normal user. Su, ie 'Switch user' or more commonly old-school 'Super user' allows you to temporarily log in as another user (we're going for 'root' here) and utilize that user without logging out and in of the current shell.
Running as root all the time is bad for security, as any Linux user can tell you.
Clearly, I have no desire to run as root on my phone ALL the time.
Also, from a development standpoint, releasing apps that ONLY work on rooted phones is ridiculous - you cut out the vast majority of users.
Which brings me back to the original topic - why don't have we su / sudo on Android yet?
Here's what I've come to this morning:
Well, su and sudo have to be compiled and compatible with the kernel. I was mistaken, in that I thought of Android similar to a normal Linux distribution (aka distro) - usually, you'll have many distros that utilize the same exact kernel, and this runs over a very large number of systems. Thinking deeper, however, I realized that even though most desktops are different, at the end of the day they are all x86 compatible - in other words, low level communication is the same between all major PCs.
On smartphones, however, you've got multiple architectures - I'm most familiar with ARM (Qualcomm) and OMAP (Texas Instruments). The kernels for the two will not be the same, unless we (the community) build a super-kernel that would run on both architectures (unlikely just from an efficiency standpoint). Android is just the framework that sits on TOP of the Linux Kernel.
In my particular case, the Evo 4G, it appears 'su' is not even on the phone. A quick 'adb shell ls -l -R -a > file_permissions.txt' show me, however, there is a hidden directory named 'sbin' on the phone, that is only accessible as root.
So my next step is to re-root my phone, flash the rooted 1.47 OTA image, and see what the hell is in that sbin directory.
The following step, I'm going to compile an ARM compatible copy of sudo, insert it into a non-rooted (stock) image, along with a proper /etc/sudoers file and see if I can develop a way to have a non-rooted image, with the ability to take root at will, on command (whether via su or sudo)
The purpose of this post is to find out if anyone's already attempted this, and if so, where they got stuck.
Click to expand...
Click to collapse
Hi there, i was trying to run Debian on my pro, but i cant install it! i try two methods, the Linux installer Beta 1.7 (say kernel dosnt have ext and loop support) and the SU terminal emulator way (cant chmod to 4755 any file, even using the su command - from here: http://www.talkandroid.com/android-forums/android-development/1091-install-debian-android.html )...
My pro is ROOTED with latest z4root, i even do a factory repair with pc companion...
Any advice???
Regards!
I tried this as well... no loop is no loop ( required for chroot type runs )
works on a Samsung i5700 I have at work tho...
thnx for the reply, so i can add loop and the ext thing? or we need a custom kernel? , what rom have the samsung?, in other hand i dont know why i cant chmod the files, even using root explorer! regards...
needs a new kernel yes.
i5700 is running samdroid cooked ( forget which version, but added multitouch )
damn :/
now why i cant chmod the files using su terminal emulator or root explorer? maybe is because my sdcard is formated in fat32, regards!
fat32 knows nothing about *nix style permissions, in a way though... all files on a fat32 are set 0777, but not really... heh
For what it's worth, I've just had Debian running in a chroot on my X10 Mini Pro, using the instructions at talkandroid.com, as mentioned by the original poster. Sorry, but as a new poster, I'm not allowed to link directly to those directions. This is with stock ROM, upgraded to Android 2.1, rooted with SuperOneClick.
A few modifications are necessary to make it work. I'm going to try to describe what I've done, but I am working backwards, so it's entirely possible that I'll leave something out and you could suffer disastrous consequences. So please be sure you back up all crucial data before proceeding, and be prepared to accept the possibility that your phone could be destroyed in the process.
First of all, the instructions tell you to run scripts from your SD card, which isn't going to work unless the card has a partition with a Linux-compatible file system. I suggest following the directions as far as step 4. Then replace the "bootdeb" file in the "debian" directory with the modified version attached to this post. Rename it "bootdeb". Then you will have to run the following commands manually, preferably using adb shell, but it can be done in a terminal on the phone. Either way, using the ash shell helps by providing command completion and history.
As root (su):
Code:
mount -o remount,rw -t yaffs2 /dev/block/mtdblock0 /system
mkdir /data/local/mnt
cd /sdcard/debian
cp bootdeb /data/local/bin #note: you may need to mkdir /data/local/bin first
cd /data/local/bin/
chmod 4777 bootdeb
You should now be able to run the bootdeb script to start up Debian.
The installation file says, "Be sure to run /scripts/onetime.sh as root from the shell after your FIRST 'boot'." This will prompt you to set a root password.
At this point, the Debian installation is command line only and root only. The image file needs to be resized before much can be added.
The other files in the Debian directory may be useful, but they all need to be modified before they can be used.
This is only a beginning. I don't know that I'm likely to get very far with it, so anyone else who's inclined to jump in and make this work better is welcome to do so!
edit: correcting grammatical error
Just in case anyone else shares my obsession -- I mean interest in getting Debian to run on an X10 Mini Pro, I thought I should report my progress. Or lack thereof.
Actually, as I said in the previous post, command line Debian works, and that's a lot of power to have available. But it would be nice to get X working, despite the lack of video drivers.
There's a lot of information out there about setting up X with a VNC server on an Android phone, then running a VNC client to access the graphic environment. The source of most accounts seems to be a thread at the androidfanatic forums, with the title "Gnome, KDE, IceWM or LXDE Desktop on your Android!"
(Sorry, I'm still too new at this to be allowed to post links, so this is the only way I can indicate where to find the information.)
I've tried lots of variations on those directions, trying to adapt them to the X10 Mini Pro. And I've had a little success. I can get to the Icewm or LXDE desktop and run the terminal program, but I can't start any programs that use X. Invariably, I get this error:
Error: Can't open display: :1.0
I've run out of ideas, so I'm taking a break from the project. If anyone else is interested enough to try, good luck to you!
For what it's worth, the most recent and comprehensive account of running Debian with X on Android phones appears to be at lanrat.com, in the "android" directory, filename "debian".
@RobbH
Very interesting! I'm waiting a new 8gb card so that I try it! Should you come up with any new progress please report here
Hi,
I tried to upgrade the busybox with different manner (busybox, busybox installer, manual installation from xda), but no one works properly.
Each time i broke the original Archos busibox, so i lose the adb shell.
Can someone explain to me the good way to upgrade the busybox?
Thanks.
SirOch
Hi,
Nobody to explain a clean upgrade of the busybox?
cheers
SirOch said:
Hi,
Nobody to explain a clean upgrade of the busybox?
cheers
Click to expand...
Click to collapse
Google? also XDA has a great search feature have you tried that? :silly: Any particular reason why you want/need to upgrade busybox?
Hi,
As i said, i tried the different busybox installers and the installation was ok, but i each time, i lost the shell from adb.
That's just my problem.
So i just want to understand why the upgrade of the busybox broke the original archos busybox?
Moreover some application need to have other busybox installed.
Regards.
David
SirOch said:
Hi,
As i said, i tried the different busybox installers and the installation was ok, but i each time, i lost the shell from adb.
That's just my problem.
So i just want to understand why the upgrade of the busybox broke the original archos busybox?
Moreover some application need to have other busybox installed.
Regards.
David
Click to expand...
Click to collapse
Ahhh right, the quest for knowledge Your problem is as much to do with adb ( /sbin/adbd to be precise ) as it is to do with busybox, firstly you've probably wiped out the symlinks in /bin, especially /bin/sh which is the location that adbd on archos looks to run the when you do adb shell from your desktop. This is not the default location which just about every other android OEM adheares ,that is /system/bin/sh.
If you are going to upgrade the archos busybox be aware that a large number of symlinks back to /bin/busybox exist not only in /bin but also in /usr/bin /usr/sbin
Archos for reasons I still haven't fathomed, really went to town on restructuring and customized Android on the platform level.
A little tip if you've got more question, to save you bumping threads , which really does upset some folks round here... you'll probably get more more if you add more details, such as error messages etc. Saying " i lost the shell from adb." doesn't really help anyone who might be able to offer assistance. There about 10 different ways adb can fail to connect, Did the device disappear from the list or report as offline. or even come up with the message "- exec '/bin/sh' failed: No such file or directory (2) -".??
Hopefully that's helped.
Hi SirOrch,
i don't know why you loose your adb shell, but concerning busybox... the things on Archos tablets are like this:
Basically on a non rooted device we got a squashfs image mounted read only.
This image contains the stock busybox compiled by Archos (sharing system's uclibc) with limited functionality,
but containing enough tools to handle the daily job.
The path to this busybox is "hard-coded" as well. It's location is /bin which is the second entry in the path environment.
You might check that by typing printenv in your console.
The first entry should be /data/local/bin on your device.
So if you like to replace stock busybox with an advanced one, you should make sure that it will be installed to /data/local/bin.
Often there's no need to use all this apk Android Market stuff to get a proper busybox installation.
Sometimes it's little better to really understand what's happening under the hood.
Most busybox app's are statically linked, because with a static binary you don't have to take care of the device's libc or uclibc.
So you might easily extract on of the apk's or get one from xda-developers.
There are many floating around in the end.
If got one push it to /data/local/bin with adb.
You might need softlinks in this directory as well. This could be done by hand as well.
Anyway if you are a lazy person, who doesn't care about what's happening, go to the market install busybox.
Then check at /data/local/bin if it is there.
If it got installed elsewhere, some commands will still use stock busybox.
Extended commands might then use the installed one.
So check it out...
EDIT:
... aaaargh again simultaneous posting.
scholbert
Hi gentlemen,
Thanks for your help and sorry to forget to give you the error message i had:
the message was : - exec '/bin/sh' failed: No such file or directory (2) -
After investigation i found my mistake:
- In manual mode, i forget to change the ownership of busybox to root in /bin.
- when i tried to use any application from the market, the busybox was well updated in /system/xbin but the application also delete the busybox in /bin and don't change the symlinks in /bin. That's explain why adb shell won't work.
Regards.
SirOch
Hello, friend! Firstly, I'd like to thank you for viewing this thread! Secondly, I'd like to thank you for ANY help ahead of time!
I must say that this has been a pretty rocky road, but I am hoping to gain some traction! I am not all that new to Android modifications and certainly not new to the Linux command line. Due to these two truths, it amazes me just how much difficulty I am having with my current project. I recently purchased a device from an up-and-coming manufacturer. It is a beautiful, powerful, and well crafted device! Sadly, due to the little recognition the manufacture gets, there is limited ROM support. Even more so, there is limited recovery support. Of course, by little, I mean zero. This was not a problem to me, however! I am a "If you want it, you do it yourself." kind of person. It's a bit more frustrating than the root, recovery, backup, flash system I've been able to follow in the past, but I know it will make the end outcome that much sweeter. Through a bit of research, I've found that I seemingly am able to completely circumvent the need to port Clockworkmod by simply using UniFlash on my excruciatingly slow Windows based laptop. From there, I am left with needing to port the ROM I desire, Cyanogenmod 12, to my device. I've come to learn that I do not need to build from source, rather I can tailor an existing recovery to fit my device. I am unsure if that is true, so that may need to be cleared up. I've went ahead and installed the adb and found my way to a porting guide on the Cyanogenmod Wiki. This is where I am running into problems, humorously early. I do not seem to have adb permissions for my device.
When attempting to grab my build.prop, I get this return:
Code:
[email protected]:~$ adb pull /system/build.prop
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
error: insufficient permissions for device
After realizing my computer may not see the device, I tried to see which were connected:
Code:
[email protected]:~$ adb devices
List of devices attached
???????????? no permissions
It seems I do not have any access to the device at all. USB Debugging is connected, it is a rooted device, and it is set show as a USB Storage. I'm sure if I can at least get this fixed, I should be able to find my way through the rest of the guide myself.
Thank you for any help I can receive!
EDIT 01-
So, I decided to do more digging, and I guess I needed to START the server as super user, and not just run commands in super user.
After running this command, I was able to use my others with permission:
Code:
[email protected]:~$ sudo adb start-server
Now, I am running into a problem in which my device is offline:
Code:
[email protected]:~$ adb pull /system/build.prop
error: device offline
After referring to this thread, I seem to get a new response:
Code:
[email protected]:~$ adb pull /system/build.prop
error: device not found
I feel it's safe to say I should remove 51-android.rules from my ~/rules.d/.
EDIT 02-
It seems I have answered my own question with research. I guess I just needed to update to the newest version because Android 4.2+ requires bridge authorization to complete tasks, and my version did not know to do that! I was successfully able to pull my build.prop!