AVRdude encrypt/decryption HEX file on the fly in VB

Hey all i am looking to decrypt my HEX code file for an ATTiny chip and programming it using the AVRDude command line interface. Problem being, i do not want the user to be able to see what the HEX file is at any given time.

Can the VB.net Cryptography crypt the HEX file before i put it onto the server and then decrypt it after the program downloads it from the server and runs it through the program without seeing the decrypted HEX file?

Obviously the HEX file can not stay encrypted while being programmed to the ATTiny chip so how can i go about it so that i can create the original HEX file to be programmed within the program without having to worry about it writing a temporary file to the hard drive and then deleting it afterwards? (Because they could close the program after it does that temp file and they wou开发者_如何学JAVAld be able to navigate and open it and see the code)

Any help would be great! :o)

David

As you already pointed out, if you decrypt the file on the host it is there in an unencrypted form, and you can't do anything about that.

The industry has the same problem from time to time, so they got their ways with cryptography: Sometimes it is needed to prevent that anyone else is able to get a compiled and runnable file as "they" would decompile it or look at it in assembly, sometimes it is only needed to prevent that anyoneelse is able to run their proper, home-brewn files on the device.

As said, decrypting the file on the host (the users/clients host) is out of question. Then push it a moment later. You can, for example, have the bootloader decrypt the firmware file that he reads from the serial line.

In this case, you deliver the hardware (chip, bootloader and initial firmware version), and updates are installed via serial line (instead of JTAG/ASP/ISP). The bootloader would contain the secret key that decrypts the firmware file. This secret key can also be used to verify that the firmware file is coming from you, and nobody else compiled something.

If you need to hand out the bootloader (hex file) as well, you will face the problem that somebody could extract or change the secret key. In this case, asymetric cryptography will save you. You keep your private key for you, and the bootloader gets the public key part. Even if somebody is able to extract the public key, he will not be able to create a file that will be recognized as yours. Alas, the ATTiny is far too weak for asymetric cryptography, and even symetric cryptography will already bloat the bootloader code.

Can't be done with the contraints specified. The ATtiny can't run a useful bootloader (no self-programming flash.) Your hex file will need to be decrypted on the host. Keeping the decrypted data in memory may slow down attackers slightly.