AVRdude crypter/décrypter fichier HEX à la volée en VB

Question

Salut tout je cherche à déchiffrer mon fichier de code HEX pour une puce ATTiny et de le programmer en utilisant l'interface de ligne de commande AVRDude. Problème étant, je ne veux pas que l'utilisateur puisse voir ce que le fichier HEX est à un moment donné.

La cryptographie VB.net peut-elle crypter le fichier HEX avant de le mettre sur le serveur, puis de le déchiffrer après que le programme l'ait téléchargé du serveur et qu'il l'ait parcouru sans voir le fichier HEX déchiffré?

De toute évidence, le fichier HEX ne peut pas rester crypté lors de la programmation sur la puce ATTiny alors comment puis-je faire pour que je puisse créer le fichier HEX original à programmer dans le programme sans avoir à écrire temporairement fichier sur le disque dur, puis le supprimer par la suite? (Parce qu'ils pourraient fermer le programme après qu'il fait ce fichier temporaire et ils seraient en mesure de naviguer et de l'ouvrir et de voir le code)

Toute aide serait géniale! : O)

David

Answer 1

Comme vous l'avez déjà dit, si vous décryptez le fichier sur l'hôte, il est là sous une forme non chiffrée, et vous ne pouvez rien faire à ce sujet. L'industrie a le même problème de temps en temps, donc ils ont obtenu leur chemin avec la cryptographie: Parfois, il est nécessaire d'empêcher que quelqu'un d'autre puisse obtenir un fichier compilé et exécutable car ils le décompileraient ou le regarderaient Lors de l'assemblage, il est parfois nécessaire d'empêcher que n'importe qui soit capable d'exécuter ses propres fichiers à la maison sur l'appareil. Comme indiqué précédemment, le décryptage du fichier sur l'hôte (l'hôte utilisateurs/clients) est hors de question. Puis poussez-le un moment plus tard. Vous pouvez, par exemple, demander au bootloader de déchiffrer le fichier de firmware qu'il lit sur la ligne série.

Dans ce cas, vous fournissez le matériel (puce, chargeur de démarrage et version de firmware initiale) et les mises à jour sont installées via une ligne série (au lieu de JTAG/ASP/ISP). Le chargeur de démarrage contiendra la clé secrète qui déchiffre le fichier de microprogramme. Cette clé secrète peut également être utilisée pour vérifier que le fichier de firmware provient de vous, et personne d'autre n'a compilé quelque chose.

Si vous avez besoin de distribuer le chargeur de démarrage (fichier hexadécimal), vous serez confronté au problème que quelqu'un pourrait extraire ou modifier la clé secrète. Dans ce cas, la cryptographie asymétrique vous sauvera. Vous gardez votre clé privée pour vous, et le chargeur de démarrage obtient la partie de clé publique. Même si quelqu'un est capable d'extraire la clé publique, il ne pourra pas créer un fichier qui sera reconnu comme le vôtre. Hélas, l'ATTiny est beaucoup trop faible pour la cryptographie asymétrique, et même la cryptographie symétrique va déjà gonfler le code du bootloader.

Answer 2

Ne peut être fait avec les contraintes spécifiées. L'ATtiny ne peut pas lancer un bootloader utile (pas d'auto-programmation flash). Votre fichier hexa devra être déchiffré sur l'hôte. Garder les données décryptées en mémoire peut ralentir légèrement les attaquants.