Time for more exploration
With root access to the ereader, I can get more info and copy what I need to the userdata partition where the books are stored. This is the partition that gets mounted as a USB mass storage device on my computer so I can easily fetch dumped files from it. It’s mount path on the Kobo is /mnt/onboard.
Let’s get the kernel config:
[root@kobo ~]$ zcat /proc/config.gz > /mnt/onboard/kernel.defconfig
I would also like to get a dump of several partitions so I can dig into them later if needed. I use the dd command for this.
[root@kobo ~]$ dd if=/dev/mmcblk0p4 of=/mnt/onboard/mmcblk0p4.img
For the system_a partition, since this is the booted system, it’s safer to remount it as read-only (when it works) before doing it, since the system can be in constant change depending on how it’s been configured.
[root@kobo ~]$ mount -o remount,ro /
It worked without any warnings so I could dump mmcblk0p10 without issues.
Understand the partition table
There is still something I’d like to know. Some partitions have _a suffixes. This makes it seem like there is some kind of A/B partitioning going on but I’m not sure. There might be some empty space between partitions that would somehow be used after rewriting the GPT partition table. Knowing when partitions start and end would let us see what we want.
Unfortunately, the fdisk that the Kobo ships with doesn’t support GPT partition tables…
[root@kobo ~]$ fdisk -l /dev/mmcblk0
Disk /dev/mmcblk0: 15 GB, 15678308352 bytes, 30621696 sectors
1898 cylinders, 256 heads, 63 sectors/track
Units: sectors of 1 * 512 = 512 bytes
Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type
/dev/mmcblk0p1 0,0,2 1023,255,63 1 4294967295 4294967295 2047G ee EFI GPT
It just shows one big partition, which means it was probably not compiled with GPT support enabled and there is nothing else on the Kobo system that can be helpful…
The only thing we can do is dump the GPT partition table from the disk. It should start at the third sector of the disk (a sector is 512 bytes, first one is MBR, second is the GPT header). Each table entry is 128 bytes. Let’s read the first 6 sectors of the table just in case. Since each partition table entry is 128 bytes, we will be reading 6*512/128=24 entries, which is more than enough.
[root@kobo ~]$ dd if=/dev/mmcblk0 bs=512 skip=2 count=6 | hexdump -C
6+0 records in
6+0 records out
3072 bytes (3.0KB) copied, 00000000 af 3d c6 0f 83 84 72 47 8e 79 3d 69 d8 47 7d e4 |.=....rG.y=i.G}.|
00000010 4a 5e ea ad fa 9b fc 47 96 4d 8f 76 be 94 7b 73 |J^.....G.M.v..{s|
00000020 00 04 00 00 00 00 00 00 ff 07 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 62 00 6c 00 32 00 00 00 |........b.l.2...|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000080 af 3d c6 0f 83 84 72 47 8e 79 3d 69 d8 47 7d e4 |.=....rG.y=i.G}.|
00000090 6c 11 c8 2c 0f 1d ad 42 bc 97 a2 ab 54 75 e3 6a |l..,...B....Tu.j|
000000a0 00 08 00 00 00 00 00 00 ff 0f 00 00 00 00 00 00 |................|
000000b0 00 00 00 00 00 00 00 00 55 00 42 00 4f 00 4f 00 |........U.B.O.O.|
000000c0 54 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |T...............|
000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000100 af 3d c6 0f 83 84 72 47 8e 79 3d 69 d8 47 7d e4 |.=....rG.y=i.G}.|
00000110 ea f1 8f 89 97 05 e8 45 8e d7 74 5f 4b 6e c6 c8 |.......E..t_Kn..|
00000120 00 90 00 00 00 00 00 00 ff 97 00 00 00 00 00 00 |................|
00000130 00 00 00 00 00 00 00 00 6e 00 76 00 72 00 61 00 |........n.v.r.a.|
00000140 6d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |m...............|
00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
...
We can see all the partitions we already saw before, and the hex values of their start and end blocks are somewhere in the output. However, we need to translate this, and at this point, we might as well ask our friend Claude for some assistance…
This is what he says based on the partition table hexdump and some additional context I gave him:
[ON] 
| # |
Name |
Start LBA |
End LBA |
Size (sectors) |
Size (MB) |
Gap After |
| 1 |
bl2 |
1,024 |
2,047 |
1,024 |
0.5 |
0 |
| 2 |
UBOOT |
2,048 |
4,095 |
2,048 |
1.0 |
32,768 |
| 3 |
nvram |
36,864 |
38,911 |
2,048 |
1.0 |
0 |
| 4 |
boot_a |
38,912 |
137,215 |
98,304 |
48 |
0 |
| 5 |
tee_a |
137,216 |
145,407 |
8,192 |
4.0 |
0 |
| 6 |
hwcfg |
145,408 |
147,455 |
2,048 |
1.0 |
0 |
| 7 |
ntxfw |
147,456 |
149,503 |
2,048 |
1.0 |
0 |
| 8 |
waveform |
149,504 |
169,983 |
20,480 |
10.0 |
0 |
| 9 |
vendor |
169,984 |
268,287 |
98,304 |
48 |
21,504 |
| 10 |
system_a |
289,792 |
2,386,943 |
2,097,152 |
1,024 |
0 |
| 11 |
recovery |
2,386,944 |
4,484,095 |
2,097,152 |
1,024 |
0 |
| 12 |
userdata |
4,484,096 |
30,621,567 |
26,137,472 |
12,762.4 |
129 |
Two gaps:
- 16 MB (32,768 sectors) between UBOOT and nvram
- 10.5 MB (21,504 sectors) between vendor and system_a
Total device size: 30,621,696 sectors (14.6 GB)
Last partition ends at: 30,621,567 sectors
Unallocated space: 129 sectors (64.5 KB)
[OFF]
So, our friend is clear, there doesn’t seem to be any significant empty space on the disk. The _a suffix is just a naming convention they used. There is a recovery partition that exists which has the same size as system_a, which is likely used when system_a is detected as corrupted by the bootloader.
What Kernel is this?
At first glance, 4.9 is an old kernel. But looking into it’s config, we might find additional information. I have transfered all the files I wanted on my computer to continue my investigations.
➜ cat kernel.defconfig | grep ANDROID
CONFIG_ANDROID_PARANOID_NETWORK=y
CONFIG_ANDROID_DEFAULT_SETTING=y
# CONFIG_USB_G_ANDROID is not set
# CONFIG_ANDROID_LOGGER is not set
# CONFIG_ANDROID_LOW_MEMORY_KILLER is not set
CONFIG_ANDROID_INTF_ALARM_DEV=y
CONFIG_ANDROID=y
CONFIG_ANDROID_BINDER_IPC=y
CONFIG_ANDROID_BINDER_DEVICES="binder,hwbinder,vndbinder"
# CONFIG_ANDROID_BINDER_IPC_32BIT is not set
# CONFIG_ANDROID_BINDER_IPC_SELFTEST is not set
Usually, having a bunch of _ANDROID_ config options means it’s an Android kernel and not mainline. This is not a good sign…
I started looking at available resources on Kobo kernels, and since there is a large community of hackers for old Kobo devices, I could find the Kobolabs git repository where Kobo actually releases tarballs of their kernels and toolchain 
It confirmed my assumption that it was an Android kernel, but also that the kernel source includes a lot of Mediatek stuff… The repo also includes the source code for the wifi driver and the u-boot they used.
It means that in order to use a recent mainline kernel, I’d need to port all these changes which is a significant amount of work and I’m far from being a kernel developer. I’m definitely not fluent enough in C and I would need to not only mainline the Mediatek parts, but also the wifi driver part if I don’t want a subpar experience with it.
But even if I managed to do this, there is still a major question that needs answering:
Is it using secure boot?
Having ssh access as root would allow us to gather everything we need to run buildroot and Nerves on this thing.
