Vic..

"USB peripherals, such as thumb drives, can be reprogrammed to steal the contents of anything written to the drive and to spread the firmware-modifying code to any PCs it touches. The net result could be a self-replicating virus that spreads through sparing thumb drives, much like the rudimentary viruses that spread by floppy disk decades ago."

spread by floppy disk ..... ?

flash memory is not an overwrite memory...like hard disk drives....a bit more to it than described when it come to flash and an infectious chewing up memory space.

Anything that might be rewritten to existing firmware would have to take control of the device write functions all together...as in having control of writes or programming of the flash memory cells in some form of write block.

Signet is an authentication issue between devices, perhaps it could be part of API that would stop unwarranted writes to firmware storage memory from unknown sources. Authenticate writes to specific firmware memory...and general storage memory.

As I see it, it's not a matter of mixing in with existing firmware software as the author considers. It's a matter of a whole separate software issue taking control of device programming in order to do what it wants.

Thing is, the infectious code (or an infectious auto exe batch file) has to write itself into the firmware memory prior to it being given life for a any direct boot up takeover...where existing firmware does not direct storage writes to its memory boot space...it directs it to other general storage memory space....

"could be" sounds a bit far fetched to me.... The would be hacker… would have to write an AUTO EXE that would boot from the general storage flash memory root directory…where it was initially download written to this memory directory space unrecognized by the existing firmware under its format.

If it manages to get written to this general storage root space, the AUTO EXE on boot from this space would have to have access back to the existing firmware API calls, where IMO, it would have no idea of how the firmware API calls are structured in order to take control over a device as described….unless they are standard calls…as in open source.

As I see it, all the existing firmware need do, is not make any storage writes to the general storage root directory and there will be no problems for open source issues.

Or better, avoid open source issues utilized for enterprise issues.

doni