大家好，我正在寻找解密 ATtiny 芯片的十六进制代码文件并使用 AVRDude 命令行界面对其进行编程。问题是，我不希望用户在任何给定时间都能看到 HEX 文件是什么。
VB.net Cryptography 是否可以在将 HEX 文件放到服务器上之前对其进行加密，然后在程序从服务器下载该文件并通过程序运行它之后解密它，而不会看到解密的 HEX 文件？
显然，HEX 文件在编程到 ATtiny 芯片时无法保持加密状态，所以我该如何处理才能创建要在程序中编程的原始 HEX 文件，而不必担心它将临时文件写入硬盘驱动器然后删除它？ （因为他们可以在执行该临时文件后关闭程序，并且他们可以导航并打开它并查看代码）
任何帮助都会很棒！ :o)
大卫
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 would be able to navigate and open it and see the code)
Any help would be great! :o)
David
发布评论
评论（2）
正如您已经指出的，如果您解密主机上的文件，它会以未加密的形式存在，您对此无能为力。
业界时不时地遇到同样的问题，所以他们用密码学找到了自己的方法：有时需要防止其他人能够获得已编译和可运行的文件，因为“他们”会反编译它或在汇编中查看它，有时只需要防止其他人能够在设备上运行他们正确的自制文件。
如前所述，解密主机（用户/客户端主机）上的文件是毫无疑问的。然后稍后再推。例如，您可以让引导加载程序解密从串行线路读取的固件文件。
在这种情况下，您交付硬件（芯片、引导加载程序和初始固件版本），并通过串行线（而不是 JTAG/ASP/ISP）安装更新。引导加载程序将包含解密固件文件的密钥。此密钥还可用于验证固件文件是否来自您，并且没有其他人编译过某些内容。
如果您还需要分发引导加载程序（十六进制文件），您将面临有人可以提取或更改密钥的问题。在这种情况下，非对称密码学将拯救你。您为自己保留私钥，引导加载程序获取公钥部分。即使有人能够提取公钥，他也无法创建一个被识别为您的文件。唉，ATTiny 对于非对称加密来说太弱了，甚至对称加密也会使引导加载程序代码变得臃肿。
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.
无法在指定的约束条件下完成。 ATtiny 无法运行有用的引导加载程序（没有自编程闪存）。您的十六进制文件需要在主机上解密。将解密的数据保留在内存中可能会稍微减慢攻击者的速度。
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.