Related
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
There were quite a few builds around I have noticed, however with Tiad gone, there only seems to be the basic FRX* and GBX0A.
Even though I never liked "Tiad's" builds, I noticed quite a few things. With little/no coding experience (as far as I can tell) he was just modifying parts of code, causing problems, etc. But still making some huge UI changes that never seemed to have issues.
I have quite a bit of coding experience but never anything for mobile devices I would like to have a look and compile some builds, teaching myself basically.
So I have two questions regarding this:
1: Do the devs use an IRC or something? I would love to sit in on development and see how they work (without interrupting them of course ).
2: Is there some kind of 'cooking' software or a suite that has been put together, like some of the stuff I have seen in the Windows section for this device? Where do I start? I have seen the Chef Central but it is a bit 'full on' and seems to be a mess. I want to be device specific, if possible. Do I use THIS?
Oh and considering I own a RHOD110 (GSM) I am up for testing pretty much anything you guys want me to.
Who knows, by the time android is working I might be up for releasing public builds, and of course NO INCLUDED PAID APPS
ryannathans said:
There were quite a few builds around I have noticed, however with Tiad gone, there only seems to be the basic FRX* and GBX0A.
Even though I never liked "Tiad's" builds, I noticed quite a few things. With little/no coding experience (as far as I can tell) he was just modifying parts of code, causing problems, etc.
I have quite a bit of coding experience but never anything for mobile devices I would like to have a look and compile some builds, teaching myself basically.
So I have two questions regarding this:
1: Do the devs use an IRC or something? I would love to sit in on development and see how they work (without interrupting them of course ).
2: Is there some kind of 'cooking' software or a suite that has been put together, like some of the stuff I have seen in the Windows section for this device? Where do I start? I have seen the Chef Central but it is a bit 'full on' and seems to be a mess. I want to be device specific, if possible. Do I use THIS?
Oh and considering I own a RHOD110 (GSM) I am up for testing pretty much anything you guys want me to.
Who knows, by the time android is working I might be up for releasing public builds, and of course NO INCLUDED PAID APPS
Click to expand...
Click to collapse
Kernel Dev: http://htc-linux.org/wiki/index.php?title=IRC
Userland Dev: http://xdandroid.com/wiki/Chat
Steps for building stuff: http://forum.ppcgeeks.com/android-t...modules-tinboot-nand-boot-more-beginners.html
You can also find steps for building userland at xdandroid.com
Specifically, for building xdandroid - http://xdandroid.com/wiki/Getting_the_Source
If you follow those instructions, you will basically be able to build your own FRX05/GBX0A equivalents.
That's how I got started on my GPS quest.
Note that in terms of IRC channels, the two links above will eventually just take you to Freenode, so you can just go over to #htc-linux and #xdandroid on freenode. Activity seems to be highest in United States evening times. It can be quite dead at other times, as occasional people who have popped in to ask questions have discovered.
In terms of what goes into the mainline xdandroid codebase - ideally I would assume the devs wish to integrate whatever they can, however, I can see the following valid reasons to diverge:
1) Replacing large parts of the user interface (Sense, heavily themed builds) - This was one of the things tiad8 did and honestly not a part of his work that I had any problems with.
2) Situations where there is a free but binary-only component that replaces one of our open source components - Not ideal but sometimes a necessary evil for the end user. However, I think the mainline devs would appreciate knowing the situations in which this is done, either for the purposes of reverse engineering the component in question, finding a source tree for the component in question (sometimes possible), or just knowing whether or not a fix can be integrated upstream. - tiad8 would often grab stuff from random places without documenting it which annoyed a lot of people
Trying to minimize the deltas between "cooked" builds and what one might call the "baseline" build is probably what is best for all of us - only diverge when there is a clear rationale for it, and when there isn't a good reason for divergence, try to get stuff mainlined.
Also to note - when running from SD it isn't exactly "ROM" development, and the nice thing about running from SD is that it's a lot easier to make tweaks to userland since the key userland files are all in a normal ext2 filesystem.
Oh yeah - HIGHLY beneficial if you've got a 64-bit Linux box like I do!
Edit: If you read my GPS testing thread, you'll see some of the lessons learned on my journey, including a few useful tips like bind-mounting specific libs that you're working on.
Entropy512 said:
Specifically, for building xdandroid - http://xdandroid.com/wiki/Getting_the_Source
If you follow those instructions, you will basically be able to build your own FRX05/GBX0A equivalents.
That's how I got started on my GPS quest.
Note that in terms of IRC channels, the two links above will eventually just take you to Freenode, so you can just go over to #htc-linux and #xdandroid on freenode. Activity seems to be highest in United States evening times. It can be quite dead at other times, as occasional people who have popped in to ask questions have discovered.
In terms of what goes into the mainline xdandroid codebase - ideally I would assume the devs wish to integrate whatever they can, however, I can see the following valid reasons to diverge:
1) Replacing large parts of the user interface (Sense, heavily themed builds) - This was one of the things tiad8 did and honestly not a part of his work that I had any problems with.
2) Situations where there is a free but binary-only component that replaces one of our open source components - Not ideal but sometimes a necessary evil for the end user. However, I think the mainline devs would appreciate knowing the situations in which this is done, either for the purposes of reverse engineering the component in question, finding a source tree for the component in question (sometimes possible), or just knowing whether or not a fix can be integrated upstream. - tiad8 would often grab stuff from random places without documenting it which annoyed a lot of people
Trying to minimize the deltas between "cooked" builds and what one might call the "baseline" build is probably what is best for all of us - only diverge when there is a clear rationale for it, and when there isn't a good reason for divergence, try to get stuff mainlined.
Also to note - when running from SD it isn't exactly "ROM" development, and the nice thing about running from SD is that it's a lot easier to make tweaks to userland since the key userland files are all in a normal ext2 filesystem.
Oh yeah - HIGHLY beneficial if you've got a 64-bit Linux box like I do!
Edit: If you read my GPS testing thread, you'll see some of the lessons learned on my journey, including a few useful tips like bind-mounting specific libs that you're working on.
Click to expand...
Click to collapse
Sweet, yeah I will definitely be having a look at all resources. I DO have a 64bit Linux box, what is so beneficial? Can I achieve the same with a 64bit Virtual PC (providing I can allocate 4gb+ RAM which shouldn't be a problem on my beast )?
When I change or include anything I definitely want to include a list of all sources and information available to make sure the use is aware of what is going on. I never really like 'closed-source' development, as some of you may have seen with the Gaming Association I founded (all our mods are open source ).
Thanks, I will post again here if I need anything.
I think some of the prebuilt tools are 64-bit binaries. It's likely possible to get it working on a 32-bit box, but all of the documentation I've seen either strongly recommends/requires 64.
A VM should work fine - I think a few people are using that approach. Memory requirements aren't too bad unless you're doing a make -j4 on a quadcore - then you might drive into swap with a 4GB machine (I have...)
Entropy512 said:
I think some of the prebuilt tools are 64-bit binaries. It's likely possible to get it working on a 32-bit box, but all of the documentation I've seen either strongly recommends/requires 64.
A VM should work fine - I think a few people are using that approach. Memory requirements aren't too bad unless you're doing a make -j4 on a quadcore - then you might drive into swap with a 4GB machine (I have...)
Click to expand...
Click to collapse
I have an i5 750 OCed to 4Ghz, it is in fact a quad. Only 4GB RAM atm but very soon i will have 8
It is running a git clone command, downloaded 40 mb already and it is only 5%, oh great... xD haha
Trying to download and getting this error.
Code:
[email protected] ~ $ sudo apt-get install git build-essential gnupg flex bison gperf libsdl-dev esound zip curl libwxgtk2.6 libc6-dev-i386 g++-multilib lib32z1-dev lib32ncurses5-dev java-common openjdk-6-jdk sun-java5-jdk
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'libsdl1.2-dev' instead of 'libsdl-dev'
Note, selecting 'libwxgtk2.6-0' for regex 'libwxgtk2.6'
Note, selecting 'libwxgtk2.6-dbg' for regex 'libwxgtk2.6'
Note, selecting 'libwxgtk2.6-dev' for regex 'libwxgtk2.6'
Note, selecting 'libwxgtk2.6-0-python' for regex 'libwxgtk2.6'
E: Unable to locate package libc6-dev-i386
E: Unable to locate package lib32z1-dev
E: Unable to locate package lib32ncurses5-dev
ryannathans said:
Trying to download perquisites and getting this error.
Click to expand...
Click to collapse
Have you tried to add a repository
Code:
add-apt-repository "deb http://archive.canonical.com/ maverick partner"
?
still getting the same error, however, when updating the list of updates, quite a few 'ign' or 'fail' but still most 'hit'.
Is everyone getting this error? It is happening on all my machines..
Don't remember encountering that error when I was getting set up...
I'm on Ubuntu 10.10 - you?
Entropy512 said:
Don't remember encountering that error when I was getting set up...
I'm on Ubuntu 10.10 - you?
Click to expand...
Click to collapse
Linux Mint 10 Gnome
Derived from Ubuntu 10.10, therefore both depositories should work.
Do you know what depository it is from?
From what I remember, I only had to add special repos for Java 5.
I do remember that back when I did it, there were some libs missing from the install directions in the wiki, that caused my build to bomb. I had to do some googling to find out what they were, and I THINK they were the ones you are having a problem with... hmm. Lemme do some more poking.
Edit: Try the prerequisites setup hints at http://source.android.com/source/download.html
Entropy512 said:
From what I remember, I only had to add special repos for Java 5.
I do remember that back when I did it, there were some libs missing from the install directions in the wiki, that caused my build to bomb. I had to do some googling to find out what they were, and I THINK they were the ones you are having a problem with... hmm. Lemme do some more poking.
Edit: Try the prerequisites setup hints at http://source.android.com/source/download.html
Click to expand...
Click to collapse
First repository worked but the other failed.
Code:
[email protected] ~ $ sudo add-apt-repository "deb-src http://archive.canonical.com/ubuntu lucid partner"
Error: 'deb-src http://archive.canonical.com/ubuntu lucid partner' invalid
I just removed -src and it accepted it, however I still get the same error with apt-get install as i did before
ill just install ubuntu instead...
and SAME error D:
Weird... I need to run out the door soon, but when I get home (going to be fairly late tonight) I'll try to look at my current repo setup.
Entropy512 said:
Weird... I need to run out the door soon, but when I get home (going to be fairly late tonight) I'll try to look at my current repo setup.
Click to expand...
Click to collapse
thanks Entropy
Uh yeah... anyway so what happened with that?
Entropy512 said:
Try the prerequisites setup hints at http://source.android.com/source/download.html
Click to expand...
Click to collapse
That's how I got the error.
I went on to...
Code:
sudo apt-get update
sudo apt-get install sun-java6-jdk
Things seem to be working fine for me.
Will post if anything changes... Ubuntu 10.10 x64
Getting errors about the update commands but repo is running fine. and javac points to where I tell it to via:
Code:
sudo update-java-alternatives -s java-1.5.0-sun
I suggest you continue to advance the installation until you run into a build problem, That will make an issue easier to resolve. Also... These issues should be posted/googled in a linux forum relevant to your distro.
Avid Droidery said:
Uh yeah... anyway so what happened with that?
Click to expand...
Click to collapse
Entropy helped me over IRC
libwxgtk2.6 could not be found via apt-get but libwxgtk2.6-0 was found and installed/works perfectly
should this be updated on the wiki?
ryannathans said:
should this be updated on the wiki?
Click to expand...
Click to collapse
I give you and Entropy my thanks and the thumbs up! As for your question, I am sure this is an installation issue specific to a certain platform. This would be relevant knowledge to any Wiki engaged in the topic.
- Keep up the great work!
Since the phone is Japanese, it is hard to find information if there is a way to root the phone or information about it.
Can anyone direct me to the right path , google is not helping >_<
The typical "me too" reply
dharkness said:
Since the phone is Japanese, it is hard to find information if there is a way to root the phone or information about it.
Can anyone direct me to the right path , google is not helping >_<
Click to expand...
Click to collapse
As per subject, me too. Got this phone on the 1st of April, switched from iPhone thinking I was now free in the world of rooting and custom roms. Guess the joke was on me as there seems to be no support for modern Japanese phones.
Weird considering this is the country of the tech obsessed. Maybe I should learn Japanese, there must be local hackers
puckman said:
As per subject, me too. Got this phone on the 1st of April, switched from iPhone thinking I was now free in the world of rooting and custom roms. Guess the joke was on me as there seems to be no support for modern Japanese phones.
Weird considering this is the country of the tech obsessed. Maybe I should learn Japanese, there must be local hackers
Click to expand...
Click to collapse
2ch might have the answer, it is just in Japanese and I do not know what to search for. Sharp might be the motorola of Japan lockin their phones >_<
puckman said:
As per subject, me too. Got this phone on the 1st of April, switched from iPhone thinking I was now free in the world of rooting and custom roms. Guess the joke was on me as there seems to be no support for modern Japanese phones.
Weird considering this is the country of the tech obsessed. Maybe I should learn Japanese, there must be local hackers
Click to expand...
Click to collapse
http://ameblo.jp/mee-now/theme-10072066016.html
dharkness said:
http://ameblo.jp/mee-now/theme-10072066016.html
Click to expand...
Click to collapse
Yep, this link seems to list the instructions for rooting the 203SH. And there are pretty straightforward and easy, I think.
I don't speak Japanese, I use Google Translate, but I have already rooted a few Sharps (SoftBank and Docomo) and have studied the rooting methods so I am pretty sure I understand the instructions.
Here's what you need to do:
1. You need a 64-bit Windows 7.
2. The build version needs to be S0012, and Android version needs to be 4.1.2.
3. Install the Sharp ADB driver. Get it from here: https://sh-dev.sharp.co.jp/android/modules/driver_eng/
4. Obtain the following files/apps:
・su
・Superuser.apk
・busybox
・unlock_security_module (*** The value "1" will remove the MIYABI lock first and the the NAND lock. However, I can't make full sense of everything in the note so you'll probably need to research this on your own, or experiment.)
5. Turn on USB Debugging on the 203SH. Disable "sleep mode" (I haven't seen this setting before but it should be somewhere in the Settings > Development menu).
6. Using command prompt on your Windows PC, transfer the "unlock" program to the phone:
Code:
> adb push unlock_security_module /data/local/tmp/unlock_security_module
7. Execute the program:
Code:
> adb shell
$ cd /data/local/tmp
$ chmod 777 ./unlock_security_module
$ ./unlock_security_module 1
8. The above should unlock both MIYABI and NAND. You'll see various results being printed for about one minute before the entire operation completes. But this is the result you will be looking for:
Code:
Unlocked LSM.
Do setresuid...
OK.
9. The cursor should change from "$" to "#' which means you have root access.
10. And you will be able to push "su" and "busybox" to the /system folder, and install "Superuser.apk" as a system app (also push it to the /system/app folder).
11. More instructions are to follow (that's that the last note says).
MY ADVICE: Perform the above very carefully and do not forget that you might end up bricking your phone and the responsibility for this will be all yours. If you are not comfortable with executing shell commands (meaning you can understand what's going on), it's best not to try this.
If this method works, please post here. I will publish these instructions on my website.
I cant risk bricking my phone >_< already on my 2nd 203sh, i lost my first one and the deductable for a new phone is expensive >_<
cheeseus said:
Yep, this link seems to list the instructions for rooting the 203SH. And there are pretty straightforward and easy, I think.
I don't speak Japanese, I use Google Translate, but I have already rooted a few Sharps (SoftBank and Docomo) and have studied the rooting methods so I am pretty sure I understand the instructions.
Here's what you need to do:
1. You need a 64-bit Windows 7.
2. The build version needs to be S0012, and Android version needs to be 4.1.2.
3. Install the Sharp ADB driver. Get it from here: https://sh-dev.sharp.co.jp/android/modules/driver_eng/
4. Obtain the following files/apps:
・su
・Superuser.apk
・busybox
・unlock_security_module (*** The value "1" will remove the MIYABI lock first and the the NAND lock. However, I can't make full sense of everything in the note so you'll probably need to research this on your own, or experiment.)
5. Turn on USB Debugging on the 203SH. Disable "sleep mode" (I haven't seen this setting before but it should be somewhere in the Settings > Development menu).
6. Using command prompt on your Windows PC, transfer the "unlock" program to the phone:
Code:
> adb push unlock_security_module /data/local/tmp/unlock_security_module
7. Execute the program:
Code:
> adb shell
$ cd /data/local/tmp
$ chmod 777 ./unlock_security_module
$ ./unlock_security_module 1
8. The above should unlock both MIYABI and NAND. You'll see various results being printed for about one minute before the entire operation completes. But this is the result you will be looking for:
Code:
Unlocked LSM.
Do setresuid...
OK.
9. The cursor should change from "$" to "#' which means you have root access.
10. And you will be able to push "su" and "busybox" to the /system folder, and install "Superuser.apk" as a system app (also push it to the /system/app folder).
11. More instructions are to follow (that's that the last note says).
MY ADVICE: Perform the above very carefully and do not forget that you might end up bricking your phone and the responsibility for this will be all yours. If you are not comfortable with executing shell commands (meaning you can understand what's going on), it's best not to try this.
If this method works, please post here. I will publish these instructions on my website.
Click to expand...
Click to collapse
dharkness said:
I cant risk bricking my phone >_< already on my 2nd 203sh, i lost my first one and the deductable for a new phone is expensive >_<
Click to expand...
Click to collapse
I want to know. Can I use CWM on 203SH or not. I want to Hard reset phone. thank you.
last i check its only temp root
are you a Chinese too？ i got it from wp7bar in tieba
Sent from my SBM203SH using XDA Premium 4 mobile app
i can not execute chmod 777 ./unlock_security_module
It shows some error, how to proceed ?
Do you have rooting methods for Sharp Aquos 506sh?
This is a cross-post from a reddit thread I started, but this is probably a more appropriate location for it.
I have been trying to modify files in the system folder for the Android container on the Asus Flip so I can install SuperSu, but have run into some problems.
The system folder is contained in a squashfs image on the chromebook at /opt/google/containers/android/system.raw.img. Mounted squashfs images appear to not support read-write access. I have been able to unsquash the image, add the SuperSU apk to the /system/priv-app folder and su to the /system/xbin folder, and remake the image. This boots, but SuperSU force closes as soon as it starts.
To make tinkering easier, I've tried building a writable image using dd and mkfs. I placed it in a location that has rw access and modified the /etc/init/android-ureadahead.conf script which mounts it to enable rw access. Unfortunately though it won't boot. The boot logs for the android container show a litany of SELinux errors for different things that it could not set context, operation not permitted. I can post the exact log if necessary. Some googling led me to find that the SELinux security context attributes weren't being replicated in my image, so I tried mounting with context and fscontext options equal to the contexts from the original image, but I get the same problem.
If anyone has any ideas I'd be especially grateful.
lionclaw said:
This is a cross-post from a reddit thread I started, but this is probably a more appropriate location for it.
I have been trying to modify files in the system folder for the Android container on the Asus Flip so I can install SuperSu, but have run into some problems.
The system folder is contained in a squashfs image on the chromebook at /opt/google/containers/android/system.raw.img. Mounted squashfs images appear to not support read-write access. I have been able to unsquash the image, add the SuperSU apk to the /system/priv-app folder and su to the /system/xbin folder, and remake the image. This boots, but SuperSU force closes as soon as it starts.
To make tinkering easier, I've tried building a writable image using dd and mkfs. I placed it in a location that has rw access and modified the /etc/init/android-ureadahead.conf script which mounts it to enable rw access. Unfortunately though it won't boot. The boot logs for the android container show a litany of SELinux errors for different things that it could not set context, operation not permitted. I can post the exact log if necessary. Some googling led me to find that the SELinux security context attributes weren't being replicated in my image, so I tried mounting with context and fscontext options equal to the contexts from the original image, but I get the same problem.
If anyone has any ideas I'd be especially grateful.
Click to expand...
Click to collapse
Wayyyy out of my area of expertise, but here's my (completely novice) best guess.
>All Chromebooks are write-protected with a screw on the motherboard
>Putting a Chromebook in developer mode allows for some tinkering ie things like chroots, and on the asus flip, the ability to install apks from unknown sources.
>Unscrewing the write-protect screw allows for the ability to completely install a new operating system or dual boot setup.
>Maybe you need to do that before you're able to accomplish root access?
My other idea would be to try and figure out a way of doing a systemless root?
Also, total aside but since this is the only thread I've found on XDA about this device, I think chroots are theoretically possible now without the need to be in developer mode via Android apps (even without root on Android). Download the GIMP port from the Play Store to see what I'm talking about. Playing around with that for a few minutes really made me wish that it didn't use emulated mouse/keyboard in it's implementation. Also, it appears that apt-get is broken, but regardless it might interest someone out there looking for a project.
back from the dead, any progress on this?
I have been able to successfully root the Android image on my Asus Flip.
I built a blank image with dd in /usr/local, formatted it with mkfs, mounted it to a folder, mounted the original system.raw.img to a folder, copied the files across, placed *all* the SuperSU files listed as 'required' in the SuperSU update-binary in the relevant places in /system in my new image, set permissions & contexts for those files, edited arc-system-mount.conf and arc-ureadahead.conf to point to the new image and, finally, patched /etc/selinux/arc/policy/policy.30 with the SuperSU sepolicy patching tool in order to boot my rooted Android instance with selinux set to enforcing.
I have created a couple of scripts which more-or-less fully automate this procedure, which can be downloaded from nolirium.blogspot.com. Please feel free to download, open the scripts in a text editor to check them out, and try them out if you like. Only tested on Asus Flip, though.
I seem to be unable to post attachments at the moment so I will just add the descriptions here, I could probably post the entire scripts here too if anyone wants. Feel free to let me know what you think.
DESCRIPTIONS:
1-3.sh
Combines the first three scripts listed below.
01Makecontainer.sh
Creates an 900MB filesystem image in /usr/local/Android_Images, formats it, then copies Android system files therein.
02Editconf.sh
Modifies two system files: arc-system-mount.conf - changing the mount-as-read-only flag and replacing the Android system image location with a new location; and arc-ureadahead.conf - again replacing the Android system image location. Originals are renamed .old - copies of which are also placed in /usr/local/Backup.
03Androidroot.sh
Mounts the previously created Android filesystem image to a folder, and copies SuperSU files to the mounted image as specified in the SuperSU update-binary.
04SEpatch.sh
Copies an SELinux policy file found at /etc/selinux/arc/policy/policy.30 to the Downloads folder, opens an Android root shell for the SuperSU policy patching command to be entered, then copies the patched policy back to the original location. A copy of the original policy.30 is saved at /etc/selinux/arc/policy/policy.30.old and /usr/local/Backup/policy.30.old
Uninstall.sh
Removes the folder /usr/local/Android_Images and attempts to restore the modified system files arc-system-mount.conf and arc-ureadahead.conf.
ok so two questions, one do you think this would work on the Acer r13 convertable? and 2 where can I find the actual instructions/scripts
keithkaaos said:
ok so two questions, one do you think this would work on the Acer r13 convertable? and 2 where can I find the actual instructions/scripts
Click to expand...
Click to collapse
The R13 has a 64-bit Mediatek processor, right?
I have added a version for ARM64, but I haven't tested it.
You can find the instructions and scripts at nolirium.blogspot.com
ya, its a mediatek. and thanks ill go see if i can find it
---------- Post added at 03:31 AM ---------- Previous post was at 02:58 AM ----------
wow, ok. i can do this but im not sure i want to.. after reading the possible problems i may run into. Im going to be getting the G. Home in a couple weeks and i gotta keep things running smooth. This seems like going a tad too far then i need to. The other day i had action launcher going and it looked pretty damn good but i really want to try and get the action3.apk that i have put into the pri-app folder or whatever the chromebook uses i found the syst folder but cant access it. Im wondering if i make the machine writable it would work but im afraid of losing my updates, as long as i could do them manualy, i guess that would be cool. Also since im already going on... has anyone found a way to disable the dev boot screen without tinkering with the physical chromebook yet?
SuperSU on Chromebook
Hey there I love this post but unfortunately im on the mediatek (well not unfortunately cause i love it) but i do really want super su .. But i found this other post that i tried out but i am having a problem executing the scripts. When i go to run the first one, it says can not open "name of script" but the dev takes a pretty cool approach. Im still new to Chrome OS but thanks for the post and if you have any advice on executing scripts id love to hear it!! http://nolirium.blogspot.com/
I'm guessing the above post was moved from another thread...
Anyway, it turns out that zipping/unzipping the files in Chrome OS's file manager sets all the permissions to read-only. Apologies! sudo chmod+x *scriptname* should fix it...
Regarding OS updates, I actually haven't had a problem receiving auto-updates with software write-protect switched off; the main possible potential issue I could imagine arising from the procedure I outlined would involve restoring the original conf files if both sets of backups get deleted/overwritten. This seems unlikely, but in that case either manually editing the files to insert the original string (/opt/google/containers/android/system.raw.img), or doing a powerwash with forced update might be necessary in order to get the original Android container booting again.
I don't think anyone's found a way to shorten/disable the dev boot screen without removing the hardware write-protect screw - from what I've read, the flags are set in a part of the firmware which is essentially read-only unless the screw is removed. Perhaps at some point the Chrome OS devs will get fed up of reading reports from users whose relatives accidentally reset the device by pressing spacebar, and change the setup. Here's hoping.
Hey just jumpig in the thread right quick to see if these instructions are old or what-- got a chromebook pro and the notion of having to update a squashed filesystem every timeto install su seems like a pain..
Is there any kind of authoritative documentation/breakdown regarding what Chromeos is mounting where before I start breaking things? Also anyone happen to know if there's a write-protect screw anywhere in the chromebook plus/pro?
Other questions:
* adbd is running, but is not accessible from adb in the (linux) shell, which shows no devices. Do I need to access adb from another device (i'm short a usb c cable right now) or can I use adb (which is there!) on the chrome side to access adbd on the android side?
* Anyone know if adb via tcp/ip is available? Don't see it in the android settings.
Hey,
There's no real documentation AFAIK, the thing is that ARC++ is a bit of a moving target, as it's so actively being developed/reworked. For instance, with the method described earlier in the thread - it started off being possible to just swap out a file location in arc-ureadahead.conf, then they changed it to arc-setup-conf, and now, since a few CrOS versions ago, the rootfs squashfs image is mounted in a loop fashion via the /usr/sbin/arc-setup binary instead, making an overview of the setup somewhat opaque to the casual observer.
I was kind of hoping to implement a kind of hybrid systemless root style setup myself, but unfortunately I haven't really managed to find the time to sit down and fully figure out a few parts of the puzzle, in particular relating to minijail and working with namespaces. So, I'm still using the method mentioned in posts above for my rooting needs at the moment, the only significant changes being that at the moment I'm replacing /opt/google/containers.android.system.raw.img with a symlink to my writeable rooted rootfs img, and also that in recent CrOS versions the mount-as-read only and debuggable flags can be found in /etc/init/arc-setup-env ("Environment variables for /usr/sbin/arc-setup").
In general though, one can kind of get an idea of what's going on in the default setup by reading through the various /etc/init/arc-* Chrome OS upstart jobs (and their logs in /var/log). Though, like I say, things keep changing around somewhat with every CrOS update, as the implementation 'improves'. As time goes by, and the subsystem matures, it'll certainly be interesting to see what other approaches are possible relating to customizing Android on Chrome OS.
There should definitely be a write protect screw somewhere on the motherboard for the Samsungs, but so far I haven't come across any pics showing exactly which screw it is. So far, no-one seems to have been brave/foolhardy enough to fully tear down their own machine and locate the screw!
Regarding adb, on my device I found the following in arc-setup-env:
# The IPV4 address of the container.
export ARC_CONTAINER_IPV4_ADDRESS=100.115.92.2/30
adb 100.115.92.2 (in Chrome OS's shell) works fine for me, the authorisation checkbox pops up and then good to go. su works fine through adb as expected. There's also a useful little nsenter script in Chrome OS to get into the android shell; /usr/sbin/android-sh, which I've been using in my script to help patch SE linux.
I actually just updated my rooting scripts recently to support 7.1.1, though I've only tested on my own Armv7 device (Flip C100).
I'll attach them to this post in case anyone wants to take a look. There's a readme in the zip, some more details can also be found here and below
EDIT: Fixed the SE Linux issue occurring with the previous version I uploaded (it was launching daemonsu from u:r:init:s0 instead of u:r:supersu:s0).
Anyone considering giving them a spin should bear in mind that the method does involve creating a fairly large file on the device as a rooted copy of the android rootfs. (1GB for arm, 1.4GB for Intel). There's a readme in the zip but the other couple of important points are that:
a) The SuperSU 2.82 SR1 zip also needs to be downloaded and extracted to ~/Downloads on the Chromebook.
b) Rootfs verification needs to be off. The command to force this is:
Code:
sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --force --partitions $(( $(rootdev -s | sed -r 's/.*(.)$/\1/') - 1))
or the regular command to do it is:
Code:
sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification
c) If, subsequent to running the scripts, there's a problem loading Android apps (e.g. after a powerwash or failed install), the command to restore the original rootfs image is:
Code:
sudo mv /opt/google/containers/android/system.raw.img.bk /opt/google/containers/android/system.raw.img
Hey this is a great response.. thanks!
Nolirum said:
Hey,
There's no real documentation AFAIK, the thing is that ARC++ is a bit of a moving target, as it's so actively being developed/reworked. For instance, with the method described earlier in the thread - it started off being possible to just swap out a file location in arc-ureadahead.conf, then they changed it to arc-setup-conf, and now, since a few CrOS versions ago, the rootfs squashfs image is mounted in a loop fashion via the /usr/sbin/arc-setup binary instead, making an overview of the setup somewhat opaque to the casual observer.
Click to expand...
Click to collapse
verity
Yeah playing with it now, I'm looking at these /etc/init/arc-*-conf files... I see that the /dev/loop# files are being set up... (more below)
Nolirum said:
I was kind of hoping to implement a kind of hybrid systemless root style setup myself, but unfortunately I haven't really managed to find the time to sit down and fully figure out a few parts of the puzzle, in particular relating to minijail and working with namespaces. So, I'm still using the method mentioned in posts above for my rooting needs at the moment, the only significant changes being that at the moment I'm replacing /opt/google/containers.android.system.raw.img with a symlink to my writeable rooted rootfs img, and also that in recent CrOS versions the mount-as-read only and debuggable flags can be found in /etc/init/arc-setup-env ("Environment variables for /usr/sbin/arc-setup").
Click to expand...
Click to collapse
Sorry not sure what you mean by "hybrid systemless root style setup"? I take it you're modifying the startup script and replaced the squashfs file in /opt... my concern about doing it was whether they were implementing some kind of dm-verity equivalent to the squashfs file to make sure it hasn't been tampered with (say, by adding /sbin/su or whatever) or whether it's safe to replace that file.. Sounds like you're saying it is? (update: I guess that's what rootfs verification does, and we can turn it off....)
Also you mean arc-setup.conf:
env ANDROID_DEBUGGABLE = 0
right?
Nolirum said:
In general though, one can kind of get an idea of what's going on in the default setup by reading through the various /etc/init/arc-* Chrome OS upstart jobs (and their logs in /var/log). Though, like I say, things keep changing around somewhat with every CrOS update, as the implementation 'improves'. As time goes by, and the subsystem matures, it'll certainly be interesting to see what other approaches are possible relating to customizing Android on Chrome OS.
Click to expand...
Click to collapse
I hadn't realized the boot was still in flux-- I'd have figured they'd worked that out by now...
Nolirum said:
There should definitely be a write protect screw somewhere on the motherboard for the Samsungs, but so far I haven't come across any pics showing exactly which screw it is. So far, no-one seems to have been brave/foolhardy enough to fully tear down their own machine and locate the screw!
Click to expand...
Click to collapse
Heh.. not gonna be me..
Nolirum said:
Regarding adb, on my device I found the following in arc-setup-env:
# The IPV4 address of the container.
export ARC_CONTAINER_IPV4_ADDRESS=100.115.92.2/30
adb 100.115.92.2 (in Chrome OS's shell) works fine for me, the authorisation checkbox pops up and then good to go. su works fine through adb as expected. There's also a useful little nsenter script in Chrome OS to get into the android shell; /usr/sbin/android-sh, which I've been using in my script to help patch SE linux.
Click to expand...
Click to collapse
Cool-- adb connect 100.115.92.2 does indeed work I was gonna use netcat to open port 5555 in chromeos and pipe it through, but looks like nc isn't here and I'm not yet ready to start changing the FS..though probably will be soon... btw any idea which partitions get overwritten when chrome it does it's updates? Will /root and /etc get overwritten, for example... would a "powerwash" overwrite it or can you get easily get into an unbootable state on these things?
It's also kind of strange that adb is listening to port 30 at that (internal?) bridge address by default witho no UI to turn it off.. and it's inaccessible from outside.. i wonder if there's an easy way to change the bridge to share the same IP as the actual interface...
Final thought-- I'd love to build that system image myself soup-to-nuts, but I can't find any "caroline" device tree set up... do you or anyone else happen to know if there's a standalone AOSP device tree for the chromebooks? It would be cool to have a mashup AOSP/lineageos if such a think could be possible-- I'm guessing chromiumos is just taking the android tree, building it and then adding it into their build... I Haven't build chromiumos for many years now so I can't even begin to imagine how this android build integrates with the whole emerge thing they had going.. but I bet it takes a while
Nolirum said:
I actually just updated my rooting scripts recently to support 7.1.1, though I've only tested on my own Armv7 device (Flip C100).
Click to expand...
Click to collapse
Cool I'll take a look at these scripts.
So I haven't yet run the scripts-- just looking through them-- I noticed the section starting:
if [ -e /etc/init/arc-setup-env ]; then
echo "Copying /etc/init/arc-setup-env to /usr/local/Backup"
This doesn't exist on the x86 CB Pro. There's an arc-setup.conf that sets up the environment variables though. It sets WRITABLE_MOUNT to 0, but then so does arc-system-mount.conf
Not sure if these are different between x86 and ARM or if it's just in the latest update.. but figured I'd let you know. Wanna throw thse scripts up on github somewhere? (Or I can do it) and we can maybe look at keeping them up to date and/or standardizing them? It wouldn't be hard to determine if it's running on ARM or x86_64 (uname -i for example)..
fattire said:
So I haven't yet run the scripts-- just looking through them-- I noticed the section starting:
if [ -e /etc/init/arc-setup-env ]; then
echo "Copying /etc/init/arc-setup-env to /usr/local/Backup"
This doesn't exist on the x86 CB Pro. There's an arc-setup.conf that sets up the environment variables though. It sets WRITABLE_MOUNT to 0, but then so does arc-system-mount.conf
Not sure if these are different between x86 and ARM or if it's just in the latest update.. but figured I'd let you know. Wanna throw thse scripts up on github somewhere? (Or I can do it) and we can maybe look at keeping them up to date and/or standardizing them? It wouldn't be hard to determine if it's running on ARM or x86_64 (uname -i for example)..
Click to expand...
Click to collapse
Oh, the arc-setup-env thing is intentional. There does appear to be another issue with the x86 version though. I've written up a detailed response to your previous post; it's in a text file at the moment so I'll copy it over and format it for posting here with quotes etc now - should only take a few minutes. Yeah, sticking them on github might be a good idea; I've been meaning to create an account over there anyway.
Yeah, so... Regarding the scripts, since I've put them up here for people to download - I should mention that the first person to test them (aside from me) has reported that something's not working right (I'm waiting for confirmation but I think he tried out the x86 version). It's likely either an error on my part when copying across from my Arm version, or perhaps something not working right with conditionals, meant to deal with the various OS versions ('if; then' statements, I mean). Once I find out more, I'll edit my earlier post...
fattire said:
Sorry not sure what you mean by "hybrid systemless root style setup"? I take it you're modifying the startup script and replaced the squashfs file in /opt... my concern about doing it was whether they were implementing some kind of dm-verity equivalent to the squashfs file to make sure it hasn't been tampered with (say, by adding /sbin/su or whatever) or whether it's safe to replace that file.. Sounds like you're saying it is?
Click to expand...
Click to collapse
Oh, sorry for being a bit vague - I just mean perhaps implementing a kind of systemless root à la Magisk/SuperSU (from what I understand of how these work) - avoiding the need to actually replace files in /system. Since I'm mainly just using su for the privileges rather than actually wanting to write to /system, I had the idea that perhaps a sort of overlay on e.g. xbin and a few other locations, rather than actually rebuilding the whole of /system, might be an interesting approach....
Yep, I've been replacing /opt/google/containers/android/system.raw.img with a symlink to my modified image lately. Works fine... I think they've been focused on just getting the apps working properly, maybe something like dm-verity is still to come.
Although, one of the cool things with Chromebooks IMO is that once the Developer Mode (virtual) switch has been flipped, the system's pretty open to being hacked around with. I think a large part of the much-trumpeted "security" of the system is thanks to the regular mode/Dev mode feature, once in Dev Mode with verified boot disabled on the rootfs, we can pretty much do what we want (I like the message that comes up in the shell when entering the first command I posted under the spoiler - it literally says "YOU ARE ON YOUR OWN!").
So yeah, with Dev Mode switched off, verified boot switched on, we can't even get into the shell (just the walled-off 'crosh' prompt), making the system indeed rather secure (but, for some of us, rather limited).
fattire said:
Also you mean arc-setup.conf:
env ANDROID_DEBUGGABLE = 0
right?
Click to expand...
Click to collapse
That's what I mean by a moving target, lol. On my device the Canary channel is at Chrome OS version 61; I think they started to move out some ARC++ (the acronym stands for Android Runtime on Chrome, version 2, if anyone's wondering, btw) environment variables to a separate file in version 60, or maybe 61. Problems with being on the more 'bleeding edge' channels include:
#Sometimes stuff gets broken as they commit experimental changes.
#Any updates sometimes overwrite rootfs customizations; the higher the channel - the more frequent the updates occur.
#Some of the stuff that gets updated, may later get reverted.
And so on...
fattire said:
I hadn't realized the boot was still in flux-- I'd have figured they'd worked that out by now...
Click to expand...
Click to collapse
Yeah you'd think so. Honestly, the more I use CrOS the more it seems like a (very polished) work-in-progress to me. Though, I guess most modern OSs are also works-in-progress though. (I don't mean the former statement in a critical way; I'm very happy that new features keep getting added to the OS - Android app support being a perfect case in point, that was a lovely surprise, greatly extending the functionality of my Chromebook).
fattire said:
Cool-- adb connect 100.115.92.2 does indeed work I was gonna use netcat to open port 5555 in chromeos and pipe it through, but looks like nc isn't here and I'm not yet ready to start changing the FS..though probably will be soon...
Click to expand...
Click to collapse
Netcat's not there but socat, which I haven't any experience with but have seen described as a "more advanced version of netcat", is listed in /etc/portage/make.profile/package.installable, meaning that adding it to CrOS is supported, and as simple as:
Code:
sudo su -
dev_install #(sets up portage in /usr/local)
emerge socat
I tried socat out and it seems to work, might be interesting to play around with.
fattire said:
btw any idea which partitions get overwritten when chrome it does it's updates? Will /root and /etc get overwritten, for example...
Click to expand...
Click to collapse
Theres a question. I forget some of the exact details now (gleaned from browsing the developer mailing lists and the documentation on chromium.org), but from what I do remember and my experiences tinkering, I can say:
The auto-update model uses kernel/rootfs pairs, e.g. at the moment my device is booting from partition 2 (KERN-A) with the rootfs being partition 3 (ROOTFS-B). My understanding is that with the next OS update pushed to my device, CrOS will download the deltas of the files to be changed, and apply the changes to partitions 4 and 5 (KERN-B and ROOTS-B), setting new kernel GPT flags (priority=, tries=, successful=), which will, post-reboot, let the BIOS know that 4 and 5 will form the new working kernel/rootfs pair. Then the following update will do the same, but with partitions 2 and 3, and so on and so forth, alternating pairs each time. It's a pretty nifty system, and I think something similar might be happening with new Android devices from version O onward (?).
So partitions 2,3,4,5 are fair game for being overwritten (from the perspective of the CrOS updater program). Partition 1, the 'stateful partition') is a bit special, in addition to a big old encrypted file containing all of the userdata (/home/chronos/ dir?), it also has some extra dirs which get overlaid on the rootfs at boot. If you have a look in /mnt/stateful/, there should also be a dir called 'dev_image', which (on a device in Dev mode) gets mounted up over /usr/local/ at boot. As I mentioned above, if you do
Code:
sudo su -
dev_install
you can then emerge anything listed in /etc/portage/make.profile/package.installable (not a great deal of stuff admittedly, compared to Gentoo), which gets installed to subdirs in /usr/local/. So I think stuff in partition 1; /mnt/stateful/, should be safe from being overwritten with an OS update. I think crouton chroots get put there by default.
Most of the other partitions don't really get used, and shouldn't get touched by the updater, here's a design doc on the disk format, and here's a Reddit post (from a Google/Chromium employee) mentioning dual booting from partitions 6 and 7.
fattire said:
would a "powerwash" overwrite it or can you get easily get into an unbootable state on these things?
Click to expand...
Click to collapse
It's not too hard to mess up the system and get it into an unbootable state, lol. The "powerwash" just seems to remove user data, mainly. If you change up (the contents of) some files in /etc, or /opt, for example, then powerwash, normally they won't get restored to their original state (unless you also change release channel).
But, as long as the write-protect screw's not been removed and the original BIOS overwritten, it's always possible to make a recovery USB in Chrome's Recovery Utility on another device, and then restore the entire disk image fresh (this does overwrite all partitions). Another thing that I did was make a usb to boot into Kali; I was experimenting with the cgpt flags on my internal drive and got it into an unbootable state, but was still able to boot into Kali with Ctrl+U, and restore the flags manually from there. (To successfully boot from USB, it was essential to have previously run the enable_dev_usb_boot or crossystem dev_boot_usb=1 command in CrOS). I understand also that the BIOS type varies with device release date and CPU architecture, and that Intel devices may have some extra potential BIOS options ('legacy boot').
fattire said:
It's also kind of strange that adb is listening to port 30 at that (internal?) bridge address by default with no UI to turn it off.. and it's inaccessible from outside.. i wonder if there's an easy way to change the bridge to share the same IP as the actual interface...
Click to expand...
Click to collapse
I think I saw something related to this on the bug tracker. If I come across any info, I'll let you know...
fattire said:
Final thought-- I'd love to build that system image myself soup-to-nuts, but I can't find any "caroline" device tree set up... do you or anyone else happen to know if there's a standalone AOSP device tree for the chromebooks? It would be cool to have a mashup AOSP/lineageos if such a think could be possible-- I'm guessing chromiumos is just taking the android tree, building it and then adding it into their build... I Haven't build chromiumos for many years now so I can't even begin to imagine how this android build integrates with the whole emerge thing they had going.. but I bet it takes a while
Click to expand...
Click to collapse
Yeah, I haven't built Chromium OS or anything, but apparently, there's an option to create a 'private' overlay for the build, which doesn't get synced with the public stuff.
I think that the higher-ups at Google might be still umming and ahing as to whether or not to make source code available for the Android container, it's certainly not been made public yet. Actually, I remember seeing a Reddit post from a Google/Chromium employee mentioning this.
"That article is a little misleading in terms of open source. While the wayland-server and services that communicate with the ARC++ container are open source, the actual ARC++ container is not."
Perhaps they're waiting to see how similar implementations of Android within a larger Linux setup (e.g. Anbox) fare.
There doesn't seem to be too much that differs from AOSP in the ARC++ container - a few binaries and bits and pieces linking the hardware to the container (e.g. the camera etc), maybe some stuff related to running in a container with the graphics being piped out to Wayland?, and so on.
Oh, I was searching the bug tracker for something else, and just saw this (quoted below). Looks like it might be possible to run AOSP based images on CrOS soon!
arc: Implement android settings link for AOSP image
Reported by [email protected], Today (72 minutes ago)
Status: Started
Pri: 1
Type: Bug
M-60
When ARC started without the Play Store support there is no way for user to activate Android settings. We need implement corresponded section that has
Title: Android settings:
Link: Manage android preferences:
Inner bug: b/62945384
Click to expand...
Click to collapse
Great response! I read it once and I'll read it again in more detail then will probably have questions For whatever it may be worth, my only experience with chromiumos was building the whole thing maybe 4 years ago for my original 2011 Samsung "snow" Chromebook-- and making a bootable USB (or was it an SDcard?) to run it on (with a modified firmware that did... something I can't remember.. i think it was basically a stripped down uboot and I remember adding a simple menu or something-- I think I was trying to bypass that white startupscreen or something..). However, after doing this a few times to play with it, I realized that Chromiumos without the Chrome goodies kinda sucks and I promptly forgot everything and went back to stock.
I did have it re-partitioned to run linux as a dual boot from the SD slot or something-- I remember using that cgpt thing to select the different boot modes and vaguely recall the way it would A/B the updates (which "O" is now doing)... but anyhoo I was using the armhf ubuntu releases with the native kernel and ran into all kinds of sound issues and framebuffer only was a little crappy so...
I'm gonna re-read in more detail soon and I'm sure I'll have questions-- one of which will be-- assuming that most stuff is the same on x86 vs arm, why are there two scripts? How do they differ?
ol. On my device the Canary channel is at Chrome OS version 61; I think they started to move out some ARC++ (the acronym stands for Android Runtime on Chrome, version 2, if anyone's wondering, btw) environment variables to a separate file in version 60, or maybe 61.
Click to expand...
Click to collapse
This is the -env file I'm missing, I presume?
I think that the higher-ups at Google might be still umming and ahing as to whether or not to make source code available for the Android container, it's certainly not been made public yet. Actually, I remember seeing a Reddit post from a Google/Chromium employee mentioning this.
Click to expand...
Click to collapse
It looks from the response that the gapps portion might be what's in question-- just like ChromiumOS vs Chrome has all the proprietary bits taken out?
Here's what I'd ideally like to see:
* Rooted Android, with a toggle switch to hide su in settings a la lineage (requires a kernel patch something like this one) + settings changes from lineageos
* adb access from outside the device-- critical for quickly testing apks from android studio w/o a cable. Basically put the chromebook in a "device mode" where adb is passed through... I'm going to see if I can pipe adb through with socat as you suggest...
* what else... I dunno watch this space.
An update from a couple of guys that have tested out the scripts on Intel: It seems to be that while they are able to launch daemonsu manually (with daemonsu --auto-daemon), it apparently does not seem to be getting launched at boot.
I am waiting for some more information on this. Previously, for Marshmallow, the script was setting up the app_process hijack method in order to to launch daemonsu at boot; to support Nougat I changed it to instead create an .rc file with a service for daemonsu, and add a line to init.rc importing it. This works for me, and from what I can gather, it copied/created all files successfully on the testers devices, too, so I'm not sure at this point what the issue is there.
Edit: Fixed the issue. I updated my previous post with further details.
fattire said:
I realized that Chromiumos without the Chrome goodies kinda sucks and I promptly forgot everything and went back to stock.
Click to expand...
Click to collapse
lol yeah. True, that.
fattire said:
...assuming that most stuff is the same on x86 vs arm, why are there two scripts? How do they differ?
Click to expand...
Click to collapse
It's literally just two things that differ: the few lines where we copy the su binary over e.g.
/x86/su.pie → /system/xbin/su, daemonsu, sugote
vs
/armv7/su → /system/xbin/su, daemonsu, sugote
...and also the size of the created container. The x86 container is about 30 percent larger than the Arm one.
I had a little look at how to determine the CPU architecture programmatically on Chrome OS a while back, but couldn't seem to find a reliable way of doing this, at least not without maybe getting a bunch of people with different CrOS devices to run something like, as you mentioned, uname -i (which returns 'Rockchip' on my device, uname -m (which returns 'armv7'), or such similar, and collating the results. It was just easier to do separate versions for x86/arm, rather than introduce more conditionals (with potential for errors). I'm certainly not averse to adding a check for $ARCH, and thus standardizing the script, as long as it's reliable.
fattire said:
This is the -env file I'm missing, I presume?
Click to expand...
Click to collapse
Yep! It's just the same few envs as in the .confs, moved into a new file. I'm fairly confident that the script's conditionals deals with them OK.
fattire said:
It looks from the response that the gapps portion might be what's in question-- just like ChromiumOS vs Chrome has all the proprietary bits taken out?
Click to expand...
Click to collapse
Yeah, although the respondant there perhaps doesn't seem to realise that he's talking to a Google/Chromium dev, the way he responds. Not that that makes anything he says in his post is necessarily less valid, though.
fattire said:
Here's what I'd ideally like to see:
* Rooted Android, with a toggle switch to hide su in settings a la lineage (requires a kernel patch something like this one) + settings changes from lineageos
* adb access from outside the device-- critical for quickly testing apks from android studio w/o a cable. Basically put the chromebook in a "device mode" where adb is passed through... I'm going to see if I can pipe adb through with socat as you suggest...
Click to expand...
Click to collapse
Interesting... I agree, those would both be useful additions to the functionality of ARC++...
Quick question-- has Samsung provided the source for the GPL components (including the kernel, obviously)? I looked here but didn't see anything...? Previously the kernel was included along with the chromium source and there was like a kernel and kernel-next repository.. but this was like five years ago. I think the codename for the samsung chromebook pro is called caroline... let me quickly see if I can find a defconfig in the chromium source...
Back.. nothing here in the chromeos-4.4 branch. Nothing here either in the master branch. Maybe I'm looking in the wrong branches-- master is probably mainline kernel. Also the directories.. it took me five minutes to realize it wasn't going to be in arch/arm - force of habit I guess. I'll keep looking unless anyone knows. This "chromium-container-vm-x86" one seems to have dm_verity as an unused option. Ah, this is looking promising.
...and... here!
So it would seem that this would be built as part of the chromiumos build system, which seemed to be half gentoo five years ago building out of a chroot and was kind of a pain to set up... still, I'm guessing that since it's got that weird script to make the defconfig, what you could do is use google's chromiumos build script to make the kernel image (with whatever changes you want), then, assuming that it doesn't care if you replace the kernel, just throw it over the right Kernel A/B partition and see if it boots and starts up chromeos... it's weird cuz the kernel has to do double-duty for chromeos and android.. but I bet you can just replace it and it would work fine...
I had a cursory go at building a couple of kernel modules for my Flip C100 a while back - I didn't get too far though, lol. People do seem to have had success building their own kernels and running them with Chrome OS though, as with most things I suppose it's just how much time/effort you're willing to put in.
I think I used this and maybe this, from the crouton project to guide me.
From what I remember, I just got fed up of all the arcane errors/config choices. I remember that even though I'd imported my current device config from modprobe configs, there were then such an incredibly long string of hoops/config choices to have to go through one by one, to then be confronted with various errors (different every time ISTR) that I think I just thought "screw this". I think there were some other issue with the Ubuntu version I was using at the time as well. I know that sort of stuff's kind of par for the course with kernel compilation, but I was mainly only doing it so I could edit xpad in order to get my joypad working, in the end I found a different solution.
It shouldn't be too much hassle though, in theory I guess.... Oh, also, in order to get a freshly built kernel booting up with the CrOS rootfs, in addition to the gpt flags, I think you might have to sign it, too? (just with the devkeys & vbutil_kernel tool provided on the rootfs), some info here, and here.
From what I remember, the build system would do whatever key signing was necessary.... although I do now remember you're right there was some manual step when I was building the kernel, but I can't remember if that's because of MY changes or that was just part of the build process.
I I just dug out the old VM (Xubuntu) I was using to build and, well, let's just say I'll be doing a LOT of ubuntu updates before I can even realistically look at this. I do kinda recall setting up the environment was a huge pain so I'm going to see if I can just update the 5 year old source, target the pro and just build the kernel image and see what pops out the other end. At least I won't have to deal with the cross compiler, though I think it should hopefully take care of that itself.
Interesting to see that those crouton projects have emerged (no pun intended) so I'll check them out too while ubuntu updates itself
Thanks for the github links.. I'm going to go read that wiki.
Update: Looked at it-- funny they just stripped out the chromeos-specific parts they needed rather than emerge everything which is smart. My only question is now that Android is involved, there's that script I linked to earlier that seems to say "if you want Android support you'll need these bits too"-- wonder if the same config scripts apply, and if there are any other device tree considerations as well...
I may play a bit and see how smoothly it goes.. Unfortunately I don't have unlimited time either :/
Also, please do let me know if you put the scripts on github and I can send you pull requests if I come up with anything.
Update: Finally updated like 3 major versions of ubuntu... the "depot_tools" repo had its last commit in 2013, so I updated that. Wow, this is so much clearer than previous docs... it looks like something called gclient is used now, which I configured with:
gclient config --spec 'solutions = [
{
"url": "https://chromium.googlesource.com/chromium/src.git",
"managed": False,
"name": "src",
"deps_file": ".DEPS.git",
"custom_deps": {},
},
]
'
that let me do gclient sync --nohooks --no-history ...which i think is updating the ancient source. I probably should have just started over, but anyway... we'll see what happens.
Update again: After updating with this new gclinet tool, it appears that the old repo sync method is still required as described here. That hasn't changed after all, so now I'm going to go through this old method, which will probably completely overwhelm my storage as it's downloading with history.. but anyway, in case anyone is trying this-- looks like the whole chroot/repo sync thing may still be how it's done... the /src directory described above may only be for building just the browser, not the whole OS...
...and here it is. I will have zero room to actually build anything tho, but hey.
* [new branch] release-R58-9334.B-caroline-chromeos-3.18 -> cros/release-R58-9334.B-caroline-chromeos-3.18
Note to self: use cros_sdk --enter to actually get in the chroot. Then:
~/trunk/src/scripts $ ./setup_board --board=caroline
to set up the build for caroline. Then to build:
./build_packages --board=caroline --nowithdebug
Useful links:
* Building ChromiumOS
* [URL="http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/portage-build-faq"]eBuild FAQ
[/URL]
This is what i have going on. I have quite a few android phones i use to mine different cryptocurrency. most are older snap dragon ARM phones.
I am looking for something already created or if it is possible to create.
Is it possible to load a custom to the phone getting ridding of all unnecessary apps and programs. All i need to mine is wifi and my mining software which is run through Userland/Ubuntu. i currently have everything disabled and background process limited to try and help.
I looked into open source OS, but i learned it isn't one size fits all and a lot of my phones aren't even compatible with what developers have available for use.
I figured if there is something like this out there someone here would know. sorry if my description isn't that great and i hope this is in the right section.
any ideas or help would be greatly appreciated.
What are the phones' brand & model?
Sidenote:
Anyone who has the impression that mining is child's play is mistaken. Millions of computers around the world are competing for the best computing power. This cannot be done with normal Android devices alone. You need either special mining hardware and/or a really good graphics card.
i have all sorts of models. samsung S series, Notes, LG, Motorola. no particular brand or model. thats where part of problem lies. Alot of them dont even have an open source offering. I understand why, but i don't. need an entire operating system ideally just loading a few functions would be best for my set up.
i agree mining is a pretty serious hobby/endeavor, but you are spreading misinformation, it can be done on cell phones and i've been doing it for 2 years. some people smarter than me made it possible with software and it is quite more profitable if done right than using gpu and cpu, especially on the network i mine.
Well, don't even start Zygote then if you can do everything in Linux world.
Renate said:
Well, don't even start Zygote then if you can do everything in Linux world.
Click to expand...
Click to collapse
that's what i am trying to figure out. I can avoid booting android all together and just run linux.. im very new to this and been searching for a solution for a few weeks now and i can't find what i'm looking for. part of problems is i don't know what to search. is it possible to remove the android OS and boot a cellphone from linux. is that what you are saying i should be looking into? thanks to everyone taking time to respond as well
Just edit init.rc wherever that may be or its tributaries init.zygote1234.rc
There's the services zygote or zygote32 or zygote64.
Just comment them out or delete the tributary files.
Renate said:
Just edit init.rc wherever that may be or its tributaries init.zygote1234.rc
There's the services zygote or zygote32 or zygote64.
Just comment them out or delete the tributary files.
Click to expand...
Click to collapse
ok i need to put that in google translate. spanish isn't my strong suit
what would the process be called of loading linux and running it like the O.S. i'm trying to figure out what to google so i can try and find instruction of some sort just wrap my mind around it. if there is a name. thanks
gotta feel like talking to a toddler right now appreaciate the help
PBL ➡ xbl ➡ abl ➡ boot.img (kernel) ➡ init ➡ zygote ➡ Android services & apps
Renate said:
PBL ➡ xbl ➡ abl ➡ boot.img (kernel) ➡ init ➡ zygote ➡ Android services & apps
Click to expand...
Click to collapse
So you're saying there is a way to boot Linux on an Android phone? I thought that needed a special build designed for that device.
Renate said:
PBL ➡ xbl ➡ abl ➡ boot.img (kernel) ➡ init ➡ zygote ➡ Android services & apps
Click to expand...
Click to collapse
ok and will wifi still function after i do this do you know
ethical_haquer said:
So you're saying there is a way to boot Linux on an Android phone? I thought that needed a special build designed for that device.
Click to expand...
Click to collapse
on youtube i saw some people booting android, cant finding anyone disabling the zygote functions though, most cases people still want phones to work lol
mknick89 said:
ok and will wifi still function after i do this do you know
Click to expand...
Click to collapse
That all should work fine.
You can just use the shell command stop which will stop all things Android-ish.
You can try out whatever you're doing without permanently disabling Android.
The only gotcha is to make sure that ADB is started inside init/init.rc and not by Android.
setprop persist.sys.usb.config adb should do that.
Renate said:
That all should work fine.
You can just use the shell command stop which will stop all things Android-ish.
You can try out whatever you're doing without permanently disabling Android.
The only gotcha is to make sure that ADB is started inside init/init.rc and not by Android.
setprop persist.sys.usb.config adb should do that.
Click to expand...
Click to collapse
Can you please explain it a little more? So you delete some files in a specific directory, and that's it? You have to use ADB for the commands I guess? And is it really just the Linux kernel, or modified? Sorry for the childish questions.
Renate said:
That all should work fine.
You can just use the shell command stop which will stop all things Android-ish.
You can try out whatever you're doing without permanently disabling Android.
The only gotcha is to make sure that ADB is started inside init/init.rc and not by Android.
setprop persist.sys.usb.config adb should do that.
Click to expand...
Click to collapse
i have one more question to. should upload ubuntu to a certain directory or boot file or anything so the phone knows how to boot. or how does that work. this information is gold and i would like thank you for your time again
ethical_haquer said:
Can you please explain it a little more?
Click to expand...
Click to collapse
I write bunches of command line (shell) applications for Android and they are mostly identical to main line Linux.
Ok, some of the paths are different and a few other details are different.
You can write shell utilities that interact with Android over Binder, but those won't work if Android isn't running.
Just get the Android NDK which has the cross compilers and headers.
A "hello world" program should take you five minutes.
Just type uname -a and you can see what Linux kernel version you have.
You don't need to delete anything, just run your program.
If you want, you can stop Android temporarily by stop
To prevent it from ever running you need to patch some .rc file so that zygote (32 and/or 64) doesn't ever start.
To write to the screen (without Android's surface flinger running) you'll have to play with the framebuffer yourself.
You have an OS already on your device, it's Linux.
If you want to run Ubuntu on your device, that's an entirely different project.
i launch the files for mining software from inside ubuntu. Currently accessing ubuntu through the userland app. here is a 2 minute video of someone on cpu launching a similar version of my program made for linux. same steps i go through pretty much would this look like it could be done from the linux command on a phone. or do you think it is compatible really?
only first minute matters of video
There's no audio and I'm not at all interested in mining.
If it's not a GUI app, just recompile it using the Android NDK.
Renate said:
There's no audio and I'm not at all interested in minin
If it's not a GUI app, just recompile it using the Android NDK.f it would lau
Click to expand...
Click to collapse
oh i understand. i actually found the info. i was more wondering if it would launch, thanks for looking though. I going to study those commands you gave me and give it a try. Im very new to this took me 12 hours to load 4 lines of code the other day successfully lol thanks again