The ET16 scanner is based on the Sunplus or iCatchtek spca6330 image processing board. Many vendors use the same hardware components. The EKEN ("eee-ken") action camera also uses the spca6330 board and a Windows PC hosted firmware flasher called the FRM ("firmware resource manager") to perform ISP ("in system programming"). The FRM can also produce Card ISP files ("insertable memory card in system programming files") . The Sunplus BRN (""sunplus burn files") are memory "Card ISP" files
These can be used to update firmware in production devices capable of being placed in RSV mode ("read save verify" mode).
Embedded hardware comes with NAND, eMMC or SPI accessible EEPROM memory. This is where the firmware is stored. Typically its divided up into chunks or "partitions" which are accessed by the bootloader at the start of memory when start up commences.
If a generic operating system like Linux is used the path of least resistance is to format some of the partitions as "virtual disk drives" with a well known file system such as ext2, or a compressed file system like cram or squashfs. In that way a generic monolithic program like Busybox can act as many parts of the operating system in a single binary to save space while exposing a common and familar (and scriptable) toolkit and programming interface.
[- then again on second thought nothing precludes "burning" as part of a partition a small file which contains a partition "image" of a filesystem itelf, like a fat16.img file.. -]
If a more conservative and deterministic (aka reliable) or 'time critical' operating system is used like eCOS, RTOS or ThreadX then the memory chunks or 'partitions' may simply be "mapped" regions of storage accessed by the programs themselves without any file system.
The SUNPLUS BURN FILE format appears to be more of the latter type.
There appear to be three partitions, two general "resource" partitions in which general purpose tool binaries are placed, which can be anything from graphical image files to font files or actual programs.
And a third partition dedicated to "default firmware", which some might call a "bootstrap" or "boot loader" except that in this context its actually more like a combination bootloader and kernel.
Resources from the other two partitions are accessed by the "kernel" using a known offset in persistent memory devices always present on these "known" hardware component boards.
The exact architecture of the file formats is not known, however they are probably a type of ELF file format, and given the processor is likely an ARM A9 it is probably for a 32 Bit ARM processor architecture.
Its more common these days with multi-core or multi-processor chips to run two entirely "different" operating systems on each core.. one dedicated to a "time critical" -- real-time -- operating system like ThreadX, and the other to a general purpose (or easier for 'humans') to script or program [user-interface] operating system like "linux".. this is called [a]symmetric multi-processing since they do not neccessarily run in synchrony and rendevouz ("link-up") by passing messages back and forth through established methods in their operating systems.. its more like the worlds "smallest" internet of computers. - This does not appear to be the case with the ET16 scanner.. if it is running two copies of an operating system, they may be the same operating system. (I base this on observing both partitions appear to simply contain binary blobs and not a recognizable 'linux' or 'dos-like' file system).
While it is possible to use the FRM tool on a production device in RSV mode to "download" or "retrieve" the actual burned firmware and make a "backup" before flashing new firmware, or for further development and inspection.. I have not done this with the ET16 scanner.
When the binary "blobs" are retrieved in this fashion they come back and are saved on typical Windows file folders. And can be further examined.
My purpose is not so much to "reverse engineer" as to simply understand in "general" terms how the ET16 actually works.. and so much of this is from inference and observation than actual "hacking".
Besides, the Sunplus Burn File (SPHOST.BRN) or "System Programming for Host Burning" file is already provided as a "firmware update" for the ET16 as a download from a website.
"Unpacking" a [Sunplus Burn File] should be a matter of looking at each "partition" inside the singular Burn file (unfortunately not a file system you could mount) and extracting the individual binary ELF format programs. - but then we'd have to stop, since unless you had a sufficient debugger or hardware development board. The programs would not run on a PC.. perhaps inside a virtual machine like QEMU, or debugger like IDA Pro.. but that would pretty much be end of story.
One gentle man has used Python to create a few scripts to extract the ELF binaries from a Sunplus Burn File
Reversing, Exploiting und Patching an Action Camera
Martin's GitHub for SPCA-FUN python scripts
One thing that came to mind was as a 32 ELF the byte-ordering might be reversed, and this might be the case in the final Burn file as well.
I hope this satisfies a few peoples curiosity.
p.s.. The EKEN (pronounced "eee-ken") action camera uses the "resource" partitions to store "parameters" or settings which the other programs access and use while running. By tinkering with these settings they have enhanced or modifed features and behaviors of their action cameras. This is a dangerous thing to do. And it does lead to "bricking" or making their $300 to $400 cameras useless.. but explains much of the interest in "hacking" their devices.
p.p.s. Sunplus is a collection of companies in China and has a large and deep history with good documentation and a thorough patent portfolio. Not all of their documents have an English language counter part. And many of their documents are proprietary and confidential. The few public samples I have seen from many years ago are excellent and quite detailed. (I am under no NDA). Sunplus does responsible releases of public GNU code that they use, but do not include the specific binaries and scripts they are not beholding to release. -- That said reverse engineering to bring much of the hardware based on their technology under support in Linux is always ongoing and appears to take place mostly in Europe. -- From I can see Czurtek is probably under NDA and cannot release many specifics about the actual EVK software development code and hardware interfaces. They have however built a rich API on top of the proprietary code and expose what appears to be a very useful API of their own.
