I started playing around with the SD card contents to see how I can parse it and verify the functionality.
The result is a small Java program that is able to read the contents page by page and display it on a little panel. You can type the page number and press <Enter>, you can use arrow keys or mouse wheel to scroll.
Part 1: http://hackcorrelation.blogspot.de/2013/07/txtr-beagle-teardown-part-1.html
Part 2: http://hackcorrelation.blogspot.de/2013/07/txtr-beagle-part-two-software.html
Part 3: http://hackcorrelation.blogspot.de/2013/07/txtr-beagle-part-3-storage-and-transfer.html
Part 4: http://hackcorellation.blogspot.de/2013/07/txtr-beagle-card-parser.html
Part 5: http://hackcorrelation.blogspot.de/2013/07/txtr-beagle-native-code-analysis.html
A couple of observations:
- building a 3bpp image in Java is a pain or I'm missing something. Perhaps the TYPE_BYTE_INDEXED would be a better choice
- although the images seem to render correctly they display differently than on the device. I think the reason for this is that the eInk gamma curve is different compared to the computer monitor, but perhaps I'm also parsing the buffer incorrectly
- there are a few Easter eggs hidden in the images: an author page, a lolzcat(?) image, a reset screen, font size screen
- at the end of the useful card contents the pages get scrambled. I believe the device might be switching to a different access mode
Next stop would be to build a Java app that parses PDF files (or something else) and is able to pipe the output to the device. Not my priority though, I'd rather study the uC first and see what it does.
Technically, the images below are screenshots taken from my application which should not pose a copyright problem just as posting a picture of the device should not constitute a copyright violation.
Useful information:
Page 0 - some not-yet-decrypted data and indexes (indices?)
Page 1 - utility page - no books, please transfer to begin reading...
Page 2 - utility page - no books, please connect your smartphone...
Page 3 - utility page - waiting after books
Page 4 - utility page - connected to smartphone
Page 5 - not decoded; random stuff, maybe some fonts
The Java code does not perform any checks, might not close files on failure, might crash your data, etc.
The result is a small Java program that is able to read the contents page by page and display it on a little panel. You can type the page number and press <Enter>, you can use arrow keys or mouse wheel to scroll.
Part 1: http://hackcorrelation.blogspot.de/2013/07/txtr-beagle-teardown-part-1.html
Part 2: http://hackcorrelation.blogspot.de/2013/07/txtr-beagle-part-two-software.html
Part 3: http://hackcorrelation.blogspot.de/2013/07/txtr-beagle-part-3-storage-and-transfer.html
Part 4: http://hackcorellation.blogspot.de/2013/07/txtr-beagle-card-parser.html
- building a 3bpp image in Java is a pain or I'm missing something. Perhaps the TYPE_BYTE_INDEXED would be a better choice
- although the images seem to render correctly they display differently than on the device. I think the reason for this is that the eInk gamma curve is different compared to the computer monitor, but perhaps I'm also parsing the buffer incorrectly
- there are a few Easter eggs hidden in the images: an author page, a lolzcat(?) image, a reset screen, font size screen
- at the end of the useful card contents the pages get scrambled. I believe the device might be switching to a different access mode
Next stop would be to build a Java app that parses PDF files (or something else) and is able to pipe the output to the device. Not my priority though, I'd rather study the uC first and see what it does.
Technically, the images below are screenshots taken from my application which should not pose a copyright problem just as posting a picture of the device should not constitute a copyright violation.
UPDATE
Page 0 - some not-yet-decrypted data and indexes (indices?)
Page 1 - utility page - no books, please transfer to begin reading...
Page 2 - utility page - no books, please connect your smartphone...
Page 3 - utility page - waiting after books
Page 4 - utility page - connected to smartphone
Page 5 - not decoded; random stuff, maybe some fonts
Page 6 - utility page - cover screen [saver]
Page 7 - utility page - please wait
Page 8 - utility page - showing shadowed book, diagonal stripes on cover
Page 8 - utility page - showing shadowed book, diagonal stripes on cover
Page 9 - utility page - timeout, connection was terminated
Page 10 - utility page - reset screen [yes/no]
Page 11 - utility page - connection lost
Page 12 - utility page - battery almost empty
Page 13 - utility page - battery empty
Page 14 - utility page - authors page
Page 118 - first page for second book
Page 12 - utility page - battery almost empty
Page 13 - utility page - battery empty
Page 14 - utility page - authors page
Page 15 - utility page - font size 24pt example
Page 16 - utility page - font size 28pt example
Page 17 - utility page - font size 32pt example
Pages 18-20 - utility page - catz
Pages 21-58 - blank
Page 59 - cover page for first book (beagle guide)
Page 60 - first page for first book (beagle guide)
Page 78 - last page for first book (beagle guide)
The Java code does not perform any checks, might not close files on failure, might crash your data, etc.
Thanks!
ReplyDeleteOne immediate use case for your findings: by sending "UTILITYPAGE 6", one can overwrite the standby screen. As long as we cannot disable standby, this is a nice workaround for displaying static content (such as a door plate).
I have just tried it out with Florian's code, and it works flawlessly :)
Is there any hint of dynamically loaded microcontroller code on the SD card?
I was hoping that the standby screen can be changed. It the first step for a low-power remote display.
ReplyDeleteI'll check the dynamic uC code but I really don't think there will be any. I wish there was a way do download the uC code, I have a lot of tools around but don't know how to use them (scope, logic analyzer, bus pirate, ...) to search for some kind of bootloader or bootstrapper.
Worst case for this would be a 555 circuit or small uC to power on the device and keep the power button pressed from time to time. The computer/phone can check for BT availability and upload the file.
Would love if someone could test the Java code against a known generated file (see python scripts in the comments from the previous post) and see if the artifacts are also visible on the reader or it's just the computer display.
I'm not sure if this was the right way to do it:
ReplyDeleteI took a screenshot of the standby image displayed in CardParser, converted it to pgm and uploaded it to the Beagle.
On the Beagle, it looks as blocky as the bitmap in CardParser, i.e. without anti-aliasing.
It might be that the conversion to pgm deteriorates the image quality, too.
That's strange then, I'm sure my code is doing something wrong. To be honest, the Android is doing the dithering so that anti-aliasing is built-in by design.
ReplyDeleteHowever, I'm getting the already rendered data from the card which should not display this aliasing. It looks as if I'm missing some pixel lines causing only incomplete data to be displayed.
Great reading your blog posst
ReplyDelete