For the binary-obsessed, unquenchable Linux junky, there may be nothing more tantalizing than having access to the files of a Linux system. So are you interested in tinkering with yesterday's firmware upgrade (http://www.mobileread.com/forums/showthread.php?t=7304) for the iLiad? Then jump over here (http://iliad.mobileread.com/os/) where you can find the userland files and the kernel image - both in virgin form before the upgrade was actually started.

Wow. I mean wow! Just look at /usr/bin/do_updates!

<snip>

#
# SSH server and root password checks
#

updates_done=0
new_password='b64NybVuHUa/U'

echo -n 'Checking for patches:'

if [ -x /usr/sbin/dropbearmulti ]
then
echo -n ' rm_sshd'
/usr/bin/ipkg remove -force-depends dropbear
updates_done=1
fi

if [ "`grep '^root:' /etc/passwd | cut -d: -f2`" != "${new_password}" ]
then
echo -n ' passwd'
sed -i "s,^\\([^:]*\\):[^:]*:0:,\\1:${new_password}:0:," /etc/passwd
updates_done=1
fi

if [ "${updates_done}" -eq 0 ]
then
echo -n " none"
fi
echo .

Someone really doesn't like us to have SSH access, right? :scholar:

So basically we need to change the script to add a password we know and maybe remove the dropbear delete code, and then - and I guess that's the harder part - find a way to get it back to the iLiad?

hehe glad someone else was able to get it, my attempt failed yesterday.

For the binary-obsessed, unquenchable Linux junky, there may be nothing more tantalizing than having access to the files of a Linux system. So are you interested in tinkering with yesterday's firmware upgrade (http://www.mobileread.com/forums/showthread.php?t=7304) for the iLiad? Then jump over here (http://iliad.mobileread.com/os/) where you can find the userland files and the kernel image - both in virgin form before the upgrade was actually started.
How did you get the files?!?

How did you get the files?!?

From Tad through capturing the packets (http://www.mobileread.com/forums/showthread.php?t=7091).

hehe glad someone else was able to get it, my attempt failed yesterday.
I am not alone anymore :-)

Serious congratulations to the author of the Man-in-the-Middle attack. While it is theoretically standard, it is not easy when you only have one try.

Wow. I mean wow! Just look at /usr/bin/do_updates!
Someone really doesn't like us to have SSH access, right? :scholar:

It could be claimed that it is a generic security "improvement", but it really address a honestly installed dropbear, not a hidden one from any cracking tool. Nice mine trap in any case, because do_updates was a inert script in previous version (old-root linuxrc doing the real update work) so nothing was expected to jump from it.

At least it is not a personal mine: it does not frozen the iLiad to extract 75 euros from you. On the other hand, it should not be sensible to do it, as an iLiad owner have the right to look into the internals of the firmware (except for propietary code as DisplayMgr and so).

HEY, IT IS NOT AGAINST US. Obviously (but it took me one hore walking/thinking) any crack would not bother on installing a .ipkg, it is too critical. And not exacly this .ipkd in any case.

So what is it? It is a tool to remove Irex's own backdoor. It means that irex service will be able to reinstall the package, perhaps remotely, perhaps from a key combination if it is already inside. And it is a security requirement to remove the package on restart even if the engineer forgets to do it.

(The other possibility is that it is a script done as result of lack of coordination between the hierarchy of analysts and programmers at iRex, and while it is typical of a big company, it should be surprising in a small intimate one as iRex is. On the other hand, if it is happening, it could signal corporate paranoia... for instance, any engineer at iRex acting on this forum or trying to contact any member this forum would risk punitive measures and so on. I have seen it to happen in corporate entities and I hope it will not move in this direction)

anyone looked into ipkg.conf?

dest root /
lists_dir ext /var/lib/ipkg

src oe http://10.56.210.143/ipk
The last line is interesting I think. Could they run ipkg over the ssl-tunnel and remotely install packages?

Anyone have a capture of the HTTP/HTTPS calls and/or the update/boot details?

anyone looked into ipkg.conf?

dest root /
lists_dir ext /var/lib/ipkg

src oe http://10.56.210.143/ipk
The last line is interesting I think. Could they run ipkg over the ssl-tunnel and remotely install packages?

"the ssl-tunnel"?? Do you assume there is one?

I think it's just a ipkg feed server in their intranet. Note this is a private LAN address.

"the ssl-tunnel"?? Do you assume there is one?
i think i said it wrong.
i was thinking, since it is a private IP, could it be that they somehow involve or plan to use the ipkg package manager to do software updates over the IDS connection.

Maybe this is more clear.

i think i said it wrong.

No, it was clear enough. But it would imply to install the tools for the tunnel, a excesive effort. But not impossible.

No, it was clear enough. But it would imply to install the tools for the tunnel, a excesive effort. But not impossible.
I was thinking of the IDS connection. I understood it that way, that the whole IDS connection/update process is SSL-encrypted.

Does this help any?

/usr/share/ecdc/irex.crt

Does this help any?

/usr/share/ecdc/irex.crt
That's used for the firmware upgrade when connecting to the iDS server via SSL.