Hacking the Chromebook for Fun and Profit
You may recall me noting that the Chromebook has been Amazon’s top selling laptop for the whole of Q4 2012. There are now a lot of Chromebooks out there — so what can we do with them? Let’s see…
Enter Developer Mode
Conveniently, Chromebooks have a developer mode, which lets you bypass all the normal checks and balances that Google use to ensure that rogue software does not run on ChromeOS devices. After you have switched into developer mode your Chromebook will run whatever you want it to, and you can open up a Linux shell in a browser tab (Chromebooks are running a cut down Linux distribution after all) simply by hitting Ctrl-Alt-T.
This is important to me with my IT manager’s hat on, because there are still a few rough edges to the ChromeOS product that make it awkward in my environment. Two particular bugbears for me are that we use the Cisco AnyConnect VPN system and VMware View for our Virtual Desktop Environment for legacy Windows apps. Both of these are supported by open source clients, but these haven’t been integrated with ChromiumOS yet.
There are also the fun and profit elements, of course… If you have hacker tendencies, then hopefully this post will give you some interesting insights along the former theme. See the end of this post for more on the latter.
Now, how do we get the OpenConnect package onto our Chromebook, to provide a free workalike for Cisco’s AnyConnect? (Cisco also have a packaged Linux client, but if we can make the open source client work then it is more likely to be embedded in ChromiumOS and thence ChromeOS)
Crouton to the Rescue
Google’s Dave Schneider has helpfully produced Crouton, the “Chromium OS Ubuntu Chroot Environment” (there are other examples out there using Tinycore and Arch Linux), which lets us run a full copy of Ubuntu Linux via chroot. It’s absolutely trivial to install, although you should note that the Chromebook’s Aura window manager doesn’t know what to do with windows spawned by random applications — hence Dave recommends that you start a new X session with a conventional window manager/desktop like Xfce.
So now we can enter our chroot environment (which is actually encrypted by default, using a key requested from the user as part of the Crouton setup process — so perhaps not as insecure as I may have implied), and start installing and even building packages just as we would on a normal Ubuntu Linux distribution. However, many Chromebooks come with quite small SSDs, so watch out when pulling in additional software!
Here we are adding some useful additional packages to our test Chromebook using apt-get, just as we might on any other Ubuntu system…
OpenConnect
Now, we can install OpenConnect in a similar fashion — in fact, we’ll need to apt-get install openconnect uml-utilities in order to also get a tunnel device management utility we need called tunctl. However, note that there is a little fancy footwork involved in actually using OpenConnect, because our chroot environment is essentially an entire Linux filesystem — with its own /etc, and so on and so forth. We may be happy running OpenConnect inside the chroot environment, but for eventual integration with the core product it will need to be able to run in the “host” ChromiumOS too.
Now we can create tunnel devices to use for the VPN tunnel back to base, like so:
root@localhost:~# tunctl -t tun0 -f /dev/net/tun
Set ‘tun0’ persistent and owned by uid 0
In my testing I sometimes found that I had to create not just tun0, but also tun1, and then OpenConnect would magically create and use tun2 for me, like so:
root@localhost:~# ifconfig tun2
tun2 Link encap:UNSPEC HWaddr 00–00–00–00–00–00–00–00–00–00–00–00–00–00–00–00 inet addr:131.231.153.69 P-t-P:131.231.153.69 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1406 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
This merits some further investigation…
However, the upshot is that we can now happily make a VPN connection back to our home institution using OpenConnect:
root@localhost:~# openconnect — disable-ipv6 -u XXXX — script /etc/vpnc/vpnc-script vpn.lboro.ac.ukAttempting to connect to 193.62.24.109:443
SSL negotiation with vpn.lboro.ac.uk
Connected to HTTPS on vpn.lboro.ac.uk
GET https://vpn.lboro.ac.uk/
Got HTTP response: HTTP/1.0
302 Object Moved
SSL negotiation with vpn.lboro.ac.uk
Connected to HTTPS on vpn.lboro.ac.uk
GET https://vpn.lboro.ac.uk/+webvpn+/index.html
Please enter your username and password.
Password:
POST https://vpn.lboro.ac.uk/+webvpn+/index.html
Got CONNECT response: HTTP/1.1 200 OK
CSTP connected. DPD 30, Keepalive 20
/etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf
Connected tun3 as 131.231.153.66, using SSL
Established DTLS connection
The vpnc-script file is a separate download, and consists of some code which tries to manage your /etc/resolv.conf (DNS resolver details) and default route automatically. This is a bit of a mixed bag under Crouton because we have two copies of a number of interesting files such as resolv.conf, and in practice you might need to zap your old default route like so:
root@localhost:~# route del -net default gw 192.168.1.1
…and manually update your /etc/resolv.conf. However, now you are VPNing:
root@localhost:~# traceroute -n 158.125.1.100
traceroute to 158.125.1.100 (158.125.1.100), 30 hops max, 60 byte packets
1 131.231.13.18 20.726 ms 20.121 ms 26.874 ms
2 10.100.255.37 27.818 ms * *
3 158.125.1.100 27.023 ms 27.102 ms 27.152 ms
(for a non-VPN connection this traceroute would normally include multiple ISP and JANET routers)
VMware View
VMware have helpfully led the VMware View Open Client project, which has released a nice open source VMware View client package that we can use. Installing it is simply a matter of apt-get install vmware-view-open-client. However, if you try to use it from a Linux shell running inside Chrome (rather than a separate X session for Ubuntu) you will see a message in your log file to the effect that:
root@localhost:~# more /tmp/vmware-root/vmware-view-32091.log
Feb 28 00:31:32.989: vmware-view| Log for VMware View Open Client pid=32091 version=4.5.0 build-297975 build=build-297975 option=Release
Feb 28 00:31:32.989: vmware-view| Host codepage=UTF-8 encoding=UTF-8
Feb 28 00:31:32.990: vmware-view| Using locale directory /usr/share/locale
Feb 28 00:31:33.001: vmware-view| Command line: vmware-view
Feb 28 00:31:33.001: vmware-view| Using gtk+ version 2.24.10
Feb 28 00:31:33.008: vmware-view| Gtk: cannot open display:
This is because your chroot’d Ubuntu session doesn’t know about the X session that you are running. You can fix this by setting $DISPLAY in your environment:
root@localhost:~# export DISPLAY=:0
root@localhost:~# vmware-view
…but you will also need to open up a non-chroot Linux shell session and give yourself permission to connect to the X server, e.g. via xhost or .Xauthority:
localhost / # /usr/local/chroots/precise/usr/bin/xhost +localhost
Success! (as shown below…) However, your VMware View session will by default take over the entire display (remember my comment about Aura not managing windows from apps that it doesn’t know about), and is a little messy to shut down again afterwards. This is where a separate dedicated X session for Ubuntu would be a lot simpler.
Wrapping Up
So, with a little bit of hacking we have taken our £199 device (actually my experiments have been with the old Samsung Series 5 Chromebook that I was given by Google a while ago) and a) turned it into a general purpose Linux box, b) integrated our corporate VPN, and c) integrated our legacy Windows apps via VMware View. OK, so it’s a little rough around the edges, but these are solveable problems.
To make the additional OpenConnect and VMware View Open Client packages more properly part of ChromiumOS (so that we could avoid having to hack things around) there are probably quite a few dependencies around library versions that would need to be resolved. But what actually are they? Well…
If you don’t mind twisting your brain a little, you can experiment with merging the chroot environment and the normal ChromeOS Linux environment through tweaking the $LD_LIBRARY_PATH environment variable, which governs where Linux picks up its shared liibraries from. The key point here is that /usr/local/chroots/precise directory I referenced above. This is the root of the chroot filesystem.
We could create a file somewhere that contained the necessary shell commands to prep our environment to use the library files on the chroot side, as shown in the screenshot below…
The Profit Bit
Remember that £199 laptop. Perhaps you thought that it was in some way less of a computer by virtue of being “underpowered” and so on, and incompatible with your enterprise software and systems. In this post I have shown you how it could be quite a nifty thin client to your corporate virtual desktop service, or a full Linux box in its own right. And these things were already flying off the shelves because normal people (not geeks reading blog posts about Linux hacking ;-) were happy to spend £199 on a laptop that would “only browse the web”.
I hope we will see OpenConnect and VMware View Open Client properly integrated with ChromeOS, and that this blog post has provided a few pointers in the right direction. My ideal scenario would be to open remote VMware apps or a full desktop as a Chrome tab, like we can with the Linux shell sessions. Why? Imagine if we could make web links to all our key student software available as part of our Virtual Learning Environment — click and Matlab appears in a browser tab, for any of our students, anywhere in the world. That’s the money shot :-)
[This piece originally appeared on my blog in February 2013 — there’s been a lot of water under the bridge since then, including Xiwi, which gives you a nice way of running X Window applications in a browser tab]
