CybUpdate

Description

Around 2008-2009 when I was working for Bookeen we had an issue with a reseller bricking devices by updating them using a corrupted updater file. At the time, update were just executable running with payload and no verification done if the file was corrupted, leading corrupted or incomplete downloaded files to have the possibility to fail updating a device and leaving it in a non working state.

As we were working on a new generation of device at that time, I took the opportunity to make sure this could not happen again on newly produced hardware.

After some search, nothing useable was found and I went through the process of creating an update application from scratch.

To make sure what happend in 2008-2009 the app and file format use strong cryptography to verify the file origin and validity.

The application was used on 3 different devices, two sharing the same base plateform, and years of update was made using it with no known problems.

Technical informations

The initial application development about 6 month to get it on a working state and during the 4 years the app continued to be used and updated was based on the foundation that was made in 2010.

The file format was the first step of designing the whole application, it was designed around extensiblity and inspired by some archive format. An update file is composed of different internal file using a unique identifier and hashing to check if the file content hasn’t been tempered. The file also include a hash of the whole file and can be ciphered using a fairly strong cipher with a key unique to each update file. A mode that was never used due to technical issues during production prevented to use signing of the update file, but the file format had provision for it.

The second step was building the application which was in two parts, the application to install the update and an application to generate the update files.

The core of the app evolved little between the first version and the final, most of the changes was on the presentation level and adding new file types to support specificities for each paltforms. The update generation grow into a collection of tools to deal with different part of the update file, tools to generate each different files, one to collate and generate the base update file, one to apply hashing and ciphers, etc..

The main update application had some abstration to support different display interface as there is no standard for epaper type screen, and both main devices had a really different interface for their display driver, the UI also evolved between the original version and the final, with more complexity in what the app could show, including some theming ability as some devices had different form factor and screen size.

Trivia

During development of the original version, a problem was found that triggered in some semi-random circunstances where some update files were working and other not without a clear pattern. It turned out that due to the way the ARM SoC was configured it was accepting non word alligned read, but in some cases the retreived data were incorrect, but not always. To fix the issue, I had to force the compiler to align some internal function local buffer to make sure they were properly word aligned by using a GCC attribute like __attribute__ ((aligned(4))).

Disclaimer

This project is not public other than th binary used in the ebook readers. I may render the file format public at some point considering the application and file format has been used for the last 10 years, and all device using that file format are not supported anymore.