Yet another tech geek weblog with a focus on technical Linux and open source, particularly server-side, on Java EE, PostgreSQL, and more.

Thursday, January 27, 2011

Enabling telnet and ftp access to the Kobo Wifi

This article is part of an extended series on Kobo development and investigation

Apparently I have to make this more obvious:

Take a backup of your Kobo's SD card before doing anything. If something doesn't work, you can't fix your Kobo without this backup. I will not send you a backup.

Any device hacking is risky. If you can't afford to break your device, leave now.

The Kobo Wifi has this handy 802.11 radio that it really only uses for online shopping. Not only is it calling out to be used for RSS feeds and web browsing, but it is also a really handy tool for developing on the device without having to crack it and solder serial port headers onto the board.

We can gain telnet and ftp access to the device quite trivially; see the pre-made KoboRoot.tgz patch linked to below for the really easy way. (WARNING: The premade patch is for an older Kobo Wifi firmware. See the comments for instructions and newer version info).

If you want to roll your own patch or you're using a different firmware revision, there isn't much to do. The Kobo already has busybox's telnetd, ftpd and inetd on it. All that's necessary is to:

KoboRoot.tgz may then be used to update the device's operating system by putting it in the .kobo directory on the user-accessible flash.

Because it's not designed to be accessible from the outside world, the Kobo doesn't have any root password set. Telnet and FTP access as root will be offered with a blank password by default. You can change that once you telnet in if you like, by typing "passwd" at the root prompt. This won't affect the device's normal operations, only telnet/ftp access.

I created a canned KoboRoot.tgz (for firmware 1.7 ONLY) with these changes to save you the hassle of making them yourself. It was made from the initscripts in firmware release 1.7.4; if you use it with any other firmware and it fails to boot you'll have to do a factory reset. Because there are no binaries in the patch, only a modified /etc/init.d/rcS and a new /etc/inetd.conf, you can easily verify that the code isn't malicious. It has two optional features you can uncomment in /etc/init.d/rcS to (a) syslog to user flash for debugging, and (b) run a user-defined script from .kobo/rc.sh every boot. Both are commented out so they do nothing unless you edit the script to enable them.

Unlike modifying the boot splash screen, this is a pretty safe change as it's completely erased by a factory reset of the device.

If you add content via ftp, it is good to refresh the database to show it without having to to plug in and remove the USB, which triggers the necessary SQLite sync. The below (complete kludge of a) script mimics the USB trigger. It could be added to startup, in the way Craig outlines, so that a restart syncs, or run through telnet. Ultimately, it would be good to put it behind a key (although a script to enable WiFi with a button would be a higher priority IMV.)

If you add content via ftp, it is good to refresh the database to show it without having to to plug in and remove the USB, which triggers the necessary SQLite sync. The below (complete kludge of a) script mimics the USB trigger. It could be added to startup, in the way Craig outlines, so that a restart syncs, or run through telnet. Ultimately, it would be good to put it behind a key (although a script to enable WiFi with a button would be a higher priority IMV.)

badtoys: I'm never going to work on a mail client for the Kobo. I never even considered it as something that might be useful. The display is too slow to make it nice to use, and the input system is way too clumsy to be worth using for email. In any case, 3G smartphones do it better than the Kobo could and are very widespread.

BloGollum: Thanks for that. I've been meaning to fake plug/unplug events through the nickel socket. You're faking plug/unplug events by calling the udev hook scripts, which is probably a better way to do it. Thanks.

I'm not doing much more on the Kobo at this point, because the Nickel app's plugin interface is nearly useless and it'd take a bit of work writing a Qt widget/object tree dumper and signal introspector to even figure out how/if you can hook into the UI. Nickel wasn't designed to be extensible; the plugin interface is a toy and and afterthought. It doesn't help that the QWS driver for epson_broadsheet is statically linked into Nickel, so you can't really write stand-alone Qt programs for the Kobo unless you hijack Nickel's startup.

It also seems like Nickel brings down the wifi before it invokes plugins via the easter egg ui, so even if you claim the poker or blackjack plugin's MIME types for your own plugin and go to the hassle of invoking it via the easter egg ui, wifi drops as soon as you run it. Grr!

Most of the things I _really_ want to improve in the Kobo require that I have access to the source code for Nickel. It's not viable to add series support, "go to page", etc using dynamically loaded plugins and runtime introspection. I have a nice Android phone now so I have lost interest in implementing an RSS reader for the Kobo; I pretty much need Nickel code to get anywhere with a worthwhile amount of time investment now.

At this point I'm too busy with my paying work to waste any more time on it, given that the Kobo guys have gone from helpful to non-responsive and there's no sign they'll open up the qws driver let alone provide a way to make Nickel extensible.

i did not want a full email client just just a way to send the books over the network just a check and download of epubs. with calibre you can setup automatic downloads for rss news witch puts it in epub then you can have it emailed to an address. im not a big programer but i have been using linux since 95 so i will see what i can do

badtoyz: Good idea. That makes sense. You could add d-bus notifications to Fickel (the wifi monitor daemon) so you could automatically download feeds whenever wifi was turned on.

The trouble is actually downloading the mailbox, with proper support for POP3+TLS, IMAP+TLS, etc.

If the Kobo shipped a Java virtual machine I could put something like that together very quickly using the JavaMail APIs. Unfortunately, I'm not aware of any similar convenient, self-contained and reliable IMAP/POP3 libraries for C/C++. Sun/Oracle are being bastards about supporting Java 2 SE on ARM (they want to sell Java ME), otherwise I'd probably just do that.

You should now be able to ssh and scp to your kobo, using keys. The -s option to dropbear disables password access in any case. If you also want sftp access, you'll have to install sftp-server from openssh. From maemo again:

http://maemo.org/packages/view/openssh-server/

Extract as before, and move usr/lib/openssh/sftp-server into /usr/lib on your kobo (via scp or by adding it to the KoboRoot.tgz before transferring. Make sure and don't accidentally just transfer usr/lib/sftp-server, since it's just a soft link to openssh/sftp-server.

I followed this guide and got ssh on my kobo but it just tells me: Permission denied (publickey).Correct me if i wrong but from reading here http://a3nm.net/blog/fnacbook_kobo_hacking.html#fnacbook_kobo_hacking_dropbear it seems i needed to "set root's home to /root in /etc/passwd to get key authentication working." However now i have no telnet and thus no access at all.

tjm: good point re using inittab to launch inetd. Thanks. I'd tried that earlier, but was having issues getting it going because I needed to mount /dev/pts. I didn't think of adding a second startup script to inittab to do that rather than tweaking rcS. Good idea, it's much safer.

As for dropbear - I generally detest telnet, but I didn't particularly care for a device as simple and dumb as a Kobo, especially since wifi is practically never turned on anyway. I wanted to provide instructions that involved minimal change to the device and no additional binaries. Certainly if I had a use case that called for wifi to actually be turned on and in use on networks I don't trust then I'd want to be using ssh.

i got the telnet and ftp to work on 1.7.4 wifi reader. I got another 1.8.x reader and tried the same rcS change - but not the 1.8.x won't complete the book. I'm able to get it into the USB mode - but still could not get it to complete boot. Any suggestions on fixing my 1.8.x reader.

I tried that but didn't work. After several hours w/the kobo tech support, still not working. The Borders store where I purchased the kobo wifi from was kind enough to replace it. The firmware was updated to 1.9. I used the inittab technique from tjm. Success! Able to telnet in. Really appreciate both yours and tjm's help/posts.

Glad you got it sorted, though I'm very surprised a factory reset didn't do the trick. It erases the OS partition and rewrites it using the recovery partition, so it really should. Factory reset has always erased changes on mine when I messed it up while figuring things out.

I very strongly advise you to make a backup disk image of your Kobo, so you can restore it if you have problems in the future. It was very kind of tech support to try to help you, because they would be entirely justified in saying "you broke it, too bad". Similarly, you're really lucky you were able to get it exchanged.

Not sure what to make of it, but the CoolReader EB600 does have something that resembles a Java VM - JamVM.Perhaps mere fragments, but at least it contains a "working" executable (i.e. you can start it and it gives you a reply).Since I'm even more ignorant about Java than I am about Linux, I didn't yet manage to get something useful out of it.

I didn't try to run it on the Kobo either, though, so perhaps it wouldn't even work.