Unbrickable iLiad

[hudson]

One reason the iLiad is easy to brick is that the setup requires the GUI to be functioning before any user interaction can take place. For most of my projects with embedded systems I always enable the ethernet and sshd long before we try to start up the gui so that we have a way in if things go wrong.

To that end, attached is a tar file that you can unpack in the root directory that will enable the ethernet with a static IP (10.0.0.200) and start sshd so that you can login as root over the network. The root password is set to 'rootme', in keeping with the Familiar distribution, you'll need to change it once you log in.

The network comes up about 1/2 the way into the boot process, then sshd is enabled about 3/4 of the way, as measured by the little bar graph on startup. There does not seem to be any increase in the time to boot. I do not know how much power the ethernet draws, but I know it is much less than the wireless. There may still be some reduction in battery life, but you could easily add an shell hack entry to turn it off. A simple 'ifdown eth0' will also unload the smc91x module.

One important note -- the iLiad does not have bzip2, so you will have to uncompress it on your Linux box before installation. One way to do that is to combine the decompress with the unpacking:

bzcat unbrickable.tar.bz2 | ssh root@ereader tar -C / -xvf -

The file manifest in the tar file is:

-rw-r--r-- root/root       319 2007-04-01 11:28:31 ./etc/network/interfaces
drwxr-xr-x root/root         0 2007-04-01 11:36:55 ./etc/dropbear/
-rwxr-xr-x root/root       427 2007-04-01 11:36:55 ./etc/dropbear/dropbear_dsa_host_key
-rwxr-xr-x root/root       460 2007-04-01 11:36:55 ./etc/dropbear/dropbear_dss_host_key
-rwxr-xr-x root/root       424 2007-04-01 11:39:13 ./etc/init.d/dropbear
lrwxrwxrwx root/root         0 2007-04-01 11:40:54 ./etc/rc5.d/S98dropbear -> ../init.d/dropbear
-rwxr-xr-x root/root    214442 2007-04-01 11:37:28 ./usr/bin/dropbear
-rw-r--r-- root/root       732 2007-04-01 11:43:49 ./etc/passwd

Adam B. Edit:
Post Updated with most recent version of Unbrickable package (unbrickable.tar.bz2) with dropbear 0.49 with scp. See this post

Also Updated with ipkg installer package w/ dhcp. See this post

[Antartica]

Originally Posted by hudson

For most of my projects with embedded systems I always enable the ethernet and sshd long before we try to start up the gui so that we have a way in if things go wrong.

To that end, attached is a tar file that you can unpack in the root directory that will enable the ethernet with a static IP (10.0.0.200) and start sshd

Ok, so now nothing stop us from substituting the GUI :-b

[BACbKA]

this is a nice package, but I fail to see it as "unbrickable". Recently a script was shown doing a cd to a directory that didn't exist ( that failed ), followed by an rm -rf * . (which had / as the cwd). For that kind of mistakes, as well as some fs / master config files being overwritten, the irex-promised unbricking is needed.

[hudson]

Originally Posted by BACbKA

this is a nice package, but I fail to see it as "unbrickable". Recently a script was shown doing a cd to a directory that didn't exist ( that failed ), followed by an rm -rf * . (which had / as the cwd). For that kind of mistakes, as well as some fs / master config files being overwritten, the irex-promised unbricking is needed.

You're right that it is still possible to hose the system to the point that it requires a return trip back to Eindhoven, but the chance of a bad /mnt/settings preventing the boot from completing is far lower. Running 'rm -rf /' on any Linux system is a bad idea and will set you back on any machine, especially if it takes out your /boot and /bin directories. Even Apple has messed up shell expansion in install scripts before -- they did a "rm -rf /Volumes/$DRIVE, where $DRIVE was a drive name selected from the gui. If the drive had a leading space in the name it would execute 'rm -rf /Volumes/', effectively wiping ALL the drives currently mounted.

But, from my perspective, baring any serious screwups this patch makes my unit far less likely to need to visit its home. I can rebuild my kdrive-Xfbdev to include the evdev patches without worry that I won't be able to get to my device if the X server doesn't start.

As for reflashing at home, the xscale PXA255 CPU has three serial ports, one of which almost always has a boot loader console in most implementations. I see in the dmesg output that the three of them are detected and initialized, but haven't pulled my device apart to find the ports are level shifted to RS232 or are still 3V TTL.

[Alexander Turcic]

How about setting important files immutable using chattr to prevent even "rm -rf" accidents?

[Adam B.]

Great work. While this wouldn't help me in my situation, it would be great for most of the possible screwups that could happen.

[joblack]

you can´t

[hudson]

I've just tested the tar file after the upgrade to 2.9.5 and it works fine. Copy it to /media/iLiad after mounting it, then using mrxvt run:

tar -C / -jxvf /mnt/free/unbrickable.tar.bz2

Reboot and enjoy the ability to ssh into 10.0.0.200 as root with the password rootme.

[Adam B.]

As an added note, after installing this, I installed the dropbear ipkg that Mathijis posted a while back. This allows me to scp into the iLiad as well.

I also changed my /etc/network/interfaces for DHCP.

auto eth0
iface eth0 inet dhcp
pre-up modprobe smc91x
post-down rmmod smc91x

My DHCP server gives my iLiad the same IP every time, so I don't have to worry about connecting to a different address. Makes my life easy when working on and testing iLiad apps.

Thanks for the package hudson.

[hudson]

Originally Posted by Adam B.

As an added note, after installing this, I installed the dropbear ipkg that Mathijis posted a while back. This allows me to scp into the iLiad as well.

I had meant to post this update that also includes the scp binary, as well as an upgraded dropbear 0.49 instead of the 0.47 version. scp is really the way to move files to the unit since, unlike USB, it doesn't lock you out of the GUI.

[jharker]

I got my shell access the other day and this was one of the first things I installed. Excellent work, and elegant. Thank you for providing it! It's allowed me to test xserver stuff I would never have dared to try otherwise.

I'm looking forward to using scp, since currently I move files by shuttling the CF card back and forth from desktop to iLiad. I feel so old-fashioned!

[scotty1024]

Originally Posted by Alexander Turcic

How about setting important files immutable using chattr to prevent even "rm -rf" accidents?

Alex, one of the things that makes the SHELL hack so dangerous is that it executes as the super user root. Since iRex didn't implement ACL's there is nothing you can do to protect critical system files from a root script.

Note: one of the nice/bad things about the Sony Reader is that the critical system files are in a read only filesystem. This kind of accident can't occur on the Sony, but you also have a bit more work to do 3rd party mods on the Sony. :-)

I also wonder if the iRex re-flash can recover from this kind of accident.

[scotty1024]

Originally Posted by hudson

To that end, attached is a tar file that you can unpack in the root directory that will enable the ethernet with a static IP (10.0.0.200) and start sshd so that you can login as root over the network.

A nice packaging of the work Design256 described here last year after the Arrivero hack broke the iLiad wide open.

Yes, it does increase power draw if left up. I personally have a .sh script to do the ifdown you describe (mine also kills the dropbear as well.)

One caution for anyone planning to use this package. Design256's method didn't leave your iLiad vulnerable to attack, this package does.

If you bring up wireless your dropbear is reachable from the internet. Someone scanning the public access points (and boy do people spend alot of time doing that, its amazing!) could enter root/rootme and you're pwned.

To protect yourself you should leave out the /etc/passwd from the TAR and just use the passwd command to set your own private root password. To enhance your security one more notch generate your own keys for these files:

-rwxr-xr-x root/root       427 2007-04-01 08:36:55 ./etc/dropbear/dropbear_dsa_host_key
-rwxr-xr-x root/root       460 2007-04-01 08:36:55 ./etc/dropbear/dropbear_dss_host_key

And then setup this file with a pass phrase on the key itself:

-rwx------    1 root     root          899 Apr 27 09:09 /home/root/.ssh/authorized_keys

That will keep silly accidents from happening. Here in Seattle we have free Wifi on some of the buses. It would really suck to forget about the open dropbear and go wireless for a little dillo/CNN action after hearing some incredible rumor from another passenger.

Other unbrickable iLiad possibilities proposed in the past.

The iLiad has a getty running on the PXA-255's built in UART. This may in fact be how iRex fixes some of the bricked iLiad's returned to them. I've asked them several times to make a cable available for developers. Heck I' offered to setup an account with one of the short run production outfits to make them easily available in the US if they'd send me a PDF of the cable. Maybe your voice will be the straw that breaks the camel's back.

The iLiad also implements the JTAG built into the PXA-255. I described to iRex how an inexpensive USB cable could be produced that would enable un-bricking even a totally zapped FLASH (no root fs, no kernel). I was willing to design the cable and have it setup for short run production at one of the places mentioned above, all that was needed was cooperation from iRex. Not only did I get a no, I got a HELL NO.

[bruce]

Originally Posted by scotty1024

The iLiad also implements the JTAG built into the PXA-255. I described to iRex how an inexpensive USB cable could be produced that would enable un-bricking even a totally zapped FLASH (no root fs, no kernel). I was willing to design the cable and have it setup for short run production at one of the places mentioned above, all that was needed was cooperation from iRex. Not only did I get a no, I got a HELL NO.

This sounds quite interesting. Would you mind explaining here how this cable would allow you to do the unbricking/reflashing?

Regarding access to the pxa-255 serial console...so do you think this is just an issue of getting a map of the pinouts used by that funky (what is it, 20 pin?) connector that attaches the travel hub or would some other hardware hack be needed to get access to the UART pins?

[Adam B.]

I've gone ahead and set it up into an installable ipkg file. Simply unzip, copy and run.

I've set it up with dhcp (more useful for the average user), so you'll need to download mrxvt and run `ifconfig` to find your IP address. You can change this in /etc/network/interfaces.