This is a very small blog post about my first reverse engineering project, in which I don't really reverse engineer anything yet, but I am just getting started!
A family member asked me to add additional book data to the LeapStart he bought for his son, this is the starting point here.
The device is known as LeapFrog LeapStart in english and as VTech MagiBook in French (I'm from France so that's the version I have). The device is a reading aid for children.
It is composed of a large plastic frame and a pen with a pointy tip. When on, you can place a compatible book on the device and use the pen to touch the pages. The device will then read the text on the page, play sounds, or do other things depending on the book.
The device has a micro USB port, an audio jack, a power button and volume buttons.
As a reverse engineering practice! I will graduate in a few months, and I haven't done any "real" reverse engineering yet, apart from tiny binary files for school projects.
I was also fascinated by the fact that the reading of the books works by recognizing a pattern of dots printed very small on the page, if you want more information about this, check out this video series (in French): https://www.youtube.com/watch?v=TWPTnmCAc6c
He is also explaining the hardware, which I won't do because I don't have the knowledge for it.
I am interested in the firmware!
To start reversing the firmware, I first need to get it. Extracting it from the device is out of my abilities, so where ? Well, when I was adding book data using the VTech Software, It also did a firmware update of the device.
This means the firmware is/was on my computer!
After searching my computer for VTech/LeapStart related files,
I found a cache folder in this location:
C:\ProgramData\VTech\DA\VtechStart\LFC_Downloads\cache
I then started using binwalk to analyze the files in this folder.
I found some interesting files, which seem to contain the audio data, however, I am not sure how they are stored exactly, if they are compressed and using which codec.
More importantly, I also found these interesting files (in cache files that were actually zip archives and/or tar archives):
- 'System'
- 'FileSys'
- 'InstLib/LibGodzilla.bin'
- 'InstLib/InstGodzilla.bin'
- 'delo2_surgeon.cbf'
I will focus on these files for now, as they seem to be the firmware files.
The FileSys file is actually a FAT32 filesystem image. When mounting it, it has the following structure:
.
├── AppManifest
├── BookManifest
├── MusicManifest
├── apps (folder)
├── audio (folder)
├── books (folder)
├── music (folder)
└── system (folder)
└── manifest.cb
All the files here are just 1 kb, and I haven't been able to find interesting data/strings inside them.
I am not sure what this file is exactly, but using binwalk with the -A flag for opcodes, it finds a lot of ARM function prologues. I assume this is some kind of ARM binary, but without any headers or anything I haven't been able to find out exactly what it is.
However, I did find a lot of useful strings in it:
- Some C++ info: "std::basic_string<char, std::char_traits, std::allocator >"
- Some logs (?)
- Some strings that hint at the kernel used in the device: "uC/OS-II Idle"
- Some file paths: \system\MfgTest\Coords.txt
While this small part already took quite a bit of time, it allows me to go more in depth on these two files. I will try to find out more information about this System file, including:
- The ISA used: I currently don't know of any tool that could guess it based on the raw binary
- The actual file format: It seems to be more than just code, so I'll look into uC/OS-II and how its firmware files may be structured
- Do some actual reverse engineering: After doing the steps above, I will actually reverse engineer parts of the firmware to understand how it works My main targets are the dot-recognition code and the audio playback code. I also want to try to put custom audio on there if possible, but that may be more involved than I think.
Thanks for reading this small first post!