caralynx teardowns
@teardowns.caralynx.com
Hack all the toys. Teardowns and analysis of various toys and electronics by @sudo.caralynx.com
Interesting new regulation somewhere that requires you to certify that Kaspersky is not installed on the EUT. This filing's factually incorrect with the amount of storage anyway (PAN1026 does not have accessible storage). They fixed it in the latest filing.
November 24, 2025 at 12:57 AM
Interesting new regulation somewhere that requires you to certify that Kaspersky is not installed on the EUT. This filing's factually incorrect with the amount of storage anyway (PAN1026 does not have accessible storage). They fixed it in the latest filing.
I guess that solution's fine, but the force of the rotating arm is probably throwing the accelerometer off a bit and not making the orientation of the screen totally stable.
November 24, 2025 at 12:51 AM
I guess that solution's fine, but the force of the rotating arm is probably throwing the accelerometer off a bit and not making the orientation of the screen totally stable.
That explains how the rotor and stator kept orientation, and some of the unpopulated components. Looks like originally they were using IR LEDs to figure synchronize, but they now changed it to a hall effect sensor.
November 24, 2025 at 12:51 AM
That explains how the rotor and stator kept orientation, and some of the unpopulated components. Looks like originally they were using IR LEDs to figure synchronize, but they now changed it to a hall effect sensor.
The FCC Equipment Authorization Electronic System is finally back online, and I'm downloading the exhibits. Looks like there's a third ID for the hamster ball filed recently. Meanwhile, I found the third page to the schematics that I was wondering about in the original filing. It's a changelog.
November 24, 2025 at 12:51 AM
The FCC Equipment Authorization Electronic System is finally back online, and I'm downloading the exhibits. Looks like there's a third ID for the hamster ball filed recently. Meanwhile, I found the third page to the schematics that I was wondering about in the original filing. It's a changelog.
The client syncs app installation status with the web service, but it doesn't seem to acknowledge any extra apps that are not licensed. It just doesn't report on it for some reason.
November 20, 2025 at 10:44 AM
The client syncs app installation status with the web service, but it doesn't seem to acknowledge any extra apps that are not licensed. It just doesn't report on it for some reason.
They were nice enough to leave in Mbed TLS' testing functions that obviously identified the cipher family.
The LDI file is generated by the web service, so theoretically there's nothing to hack on the client, but the system app is easy to locate and download, so that didn't really stop anything.
The LDI file is generated by the web service, so theoretically there's nothing to hack on the client, but the system app is easy to locate and download, so that didn't really stop anything.
November 20, 2025 at 10:40 AM
They were nice enough to leave in Mbed TLS' testing functions that obviously identified the cipher family.
The LDI file is generated by the web service, so theoretically there's nothing to hack on the client, but the system app is easy to locate and download, so that didn't really stop anything.
The LDI file is generated by the web service, so theoretically there's nothing to hack on the client, but the system app is easy to locate and download, so that didn't really stop anything.
The LDI file is pretty simple, it's just a comma-separated list of package IDs bookended by header and footer strings, encrypted with AES-256-CBC. The key is the SHA-256 hash of the device serial and a static string, and the IV is another static value.
November 20, 2025 at 10:40 AM
The LDI file is pretty simple, it's just a comma-separated list of package IDs bookended by header and footer strings, encrypted with AES-256-CBC. The key is the SHA-256 hash of the device serial and a static string, and the IV is another static value.
I also found how it does DRM. If you just upload a package without corresponding authorization in the LDI file (\LDI.dat), the package folder just gets deleted on boot.
November 20, 2025 at 10:40 AM
I also found how it does DRM. If you just upload a package without corresponding authorization in the LDI file (\LDI.dat), the package folder just gets deleted on boot.
Finished implementing upload/download functionality, and also package upload, so I can also send .tar files to the device to unpack. Code is a bit of a mess because of everything being top level statements instead of classes, so I've got a mess of nesting IEnumerable<string>s going on.
November 20, 2025 at 10:40 AM
Finished implementing upload/download functionality, and also package upload, so I can also send .tar files to the device to unpack. Code is a bit of a mess because of everything being top level statements instead of classes, so I've got a mess of nesting IEnumerable<string>s going on.
I've now got a DFTP client. No upload/download yet, going to figure that out soon.
November 20, 2025 at 2:27 AM
I've now got a DFTP client. No upload/download yet, going to figure that out soon.
Forgot to mention, .cbf files are also documented and were previously used on other devices.
November 19, 2025 at 7:33 AM
Forgot to mention, .cbf files are also documented and were previously used on other devices.
That implies it has GeneralPlus' USB protocol implemented, which should be interesting. I may have to try that at some point once I can pull my save data and stuff off via DFTP.
November 19, 2025 at 7:32 AM
That implies it has GeneralPlus' USB protocol implemented, which should be interesting. I may have to try that at some point once I can pull my save data and stuff off via DFTP.
7. LeapFrog Connect is allegedly capable of recovering even a bricked device. There's a binary called NandUsbBin that loads as a raw image into memory, and presumably receives .cbf files to reload the bootloader and application code.
November 19, 2025 at 7:32 AM
7. LeapFrog Connect is allegedly capable of recovering even a bricked device. There's a binary called NandUsbBin that loads as a raw image into memory, and presumably receives .cbf files to reload the bootloader and application code.
It seems to run in two modes, USB mode and update mode. Not sure what update mode actually does. I've currently got Surgeon loaded for analysis. Looks like applications are loaded at 0x100 in RAM, and copies a vector table to 0x0 as part of initialization.
November 19, 2025 at 7:32 AM
It seems to run in two modes, USB mode and update mode. Not sure what update mode actually does. I've currently got Surgeon loaded for analysis. Looks like applications are loaded at 0x100 in RAM, and copies a vector table to 0x0 as part of initialization.
6. Surgeon is what boots when you hold the power button. Normally it's used for recovery, and the main system would have a DFTP server running, but LeapFrog made a design choice to not enable any USB in normal operating mode, so Surgeon is the sole method for data transfer.
November 19, 2025 at 7:32 AM
6. Surgeon is what boots when you hold the power button. Normally it's used for recovery, and the main system would have a DFTP server running, but LeapFrog made a design choice to not enable any USB in normal operating mode, so Surgeon is the sole method for data transfer.
and another partition called MfgData. MfgData contains the serial number, product ID, and I think language and some other stuff. After that is a normal FAT partition where the content, boot videos, and resources for the manufacturing test live.
November 19, 2025 at 7:32 AM
and another partition called MfgData. MfgData contains the serial number, product ID, and I think language and some other stuff. After that is a normal FAT partition where the content, boot videos, and resources for the manufacturing test live.
You write a sector with something like "LIST /", and you can read the same sectors for the response and eventually it'll end with something like "200 OK". I'm currently trying to write a REPL for it.
5. The firmware layout consists of the bootloader, then apps System, MfgTest, Surgeon,
5. The firmware layout consists of the bootloader, then apps System, MfgTest, Surgeon,
November 19, 2025 at 7:32 AM
You write a sector with something like "LIST /", and you can read the same sectors for the response and eventually it'll end with something like "200 OK". I'm currently trying to write a REPL for it.
5. The firmware layout consists of the bootloader, then apps System, MfgTest, Surgeon,
5. The firmware layout consists of the bootloader, then apps System, MfgTest, Surgeon,
Instead of normal file operations, it uses a protocol called DFTP, which is a little bit like FTP, but not really. This protocol has apparently been used on the Leapster Explorer (although that's a Linux system and seems to emulate a network connection?).
November 19, 2025 at 7:32 AM
Instead of normal file operations, it uses a protocol called DFTP, which is a little bit like FTP, but not really. This protocol has apparently been used on the Leapster Explorer (although that's a Linux system and seems to emulate a network connection?).
More specifically, it's AES-128-CTR with a fixed key and IV from the start of the downloaded file (as you'd expect). The key here is different from the one floating around.
4. The device itself shows up as a USB drive that's is all zeroes by default, so doesn't show in Explorer.
4. The device itself shows up as a USB drive that's is all zeroes by default, so doesn't show in Explorer.
November 19, 2025 at 7:32 AM
More specifically, it's AES-128-CTR with a fixed key and IV from the start of the downloaded file (as you'd expect). The key here is different from the one floating around.
4. The device itself shows up as a USB drive that's is all zeroes by default, so doesn't show in Explorer.
4. The device itself shows up as a USB drive that's is all zeroes by default, so doesn't show in Explorer.
2. There's no certificate pinning, so I was able to intercept all the API calls. The process for getting new content is lmao, very easy to get the file for anything available in the store.
3. .lfp files are ZIPs, .lf2 files are .tar.bz2, and .lf3 files are encrypted .lf2 files.
3. .lfp files are ZIPs, .lf2 files are .tar.bz2, and .lf3 files are encrypted .lf2 files.
November 19, 2025 at 7:32 AM
2. There's no certificate pinning, so I was able to intercept all the API calls. The process for getting new content is lmao, very easy to get the file for anything available in the store.
3. .lfp files are ZIPs, .lf2 files are .tar.bz2, and .lf3 files are encrypted .lf2 files.
3. .lfp files are ZIPs, .lf2 files are .tar.bz2, and .lf3 files are encrypted .lf2 files.
Some updates:
1. Tried out LeapFrog Connect, it's basically a Qt webview wrapper with a websocket interconnect and some other messaging stuff. Surprising amount of the backend service calls are from the web app. It does way too much logging.
1. Tried out LeapFrog Connect, it's basically a Qt webview wrapper with a websocket interconnect and some other messaging stuff. Surprising amount of the backend service calls are from the web app. It does way too much logging.
November 19, 2025 at 7:32 AM
Some updates:
1. Tried out LeapFrog Connect, it's basically a Qt webview wrapper with a websocket interconnect and some other messaging stuff. Surprising amount of the backend service calls are from the web app. It does way too much logging.
1. Tried out LeapFrog Connect, it's basically a Qt webview wrapper with a websocket interconnect and some other messaging stuff. Surprising amount of the backend service calls are from the web app. It does way too much logging.
Resources are extracting as expected, no new compression methods or anything like that for the graphics. Audio is still A3600 DRM as always.
November 16, 2025 at 11:02 PM
Resources are extracting as expected, no new compression methods or anything like that for the graphics. Audio is still A3600 DRM as always.
I guess I got a little over-ambitious trying to connect all six SD signal lines, and managed to rip the trace off one line (not the whole thing, just from the chip to the edge of the solder mask. Ended up just using 1-bit I/O and the dumping went OK. Fixed the trace afterwards.
November 16, 2025 at 9:40 PM
I guess I got a little over-ambitious trying to connect all six SD signal lines, and managed to rip the trace off one line (not the whole thing, just from the chip to the edge of the solder mask. Ended up just using 1-bit I/O and the dumping went OK. Fixed the trace afterwards.
Well now I know why there's a resistor on the SD CLK pin. Looks like it's part of the IOTRAP system where setting particular pins at power-on changes bootrom behavior, and if this is set high it enters USB ISP mode. Doesn't seem to be a pulldown on it, so maybe it's there for easy access?
November 16, 2025 at 5:31 PM
Well now I know why there's a resistor on the SD CLK pin. Looks like it's part of the IOTRAP system where setting particular pins at power-on changes bootrom behavior, and if this is set high it enters USB ISP mode. Doesn't seem to be a pulldown on it, so maybe it's there for easy access?
This time I hedged my bets that the boot code is probably going to be Thumb, so looked for odd addresses.
November 16, 2025 at 6:46 AM
This time I hedged my bets that the boot code is probably going to be Thumb, so looked for odd addresses.