PIC Uitlezen Code Protection

Hang er een analyzer aan en kijk wat er verstuurd wordt. Als er een bootloader in zit, kan dat van alles zijn. Nog afgezien van eventuele Copyright overtredingen, is het meestal eenvoudiger om de software gewoon opnieuw te schrijven.

Arco: Je bedoeld deze?

http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&no…

Heb een PicKit 2.

[Bericht gewijzigd door Jeroen op dinsdag 9 september 2014 21:20:36 (93%)]

Als het beetje goed is aangepakt is de data(firmware en andere data) die verstuurd word versleuteld en word door de bootloader omgezet, ben daar toevallig gisteren mee begonnen om bootloader te schrijven voor xmega die dat kan. Zodat ik mijn nieuwe firmware kan verspreiden voor updates met minder risico dat iedereen zomaar mijn project kan kapen.

Arco bedoeld denk ik een logic analyzer ertussen hangen om de data op te vangen die verstuurd word of het signaal te analyseren zodat je het na kan bootsen in je eigen software. Want denk niet dat kraken van software hier bespreken helemaal de bedoeling is omdat het (mogelijk, niet na te gaan voor ons) illegaal is.

Zelf programma maken die het signaal nabootst mag volgens mijn wel, en daar zullen mensen denk ik ook meer bereid zijn om te helpen.

Edit/
Zoiets
http://www.saleae.com/logic/

Kan je overigens ook redelijk simpel maken met aanvaardbare snelheden voor meeste communicatie protocols met simpel pic of avr en open analyser software.
http://www.ikalogic.com/scanalogic_home.php

Interessant dat UV erasen van de fuses. Zou je dat als chipmaker niet makkelijk kunnen omzeilen door enkele metaallagen te leggen boven de fuse mosfet zodat de gate niet zichtbaar is? Dan moet je die ook nog selectief kunnen wegetsen.

Of gaat een felle UV lamp daar gewoon door?

Op 13 januari 2012 14:33:50 schreef peter79:
Als het beetje goed is aangepakt is de data(firmware en andere data) die verstuurd word versleuteld en word door de bootloader omgezet, ben daar toevallig gisteren mee begonnen om bootloader te schrijven voor xmega die dat kan. Zodat ik mijn nieuwe firmware kan verspreiden voor updates met minder risico dat iedereen zomaar mijn project kan kapen.

Arco bedoeld denk ik een logic analyzer ertussen hangen om de data op te vangen die verstuurd word of het signaal te analyseren zodat je het na kan bootsen in je eigen software. Want denk niet dat kraken van software hier bespreken helemaal de bedoeling is omdat het (mogelijk, niet na te gaan voor ons) illegaal is.

Zelf programma maken die het signaal nabootst mag volgens mijn wel, en daar zullen mensen denk ik ook meer bereid zijn om te helpen.

Edit/
Zoiets
http://www.saleae.com/logic/

Kan je overigens ook redelijk simpel maken met aanvaardbare snelheden voor meeste communicatie protocols met simpel pic of avr en open analyser software.
http://www.ikalogic.com/scanalogic_home.php

Waarom zou reverse engineering illegaal zijn? Zolang het bedoelt is om er iets van te leren kan ik er geen moeite mee hebben.

Aangezien je de controller steeds opnieuw kunt flashen, maar de controller daarna copy-protected is, zou het wellicht de moeite zijn om uit te zoeken welk deel in de verstuurde data de juiste fuses zet en dat te manipuleren.

Software kraken of kopiëren is illegaal als je daarvoor geen rechten heb van de maker en er rechten berusten op de software, ik kan niet controleren dat dat hier nu niet het geval is. Misschien wilt die wel ipod(zomaar voorbeeld) kraken om software te kopiëren, dus werkt ik daar niet aan mee. zit niet voor niks beveiliging op, anders was het wel open geweest als de maker het niet erg zou vinden dat andere het gebruiken of kopiëren lijkt me.

Reverse engineering is niet illegaal, en aan de hardware mag je zover ik weet ook alles aanpassen, software is andere verhaal en mag het niet altijd en kan dat dus niet controleren dus werk ik er niet aan mee. Als je wel meewerkt heb je zelfs kans dat jij dus aan helpen ben om iets illegaals te doen of te bereiken.

Update zegt niks, kan versleuteld zijn, werkt dus aan zo zelfde project en zijn tal van bootloaders in omloop al dan niet betaald, waarmee je micro controllers kan update met versleutelde firmware.

Edit/
En voor eigen gebruik heb ik er ook niet zo moeite mee, maar ook dat kan ik niet controleren, wellicht wilt die iets kopiëren en gaan verkopen. Om dat ik dat niet kan bepalen is de enige oplossing helemaal niet meewerken aan kraken van chips om de firmware eruit te halen. Klinkt misschien kinderachtig maar zou het zelf ook niet leuk vinden als het bij mij zouden doen, is me al eerder overkomen dat mensen gewoon je project te koop gaan aanbieden waar jij dan alle tijd in heb gestoken en kopiëren het dan zonder blikken of blozen.

[Bericht gewijzigd door Henry S. op vrijdag 13 januari 2012 19:51:11 (13%)]

is niet illegaal!!!
voor eigen gebruik mag je alles copieren en nabouwen maar zodra je het op de markt gaat brengen (ook niet als onderdeel van een totaal ander product!!!) of verspreiden naar anderen ben je wel illegaal bezig.

de gewonnen bestanden online zetten op bijvoorbeeld co is dus wel verboden, want dan ben je aan het verspreiden.

maar hulp vragen mag natuurlijk wel

Misschien wilt die wel ipod(zomaar voorbeeld) kraken om software te kopiëren

dat mag gewoon zolang je ze niet verspeidt naar anderen.
je mag ook dvd's copieren als reserve enz.
en dit mag dus ook het is alleen een ander medium en heeft een andere functie

maar voor eigen gebruik mag je copieren, nabouwen, hacken, ect net wat je wilt.

In de EU is "reverse engineering" expliciet toegestaan, MITS met het doel om iets compatibel te maken.

Diverse fabrikanten vinden dat natuurlijk niks en blijven tegen de wet in roepen in EULA's en zo dat het niet mag. Hopelijk houden sommige potentiële reverse engineering mensen zich daar dan aan. Of gaan luid op het internet verkondigen dat het illegaal is.

hoe wil je het kontroleren of iemand een van jouw producten heeft omgebouwd??

(tenzij die sukkel natuurlijk zo stom is geweest om het op internet te zetten

Op 13 januari 2012 15:10:18 schreef Uranium:
Interessant dat UV erasen van de fuses. Zou je dat als chipmaker niet makkelijk kunnen omzeilen door enkele metaallagen te leggen boven de fuse mosfet zodat de gate niet zichtbaar is? Dan moet je die ook nog selectief kunnen wegetsen.

Of gaat een felle UV lamp daar gewoon door?

een lamp niet, een laser wel ... en met een fib is het al helemaal geen probleem meer.
het enige wat doeltreffend werkt is er silicium bovenop groeien. dat in combinatie met een lockbit die eendert waar kan zitten is haast ondoenbaar. er zijn processors die de lockbit ergens random in de flash hebben. een pointertabel haalt bij powerup een aantal locaties op en doet daar een operatie op. het resultaat is een 32 of 48 bit sleutel. elke 6 bytes die gelezen wordt uit de flash moet ge-exord worden . het resultaat daarvan is uitvoerbare code. de decryptie van een instructie wordt gedaan vlak voor uitvoer. de gedecrypteerde code is dus nooit ergens aanwezig behalve op byte per byte basis in de instruction decoder. de drypto is hardware, de cpu merkt daar niks van.
om dat te kraken moet je chip openen , de tabel lezen, de data ophalen, de crypto code emuleren om de sleutel te vinden en dan gans het memory exoren.... de kans dat je alle bytes kan recupereren uit zo een gestripte chip is nul. je moet het silicium afvreten , metal strippen en met een ebeam de flash afstappen... die is al lang corrupt tegen dan.

als bijkomende protectie kunnen ze dan nog eens de pointertabel in ee nram plaatsen met een microbatterij. chip open is ram lleeg.. weg pointertabel...

de dallas ds5000 secure cpu werkt zo. is een 8051 door een uitgekiende mechanische opbouw , een extra metalen boven en onderplaat , een slimme chip layout, batterij en keramische behuizing is die niet te kraken. tegen dat je aan de naakte die bent en je kan beginnen strippen is de pointertabel al verloren... het enige wat je nog kan is brute force maar je moet random een aantal rom adressen lezen, daar een calculatie mee doen de jou onbekend is om het startadres te weten en dan de ganse rom decrypteren terwijl je hem uitvoert...

er gebeurt nog iets in de uitvoer ook geloof ik. die 48 bit sleutel is slechts de start. dallas heeft een appnote waarin ze uitleggen hoe het werkt. zo zeker zijn ze van dat ding.
de crypto gebeurt tydens het flashen. elke chip heeft een unieke code vanuit de fabriek, ook die zit mee in de encyptie. dus twee chips met een identiek programma bevatten fysiek compleet andere data in de rom. de chip encrypteert zichzelf tydens het programmeren. dus ja kan ook niet van 2 , een maken...

"niet te kraken" is een heel gevaarlijke uitspraak!

Om te beginnen is het hele flash XOR'ren met dezelfde sleutel kinderspel om te kraken, daar heb je geen ingewikkelde cryptanalysis voor nodig. Sommige instructies komen veel vaker voor dan anderen, net als de letters van ons alfabet in normale tekst. Daarbij zijn er altijd ongebruikte instructienummers, die de processor niet kent, of instructies die een bepaalde compiler niet gebruikt. De sleutel vinden is dan weinig meer dan bitpatronen turven, en kijken welke combinaties veel of juist weinig voorkomen.

Daar komt natuurlijk nog bij dat 48 bits prima te brute-forcen is, en aangezien compilers vaak bepaalde patronen van instructies gebruiken, en het relatief eenvoudig is om automatisch te beoordelen of een bepaalde serie instructies mogelijk functionele code zou kunnen zijn, is zo'n brute-force zeker haalbaar, als je er genoeg moeite en processorcapaciteit in wilt steken.

Nog een ander alternatief is om een stukje (al dan niet gebruikt) flash door de controller te laten overschrijven met data die door de aanvaller gekozen wordt, om het flash vervolgens uit te lezen. Als het algoritme niet deugt, of de sleutel erg kort is, is het ook mogelijk om de sleutel te achterhalen. Dit is een zogenaamde "chosen plaintext" aanval.

Het is vaak een veel beter idee om de controller zo te ontwerpen dat je de code er simpelweg niet uit krijgt, ook niet in gecodeerde vorm. Als de ontwerper wat meer silicium wil gebruiken voor de crypto engine, is het ook wel mogelijk om een fatsoenlijk algoritme en een sleutel van voldoende lengte te gebruiken, zodat een brute-force, cryptanalysis, of chosen plaintext aanval niet haalbaar is.

Ik meen me te herinneren dat er iets mis was met de beveiliging van de PIC, waardoor het uitlezen mogelijk zou zijn. Het was iets ontzettend stoms, waarbij de fusebits als eerste gewist werden bij een chip erase, of de fusebits wel en het flash niet als de spanning te laag was, of de temperatuur te hoog of te laag of zoiets.

Ik ben het toch wel een beetje met Peter79 eens; in principe is het niet verboden om iets te reverse-engineeren om iets compatible te kunnen maken, of om er zelf van te leren, zolang je de code niet publiceert of gebruikt in een product dat je verkoopt of zo. Ik geloof dat er ook wel iets was geregeld voor de situaties waarin de originele producent failliet is, of het product uit de productie heeft genomen, maar dat weet ik niet zeker.

@TS: wat zit er in de controller, en waarom vind je het zo interessant om de code te kunnen inzien? Kun je er wel iets mee als je de code eenmaal hebt? Het is dan nog steeds machinecode die je kunt omzetten naar ASM, maar verwacht niet dat je er C code compleet met functie- en variabele namen en commentaar uit krijgt.

Bij reverse engineeren van software op een MCU moet je niet meteen aan commerciele fraude denken.

Ik heb een cheapo LiPo batterijlader uit china en de dat afstelling van de balancer is niet zo goed (plus en min 0.1V afwijking). Nu heeft die software normaal een menu waar je zelf mee kunt calibreren, maar dat kan slechts 1 keer. Ik had 2$ meer betaald voor een af fabriek gecalibreerde versie, ik heb het nagemeten en dat is goed gedaan. Helaas verlopen de waarden in de spanningsdeler heel sterk in waarde als de lader opwarmt. De calibratie is dan niet meer goed, en gezien hij voornamelijk moet balancen als hij al een tijdje heeft geladen, tja...

Denk ik bummer en vervang de weerstanden door 0.1% exemplaren. Nu zou ik natuurlijk opnieuw moeten calibreren, maar dat menu is al gebruikt. De CPU is gelockt dus de firmware uitlezen gaat niet. Nu heb ik gelukkig op een chinese filehost de firmware.hex gevonden van een clone van deze clone lader. Die aangepast dat het calibratie menu toegangkelijk blijft en nu is het in orde.

Het kan dus ook puur voor eigen gebruik zijn. Hoewel als je bereid bent om behoorlijk veel tijd kostende invasieve dingen te doen je wss wel op winst uit bent.

Op 13 januari 2012 16:44:23 schreef roel999:
is niet illegaal!!!
voor eigen gebruik mag je alles copieren en nabouwen maar zodra je het op de markt gaat brengen (ook niet als onderdeel van een totaal ander product!!!) of verspreiden naar anderen ben je wel illegaal bezig.

Voor eigen gebruik mag je ook niet zomaar altijd software kraken, hangt geheel af van de overeenkomsten. Kan me iets herinneren dat bepaalde software pakketten helemaal niet je eigendom worden maar je recht heb om het te gebruiken. Maar weet niet of dat in Nederland ook zo is.

Maar geen haan die er naar kraait natuurlijk als je dat binnenshuis doet.

Edit/
@SparkyGSX
XOR versleuteling is wel de simpelste manier, beetje goede bootloader doet 128bits-encryptie.

Op 13 januari 2012 18:41:21 schreef SparkyGSX:
"niet te kraken" is een heel gevaarlijke uitspraak!

en daar heb je gelijk in. het probleem bij die dallas chip is dat de boel weg is op het moment dat je het ding opengepulk gekregen hebt. niet alleen de sleutel is weg , het decrypter algoritme en het programma zelf is ook weg ...
Zelfs als je hem afprobed zal je overal alleen maar FF lezen.

de 8051 core is zodanig gemodificeerd dat hij alleen code kan runnen vanuit zijn on chip ram. en wat daar in ligt opgeslagen is geencrypteerd via een sleutel die gebaseerd is op een uniek serienummer dat vanuit de fabriek is gezet en een random nummer wat door de flashing software wordt geladen. je stuurt de ongecrypteerde hex file naar de cpu , die verlseutelt hem on board en slaat het versleutelde resultaat op in die battery backed ram , samen met de cryptokey. de code wordt on the fly gedecrypteerd terwijl de cpu runt.

open je de verpakking , dompel je hem onder in zuur , ets je hem , open , boor je een gat en probeer je backside probing : ram leeg . weg programma.

het ding heeft ook actieve defensie. probeer je hem extern to 'overloaden' via spanningspulsjes of iets dergelijks dan pleegt het ding zelfmoord door het codeblok vol te schieten met random garbage.

ze doon ook random address layout. gebaseerd op de crypto sleutel gaan ze de addressering van de code remappen. reset is dus niet address nul , maar het resultaat van een logische operatie met de sleutel. elke address is dus pseudo randomized. en die randomizaten is uniek per cpu ( hangt weer af van zijn serienummer ). ze noemen dat vector ram. het is een translatietabel die zegt : als de cpu instructe van 0x321 nodig heeft dan staat die eigenlijk op 0x021.

dus zoeken naar patterns is ook uitgesloten. de boel ligt compleet door elkaar.

http://para.maxim-ic.com/en/search.mvp?fam=micros&1233=Secure&…

http://www.keil.com/dd/docs/datashts/dallas/secure_ug.pdf

Het ding is heel secure.

Of de software echt je eigendom is of niet, is niet eens relevant. Zolang je het voor jezelf doet en niet publiceert, mag bijna alles.

Nu claimen veel bedrijven de meest idiote dingen in hun licentie overeenkomsten, maar een groot deel daarvan is niet rechtsgeldig. Je kunt een handtekening onder een contract zetten (en een "ik ga akkoord" is niet bepaald een handtekening), maar dat wil nog niet zeggen dat het rechtsgeldig is. De redenatie is heel logisch; ook als het niet rechtsgeldig is, kun je het altijd proberen. Nu is dat eigenlijk ook niet zo relevant want als een willekeurig groot bedrijf het op je voorzien heeft, want zo'n rechtszaak kun je niet winnen, of je in je recht staat of niet. Dat is het verschil tussen gelijk hebben en gelijk krijgen.

NXP vond ongetwijfeld ook dat het reverse-engineeren van de OV-chipkaart en het publiceren van de resultaten niet mocht, maar gelukkig vond de Nederlandse rechter toch iets anders.

EDIT @FE: er zijn ongetwijfeld controllers die heel moeilijk te kraken zijn, maar vaak zit er wel ergens een subtiel foutje waardoor het toch mogelijk is. De geschiedenis leert dat dergelijke dingen altijd gekraakt kunnen worden, als iemand maar graag genoeg wil. Ooit werd gedacht dat de Caesar Cipher veilig was.

De onderzoekers die de OV-chipkaart uiteindelijk gekraakt hebben, waren (geloof ik) ook niet bepaald een team professionals met een enorm budget en onbeperkte tijd. Als ik me goed herinner, was het min of meer een paar studenten die na een paar biertjes teveel hadden besloten dat dat wel een leuk projectje was voor in de avonduren. Niet om ze te denigreren natuurlijk, de prestatie is des te meer bewonderenswaardig.

[Bericht gewijzigd door SparkyGSX op vrijdag 13 januari 2012 19:15:04 (28%)]

Op 13 januari 2012 17:08:14 schreef free_electron:
[...] de dallas ds5000 secure cpu werkt zo. is een 8051 door een uitgekiende mechanische opbouw , een extra metalen boven en onderplaat , een slimme chip layout, batterij en keramische behuizing is die niet te kraken. tegen dat je aan de naakte die bent en je kan beginnen strippen is de pointertabel al verloren... het enige wat je nog kan is brute force maar je moet random een aantal rom adressen lezen, daar een calculatie mee doen de jou onbekend is om het startadres te weten en dan de ganse rom decrypteren terwijl je hem uitvoert...

Anderson en Kuhn hebben dat ding 15 jaar geleden al gekraakt:
http://www.cl.cam.ac.uk/~mgk25/tamper.pdf

- Rob.

Free, jij hebt duidelijk de docu van Dallas gelezen. 't ziet er naar uit dat dat ding heel redelijk beveiligd is.

Maar ga nu eens 10 jaar (of zo) terug in de tijd en lees de docu van Microchip over de PIC: Met geen mogelijkheid is het programma er uit te krijgen. Wel kan je een "erase chip" sturen en het programma en de fusebits wissen....

Tja. 10 jaar later weten we dus dat als je de power precies XX ms na het sturen van het "wis chip" commando er af haalt, je dan wel de fusebits en niet de flash gewist hebt.... Foutje bedankt!

En STEL dat Dallas gelijk heeft. Mogelijk heeft de fabrikant er een "update firmware" ingestopt. MOgelijk kan je dan een "decodeer flash en stuur serieel naar buiten" programma er in stoppen.

Dat chipje van Dallas lijkt alle tot nu toe succesvolle attacks te weerleggen, volgens de marketing praat. Maar wie zegt dat dat klopt?

Whatsapp zat deze week een bugje in. Je kon zomaar andermans status veranderen. Dus had de ontdekker van de bug ze gewaarschuwd. Demo gepubliceerd (website) en voila! 3 dagen later: Ja hoor, echt we hebben de bug gefixed.

Wat blijkt. Ze beschouwen: "je kan op die website andermans status veranderen" als de bug. En dat hebben ze gefixed door in de firewall het IP adres van die demo-website te blokkeren.

Toch komen ze naar buiten met de marketing praat: "we hebben het gefixed, u bent weer veilig".

Je moet heel erg uitkijken met wat voor marketing praat je echt gelooft.

Nu zou het me niet verbazen als dat dallas chipje van jou het 10 of 20 jaar volhoudt of nog langer voordat ze die kraken. Maar het zou me ook niet verbazen dat ie over een paar jaar al gekraakt is. [edit, net dat artikel gelezen. Ik was dus nog een 16 jaar te optimistisch met "over een jaar al" ]

En als dat ding rustig in high-end scopes ingebouwd zit, zal geen student zich er druk over maken. Zodra ie in een PS4 wordt ingebouwd en ze ineens geen Linux meer kunnen draaien heb je de poppen aan het dansen....

Bedenk ook dat in veel gevallen een class-break mogelijk is; als iemand ooit een chip van een bepaald type gekraakt heeft, en de methode publiceert, is het meestal voor anderen relatief eenvoudig om een exemplaar met andere code te kraken, omdat het grootste deel van het werk al gedaan is. Het enige dat nodig is, is persoon of groep met voldoende motivatie (en in beperktere mate, budget en apparatuur) om het ding de eerste keer te kraken.

Uiteindelijk kun je niet voorkomen dat degene die de controller wil kraken, een of meerdere werkende exemplaren in handen krijgt. Als de controller de code uit kan voeren, kan de code er ook uit gehaald worden. Het kraken van de encryptie van DVD, HD-DVD en BlueRay zijn daar mooie voorbeelden van; een bedrijf wil de schijfjes verkopen, zodanig dat de consument ze af kan spelen (anders kun je ze natuurlijk niet verkopen), maar ze niet kan kopiëren. In mindere mate geldt hetzelfde voor producten met microcontrollers; als een kwaadwillende gebruiker ze in handen krijgt, en er alles mee kunnen doen wat ze willen, is de code niet veilig. De fabrikant kan het alleen moeilijk maken om er bij te komen, maar zeker niet onmogelijk.

De HD-DVD en BlueRay zijn ook een mooi voorbeeld van een class-break; toen de bovenste sleutel eenmaal uitgelekt was, was er al heen snel software waarmee iedere digibeet zo'n schijf kon kopiëren. De motivatie om het te kraken, was in dat geval de afwezigheid van software om de schijven af te spelen in Linux e.d.

Bedankt voor alle reacties. Ik zal uitleggen waarom en wat ik wil doen.

Ik ben werkzaam voor Fujitsu waarbij wij USB sticks hebben gekregen met een lock erop. Als deze wordt gekraakt dan wordt er een update gedaan en krijg je een presentje.

Ik ben al aardig ver, maar ik heb een 16 character hex nodig die op de PIC te vinden is.

De PIC is protected, maar dat is het enige wat ik mog nodig heb. Er wordt gebruik gemaakt van SHA 256 bit, maar dat is een ander verhaal

Gezien de controlller bij het locken met een nieuwe code opnieuw gestuurd wordt vroeg ik me af of dit op te vangen is om zo de code uit te lezen. Ik weet niet of het voor mij te doen is om met salpeterzuur te gaan werekn gezien ik een IT'er ben en geen chemist

[Bericht gewijzigd door Jeroen op dinsdag 9 september 2014 21:21:31 (98%)]

Je kunt natuurlijk proberen hoe ver je kunt komen met een logic analyser, maar ik zie nog een andere mogelijkheid.

Je zegt dat hij steeds een nieuwe code krijgt, en die code zal in software gegenereerd moeten worden, lijkt me. Dan lijkt het me dus voor de hand liggen om die software aan te vallen, door die in een debugger te draaien en daar de code uit te halen.

Er zijn debuggers die "terug in de tijd" kunnen; ze houden een volledige log bij van alle processor registers e.d. tijdens het uitvoeren, waardoor je deze in omgekeerde volgorde kunt bekijken. Je begint dat met de code die uiteindelijk uitgestuurd wordt, en kunt dan herleiden hoe die tot stand is gekomen.

Die PIC heeft, als ik het goed zie, geen USB periferal aan boord. Hoe wordt de code erin geladen? Via de UART met een FT232 o.i.d.?

Je kunt dan ook softwarematig de USB communicatie afluisteren, het ding een paar keer opnieuw laten locken, en uitzoeken welk stuk van de communicatie veranderd. Daar zou dan de code in moeten staan, mogelijk gewoon leesbaar, of op een of andere manier versleuteld.

Weet je wat er met die code gebeurd? Als die code een sleutel is voor een encryptie algoritme, en de PIC de codering/decodering uitvoert, kun je ook proberen of je iets kunt leren door de ciphertext en plaintext naast elkaar te leggen, of de PIC een bekende plaintext of ciphertext te laten bewerken.

16 karakters is hex is maar 64 bits, dat is niet echt veel voor een sleutel. Als het algoritme bekend is, zou een brute-force haalbaar kunnen zijn. Misschien zou je zelfs nog wel een bruikbare rainbow table kunnen vinden. Het lastige is dat een echte brute-force, waarbij je gemiddeld 50% van de keyspace, en mogelijk (bijna) de hele keyspace moet doorzoeken, op een dergelijke sleutel nog steeds lang duurt als je geen flinke hoeveelheid processorcapaciteit beschikbaar hebt.

Als die PIC de encryptie en decryptie moet doen, en nog een redelijke datarate moet halen voor het lezen en schrijven van de memory stick, is het mogelijk dat het algoritme niet al te sterk is. Een datarate van een paar megabyte wil je toch wel kunnen halen, en dat betekend dat je maar een paar processorcycles per byte beschikbaar hebt om het algoritme uit te kunnen voeren.

SparkyGSX: Bedankt voor het antwoorden. De code verandert niet. Heb ik verkeerd verwoord. Excuses daarvoor. Ik bedoel dat je een code opnieuw kan invoeren met 5 toetsen op de stick zelf. Zo zou je code 0000 kunnen gebruiken als je de PIC zou kunnen uitlezen en daarna code 0001 gebruiken en kijken of ik een patroon zie (of misschien wel platte text).

De encryptie wordt gedaan met de rijndael algoritme (AES). De NAND kan ik uitlezen, maar is dus encrypted. Ik heb een programma in C# geschreven die de dump van de NAND kan decrypten als ik de sleutel heb.

Ik moet dus alleen de sleutel hebben die in de PIC wordt weggeschreven.

Ik vermoed dat wanneer je de code invoert en op lock drukt de data in de NAND wordt ge-encrypt en de code wordt dan in de PIC weggeschreven. Doorte unlocken wordt de code gebruikt uit de PIC en de data in de NAND wordt ge-decrypt.

[Bericht gewijzigd door Jeroen op dinsdag 9 september 2014 21:21:56 (99%)]

Begrijp ik het goed dat de code maar 4 cijfers lang is, waarbij elk cijfer een waarde 0-4 kan hebben? Dat zijn maar 625 mogelijke combinaties. Aangenomen dat het bestandssysteem bekend is, kun je vrij eenvoudig detecteren of je een geldige header of FAT tabel (of equivalent in een ander bestandssysteem) hebt.

Als dat klopt, zal de PIC dus uit die pincode een sleutel moeten genereren. Tenzij er nog iets van random data wordt gebruikt, zijn er dan ook maar 625 mogelijke sleutels. Als je op de een of andere manier kunt achterhalen hoe de sleutel gegenereerd wordt, wordt brute-force misschien wel heel eenvoudig.

Aangezien er blijkbaar maar een klein aantal mogelijke sleutels is, en voorspelbare plaintext (vanwege het bestandssysteem), zou je kunnen proberen handmatig alle mogelijke sleutels een keer in te voeren, en de gecodeerde file system header uit te lezen. Als het goed is, zou je later die header kunnen uitlezen, en die gecodeerde data zou in de lijst van 625 opgeslagen mogelijkheden moeten voorkomen. Je weet dan welke pincode daarbij hoort.

Ik zou eerst proberen of je dezelfde ciphertext krijgt als je twee keer dezelfde pincode invoert; je kunt dan vaststellen of algoritme waarmee de sleutel wordt gegenereerd deterministisch is, of dat er op de een of andere manier (pseudo)random data in wordt gemengd.

Wordt het ding na een bepaald aantal pogingen vergrendeld, of kun je eindeloos codes proberen? Met 625 mogelijkheden is een handmatige brute-force wel te doen, lijkt me, en dan heb je geen bijzondere tools nodig. Het lijkt me een erg onveilige memorystick als dat zo is, dus dat kan ik me niet voorstellen.

Het ligt natuurlijk voor de hand dat er iets aan pseudo-random data wordt toegevoegd, anders zouden ze de sleutel niet op hoeven te slaan; hij zou dan gewoon opnieuw gegenereerd kunnen worden. Het is natuurlijk ook mogelijk dat de pincode helemaal niets met de sleutel te maken heeft, en dat deze met random data gegenereerd wordt, en de pincode alleen wordt vergeleken met de opgeslagen pincode.

Het ligt voor de hand dat de sleutel en/of de pincode in de EEPROM van de PIC wordt opgeslagen; als je daar op de een of andere manier bij kunt komen, ben je natuurlijk klaar. Als je de EEPROM kunt lezen, is het waarschijnlijk vrij simpel. Als je in de EEPROM zou kunnen schrijven, en de pincode alleen vergeleken wordt met een opgeslagen code, zou je die kunnen overschrijven, als je er achter kunt komen waar die code precies staat.

EDIT: als de hele NAND opnieuw wordt gecodeerd wanneer je een nieuwe code invoert, moet deze helemaal gelezen en opnieuw geschreven worden. Dit zou toch wel enige tijd duren, lijkt me, en in die tijd moet er een enorme hoeveelheid data heen en weer tussen de PIC en de NAND chip. Het zou natuurlijk ook kunnen dat de sleutel nooit veranderd, en alleen de nieuwe pincode wordt opgeslagen in de PIC.

EDIT2: Ik heb net een stukje in PIC12F6XX/16F6XX Memory Program-
ming Specification DS41204 zitten lezen, en het lijkt erop dat EEPROM en SRAM een lockbit delen, het CPD bit. Dit lag natuurlijk voor de hand. Het lijkt me dus onwaarschijnlijk dat je iets zinnigs uit die PIC krijgt, tenzij je op de een of andere manier aan de hex file kunt komen die er in zit; als dat wel het geval is, zou je natuurlijk een onbeschermde PIC kunnen programmeren, en de EEPROM en RAM bekijken met een debugger. Ik neem aan dat zo'n hex file buiten bereik is.

Het AES algoritme wordt uitgevoerd door de controller van de USB stick. De PIC laadt slechts bij ingave van de juiste code de sleutel hierin. Ik zou beginnen om die bus te sniffen met een goedkope LA. Dan kun je zien of er steeds dezelfde sleutel wordt verzonden. Dan de pincode veranderen en zien of de PIC wat anders stuurt.

Als het hetzelfde blijkt te zijn zul je idd de PIC op een of andere manier moeten kraken.

De sleutel zal steeds hetzelfde moeten zijn, anders is de data natuurlijk niet te lezen. Of de communicatie tussen de PIC en de USB controller van de stick steeds hetzelfde is, is natuurlijk afhankelijk van de manier waarop de sleutel wordt overgedragen. Mogelijk wordt deze plain-text verstuurt (wat op zich niet onveilig is; de juist pincode is immers ingegeven, dus de data mag gelezen worden), of via een of ander key exchange algoritme (Diffie-Hellman of zo).

Linksom of rechtsom lijkt het me noodzakelijk om de PIC te kraken; de hele uitdaging komt daarop neer. Met de juiste sleutel zou de rest van de hardware gewoon moeten werken, en zonder die sleutel kom je er niet, aangenomen dat je de AES encryptie zelf niet kunt kraken, en dat lijkt me een bijzonder veilige aanname.

Werkt zo'n memory stick alleen op een PC waarop de rest van de software geïnstalleerd is? In principe maakt dat natuurlijk niet zoveel uit, als je de ruwe data in de NAND chip kunt dumpen, en de sleutel hebt, is de rest niet zo moeilijk meer.

Het lijkt me in ieder geval handig te voorkomen dat de PIC of USB controller nog in de NAND flash kan schrijven, zodat de data op die manier in ieder geval niet gewist kan worden. Als je eerst de NAND flash wist, maakt dat natuurlijk niet echt meer uit.

De enige echte optie die ik zie voor de PIC om toegang tot de data te voorkomen, wanneer de ingestelde tijd verstreken is, of het maximale aantal pogingen voor het ingeven van de code is bereikt, is het wissen van de sleutel.

Draait die PIC op de interne clock, of heeft hij een externe clock source? Afhankelijk van de correctheid van de ingegeven code zal hij een ander executie pad uitvoeren, lijkt me; in het ene geval zal de poging tot het invoeren van de code opgeslagen worden, en eventueel de sleutel gewist, en in het andere geval zal hij de sleutel lezen en versturen naar de USB controller.

Als je in een vroeg stadium kunt vaststellen welk pad hij gekozen heeft, zou je in het geval van een verkeerde code de PIC kunnen resetten, waarbij je eventueel direct de clock stopt. Dit is een waarschijnlijk een stuk gemakkelijker als je bij de clock source van de PIC kunt, maar in het ergste geval zou je die interne clock kunnen meten door de rimpel in de opgenomen stroom te meten. Afhankelijk van de clock frequentie kan dat zo simpel zijn als een shunt met een high-speed comparator. Bij het wissen en schrijven van de EEPROM trekt die PIC significant meer stroom dan bij het uitvoeren van andere instructies, geloof ik, dus dat zou je ook nog wel vast kunnen stellen, maar als je daar op wilt reageren ben je waarschijnlijk al te laat.

Hiermee wil ik dus aangeven dat je niet perse de hele PIC hoeft te kraken; als je een succesvolle aanval tegen deze specifieke software implementatie kunt uitvoeren, is dat voldoende.

Is er nog een visuele indicatie dat de ingevoerde code juist of onjuist is? Misschien hebben ze de fout gemaakt eerst een LED aan te zetten, en daarna pas in de EEPROM te gaan schrijven. In dat geval kan het voorkomen van die schrijfactie zo simpel zijn als een weerstand opnemen in serie met de voeding van de PIC, en de LED kortsluiten, zodat hij zijn eigen voeding onderuit trekt.