In this followup to my previous post about hacking the Kobo, I present a few other tips.

Reindexing the collection

It turns out that you can reindex the collection on the device without actually pluging it in a computer. This is very useful if you add or remove files to the device directly (using sftp, for instance), though you do not need it if you are just replacing existing files. The idea is that nickel uses the FIFO /tmp/nickel-hardware-status to get notified about events: if you write usb plug add or usb plug remove to this file, it will act as if the Kobo had been connected or disconnected to the computer.

Hence, you can create a file reindex.sh containing:

echo usb plug add >> /tmp/nickel-hardware-status \
  && sleep 10 \
  && echo usb plug remove

Make it executable and run it with nohup ./reindex.sh. nickel will present a dialog, quickly select "connect", and wait for the fake disconnection and reindexing to take place. Unfortunately, this will disconnect the Wi-Fi (hence the nohup business).

[This one was sent to me by Andreas Heider. Thanks a lot for suggesting this!] I also noticed that, when you download a file through the built-in web-browser, it will get indexed. It could be sensible to run a minimalistic web-server on the device to serve files already stored on the device to make the device index them. Maybe I'll investigate this later.

Automatic reverse ssh

You might want to connect to the device easily without having to find out its IP or worrying about NATs. The right tool for this problem is openvpn, but it has a lot of dependencies and isn't exactly light. A satisfactory (and probably simpler) alternative is to get the device to reverse ssh to a trusted server (with key-based authentication) when it connects to the Internet, so that you can always use this to get a shell.

I already mentioned how to get dropbear running on the device. To get reverse ssh working, it turns out that you have to add busybox ifconfig lo up to the /etc/init.d/rcS file because it isn't done by default. Then, generate a key using dropbearkey -f /root/.ssh/id_rsa -t rsa and copy the fingerprint returned by the command to your authorized_keys file on the trusted server. Obviously, if you worry that unauthorized people might have access to your device, you should use an account with very little permissions.

Now, once you have checked that dbclient -i /root/.ssh/id_rsa USER@SERVER works without asking for a password, you can add the following reverse ssh command at the end of the renew|bound) section of file /etc/udhcpc.d/default.script (note the unsafe "-y" to avoid unknown host key issues, and adapt if you don't like this):

dbclient -y -i /root/.ssh/id_rsa -R 4080:127.0.0.1:22 USER@SERVER < dev/ptmx &

Now, when obtaining or renewing a DHCP lease, the device should run the reverse ssh. I have found this to be pretty fragile when testing, for unknown reasons: workarounds you might want to try are using the IP address of SERVER directly (in case DNS resolution is not working properly yet) or moving the command to a separate script which sleeps for a few seconds before running the command.

Leaving the Wi-Fi active

I was complaining in my previous post about the Wi-Fi getting disabled after a few minutes. According to the (very insightful) guide Hacking the Kobo Touch for Dummies, the responsible for this is nickel, and, indeed, just running killall nickel will fix the problem. Obviously, without nickel running, there is little you can do with the device except from using ssh. When you're done, the /etc/init.d/rcS file suggests that you can get nickel back by issuing something like:

INTERFACE=wlan0
WIFI_MODULE=ar6000
if [ $PLATFORM == ntx508 ]; then
  INTERFACE=eth0
  WIFI_MODULE=dhd
fi

export INTERFACE
export WIFI_MODULE

export QWS_MOUSE_PROTO="tslib_nocal:/dev/input/event1"
export QWS_KEYBOARD=imx508kbd:/dev/input/event0
export QWS_DISPLAY=Transformed:imx508:Rot90
export NICKEL_HOME=/mnt/onboard/.kobo
export LD_LIBRARY_PATH=/usr/local/Kobo
export WIFI_MODULE_PATH=/drivers/$PLATFORM/wifi/$WIFI_MODULE.ko
export LANG=en_US.UTF-8
export UBOOT_MMC=/etc/u-boot/$PLATFORM/u-boot.mmc
export UBOOT_RECOVERY=/etc/u-boot/$PLATFORM/u-boot.recovery

/usr/local/Kobo/nickel -qws

Trouble is, this does not seem to work perfectly (the new nickel instance is a bit broken, especially with regards to Wi-Fi). I would need to investigate more. Of course, to fix things for real, you can always just reboot the device.

Displaying stuff on the Kobo from the shell

People have already figured out how to display stuff on the Kobo's screen from the shell. It's pretty minimalistic (only images in a weird format). To spare a click, here is how you do it:

ffmpeg -i $INPUT.png -vf transpose=2 -f rawvideo
    -pix_fmt rgb565 -s 600x800 -y $OUTPUT.raw
cat $OUTPUT.raw | ssh DEVICE /usr/local/Kobo/pickel showpic

Of course, this means that you can replace the images in /etc/images and /usr/local/Kobo/slideshow by other images. Disappointingly, though, the interesting images (the "powered off" and "sleeping" logos) don't seem to be there and seem to be displayed in another way. The most interesting thing you can customize is the boot animation (/etc/images/on-*.raw.gz).

Retrieving touchscreen events from the device

The (very insightful) guide Hacking the Kobo Touch for Dummies also explains how to recover the touchscreen input events from the device:

evtest /dev/input/event1

There is a lot you can do by forwarding these events to your computer and interpreting them creatively (a custom remote control, for instance). As always, buffering issues are a problem when trying to retrieve the events synchronously. Here is a possible way to retrieve the useful info, where DEVICE is where you can reach the device:

cat <(echo 'evtest /dev/input/event1;') - |
  socat EXEC:'ssh DEVICE',pty,ctty,echo=0 STDIO |
  sed -u 's/$/\n/' |
  stdbuf -i0 -o0 -e0 cut -d ' ' -f 9,11,13

In case you're wondering, the sed command is because the newline at the end of the last event is outputted when the next one happens, which isn't really convenient if you want to pipe the data to something.

Here is a small Python program to run on your computer which accepts this input and will draw what you do on your touchscreen:

import pygame
import pygame.draw
import sys

pygame.init()

def line(x1, y1, x2, y2, r=255, g=255, b=255):
  global window
  pygame.draw.aaline(window, (r, g, b), (x1, y1), (x2, y2))

window = pygame.display.set_mode((600, 800))

pre = None

while True:
  l = sys.stdin.readline()
  if not l:
    break
  l = l.rstrip().split(' ')[0:3]
  if len(l) != 3 or '' in l:
    continue
  print l
  if pre:
    line(600-int(pre[1]), int(pre[0]), 600-int(l[1]), int(l[0]))
  if l[2] != '0':
    pre = l
  else:
    pre = None
  pygame.display.flip()

Obviously, you should try to minimize the network latency if you want this to be pleasant.