Protection du micrologiciel sur les contrôleurs AVR et PIC


23

Quelqu'un peut-il extraire le fichier HEX que je grave dans un microcontrôleur que je lui fournis?

Si cela est possible, comment quelqu'un peut-il s'assurer que son code est sécurisé dans les systèmes embarqués? Dans le cas des microcontrôleurs PIC et AVR, comment protéger leur micrologiciel contre la reproduction?



1
Dans le cas # 1, vous semblez suggérer de fournir le fichier hex à vos clients, dans ce cas, ils peuvent simplement l'écrire sur plusieurs périphériques de clonage, pas vraiment besoin de décompiler le code bien que cela soit possible. Dans le cas d'un appareil verrouillé (# 2), c'est généralement une question de détermination à obtenir le code (en d'autres termes, combien ils sont prêts à dépenser), mais c'est généralement possible.
alexan_e

1
il était de deux ans, mais la protection de nos jours a tendance à être annulée en un jour ou deux en moyenne pour les appareils populaires. fondamentalement, une fois que quelqu'un a décidé que cela en valait la peine. Si vous voulez vraiment la sécurité dont vous avez besoin pour vous lancer dans le secteur des puces, vous n'en obtiendrez pas avec des pièces commerciales standard.
old_timer

Réponses:


33

De nos jours, la plupart des microcontrôleurs ont des méthodes spécifiques à la pièce ou au fabricant pour protéger le code du firmware intégré. Cela se fait généralement en verrouillant les circuits qui permettent normalement la lecture de la mémoire de code. (Vous devrez rechercher des détails spécifiques à la pièce dans la fiche technique ou sur le site Web du fabricant dans les notes d'application applicables).

Une fois verrouillé, il n'est pas possible de lire la mémoire de code en utilisant des techniques normales. Cela fournit un niveau de protection raisonnable pour empêcher la plupart des pirates de visualiser le code machine de votre application intégrée.

De nombreux appareils MCU ont de nos jours une mémoire FLASH intégrée pour stocker le code du programme. Un programme précédemment stocké et protégé stocké dans FLASH peut généralement être remplacé par un nouveau code, mais il faut une opération d'effacement FLASH sur puce complète pour déverrouiller le mécanisme de protection. Une fois effacée, la pièce fonctionnera comme avant le verrou de protection d'origine. Si un nouveau programme est chargé, il est généralement possible de reverrouiller la pièce afin de protéger le code machine nouvellement chargé.

Toute discussion sur la protection du code dans les microcontrôleurs ne serait pas complète sans mentionner qu'il n'y a généralement aucune garantie que tout schéma de protection proposé par le fabricant de pièces est à toute épreuve. Les fabricants diront même que les systèmes de protection ne sont pas à 100% infaillibles. L'une des raisons à cela est qu'il y a toute une industrie du marché noir en cours où, moyennant des frais, des pirates informatiques diligents liront le code d'une partie protégée pour quiconque veut payer. Ils ont conçu divers schémas qui permettent de lire le code des ROM ou FLASH sur des microcontrôleurs protégés. Certains de ces régimes sont incroyablement intelligents mais fonctionnent pour mieux réussir sur certaines familles de pièces que sur d'autres. Soyez donc conscient de ce fait et essayez de protéger votre programme des regards indiscrets.

Une fois que quelqu'un a mis la main sur l'image binaire du code machine qui a été lu à partir d'un microcontrôleur, qu'il s'agisse d'un microcontrôleur protégé ou non, il peut traiter le code machine via un outil appelé désassembleur. Cela transformera les données binaires en code de langage d'assemblage qui peut être étudié pour essayer d'apprendre comment fonctionnent les algorithmes de votre programme. Le démontage précis du code machine est un travail minutieux qui peut prendre d'énormes quantités de travail. En fin de compte, le processus peut conduire au code assembleur comme je l'ai décrit. Si votre programme a été écrit dans un langage de haut niveau tel que C, C ++ ou Basic, le code assembleur ne représentera que le résultat compilé et lié de votre programme. Il n'est généralement pas possible de rétroconcevoir le code volé jusqu'au niveau de langage de haut niveau.

Cela signifie qu'il y a réellement un avantage à écrire le micrologiciel de votre application intégrée dans un langage de haut niveau. Il fournit une autre couche qui rend plus difficile la rétro-ingénierie complète de votre programme. Un avantage encore plus important doit être obtenu en utilisant l'état de l'art le plus élevé dans l'optimisation des compilateurs pour compiler l'application intégrée, car les optimiseurs les plus performants peuvent littéralement transformer le programme en un énorme bol à spaghetti rempli de dizaines d'appels à des sous-programmes courts qui sont très difficiles à déchiffrer dans un démonteur.

La plupart des développeurs embarqués expérimentés vous diront d'aller de l'avant et d'utiliser tout schéma de protection offert sur le MCU dans votre application ... mais de ne pas en dépendre jusqu'au bout pour votre produit. Ils vous diront que la meilleure façon de garder une longueur d'avance sur la concurrence est de constamment mettre à niveau votre produit afin que les anciennes versions soient obsolètes et sans intérêt au moment où les pirates peuvent avoir cloné votre code. Changez le code, ajoutez de nouvelles fonctionnalités, faites tourner vos cartes PC de temps en temps pour échanger toutes vos E / S et toutes les autres choses auxquelles vous pouvez penser. De cette façon, vous pouvez gagner la course à chaque fois.


Merci beaucoup @Michael Karas C'était une réponse complète
Rookie91

12

Je pense que la réponse de Michael est suffisante pour cette question mais j'ajoute ces deux liens: pirater le PIC 18F1320 et tout ce qu'ils font, nous pouvons casser! Ces deux étaient très intéressants pour moi.


L'EE diligente devrait étudier ce dernier lien et rechercher / comparer / choisir les dispositifs qui manquent dans la liste. La complexité est toujours plus dissuasive - comme l'ajout d'un DS3641 ou ATSHA204 . Bien qu'aucune sécurité supplémentaire ne soit jamais 100% incassable, la complexité supplémentaire pourrait la rendre inutile.
rdtsc
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.