New feature to require User approval to upload new sketch (bootloader)

Development Libraries
#1

Normally, we can just plug an Arduino into a USB port and update the sketch when we want, and leave it connected (for serial commands, etc...) and not update the sketch when we don't want to.

However, for a project I am doing with an Uno, I will be giving the Uno to my end user who may have it connected to USB and whom I would like to be able to update the sketch, but for safety reasons, only when they should be able to (not when someone hacks into their PC, etc...)

I would like to modify the bootloader so that when an attempt is made to upload a new sketch, the user would be asked (via the UI I am already adding) to approve and if they do, the upload would proceed normally and if they do NOT, the upload would fail and the current sketch would continue un-interrupted.

I am thinking adding a 2nd bind-point to the bootloader (in addition to app_start()) called app_upload_request() which a sketch would implement.

When write command('d') is received (line 557), if its the first time since the last Q command or if its the first time since boot, the bootloader will call app_upload_request(). The sketch (if user approves), would then call app_upload_approve() which would call the existing code for 'd'. Additional 'd' commands would be handled as normal.

If the user does not approve, then app_upload_approve() is not called and the response codes (0x14, etc...) are not sent, so avrdude will timeout.

See http://github.com/arduino/Arduino/blob/master/hardware/arduino/bootloaders/atmega/ATmegaBOOT_168.c#L557

Will this work or totally break avrdude?

Is there a better way?

#2

Seems like overkill.
A hacker would need to be able to control the IDE, ensure the Arduino is connected, start the IDE and the upload process, which we have seen is full of issues already.

#3

For my current project, I do need to have this ability.

#4

Hopefully someone will help out. Low level coding like that is beyond me. Maybe PM westfw and see if he can help out.

#5

I suspect you are going to put forth a great deal of effort only to end up with a very fragile communications path.

This is how I would approach the problem...

• Designate an EEPROM location as a "lock" (referred to as "lock byte"). If the lock byte is 0xC5 then the board is "unlocked" and an upload can proceed. If the lock byte is anything else then an upload cannot proceed.

• The bootloader only needs a very minor modification. Check the lock byte for 0xC5. If the lock byte is not 0xC5 jump to the application. The modification is so minor you may even be able to keep the bootloader image under 512 bytes.

• Once the new bootloader is installed the lock byte is now entirely in your hands. You can make the process of locking / unlocking as simple or as complicated as you want. For example, the user could enter a password via a terminal (like Serial Monitor) to unlock the board. If the password is invalid, the board is locked.

#6

I agree with @CrossRoads that this is overkill.

What is the probability that someone would hack a PC in the way you imagine? How much damage would arise if the hack did happen?

If the damage would be severe there is very simple solution. Don't connect the host PC to the internet.

In my opinion the development effort required to "solve" this "problem" could almost certainly be put to more productive use - possibly time for a few beers down the pub.

...R

#7