Protéger le flash AVR de la lecture via le FAI?


15

J'essaie de protéger le flash entier de la lecture via le FAI. Il a un chargeur de démarrage, capable de programmer automatiquement la section des applications.

Définition de l'octet de verrouillage sur:

LB1/LB2 ne permettra pas à l'utilisateur d'utiliser le chargeur de démarrage pour télécharger un nouveau firmware.

BLB12/BLB11et BLB01&BLB02n'empêchera pas la lecture du flash via le FAI, si je ne me trompe pas.

Il n'y a donc aucun moyen de laisser l'utilisateur mettre à jour le firmware par un chargeur de démarrage personnalisé et protéger le flash de la lecture en même temps?

Réponses:


18

Vous n'avez pas spécifié de puce, ce qui suit est principalement adapté aux appareils atmega 8 bits, mais il s'agit d'informations générales. Lisez la section «Programmation de la mémoire» pour la fiche technique de votre puce spécifique pour des informations plus spécifiques!

Cela étant dit, et comme vous l'avez dit, tous les appareils AVR contiennent deux bits de verrouillage nommés LB1 et LB2. La programmation de ceux-ci (à 0, faible) ajoutera une protection au contenu écrit dans les mémoires Flash et EEPROM conformément au tableau ci-dessous. Le niveau de protection est divisé en trois modes, où le mode 1 n'offre aucune protection et le mode 3 offre une protection maximale. Il est possible de passer à un mode de protection supérieur simplement en reprogrammant les bits de verrouillage.

L'AVR permet de changer les bits "hauts" en "bas", mais pas l'inverse. Il n'est pas possible de changer un bit de verrouillage "bas" en un bit "haut", il n'est donc pas possible d'abaisser le niveau de protection. Pour effacer les bits de verrouillage, un effacement de puce complet est requis, ce qui efface la mémoire flash.

Tableau des bits de verrouillage AVR

Ces 2 bits de verrouillage seuls (LB1 et LB2) lorsqu'ils sont bas empêcheront 99,9% des gens de voler votre firmware! Probablement plus de 99,9%. Il serait presque toujours plus facile de rétroconcevoir votre code.

Il n'y a donc aucun moyen de laisser l'utilisateur mettre à jour le firmware par un chargeur de démarrage personnalisé et protéger le flash de la lecture en même temps?

À ma connaissance (je pourrais me tromper mais je pense que j'aurais eu des problèmes avec cela auparavant) sur les appareils qui ont les fusibles de protection du chargeur de démarrage (BLB12 et BLB11), vous pouvez verrouiller votre section de chargeur de démarrage personnalisé , désactiver SPI et être protégé de 97 à 98% des personnes.

Cependant, quand aucun des bits de verrouillage n'est programmé, aucune fonction de verrouillage de la mémoire n'est activée !!! La désactivation du FAI ne suffit que pour bloquer 70% des personnes.

Pour quelques informations supplémentaires, les bits de verrouillage et les fusibles ne sont pas situés dans l'espace flash ou EEPROM normal, ni accessibles depuis le logiciel, à l'exception des bits de verrouillage liés au chargeur de démarrage dans les appareils dotés de la fonction d'auto-programmation. Le tableau 2 de cette note d'application vous aidera à identifier ce que vous pouvez faire pour votre appareil particulier!

La gamme AVR d'Atmel ne sont pas des appareils de haute sécurité (sauf indication explicite!) Et en tant que tels, ils ne sont absolument pas accompagnés d'une garantie de sécurité de code, et ils ne devraient pas non plus! Comme tous les appareils non sécurisés (et malheureusement même certains sécurisés), ils sont sujets aux attaques courantes!


Éditer

Je mettrai l'en-tête de l'interface de programmation HV à bord. Mais quelqu'un peut-il utiliser le programmateur HV pour LIRE le flash? Je sais que le programmeur HV peut effacer les puces même si les FAI / Jtag sont désactivés.

Je ne pense pas que vous devriez inclure le programmateur HV dans la conception de votre carte, sauf si cela est absolument nécessaire et vous savez avec certitude que cela ne causera aucun problème avec quoi que ce soit. Les programmateurs HV (signaux 12 volts) ne sont disponibles que par mesure de sécurité pour programmer des puces verrouillées (verrouillées en erreur, principalement). En théorie, cela ne vise qu'à programmer l'appareil pour ne rien lire. Et je n'ai jamais entendu parler d'un exploit qui permettrait de lire.

Pour mettre à niveau le chargeur de démarrage (occasionnellement), je mettrai l'en-tête de l'interface de programmation HV à bord. Mais quelqu'un peut-il utiliser le programmateur HV pour lire le flash? Je sais que le programmeur HV peut effacer les puces même si les FAI / Jtag sont désactivés.

Je pense qu'il peut y avoir un moyen de mettre à jour le flash verrouillé via le chargeur de démarrage, (quelque chose à voir avec un indicateur d'écriture interne et / ou un ISR peut-être ???) Mais je vais devoir rechercher mes notes et peut-être devoir le tester. Je ne pourrai pas le faire pendant environ 20 heures; Je recommande donc fortement de poser une nouvelle question axée uniquement sur cela et pour le processeur que vous avez mentionné. C'est une très bonne question !


+1 pour le dernier commentaire, si tout le reste échoue, tout type peut simplement dessouder la puce et nous coller un débogueur / programmeur AVR pour réinitialiser les bits de verrouillage et votre sécurité est finie.
helloworld922

@ Garrett Fogerlie: je ne sais pas ce qui vous fait penser que j'essaie de voler le code, merci de me le faire savoir et je corrigerai ma question pour que les autres ne pensent pas de la même manière. J'essaie de protéger au minimum mon propre code, mon propre chargeur de démarrage. Quoi qu'il en soit, quelques questions supplémentaires à ce sujet. La puce est ATMega328, pensant que la famille aura une utilisation commune des bits de verrouillage. Vous avez expliqué LB1et LB2, que j'ai également décrit dans ma question comme une option limitante pour utiliser le chargeur de démarrage à des fins de mise à niveau. Ce n'est donc pas une option. Quant à BLB12et BLB11- c'est ce que je ne comprends pas. (à suivre)
Pablo

La définition de ces bits n'empêchera personne de lire le flash (application + chargeur de démarrage) de l'extérieur. D'après la fiche technique, il semble que ces bits bloqueront simplement les commandes LPM / SPM, mais le programmeur série ne l'utilise pas. Quant à la désactivation de la programmation série et de jtag, c'est une autre grande question pour moi. Pour mettre à niveau le chargeur de démarrage (occasionnellement), je mettrai l'en-tête de l'interface de programmation HV à bord. Mais quelqu'un peut-il utiliser le programmateur HV pour LIRE le flash? Je sais que le programmeur HV peut effacer les puces même si les FAI / Jtag sont désactivés.
Pablo

@pablo, désolé, je ne voulais pas vous offenser. Quand j'ai vu votre question pour la première fois, l'idée de vol ne m'est pas venue à l'esprit; et j'ai écrit une réponse qui était quelque peu axée sur la récupération de code verrouillé. Cependant, j'étais au travail et avant de soumettre cette réponse, j'ai eu une pause d'environ 2 heures. Puis, quand je suis revenu, j'ai remarqué qu'il n'y avait toujours pas de réponse et j'ai été un peu surpris, puis en relisant votre question, j'ai pensé que le «vol» était peut-être la raison. Ce n'est pas de votre faute du tout, j'ai maintenant supprimé la clause de non-responsabilité. Le modèle de processeur était nécessaire en raison des différences répertoriées dans ce tableau et parce qu'il existe des AVR
8/16/32

1
Garrett Fogerlie: Je ne voulais pas mettre le programmateur HV à bord, juste un en-tête :) Mais j'ai compris que ce n'était pas nécessaire car les bits de verrouillage fonctionnaient et juste au cas où je pourrais utiliser l'en-tête du FAI pour effacer les puces et réécrire tout le flash sur l'appareil. Donc, pour résumer la réponse à ma question d'origine - le réglage de LB1 et LB2 empêchera quiconque de lire toute la zone flash ET en même temps ne m'empêchera pas d'écrire la mémoire du programme via le chargeur de démarrage.
Pablo

3

Vous pouvez utiliser les bits de verrouillage sur certains appareils ATMega et toujours mettre à jour votre code avec le chargeur de démarrage.

J'ai programmé LB1 et LB2 sur un ATMega 328. Puis j'ai appelé le chargeur de démarrage, mis à jour le programme principal - tout fonctionnait parfaitement.

Le FAI ne peut ni lire ni écrire de flash / eeprom / fusibles mais le chargeur de démarrage peut toujours écrire la section d'application.

Un effacement de puce avec le FAI effacera les bits de verrouillage (LB1 et LB2), mais efface également l'intégralité du flash / eeprom, vous pouvez donc protéger votre code (cependant vous devez vous assurer que votre chargeur de démarrage ne peut pas être piraté)


3
Comment cela améliore-t-il la réponse actuellement acceptée?
Ignacio Vazquez-Abrams

Notez que tant que vous avez un résident de chargeur de démarrage de type Arduino standard, le verrouillage de la relecture serait presque inutile car le chargeur de démarrage lui-même a une capacité de relecture, sauf si vous utilisez le mode avancé 328P uniquement qui désactive le LPM du chargeur de démarrage dans la mémoire de l'application. Sinon, vous devrez modifier le chargeur de démarrage pour le supprimer, au prix de ne plus pouvoir vérifier la programmation. (Vous pourriez potentiellement créer un mécanisme de vérification différent, mais ce serait non standard vous obligeant à modifier / remplacer également avrdude)
Chris Stratton
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.