Vraag:
Firmwarebescherming op AVR- en PIC-controllers
Rookie91
2014-03-10 08:57:40 UTC
view on stackexchange narkive permalink

Kan iemand het HEX-bestand dat ik brand uitpakken in een microcontroller die ik hem bezorg?

Als dat mogelijk is, hoe kan iemand er dan voor zorgen dat zijn code is beveiligd in embedded systemen? Hoe kan men in het geval van PIC- en AVR-microcontrollers hun firmware tegen reproductie beschermen?

http://www.atmel.com/Images/doc2589.pdf
In geval # 1 lijkt het erop dat u suggereert dat u het hex-bestand aan uw klanten verstrekt, in dat geval kunnen ze het gewoon naar verschillende kloonapparaten schrijven, het is niet echt nodig om te [decompileren] (http://en.wikipedia.org/wiki / Decompiler) de code, hoewel het mogelijk is. In het geval van een vergrendeld apparaat (# 2), is het meestal een kwestie van hoe vastbesloten ze zijn om de code te krijgen (met andere woorden hoeveel ze bereid zijn te besteden), maar het is meestal mogelijk.
Vroeger was het twee jaar, maar bescherming wordt tegenwoordig gemiddeld binnen een dag of twee verslagen voor populaire apparaten. eigenlijk als iemand eenmaal heeft besloten dat het de moeite waard is om te doen. Als je echt beveiliging wilt, moet je in de chipindustrie komen, die krijg je niet met standaard commerciële onderdelen.
Twee antwoorden:
Michael Karas
2014-03-10 09:18:20 UTC
view on stackexchange narkive permalink

De meeste microcontrollers hebben tegenwoordig onderdeel- of fabrikantspecifieke methoden om de ingebouwde firmwarecode te beschermen. Dit wordt meestal gedaan door de circuits te vergrendelen die normaal gesproken het codegeheugen toestaan ​​om te worden uitgelezen. (U moet onderdeelspecifieke details zoeken in het gegevensblad of op de website van de fabrikant in de toepasselijke toepassingsinformatie).

Eenmaal vergrendeld is het niet mogelijk om het codegeheugen met normale technieken uit te lezen. Dit biedt een redelijk beschermingsniveau om te voorkomen dat de meeste hackers de machinecode voor uw ingesloten toepassing bekijken.

Veel MCU-apparaten hebben tegenwoordig FLASH-geheugen aan boord om de programmacode op te slaan. Een eerder opgeslagen en beveiligd programma dat is opgeslagen in FLASH kan meestal worden vervangen door een nieuwe code, maar het vereist een volledige flash-wisbewerking van de chip om het beschermingsmechanisme te ontgrendelen. Eenmaal gewist zal het onderdeel werken zoals het deed voordat het originele beveiligingsslot werd vergrendeld. Als een nieuw programma wordt geladen, is het over het algemeen mogelijk om het onderdeel opnieuw te vergrendelen om de nieuw geladen machinecode te beschermen.

Elke discussie over codebescherming in microcontrollers zou niet compleet zijn zonder te vermelden dat er gewoonlijk geen garantie dat een door de fabrikant van het onderdeel aangeboden beschermingsplan onfeilbaar is. Fabrikanten zullen zelfs stellen dat de beveiligingssystemen niet 100% onfeilbaar zijn. Een van de redenen hiervoor is dat er een hele zwarte markt-industrie gaande is waar ijverige hackers tegen betaling code uit een beschermd gedeelte voorlezen voor iedereen die wil betalen. Ze hebben verschillende schema's bedacht waarmee de code kan worden uitgelezen uit de ROM's of FLASHes op beschermde microcontrollers. Sommige van deze schema's zijn ongelooflijk slim, maar werken bij sommige gezinnen beter tot succes dan bij andere. Houd dus rekening met dit feit en probeer uw programma te beschermen tegen nieuwsgierige blikken.

Zodra iemand de binaire afbeelding van de machinecode in handen heeft die uit een microcontroller is uitgelezen, of dat nu een beschermde microcontroller was of niet, kan hij de machinecode verwerken met een tool die een disassembler wordt genoemd. Hierdoor worden de binaire gegevens weer omgezet in assembleertaalcode die kan worden bestudeerd om te proberen te leren hoe de algoritmen van uw programma werken. Het nauwkeurig demonteren van machinecode is een nauwgezette klus die enorm veel werk kan vergen. Uiteindelijk kan het proces leiden tot de assembler-code zoals ik heb beschreven. Als je programma is geschreven in een taal op hoog niveau, zoals C, C ++ of Basic, zal de assemblagecode alleen het gecompileerde en gekoppelde resultaat van je programma vertegenwoordigen. Het is over het algemeen niet mogelijk om gestolen code helemaal terug te brengen naar het taalniveau op hoog niveau. Ervaren hackers kunnen dichtbij komen als ze voldoende tijd en ervaring hebben.

Wat dit betekent, is dat het feitelijk een voordeel is om uw ingebouwde toepassingsfirmware in een hoge taal te schrijven. Het biedt nog een laag die het moeilijker maakt voor uw programma om volledig reverse-engineered te worden. Een nog groter voordeel is te behalen door de hoogste stand van de techniek te gebruiken bij het optimaliseren van compilers om de embedded applicatie te compileren, omdat de best presterende optimizers het programma letterlijk kunnen veranderen in een enorme spaghettikom vol tientallen oproepen naar korte subroutines die erg moeilijk zijn om te ontcijferen in een disassembler.

De meeste ervaren embedded ontwikkelaars zullen u vertellen om door te gaan en elk beschermingsschema te gebruiken dat op de MCU in uw toepassing wordt aangeboden ... maar niet om er tot het einde van de weg van af te hangen voor uw product. Ze zullen je vertellen dat de beste manier om de concurrentie voor te blijven, is door je product constant te upgraden, zodat de oude versies verouderd en oninteressant zijn tegen de tijd dat hackers je code hebben gekloond. Verander de code, voeg nieuwe functies toe, draai je pc-kaarten van tijd tot tijd om al je I / O's om te wisselen en alle andere dingen die je maar kunt bedenken. Op deze manier kun je de race elke keer winnen.

Heel erg bedankt @Michael Karas Dat was een volledig antwoord
Roh
2014-03-10 20:25:55 UTC
view on stackexchange narkive permalink

Ik denk dat Michaels antwoord voldoende is voor deze vraag, maar ik voeg deze beide links toe: Hacking the PIC 18F1320 en Everything they make, we can break! Dit waren allebei erg interessant voor mij.

De ijverige EE moet die laatste link bestuderen, en apparaat (en) onderzoeken / vergelijken / kiezen die * ontbreken * in de lijst.Complexiteit is altijd afschrikkender - zoals het toevoegen van een [DS3641] (https://www.maximintegrated.com/en/products/power/supervisors-voltage-monitors-sequencers/DS3641.html) of [ATSHA204] (http: //www.atmel.com/products/security-ics/cryptoauthentication/cryptoauthentication-companion.aspx).Hoewel geen enkele aanvullende beveiliging ooit 100% onbreekbaar zal zijn, kan de extra complexiteit het niet de moeite waard maken.


Deze Q&A is automatisch vertaald vanuit de Engelse taal.De originele inhoud is beschikbaar op stackexchange, waarvoor we bedanken voor de cc by-sa 3.0-licentie waaronder het wordt gedistribueerd.
Loading...