Related
I've been tinkering with dnsmasq and ad blocking (using the terminal to input commands). It works so far, except breaks the words-with-friends app.
I was thinking that it would be easier to maintain than a HOSTS file (cause you can block subdomains), and that it would be quicker (less resources than the linear lookup of a giant hosts file). I could be completely wrong, but let me know what you think.
To get it running, I do this, more or less:
su
mount -o rw,remount -t yaffs2 /dev/block/mtdblock3 /system
cp /sdcard/adblock.conf /system/etc/adblock.conf
dnsmasq -C /system/etc/adblock.conf
Then cycle the airplane mode, that sometimes gets it working. If not:
getprop
setprop net.dns1 127.0.0.1
Sometimes it doesn't stick. I had some questions for people that know more than I do:
1. Is it possible to get a pixelserv script running? One of my goals is to block words with friends ads, without breaking words with friends, and I think that might do the trick. (http://proxytunnel.sourceforge.net/pixelserv.php)
2. Would this affect the use of dnsmasq elsewhere, like tethering? Can two dnsmasq instances run at the same time in that case, or would this one have to be ended?
3. Is this a worthwhile endeavor?
PS: The script uses OpenDNS for actual DNS requests. Also, 50-60 ad servers are blocked, they're routed to 0.0.0.0 for speed (as they immediately return invalid, rather than trying to connect), if we were to use the pixelserv in the future, they'd have to go back to 127.0.0.1 for that to work.
PPS: Pixelserv is a perl script, I guess wouldn't run natively, but these may be worth looking at: http://code.google.com/p/android-scripting/ , http://code.google.com/p/perldroid/
Thanks for looking! If this is in the wrong area, please move it.
Another thought, could iptables be used instead? I'm not very familiar with linux
Well the script should be working, it is 'ettin.sh' now. To get VNC to work on separate device just change 'eth0' to 'wlan0' or whatever other interface you know how to configure, like usb maybe, in the 'init.sh' script that resides in ~/ on the images you can download from http://linuxonandroid.org/downloads/. Cool. If anyone can help with the usb configuring that would be cool.
Also on the different roms your storage might be different so just change that to what suites your environment,
BAD NEWS, After my first launch and exiting the VNC on my laptop (Ubuntu) My phones home button and a few other functions stopped working, a reboot remounts the root and system partitions and it goes back to normal essentially, I haven't noticed any adverse affects after the reboot.
Good luck.
EDIT: If you can't help me, you probably shouldn't attempt any of this.
I want to connect to backtrack over usb from Ubuntu on my laptop instead of from my phone. Is there a good way of doing this?
The thing is, I didn't chroot, I mounted the image, copied the contents of '/etc/*' and '/sbin/*' to the '*/etc' '*/sbin' dirs of the mounted image. and then mounted it's (the image's) contents to Androids rootfs '/' then I set up a little script to set up the environment and execute '/bin/bash -i init.sh' and again reset PATH to include /system/*.
Then in the init.sh script I want to set up a way to 'vnc' through' usb to backt4acks desktop. How would I do this?
EDIT: I started this script blelow, its not complete, feel free to use it however you like.
If anyone is good with bash I need help with loops in Bash or shell, ksh, or ash. So if you change it at all share those changes here. I haven't tested any of the loops, I wrote this here and need to do some reading on shell scripting, peace out.
Just NOTE that I would not execute this script yet, it is NOT YET COMPLETE.
I will be making minor changes as I learn and test things out, Also this was inspired by the autobootscrip (sp?) that the Linux on Android Installer app uses.
mintberrycrunch revision
I need a little help with the mounting part, "is there anybody out there?"
EDIT: Maybe escape '\' characters...
Maybe this will work? 'if [ ! -d "/$d" -a "$d" \!= "dev" -o "$d \!= "mnt" ]; then ' I want it to test whether the directory does not already exists in / and if it is not named dev or named mnt then mount it. Do you think this is a decent way to do it? Any suggestions?
Sorry, I still haven't tested this script yet, so if you brave and see any changes that will make it work I am not resposible. But it is getting close to when I will run it for the first time. The difference between this and the one I wrote for Kali is this should be a one stop shop so to speak for getting into a non chroot enviroment where you can access Bt's tools from Android directly. Apperently about a year ago someone was trying something similar called "debian installer" or something, I haven't tried it out so maybe that actually works, idk, I am happy with this.
LOL
LMFAO!
I just realized I don't think I needed to worry about testing if the variable $d was named 'dev' or 'mnt' because they should get skipped by already being mounted. If not I guess if it works as is, may be extra precaution.
Done! Almost ;{)-
Uhmm.... hope you can see the screenshot...
its over wifi though, I had to edit the init.sh script just eth0 to wlan0 in 2 lines, duh! where is eth0 on phone?
Check out the filesystem
Bada bing, bada doom, dare ya goes`a for ya.
V-0.021
This should support args, if your using different image or location such as external sdcard or want to mount to a different location
Notes: 'ettin.sh' [/IMAGE/LOCATION] [IMAGENAME] [MOUNT/POINT]'
1) Don't add a trailing forward slash for image location, the first argument. Doing so may conflict with the script.
2) Don't add suffix to image name ( second argument), the script uses a wild card period wild card syntax to account for .iso, .raw, or .img aswell as version numbers, so if its backtrack-v-r5.img all you need is 'backtrack'.
3) Default mount is "/data/local/mnt"
for example:
Code:
ettin.sh /storage/extSdCard/ubuntufolder ubuntu /mnt/myLinux
That ^^^ will use a ubuntu image on the external sdcard and mount it to a folder called "myLinux" within the "/mnt" directory.
The script below...
Code:
#!/system/bin/sh
# ettin.sh v-0.021, "Two heads are better than one."
# Written by 'Edge-Case' @ 'forum.xda-developers.com'
# This version is attempting to use symbolic linking to correct some issues.
## The purpose of ettin.sh is to merge a Linux system with Android
## hopefully allowing both systems to run in synch with each other.
## It is probably best to be ran on devices with multi-core processors.
##"""Notes on Backtrack and Kali Linux Distributions:
##"""1) Postgresql needs to be configured in order for metasploit to connect to
##""" the database. This might be possible within the script. Perhaps
##""" it is simply a matter of configuring SSH? I don't know.
##"""2) The Kernel needs to be patched to allow for packet injection and
##""" monitor mode for an external 'wi-fi' card as the factory hardware
##""" does not support monitor mode, at least on Samsung Galaxy SIII.
#########
# Prep ##
#########
mount -wo remount systemfs /system
mount -wo remount rootfs /
imloc=${1:-"/storage/sdcard0/backtrack"}
imname=${2:-"backtrack"}
subset=${3:-"/data/local/mnt"}
#Check for root!
if [ ! -d "$subset" ]; then mkdir "$subset"; fi
busybox mount -wo loop ${imloc}*/${imname}*.* ${subset}
check_mnt="`echo $?`"
if [ ${check_mnt} != 0 ]; then echo "Something is wrong with mounting, check the situation!" && exit; fi
##################################################
# Copy contents of special directories to image ##
##################################################
if [ ! -f "${imloc}/success.txt" ] ; then cp -ai /sbin/* ${subset}/sbin && echo "Files have been copied on `date`." > ${imloc}/success.txt; fi
if [ -e "/root/*" ]; then cp ai /root/* ${subset}/root; fi
######################################################
# Make directories needed and mount the file-system ##
######################################################
cd ${subset}
for d in `ls` ; do if [ ! -d "/${d}" ] ; then mkdir /${d} && busybox mount --rbind ${subset}/${d} /${d} ; fi ; done
busybox mount --rbind ${subset}/root /root
busybox mount --rbind ${subset}/sbin /sbin
busybox cp -rspi ${subset}/etc/* /etc # We'll try making symbolic links from the image to Android's /etc instead.
# Add any directories as needed.
###############################
# be safe before we continue ##
###############################
mount -ro remount systemfs /system
mount -ro remount rootfs /
######################################
# continue building the environment ##
######################################
export PATH="/system/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/system/xbin:/usr/games"
export TERM=linux
export HOME="/root"
#################################
# further down the rabbit hole ##
#################################
/bin/bash -i ~/init.sh
Pretty happy with it now, so far. Touch FIXED
Well, I am tethered from my phone to my laptop, running ubuntu, this is how I am on the internet, so my phone is doing that...
I ran 'ettin.sh /storage/sdcard0/ubuntu ubuntu' using V-0.022 and only had two files that needed overwriting.
The touch is working....check
adb is working...check
Everything is mounted ...check
Apps like browser and dsploit are working on the phone as usual...check
'apt-get update && apt-get upgrade'....check (over adb, no chroot, as [email protected] using bin/bash)
'which nmap' .....check ("
[email protected]:~# which nmap
/usr/bin/nmap
")
Well **** ya'll looks like this might work... I am now going to consider modifying a stock rom to support users and login that meshes with debian and its "shadow" file etc etc, also I need to work out permissions and enviroment variables...
I'm happy...
Also for pentesting distro's "modifying Android kernel" tutorials would be nice, anybody able to point me to one?
I have a rooted a GT-I9195 (SGS4-mini) done with CF-Auto-Root and the latest Busybox. I then decided to use the "Ssh server" from The Olive Tree, since it is simple, small, free, but unfortunately have ads. For on-device/local shell, I use the Android Terminal Emulator and everything works great, including su and shell environment.
However, I have a really strange bahaviour when connecting using ssh via WiFi, and trying to su.
First when connecting via ssh, I get the following message.
Code:
[SIZE=2]$ ssh -2 -4 -t [email protected] -p 50555
Authenticated with partial success.
[email protected]'s password:
/system/bin/sh: No controlling tty: open /dev/tty: No such device or address
/system/bin/sh: can't find tty fd
/system/bin/sh: warning: won't have full job control
[email protected]:/ $[/SIZE]
I have Googled this and there's little useful info. On one site they even say:
Code:
[SIZE=2]Getting a controlling tty
[B]How does one get a controlling terminal? [COLOR=Red]Nobody knows[/COLOR], this is a great mystery.[/B]
The System V approach is that the first tty opened by the process
becomes its controlling tty. The BSD approach is that one has to
explicitly call
ioctl(fd, TIOCSCTTY, ...);
to get a controlling tty.
Linux tries to be compatible with both, as always, and this results in
a very obscure complex of conditions. Roughly:
The [B]TIOCSCTTY [/B]ioctl will give us a controlling tty, provided that (i)
the current process is a session leader, and (ii) it does not yet have
a controlling tty, and (iii) maybe the tty should not already control
some other session; if it does it is an error if we aren't root, or we
steal the tty if we are all-powerful.
Opening some terminal will give us a controlling tty, provided that
(i) the current process is a session leader, and (ii) it does not yet
have a controlling tty, and (iii) the tty does not already control
some other session, and (iv) the open did not have the [B]O_NOCTTY[/B] flag,
and (v) the tty is not the foreground VT, and (vi) the tty is not the
console, and (vii) maybe the tty should not be master or slave pty.
[/SIZE]
Now this is not the end of the world, if it was not that it doesn't understand normal terminal control characters and in addition, when I do su, I loose the command prompt. However, using the "-i" (interactive) switch gets me the "#" prompt, but environment is still completely messed up:
Code:
[SIZE=2][email protected]:/ $ [B]su -c /system/bin/sh -i[/B]
/system/bin/sh: No controlling tty: open /dev/tty: No such device or address
/system/bin/sh: can't find tty fd
/system/bin/sh: warning: won't have full job control
[email protected]:/ #[/SIZE]
I've never had or seen this issue before. Any ideas?
(Also, where would I put a source to my .bashrc and make sure it runs when su'ing or ssh?)
PS. The phone is using a stock 4.2.2 SELinux kernel.
Code:
[SIZE=2]Device: Samsung Galaxy S4 Mini LTE (GT-I9195)
Board/Platform: MSM8930AB (Snapdragon 400)
Baseband: I9195XXUBML4
Kernel: 3.4.0-2340422
[email protected] #1
Build: JDQ39.I9195XXUBML4
SE: SEPF_GT-I9195_4.2.2_0022
ro.build.date: Sat Dec 21 01:46:00 KST 2013
ro.build.description: serranoltexx-user 4.2.2 JDQ39 I9195XXUBML4
[/SIZE]
I still have no idea of what's causing those error messages above, also because logcat is not telling us anything interesting either. Only as Warning from "System.err", but without any useful information. However, I have got some improvement in the terminal behavior when doing the initial ssh connection.
One problem seem to be that the TERM environment variable was copied from local machine (PC side) to remote server (Android phone), thus giving TERM=cygwin to the Android shell. This can be disabled or changed as follows.
Some relevant SSH options:
Code:
[SIZE=2]
-e escape_char
Sets the escape character for sessions with a pty (default: `~'). The escape
character is only recognized at the beginning of a line. The escape charac-
ter followed by a dot (`.') closes the connection; followed by control-Z sus-
pends the connection; and followed by itself sends the escape character once.
Setting the character to "none" disables any escapes and makes the session
fully transparent.
-T Disable pseudo-tty allocation.
-t Force pseudo-tty allocation. This can be used to execute arbitrary screen-
based programs on a remote machine, which can be very useful, e.g. when
implementing menu services. Multiple -t options force tty allocation, even
if ssh has no local tty.
[/SIZE]
Some relevant SSH -o options:
Code:
[SIZE=2][B]RequestTTY[/B]
Specifies whether to request a pseudo-tty for the session. The argument may
be one of: "no" (never request a TTY), "yes" (always request a TTY when stan-
dard input is a TTY), "force" (always request a TTY) or "auto" (request a TTY
when opening a login session). This option mirrors the -t and -T flags for
ssh(1).
[B]
SendEnv[/B]
Specifies what variables from the local environ(7) should be sent to the
server. Note that environment passing is only supported for protocol 2. The
server must also support it, and the server must be configured to accept
these environment variables. Refer to AcceptEnv in sshd_config(5) for how to
configure the server. Variables are specified by name, which may contain
wildcard characters. Multiple environment variables may be separated by
whitespace or spread across multiple SendEnv directives. The default is not
to send any environment variables.
[/SIZE]
So by using the ssh -T option (which is equivalent to using '-o RequestTTY="no"'), we are disabling "pseudo-tty allocation" which doesn't work anyway, but with the effect of not forwarding local TERM to server, and thus setting it to default "vt100" which accepts backspace (but not insert). But a better way is to actually set the TERM variable on our own. This is done by simply adding it as a prefix to the ssh command like this:
Code:
[SIZE=2]TERM=[B]vt220[/B] ssh -t [email protected] -p 50555[/SIZE]
(This effectively, but temporarily overrides the local TERM value and forwards it to remote server shell.)
RanTime!
Since Google intruduced the SELinux/SEAndroid features, they have essentially fukced up the entire AOS ecosystem as based on good-old normal Linux environments and all the years of standards therein. Basically nothing works as before and as logically intended or preferred and I bet from now on, developers will have to spend a significant and expensive time, on just trying to setup their various developer environments and jump through the hoops of dikchead Google engineers, rather than on actual developing. A very sad story all thanks to the populist "security" eye-candy marketing.
The SU time!
Apparently after having read about the various quirks and issues in using an SELinux Enforced based AOS {4}, it seem that the issue from OP is probably due to one of 3 things or a combination thereof.
My su binary (SuperSU 1.94) is not yet handling SElinux properly
The SSHd server is not handling SELinux properly
Lack of properly set SSH and SHELL environment files on the server side
As for (1) I just have to wait and see. For (2) we can only test with other SSHd servers/solutions which I don't know what to use. (They're all, either not free or full of ads. WTF!) And finally, for (3) we can only test, since I don't have the source code...
Unfortunately listing the SuperSU (1.94) command line options is not very helpful, since they're rather poorly explained. While some of the option themselves just doesn't work (for me). It would have been great if @Chainfire could write a more detailed how-to {2} for all these options, but then again we should be extremely grateful he's written anything at all.
Code:
[SIZE=2]Usage: su [options] [--] [-] [LOGIN] [--] [args...]
------------------------------------------------------------------------------------
Options:
-c, --command COMMAND pass COMMAND to the invoked shell
-cn, --context CONTEXT switch to SELinux CONTEXT before invoking
-h, --help display this help message and exit
-, -l, --login pretend the shell to be a login shell
-m, -p,
-mm, --mount-master connect to a shell that can manipulate the
master mount namespace - requires su to be
running as daemon, must be first parameter
--preserve-environment do not change environment variables
-s, --shell SHELL use SHELL instead of the default detected shell
-v, --version display public version and exit
-V display internal version and exit
Usage#2: su LOGIN COMMAND...
Usage#3: su {-d|--daemon|-ad|--auto-daemon|-r|--reload}
auto version starts daemon only on SDK >= 18 or
if SELinux is set to enforcing
Usage#4: su {-i|--install|-u|--uninstall}
perform post-install / pre-uninstall maintenance
[/SIZE]
References:
[1] [Chainfire G+] Next Android version: even more breakage
[2] [Chainfire] How-To SU (Guidelines for problem-free su usage)
[3] SuperSU Download
[4] [Google] Validating Security-Enhanced Linux in Android
From THIS very old post by @mirabilos , it is possible that command-line TAB-completion and up-arrow is not working on all mksh binaries. So perhaps we just need a new static mksh binary installed?
Tab expansion is pretty broken on BSD with xterm and GNU screen, but the same seems to work better on ssh’ing out to Linux, I wonder why, since all software involved is the same… except tput though. But it works like that and is usable. With post-R40 mksh, you can get about with even less hacks (more similarity to AT&T ksh).
Click to expand...
Click to collapse
However, this still doesn't explain why I have no controlling tty for ssh sessions.
Also I tested a new and different SSH server called SSHelper, which has more features and is better maintained, without ads, but is also 6 times larger at ~ 6MB, because of included OpenSSH, FTP and webserver log functionality. When logging in via ssh I get:
Code:
...
Server refused to allocate pty
Followed by an empty non-responsive connection.
Is this the same as […]this problem elsewhere? Man, I'm searching for ideas and keep coming back to your questions all over the 'net
To clarify, I talked to someone at Google; they renamed mksh into just sh lately, but this should have no adverse effect. They currently ship R48 and “would have updated it if I knew there was a new version”. That being said, the code of the shell itself is not at fault here.
The “no controlling tty” message here is a red herring: you do not have access to a tty at all, let alone a ctty
As I said elsewhere, use “ssh -t” and either change the SELinux policies to allow pty/tty pair allocation, or disable it (possibly set it into permissive mode).
@mirabilos: Yes, thanks for that info. I haven't updated this thread since I started it, in anticipation of a writeup about SELinux. However, that proves to be a little over my head, so it will take some time. What is clear though, is that the above problem is connected with the SEAndroid protection mechanisms, which in turn have been mangled and incorporated into Samsungs KNOX.
Also I have been busy making the SSHelper support thread:
[APP][INFO|SUPPORT] SSHelper (The free Android SSH Server Application)
There I have also added a small section about mksh.
@ E:V:A - I recently put together a little package containing all necessary bins/scripts to create a SSH server (via dropbear and dropbearkey) (properly secured, not public) and connect with a SSH client (ssh). The package also contains bins/scripts to create a Telnet server (via utelnetd) and connect with Telnet client (via "static busybox" telnet). Everything works with superuser that I've tested. Linked in my signature and attached to post as well.
Instructions (for anyone who sees this and would like a guide)::
Basically just extract it anywhere with:
Code:
tar -xf easy.ssh.and.telnetz.clients+servers.tar.gz
(if it's in /sdcard/Download which is probable, do "cd /sdcard/Download" then run the above)
Change directory inside the folder:
Code:
cd ./ssh.telnetz
There are 6 scripts: ssh.start(connect to ssh server via ssh), sshd.start(create ssh server), ssh.kill(kill ssh processes and remove ssh server keys), and... 3x telnet scripts for the telnet equivalents.
Running scripts and optional parameters:
Code:
./telnetd.start [ shell ]
e.g. TELNET_PORT=8080 ./telnetd.start /system/bin/mksh
./telnet.start [ ip port ]
e.g. ./telnet.start 192.168.0.3 8080
./sshd.start [ <dropbear_flags_and_options ]
e.g. ./sshd.start (default port is 8090)
./ssh.start [ ip port shell ]
e.g. ./ssh.start 192.168.0.3 8090 /system/bin/mksh
Default ip is the loopback 127.0.0.1 so you can test running a server and connecting to it on your phone at the same time. Just change params as described above to connect from/to your phone (phone is client/server).
***As far as I have tested on Android 4.4.4, this works perfectly as root or restricted user. You can get a su'd ssh shell by starting the sshd.start with /system/xbin/su or just entering su after you've connected as a restricted user.***
I've finally found a work-around for the crippled /dev/pts job-control and su combination. There are two small problems that combines to this issue.
1. The SELinux policy is screwed up by Samsung. And others?
2. The /dev/pts is mounted wrong by default.
The work-around:
Make sure you're device is already in Enforcing mode, so that you get the proper su prompt (#).
1. Open terminal session 1.
Code:
[SIZE=2]
## On Terminal 1
ssh -2 [email protected] -p 2222
$ su -c /system/bin/sh -i
# su 0 setenforce 0
# umount /dev/pts
# su -cn u:r:init:s0 -c "busybox mount -t devpts -o rw,seclabel,relatime,mode=620,gid=5 devpts /dev/pts"[/SIZE]
2. Now go to Terminal 2 and login:
Code:
[SIZE=2]## On terminal 2
ssh -2 [email protected] -p 2222
$
[/SIZE]
(You now have job-control but no su possibility.)
3. Now go back to Terminal 1 and enable Enforcing mode:
Code:
[SIZE=2]## On Terminal 1
# su 0 setenforce 1
[/SIZE]
4. Now go back to Terminal 2 and escalate to su:
Code:
[SIZE=2]## On terminal 2
$ su -c /system/bin/sh -i
# [/SIZE]
Unfortunately if you exit the su (#) shell, you'll have to repeat steps 2-4 of the procedure.
Hello,
I want to install DNScrypt proxy 1.4 on my android phone. You can get it here : download.dnscrypt.org/dnscrypt-proxy/
Could someone please make a tutorial an tell me how to install this? I want it to work with following DNS server: https://dnscrypt.eu/
It is a great enhancement in security and I would be glad if someone can get it to work and tell us.
Regards
Is nobody interested in this? [emoji20]
Can't believe there is no response. Is no one of the XDA members who looked at this able to install DNScrypt on there phone?
Do you prefer flappy bird clones over such a security enhancement?
Bump again then.
Bump
Another bump for all secureless xda members
XDA members are not able to install a tar.gz package on their android phone? Aww, really guys?!
B u m p
Seriously, no one...?
How to install dnscrypt on android
Requirements:
rooted phone
installed busybox
some handy tools like terminal emulator or ssh daemon for testing purpose, file explorer with acces to system partition
dnscrypt: https://copy.com/M6r38z6g3iyj (thanks to GitHub esp. @daddybr, KionLi...) - files for arm7
About:
We need to run dnscrypt every time phone is booted - for this purpose is necessary to add script "dnscrypt" into "init.d" directory In this script-file you can also change parameters like used resolver/provider etc.
dnscrypt-proxy is main binary file which will provide dnscrypt service for us. There is also script to start/stop dnscrypt-proxy service anytime we need and made some other usefull things for us...
How to:
check if directory "init.d" in /system/etc/ exist - if there is not such directory use program "Universal Init.d" and create it - otherwise follow bellow
extract downloaded files and put it into same directories they are, just to system partition (u can use any file browser with access to system partition, eg. Solid Explorer)
check if there is file "resolv.conf in /system/etc/ directory
- if there is not such file create it and put this into it "nameserver 127.0.0.1"
- if there is such file check if "nameserver 127.0.0.1"and delete else
all files putted in directory /system/xbin/ should have right permission to work correctly
Checking functionality:
Easiest way is to visit "www.opendns.com/welcome"
If it is working you will get something like "Your Internet is safer, faster, and smarter..."
If it is not working you will get something like "OOPS..."
Other way is to run nslookup in terminal emulator and check if you get 127.0.0.1 and name, eg "nslookup 8.8.8.8"
The hardest way is to use wireshark or tcpdump and analyze traffic while browsing on the phone..., eg. http://askubuntu.com/questions/105366/how-to-check-if-dns-is-encrypted
Also you can check if dnscrypt-proxy is running in terminal , eg. "ps w |grep dnscrypt"
DNS setting
Did anyone got this one to work? I did all the steps mentioned but it seems that the resolv.conf is not being checked. I even try with apps to change dns settings (dnset, dnschanger..) it just seems that the dynamic dns assigment takes precedence, it keeps going to the dynamically assigned DNS server when on wifi and LTE. Aside from that I did not have any issues, dnscrypt runs fine with all arguments. I'm trying this on a Verizon Galaxy S5.
<dexter> said:
Did anyone got this one to work? I did all the steps mentioned but it seems that the resolv.conf is not being checked. I even try with apps to change dns settings (dnset, dnschanger..) it just seems that the dynamic dns assigment takes precedence, it keeps going to the dynamically assigned DNS server when on wifi and LTE. Aside from that I did not have any issues, dnscrypt runs fine with all arguments. I'm trying this on a Verizon Galaxy S5.
Click to expand...
Click to collapse
Yes, working here.
Had trouble with afwall though, but this post http://forum.xda-developers.com/showpost.php?p=54263022&postcount=8 helped me.
Script i've used:
Code:
$IPTABLES -t nat -D OUTPUT -p tcp --dport 53 -j DNAT --to-destination 127.0.0.1:53 || true
$IPTABLES -t nat -D OUTPUT -p udp --dport 53 -j DNAT --to-destination 127.0.0.1:53 || true
$IPTABLES -t nat -I OUTPUT -p tcp --dport 53 -j DNAT --to-destination 127.0.0.1:53
$IPTABLES -t nat -I OUTPUT -p udp --dport 53 -j DNAT --to-destination 127.0.0.1:53
$IPTABLES -A "afwall" --destination "208.67.220.220" -j RETURN
You can restrict the last line to only UDP 443 if you want.
Confirmed packets with tcpdump, blocked UDP 53 at my router.
piscoo said:
Yes, working here.
Had trouble with afwall though, but this post http://forum.xda-developers.com/showpost.php?p=54263022&postcount=8 helped me.
Script i've used:
Code:
$IPTABLES -t nat -D OUTPUT -p tcp --dport 53 -j DNAT --to-destination 127.0.0.1:53 || true
$IPTABLES -t nat -D OUTPUT -p udp --dport 53 -j DNAT --to-destination 127.0.0.1:53 || true
$IPTABLES -t nat -I OUTPUT -p tcp --dport 53 -j DNAT --to-destination 127.0.0.1:53
$IPTABLES -t nat -I OUTPUT -p udp --dport 53 -j DNAT --to-destination 127.0.0.1:53
$IPTABLES -A "afwall" --destination "208.67.220.220" -j RETURN
You can restrict the last line to only UDP 443 if you want.
Confirmed packets with tcpdump, blocked UDP 53 at my router.
Click to expand...
Click to collapse
Could you please write a small, complete guide for the installation of DNScrypt? I still can't get it to work.
Draygon said:
Could you please write a small, complete guide for the installation of DNScrypt? I still can't get it to work.
Click to expand...
Click to collapse
Flash this zip from recovery. It works
Do you have any source for this?
How can I enter the IP address of the service I want to use?
Draygon said:
How can I enter the IP address of the service I want to use?
Click to expand...
Click to collapse
Edit /etc/init.d/dnscrypt and see here
So you compiled DNScrypt for Android from this source at github?
Draygon said:
So you compiled DNScrypt for Android from this source at github?
Click to expand...
Click to collapse
No. I just flashed zip file and investigated on it
Anyone flash this zip besides the guy who posted it? Can't find much reference to this file name anywhere dnscrypt-5-armv7-opendns.zip
lamero1 said:
No. I just flashed zip file and investigated on it
Click to expand...
Click to collapse
How do you set your phones global DNS setting for any dynamic IPs on any network? I cannot figure out how to point my phone to 127.0.0.1
Draygon said:
So you compiled DNScrypt for Android from this source at github?
Click to expand...
Click to collapse
Assuming you have the Android NDK installed (no idea how to do it under Windows; Cygwin has never been my forte... Under Arch all you need to do is install the packages from the AUR), it's insanely easy to do yourself, thanks to the build scripts in the libsodium and dnscrypt packages.
Code:
export ANDROID_NDK_HOME=${ANDROID_NDK} # Or wherever your NDK dump happens to be residing
mkdir ~/dnsc && pushd ~/dnsc
This part deals with signature verification, used to determine we have not received a tampered-with copy of DNSCrypt. This page is being delivered over unsecured HTTP, so don't necessarily trust what's being written here.
Again: REMEMBER THAT THIS PAGE IS UNSECURE (granted, I imagine a person intending to cause malice would remove these warnings but, hey, it's not like I have alternatives). I'm also not a security expert in the slightest, so it wouldn't be surprising if it transpired I was giving bad advice.
Read http://doc.libsodium.org/installation/README.html for instructions on how to get libsodium's SHA256 hashsum (which you can verify against the file you've got downloaded by running sha256sum) and for the public key used to sign the downloaded files. It can be imported by copying it, pasting it into a Notepad etc. instance, saving it and running gpg --import <whatever.gpg>.
Use your own judgement, other keyservers and Google to determine whether you have jedisct1's real key.
Download dnscrypt's dependency, libsodium:
Code:
curl -O https://download.libsodium.org/libsodium/releases/libsodium-1.0.2.tar.gz -O https://download.libsodium.org/libsodium/releases/libsodium-1.0.2.tar.gz.sig
Verify the file's signature:
Code:
gpg --verify libsodium-1.0.2.tar.gz.sig libsodium-1.0.2.tar.gz
I get the following (the warning can be ignored -- unless you've managed to verify the key with jedisct1 in person):
Code:
gpg: Signature made Tue 10 Feb 2015 10:59:17 AM GMT using RSA key ID 2B6F76DA
gpg: Good signature from "Frank Denis (Jedi/Sector One) <redacted>" [unknown]
gpg: aka "Frank Denis (Jedi/Sector One) <redacted>" [unknown]
gpg: aka "Frank Denis <redacted>" [unknown]
gpg: aka "Frank Denis <redacted>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 54A2 B889 2CC3 D6A5 97B9 2B6C 2106 27AA BA70 9FE1
Subkey fingerprint: 0C79 83A8 FD9A 104C 6231 72CB 62F2 5B59 2B6F 76DA
If everything looks OK, then continue. Conversely, if anything is out of place, then abort. Seriously.
Untar and go to the directory with the libsodium code:
Code:
tar xf libsodium-1.0.2.tar.gz && pushd libsodium-1.0.2
It's not in the tarball yet, so download this into the dist-build folder and chmod 0755 it.
If running into problems, edit aandroid-armv7-a.sh and do the following:
change TARGET_ARCH to arm
set the march value to armv7-a
Start building libsodium:
Code:
./dist-build/android-armv7-a.sh
I get the following dumped:
Code:
[email protected] ~/dnsc/libsodium-1.0.0 % ./dist-build/android-arm.sh
<configure output removed>
libsodium has been installed into /home/faheem/dnsc/libsodium-1.0.0/libsodium-android-arm
./dist-build/android-arm.sh 21.97s user 2.72s system 165% cpu 14.927 total
Note the line saying where libsodium has been installed. Let its value be stored in the environment:
Code:
export SODIUM_ANDROID_PREFIX=<folder where libsodium has been installed, as reported by android-arm.sh>
Consider removing debugging symbols to reduce the size of the file:
Code:
./android-toolchain-arm/arm-linux-androideabi/bin/strip $SODIUM_ANDROID_PREFIX/lib/libsodium.so
I won't repeat what's on the main dnscrypt.org site or, really, what I've already written.
popd back to the ~/dnsc folder and download the latest version of dnscrypt and its signature. Follow the instructions on the website to verify the tarball's SHA256SUM and run gpg like above to verify the tarball against the signature. If everything is OK, untar dnscrypt like we did libsodium.
Run to build:
Code:
./dist-build/android-armv7.sh
If running on Lollipop, make the changes below, as per alihassani:
add -fPIE to the end of the CFLAGS
place export LDFLAGS="-fPIE -pie" under the CFLAGS line
If running into problems running android-armv7.sh, make the applicable changes above again.
After it's been built, you'll get this:
Code:
[email protected] ~/dnsc/dnscrypt-proxy-1.4.1 % SODIUM_ANDROID_PREFIX="$HOME/dnsc/libsodium-1.0.0/libsodium-android-arm/" dist-build/android-armv7.sh
<configure output snipped>
dnscrypt-proxy has been installed into /home/faheem/dnsc/dnscrypt-proxy-1.4.1/dnscrypt-proxy-android-armv7
Again, consider stripping the resulting binary. Transfer, fix permissions etc.
Some notes:
The binary is dynamically linked to libsodium. If installing, you'll need to copy libsodium.so to /system/lib. If you're just testing you can put libsodium.so in the same folder as the dnscrypt-proxy binary and invoke dnscrypt-proxy as such: LD_LIBRARY_PATH=<path to current folder> ./dnscrypt-proxy
The prefix is weirdly set by the android-build script. You'll need to point dnscrypt to the resolver list manually (I recommend putting it somewhere on the system partition as a file on the [internal] SD card is too easy to change): https://github.com/jedisct1/dnscrypt-proxy/issues/123
I've had the Samsung Chromebook Plus for about 2 weeks now, and I love it! Chrome OS is pretty good at handling itself for notetaking with the stylus, and the gorgeous screen is great for high res stuff (although Chrome OS is in desperate need of DPI scaling). It even runs Android apps out of the box! So far, I only have 2 major gripes about Chrome OS:
-It cannot do multitasking on anything (Android or Chrome app) when in tablet mode (buttons disappear, window drags are disabled) even on the beta branch
-Android cannot be rooted on the Chrome OS (so I think).
That second one is the one I'd like help with. Can you root the Android OS installed on the Chromebook? I'd love to know; I have a game called War Robots I want to play on it, but I can't manually turn down the graphical fidelity without using GLTools.
Any help is appreciated!
Nilithium said:
Can you root the Android OS installed on the Chromebook? I'd love to know; I have a game called War Robots I want to play on it, but I can't manually turn down the graphical fidelity without using GLTools.
Any help is appreciated!
Click to expand...
Click to collapse
Yes, certainly you can root Android on Chrome OS. The rootfs of the Android container is read-only by default, so the method I've been using involves making a writeable copy of the Android rootfs .img in /usr/local, adding SuperSU (adding its binaries to /system/xbin, the SuperSU apk to /system/priv-app, and modifying init.rc to autoload daemonsu), then replacing the original Android rootfs .img file path with a symlink to the rooted one. In addition, a couple of flags (mount-as-read-only and font sharing) need to be changed in one or two of the /etc/init/arc* files (CrOS version dependent), and also the SElinux policy file needs to be patched.
I have written a script to automate the above procedure, if you would like to try it out you can do so by entering the following into the Chrome OS shell (then rebooting).
Code:
curl -Ls https://raw.githubusercontent.com/nolirium/aroc/onescript/RootandSEpatch.sh | sudo sh
You need to be in Dev mode to get into the shell (Ctrl+Alt+T; type 'shell'), and rootfs verification needs to be switched off to modify system files (the script will give you the command to do this, if you haven't already done it).
It would be prudent to make sure any important files are backed up prior to making any changes to the rootfs.
Edit: If any errors occur, or problems are are experienced after using the script, such as Android (apps) failing to load, it's usually not necessary to powerwash. The script makes a backup of the original Android system.raw.img, which can be restored with the following command:
Code:
sudo mv /opt/google/containers/android/system.raw.img.bk /opt/google/containers/android/system.raw.img
Nolirum said:
Yes, certainly you can root Android on Chrome OS. The rootfs of the Android container is read-only by default, so the method I've been using involves making a writeable copy of the Android rootfs .img in /usr/local, adding SuperSU (adding its binaries to /system/xbin, the SuperSU apk to /system/priv-app, and modifying init.rc to autoload daemonsu), then replacing the original Android rootfs .img file path with a symlink to the rooted one. In addition, a couple of flags (mount-as-read-only and font sharing) need to be changed in one or two of the /etc/init/arc* files (CrOS version dependent), and also the SElinux policy file needs to be patched.
I have written a script to automate the above procedure, if you would like to try it out you can do so by entering the following into the Chrome OS shell (then rebooting).
Code:
curl -Ls https://raw.githubusercontent.com/nolirium/aroc/onescript/RootandSEpatch.sh | sudo sh
You need to be in Dev mode to get into the shell (Ctrl+Alt+T; type 'shell'), and rootfs verification needs to be switched off to modify system files (the script will give you the command to do this, if you haven't already done it).
It would be prudent to make sure any important files are backed up prior to making any changes to the rootfs.
Click to expand...
Click to collapse
On a general basis, running scripts from random strangers on the Internet is a bad thing. But I'll take it!
I've encountered an ID10T error though: I set the debugging password during setup, and I THOUGHT that was the sudo password to run your script. Problem is, that's not true, and I've no idea what it is.
Tried Google Account password, no dice.
Tried Chromebook PIN, no dice.
Tried Debug Pass set in Setup, no dice.
Tried password, no dice.
Tried null password (no input), no dice.
What is the sudo password? Did I miss something?
Nilithium said:
What is the sudo password? Did I miss something?
Click to expand...
Click to collapse
Yeah, this seems to be quite a common issue. Perhaps it would be more user-friendly if more information was available during the initial OOB setup, such as a link describing the 'debugging features' feature's features in a bit more depth.
Anyway, if you go into a VT with e.g. Ctrl+Alt+F2, you should be able to log in there as the user 'root' with your debugging password, and then you can run the command chromeos-setdevpasswd to set a sudo password for chronos.
Nolirum said:
Yeah, this seems to be quite a common issue. Perhaps it would be more user-friendly if more information was available during the initial OOB setup, such as a link describing the 'debugging features' feature's features in a bit more depth.
Anyway, if you go into a VT with e.g. Ctrl+Alt+F2, you should be able to log in there as the user 'root' with your debugging password, and then you can run the command chromeos-setdevpasswd to set a sudo password for chronos.
Click to expand...
Click to collapse
DELETE
Worked for me on Samsung Chromebook 3.
Manually downloaded and extracted SuperSU.zip to downloads.
Manually downloaded busybox using curl in shell. Moved it manually to /usr/local/bin/ believe thats correct.
Then re-ran script and it worked.
Anyone tried it on Pixelbook?
Nolirum said:
Yes, certainly you can root Android on Chrome OS. The rootfs of the Android container is read-only by default, so the method I've been using involves making a writeable copy of the Android rootfs .img in /usr/local, adding SuperSU (adding its binaries to /system/xbin, the SuperSU apk to /system/priv-app, and modifying init.rc to autoload daemonsu), then replacing the original Android rootfs .img file path with a symlink to the rooted one. In addition, a couple of flags (mount-as-read-only and font sharing) need to be changed in one or two of the /etc/init/arc* files (CrOS version dependent), and also the SElinux policy file needs to be patched.
I have written a script to automate the above procedure, if you would like to try it out you can do so by entering the following into the Chrome OS shell (then rebooting).
Code:
curl -Ls https://raw.githubusercontent.com/nolirium/aroc/onescript/RootandSEpatch.sh | sudo sh
You need to be in Dev mode to get into the shell (Ctrl+Alt+T; type 'shell'), and rootfs verification needs to be switched off to modify system files (the script will give you the command to do this, if you haven't already done it).
It would be prudent to make sure any important files are backed up prior to making any changes to the rootfs.
Click to expand...
Click to collapse
holy cow, script works flawlessly! (Samsung Chromebook Plus)
Anyone know why my Tivo app and Sirius XM don't work on my new Samsung Chromebook Plus V2? They install and than don't open and crash any other workable apks that anyone knows about? Sirius I can do online Tivo won't play all my recorded shows online just some and I really bought this Chromebook to use the Tivo app to watch shows when not at home or sitting outside. I know this thread is about rooting but I thought someone here may be able to help me. I also posted in the Tivo Community Forum also and am waiting for a response. Thanks!
MsWadera said:
Anyone tried it on Pixelbook?
Click to expand...
Click to collapse
This is the question I'm interested in also as I will be receiving my first PixelBook in a couple of days. Having root access in the Android container along with a Linux install would rapidly move this to my daily driver.
Can anyone confirm this?
phonefreedom said:
This is the question I'm interested in also as I will be receiving my first PixelBook in a couple of days. Having root access in the Android container along with a Linux install would rapidly move this to my daily driver.
Can anyone confirm this?
Click to expand...
Click to collapse
Well, I gave this a try and can say this is a no go for the Pixelbook. It did make Android unusable though causing me to powerwash and reload.
phonefreedom said:
Well, I gave this a try and can say this is a no go for the Pixelbook. It did make Android unusable though causing me to powerwash and reload.
Click to expand...
Click to collapse
When you say it was unusable, did Android (apps) appear to fail to load up completely, just the icon spinning? Or something else?
Did you happen to notice if any errors were shown on the script's output at all?
For example, there was this issue reported on github when the Pixelbook was first released, in which the Android rootfs container created by the script turned out to be a bit smaller than required, and so errors occurred when copying files to the new rooted /system. The user was able to successfully continue after manually editing the script so it created a container that was slightly bigger.
The script has been updated since then to reflect the increased space requirements, so that particular problem should no longer occur. Other potential sources of error might include if there could have been a problem downloading the required files (SuperSU, BusyBox), a problem patching SE Linux (in which case there is a separate script to do this part) , or maybe something else, possibly due to Chrome OS changes/updates.
In the case of the script rendering Android unusable, it's usually not necessary to powerwash. The script makes a backup of the original Android system.raw.img, which can be restored with the following command:
Code:
sudo mv /opt/google/containers/android/system.raw.img.bk /opt/google/containers/android/system.raw.img
Entering the above will restore the original read-only squashfs unrooted rootfs, which, after a reboot, should then load up as normal.
I think I'll edit my earlier post in this thread to add the command to restore from backup. Apologies for failing to mention it here initially. I might add an explicit message in the script itself regarding this, as well.
Flashing zips
Hey first time poster here. This may seem like a newbie question, but how do I flash zips without a custom recovery?
Is there a way to sideload to the container? I tried several apps like Flashfire (used an unofficial build since I could not disable the time bomb on Chrome Os) and Flash Gordon, but it did not seem to work.
Thanks
do-tim said:
Hey first time poster here. This may seem like a newbie question, but how do I flash zips without a custom recovery?
Is there a way to sideload to the container? I tried several apps like Flashfire (used an unofficial build since I could not disable the time bomb on Chrome Os) and Flash Gordon, but it did not seem to work.
Thanks
Click to expand...
Click to collapse
Depends what you want to flash, probably.
You might be able to rewrite the relevant edify commands in the update-binary that you want to flash into an equivalent shell script for the Chrome OS shell.
However, by default the Android rootfs container is in a read-only squashfs format, so normally cannot be modified directly. One way to modify it is to make a writable copy of the container in /usr/local, then replace the original file pathname with a symbolic link to the R/W copy. This works fine for the most part (but does takes up extra disk space, and needs to be re-done after an OS update).
For instance, here is part of the rooting script mentioned upthread, which makes a writable copy of the Android container, copies the files from the original container therein, renames the original to .bk, replaces the original file pathname with a symlink to the copy and, at the end, changes a couple of relevant envs in CrOS's /etc/init/arc-setup-env file.
Code:
#!/bin/sh
# Detect CPU architecture
case "$ARCH" in
x86 | i?86) ANDROID_ARCH="x86";;
x86_64 | amd64) ANDROID_ARCH="x86";;
armel) ANDROID_ARCH="armel";;
arm64 | aarch64) ANDROID_ARCH="armv7";;
arm*) ANDROID_ARCH="armv7";;
*) error 2 "Invalid architecture '$ARCH'.";;
esac
# Make some working dirs
mkdir -p /usr/local/Android_Images
mkdir -p /usr/local/Android_Images/Mounted
mkdir -p /usr/local/Android_Images/Original
# Create container image file. Intel devices need a slightly larger file.
if [ $ANDROID_ARCH=armv7 ]; then
cd /usr/local/Android_Images
fallocate -l 1.7G /usr/local/Android_Images/system.raw.expanded.img
else
if [ $ANDROID_ARCH=x86 ]; then
cd /usr/local/Android_Images
fallocate -l 2.2G /usr/local/Android_Images/system.raw.expanded.img
# Format the .img file.
mkfs ext4 -F /usr/local/Android_Images/system.raw.expanded.img 2>/dev/null
# Set SELinux to permissive.
setenforce 0
# Check that the stock Android container exists and is not already a symlink.
# If this is the case, mount it in order to copy files.
if [ ! -L /opt/google/containers/android/system.raw.img ]; then
if [ -e /opt/google/containers/android/system.raw.img ]; then
umount -l /usr/local/Android_Images/Original 2>/dev/null
mount -o loop,rw,sync /opt/google/containers/android/system.raw.img /usr/local/Android_Images/Original 2>/dev/null
else
# If the stock container's missing, check if there is a backup.
if [ -e /opt/google/containers/android/system.raw.img.bk ]; then
umount -l /usr/local/Android_Images/Original 2>/dev/null
mount -o loop,rw,sync /opt/google/containers/android/system.raw.img.bk /usr/local/Android_Images/Original 2>/dev/null
else
# If there's no backup in the expected location, check in ~/Downloads, too.
# NOTE: We can also use a container from a different device/other OS versions by putting it in ~/Downloads.
# To use a different container, we just need to rename any existing containers in /opt/google/containers/android/
# e.g. rename /opt/google/containers/android/system.raw.img.bk to /opt/google/containers/android/system.raw.img.bk.bk
# Containers from different devices/OS versions are unlikely to boot, however.
if [ -e /home/chronos/user/Downloads/system.raw.img ]; then
echo "Mounting /home/chronos/user/Downloads/system.raw.img and copying files"
umount -l /usr/local/Android_Images/Original 2>/dev/null
mount -o loop,rw,sync /home/chronos/user/Downloads/system.raw.img /usr/local/Android_Images/Original 2>/dev/null
else
echo
echo "Error!"
echo "System.raw.img not found"
echo
exit 1
fi
fi
fi
fi
ANDROID_ROOTFS=/usr/local/Android_Images/Original
# Mount the new .img.
mount -o loop,rw,sync /usr/local/Android_Images/system.raw.expanded.img /usr/local/Android_Images/Mounted
# Copy the files.
cp -a -r $ANDROID_ROOTFS/. /usr/local/Android_Images/Mounted
# Rename the original container to .bk.
if [ -e /opt/google/containers/android/system.raw.img ]; then
if [ ! -L /opt/google/containers/android/system.raw.img ]; then
echo "Moving original Android rootfs image to /opt/google/containers/android/system.raw.img.bk"
mv /opt/google/containers/android/system.raw.img /opt/google/containers/android/system.raw.img.bk
# Make the symlink from the original pathname to our writeable rootfs image.
echo "Replacing original Android rootfs image path with symlink to /usr/local/Android_Images/system.raw.expanded.img"
ln -s /usr/local/Android_Images/system.raw.expanded.img /opt/google/containers/android/system.raw.img
fi
else
if [ -e /usr/local/Android_Images/system.raw.expanded.img ]; then
echo "Creating symlink to /usr/local/Android_Images/system.raw.expanded.img at original Android rootfs image file path"
ln -s /usr/local/Android_Images/system.raw.expanded.img /opt/google/containers/android/system.raw.img
fi
fi
# Change the envs for writeable mount and debuggable in CrOS's /etc/init.
sed -i 's/export WRITABLE_MOUNT=0/export WRITABLE_MOUNT=1/g' /etc/init/arc-setup-env 2>/dev/null
sed -i 's/export ANDROID_DEBUGGABLE=0/export ANDROID_DEBUGGABLE=1/g' /etc/init/arc-setup-env 2>/dev/null
The rooting script is basically just the above, with the addition of a couple of other bits, including the relevant commands from the update-binary script in the SuperSU zip, slightly rearranged from Edify to regular shell script for the CrOS shell. That part of the script can be seen here.
So you could maybe do a similar script, with the files you want to flash. Also, once you have a R/W Android rootfs, it may be possible to update files from directly within Android, although, as mentioned in the last few posts in this thread, on some recent CrOS builds, some people have been running into an issue with the rootfs still getting mounted RO within Android, even with a writable container. This does not occur on all devices though, and should be just a temporary issue.
It would probably also be possible to set up a sort of overlay configuration, somewhat similar to Magisk in effect, but due to the somewhat convoluted mount configuration of the container based system, and the almost constant changes/updates (to the container, its config, and so on) that have been occurring with each update to Chrome OS, this would likely require quite a bit of work to implement and maintain.
Corrective measures to run the script...
Spoke too quickly - all installed but no root detected in SuperSU...
Yes, thanks, it seems to work.
I wonder why the script cannot handle downloading SuperSU & busybox on its own, some corrections are needed.
justqt said:
Worked for me on Samsung Chromebook 3.
Manually downloaded and extracted SuperSU.zip to downloads.
Manually downloaded busybox using curl in shell. Moved it manually to /usr/local/bin/ believe thats correct.
Then re-ran script and it worked.
Click to expand...
Click to collapse
Is it possible that I don't have write access to /system of the Android container or am I doing something wrong?
Davestar2000 said:
Is it possible that I don't have write access to /system of the Android container or am I doing something wrong?
Click to expand...
Click to collapse
Yes, depending on the Chrome OS version you're on, it's possible that the container's still being mounted read-only. They keep changing around some bits and pieces related to the container mount config with (almost) every new version release of the OS. There was a change that they made to config.json (which could be worked around by editing the file) a while back which broke the RW mount, but this was reverted quite quickly. Some other related changes have been made recently though, causing the issue to crop up again.
I've been reluctant to add something in to the script to deal with this read-only mount issue as yet, since the need for it has been CrOS version-dependent. The following fix should work on v69 and 70 (enter it in a Chrome OS root shell):
Code:
sed -i 's|mount rootfs rootfs / remount bind ro|mount rootfs rootfs / remount bind rw|g' /opt/google/containers/android/rootfs/root/init.rc
After a reboot (or just rebooting Android), the container should mount as R/W as expected. Let me know if this doesn't work.
Nolirum said:
Yes, certainly you can root Android on Chrome OS. The rootfs of the Android container is read-only by default, so the method I've been using involves making a writeable copy of the Android rootfs .img in /usr/local, adding SuperSU (adding its binaries to /system/xbin, the SuperSU apk to /system/priv-app, and modifying init.rc to autoload daemonsu), then replacing the original Android rootfs .img file path with a symlink to the rooted one. In addition, a couple of flags (mount-as-read-only and font sharing) need to be changed in one or two of the /etc/init/arc* files (CrOS version dependent), and also the SElinux policy file needs to be patched.
I have written a script to automate the above procedure, if you would like to try it out you can do so by entering the following into the Chrome OS shell (then rebooting).
Code:
curl -Ls https://raw.githubusercontent.com/nolirium/aroc/onescript/RootandSEpatch.sh | sudo sh
You need to be in Dev mode to get into the shell (Ctrl+Alt+T; type 'shell'), and rootfs verification needs to be switched off to modify system files (the script will give you the command to do this, if you haven't already done it).
It would be prudent to make sure any important files are backed up prior to making any changes to the rootfs.
Edit: If any errors occur, or problems are are experienced after using the script, such as Android (apps) failing to load, it's usually not necessary to powerwash. The script makes a backup of the original Android system.raw.img, which can be restored with the following command:
Code:
sudo mv /opt/google/containers/android/system.raw.img.bk /opt/google/containers/android/system.raw.img
Click to expand...
Click to collapse
If it says no android system detected, I downloaded it in 2 parts from here: ( github(dot)com/nolirium/aroc ), followed the instructions, and then it worked for me.
Nolirum said:
Yes, depending on the Chrome OS version you're on, it's possible that the container's still being mounted read-only. They keep changing around some bits and pieces related to the container mount config with (almost) every new version release of the OS. There was a change that they made to config.json (which could be worked around by editing the file) a while back which broke the RW mount, but this was reverted quite quickly. Some other related changes have been made recently though, causing the issue to crop up again.
I've been reluctant to add something in to the script to deal with this read-only mount issue as yet, since the need for it has been CrOS version-dependent. The following fix should work on v69 and 70 (enter it in a Chrome OS root shell):
Code:
sed -i 's|mount rootfs rootfs / remount bind ro|mount rootfs rootfs / remount bind rw|g' /opt/google/containers/android/rootfs/root/init.rc
After a reboot (or just rebooting Android), the container should mount as R/W as expected. Let me know if this doesn't work.
Click to expand...
Click to collapse
thanks for all the help. I have chromebook plus v1,I am on chrome osversion 74. I tried to follow the instruction
but my android apps did not start after restarting. I tried doing it manually but i got stuck at remounting file system as read only. Please help if possible. Thanks again.
Hi,
I'm having problems with this. I have an HP Chromebook with an Intel cpu, Chrome OS Version 75.0.3770.144 (Official Build) (64-bit). When I run the scripts this is the output:
Setting 'ANDROID_DEBUGGABLE: true' and 'WRITABLE_MOUNT: true' in /usr/share/arc-setup/config.json
The file at /opt/google/containers/android/system.raw.img is already a symlink!
Removing symlink
Using /opt/google/containers/android/system.raw.img.bk
Creating new Android system image at /usr/local/Android_Images/system.raw.expanded.img
1814633472 bytes (1.8 GB, 1.7 GiB) copied, 13 s, 140 MB/s
1800000+0 records in
1800000+0 records out
1843200000 bytes (1.8 GB, 1.7 GiB) copied, 25.2601 s, 73.0 MB/s
Formatting system.raw.expanded.img as ext4 filesystem
mke2fs 1.44.1 (24-Mar-2018)
Discarding device blocks: done
Creating filesystem with 450000 4k blocks and 112672 inodes
Filesystem UUID: fe69179d-f136-475f-84de-007de70ff729
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
Converting system.raw.expanded.img to sparse image
Mounting system.raw.expanded.img
SELinux successfully set to 'Permissive' temporarily
Copying Android system files
Formatting system.raw.expanded.img as ext4 filesystem
mke2fs 1.44.1 (24-Mar-2018)
Discarding device blocks: done
Creating filesystem with 450000 4k blocks and 112672 inodes
Filesystem UUID: fe69179d-f136-475f-84de-007de70ff729
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
Converting system.raw.expanded.img to sparse image
Mounting system.raw.expanded.img
SELinux successfully set to 'Permissive' temporarily
Copying Android system files
Creating symlink to /usr/local/Android_Images/system.raw.expanded.img
SuperSU files not found in ~/Downloads! Attempting to download BusyBox and SuperSU now...
Downloading SuperSU-v2.82-SR3
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5810 100 5810 0 0 5624 0 0:00:01 0:00:01 --:--:-- 9078
Unexpected file size. Trying again...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
50 6756k 50 3407k 0 0 305k 0 0:00:22 0:00:11 0:00:11 311k
Unzipping SuperSU zip, and copying required directories to ~/Downloads.
/usr/local/bin/busybox: 1: /usr/local/bin/busybox: Syntax error: word unexpected (expecting ")")
cp: cannot stat 'common': No such file or directory
cp: cannot stat 'armv7': No such file or directory
Downloading SuperSU-v2.82-SR3
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 6756k 100 6756k 0 0 328k 0 0:00:20 0:00:20 --:--:-- 351k
chgrp: cannot access '/usr/local/Android_Images/Mounted/system/lib/libsupol.so': No such file or directory
chcon: cannot access '/usr/local/Android_Images/Mounted/system/lib/libsupol.so': No such file or directory
Copying sh from system/bin/sh to system/xbin/sugote-mksh and setting permissions and contexts
Adding extra files system/etc/.installed_su_daemon and system/etc/install-recovery.sh
cp: cannot stat '/home/chronos/user/Downloads/common/install-recovery.sh': No such file or directory
chmod: cannot access '/usr/local/Android_Images/Mounted/system/etc/install-recovery.sh': No such file or directory
chown: cannot access '/usr/local/Android_Images/Mounted/system/etc/install-recovery.sh': No such file or directory
chgrp: cannot access '/usr/local/Android_Images/Mounted/system/etc/install-recovery.sh': No such file or directory
chcon: cannot access '/usr/local/Android_Images/Mounted/system/etc/install-recovery.sh': No such file or directory
Symlinking system/bin/install-recovery.sh to system/etc/install-recovery.sh
Adding system/bin/daemonsu-service.sh
cp: cannot stat '/home/chronos/user/Downloads/common/install-recovery.sh': No such file or directory
chmod: cannot access '/usr/local/Android_Images/Mounted/system/bin/daemonsu-service.sh': No such file or directory
chown: cannot access '/usr/local/Android_Images/Mounted/system/bin/daemonsu-service.sh': No such file or directory
chgrp: cannot access '/usr/local/Android_Images/Mounted/system/bin/daemonsu-service.sh': No such file or directory
chcon: cannot access '/usr/local/Android_Images/Mounted/system/bin/daemonsu-service.sh': No such file or directory
Creating file init.super.rc in Android rootfs
Adding daemonsu service to init.super.rc
Adding 'import /init.super.rc' to existing init.rc
Substituting '|mount rootfs rootfs / remount bind rw' for '|mount rootfs rootfs / remount bind ro' in existing init.rc
A backup of init.rc will be stored as init.rc.old
sed: can't read /../init.rc: No such file or directory
Removing temporary files
Done!
Please check the output of this script for any errors.
Please reboot now, then run script 02SEPatch.sh.
[email protected] / $
Any help would be very much appreciated. I've done a good bit of searching and so far have been unable to figure what the problem is. Thanks alot, guys.
JR