I entered the following in the file /etc/rc5.d/S99z
then chmod to 755.

#!/bin/sh

if test -f /mnt/card/startup.sh
then
/bin/sh /mnt/card/startup.sh
fi

: exit 0

Then I held my breath and did the update to 2.7.1.

No problems afterwards - iliad executed startup.sh on my card fine and I'm back in again. This is also a very safe way of executing stuff on normal boot after /home/root/start.sh has completed.

Well done! This should be a sticky to everyone who wants to keep the door open to his iLiad. :shy:

That will only survive a patch update. On their full updates they dd a new file system into the disk on chip.

I hope that wasn't the real name you used for your rc script, I'm sure they'll have a patch for that in 2.7.2. :D

Still though, a worthy hack.

BTW I'm not some cowboy with my start.sh hack for the clock. Once their panel starts you have to kill out and restart the icon container, which is a central nexus in how the iLiad routes things like the keyboard events. I've done it by hand but its cleaner to just mod the actual start.

What is scary is how iRex doesn't understand rc scripting. That start.sh script should be broken up into several rc scripts. :(

That will only survive a patch update. On their full updates they dd a new file system into the disk on chip.

Yes, this will be more tricky, but still possible to backdoor. I'll wait until 2.8 is out before posting suggestions.


I hope that wasn't the real name you used for your rc script, I'm sure they'll have a patch for that in 2.7.2. :D


It was a throwaway - but an interesting measure of their paranoia to see whether they do patch it or not.



BTW I'm not some cowboy with my start.sh hack for the clock. Once their panel starts you have to kill out and restart the icon container, which is a central nexus in how the iLiad routes things like the keyboard events. I've done it by hand but its cleaner to just mod the actual start.


No indeed, but (as I find daily), you can't underestimate the clumsiness of people entering your scripts into their machine. If a mistake is possible, then somebody will make it. And missing off the last & in startup.sh is very easy and deadly to do.

Perhaps we could post an exploit to update er_registry (harmless), then supply clickable sed or shell scripts to do the rest...


On a related topic, have you any idea where the kernel boot image lives? Its symlink in /boot doesn't exist and it's not on /dev/tffsa1 where I might have expected to find it. I can only assume that there's another paged boot flash that we don't have access to... If we could find that, then we'd be on the first steps to brick-protection..

Their code for flashing the kernel and user filesystem is all out in the public there in /old-root/linuxrc.

I know how to flash the iLiad what I'm working on is the buttons.

I'd like to write something that sniffs the connection button on startup, if it's pressed then mount the MMC/CF and flash off it.

Of course if you brick your kernel... we'd need access to the boot loader to make a truly brick free iLiad. But we nearly have all the tools needed to brick protect from user file system problems such as a bad start.sh.

Of course we could also post a start.sh upgrade that uses rc.d properly.

Their code for flashing the kernel and user filesystem is all out in the public there in /old-root/linuxrc.


Indeed it is, but can you find where the kernel ends up once it has been flashed? It's not on any of the accessible partitions.

Poking around inside /bin/firmupdate makes it look like it searches through /dev/tffsa for a hidden partition, then puts the kernel there. If we can find that, then we may also find any pre-kernel loading code that also runs.

Well, then I hope you get lucky and find that as wel...:-)

I'm moving this one to the dev. section as well...I hope you don't mind.

tffsa1 looks like the winner...

root@ereader:/proc# cat partitions
major minor #blocks name

100 0 239616 tffsa
100 1 3094 tffsa1
100 2 74256 tffsa2
100 3 1 tffsa3
100 5 29926 tffsa5
100 6 131326 tffsa6
100 7 910 tffsa7
root@ereader:/proc# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/tffsa2 3040 2368 672 78% /old-root
/dev/tffsa2 73045 60249 12796 82% /
/dev/tffsa5 28973 885 26592 3% /mnt/protected
/dev/tffsa6 131180 122848 8332 94% /mnt/free
/dev/tffsa7 888 179 664 21% /mnt/settings

I yanked it with dd and I can see why firmupdate says it has to search for the kernel. Lots of garbage at the front of that partition.

tffsa1 looks like the winner...

root@ereader:/proc# cat partitions
major minor #blocks name

100 0 239616 tffsa
100 1 3094 tffsa1
100 2 74256 tffsa2
100 3 1 tffsa3
100 5 29926 tffsa5
100 6 131326 tffsa6
100 7 910 tffsa7
root@ereader:/proc# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/tffsa2 3040 2368 672 78% /old-root
/dev/tffsa2 73045 60249 12796 82% /
/dev/tffsa5 28973 885 26592 3% /mnt/protected
/dev/tffsa6 131180 122848 8332 94% /mnt/free
/dev/tffsa7 888 179 664 21% /mnt/settings

I yanked it with dd and I can see why firmupdate says it has to search for the kernel. Lots of garbage at the front of that partition.

...and why are there two different partitions called tffsa2? /old-root should be tffsa1, hinting that there was another partition before it that was mounted to load the kernel.

...and why are there two different partitions called tffsa2?

(DELETED -- misreading)

You're right:
root@ereader:/mnt/cf# file zImage
zImage: Linux rev 0.0 ext2 filesystem data (mounted or unclean)

But then that would tend to mean tffsa3 is the boot block and ttfsa4 is the "hidden" kernel.

Strange.

You really shouldn't try to flash any kernel to a TFFS# partition, that will certainly brick your iLiad. You'd better have a look at the contents of the tffsa1 partition...

The kernel is not located on any of these TFFS partitions.

Also: if you flash your own kernel, you most certainly won't have a working iLiad anymore: no wired ethernet, no filesystem -> brick.