View Single Post
Old 10-20-2012, 09:47 AM   #55
murg
No Comment
murg ought to be getting tired of karma fortunes by now.murg ought to be getting tired of karma fortunes by now.murg ought to be getting tired of karma fortunes by now.murg ought to be getting tired of karma fortunes by now.murg ought to be getting tired of karma fortunes by now.murg ought to be getting tired of karma fortunes by now.murg ought to be getting tired of karma fortunes by now.murg ought to be getting tired of karma fortunes by now.murg ought to be getting tired of karma fortunes by now.murg ought to be getting tired of karma fortunes by now.murg ought to be getting tired of karma fortunes by now.
 
Posts: 3,240
Karma: 23878043
Join Date: Jan 2012
Location: Australia
Device: Kobo: Not just an eReader, it's an adventure!
While a feature like this may only take a day for the coding, the effort around that day will consume person-weeks.

The firmware update protection feature itself operates at a time when the device is engaged in a single thread, that of recognising that the firmware update files exist and had made the decision to update the firmware. At this point, the device should be very single task oriented.

The firmware update protection feature itself is fairly simple. Look for a specific file, read the file, use the contents to make the determination of whether or not to proceed with the update. You can even use the filename of the md5 hashes as the check, in that the firmware will look for the md5 file that is named for the device type, and if it cannot be found, goes through the normal hash-not-match functionality.

The tricky bit is deleting the update if it is not the correct one for the device.

Testing is actually fairly simple. Due to the single-taskedness of what is happening on the device at the time the firmware update is happening, the device can pretty much ignore everything else that is happening on the device, just like it does not when the update is being processed.

As that covers the technical side, the consumer electronics side is much simpler. As Kobo has decided to give its customers access the the user-accessable drive, prudent design demands that they make it next to impossile for anything that a user does to that side of the device cause the device harm. On the Touch, this was ultimately handled with the paperclip factory reset. On the Glo, this seems to require a PC and some specialised knowledge.

The device is already checking the md5 hashes to ensure that a good copy of the firmware is available. It is but a short leap to ensure that the correct copy of the firmware is the one being presented.

I am not advocating that Kobo should be able to handle anything that gets thrown at it. If you try to deliberately mess up the device, you get what you deserve. But normal everyday interfacing with PCs and users should be covered.
murg is offline   Reply With Quote