PIC Uitlezen Code Protection

franzki,

er zijn meerdere fouten te bedenken:

- de RNG heeft een flaw, hierdoor zijn er te weinig bits werkelijk random
- de PIC bevat een beperkte set keys en kiest er steeds een. de hele set achterhalen is een kwestie van tijd
- de key is gebaseerd op een getallenreeks. als je een stick vind kun je na een reset de vorige key uit die reeks bepalen.

het zou een enorm leuke uitdaging zijn om 10 of 25 keys te hebben. misschien zit er een patroon in, en kunnen we dat ontdekken. echte RNG is lastig, en de reset lijkt wel op orde te zijn.

de brute force optie is ook mogelijk, gewoon alle PIN codes proberen. kost je een dag, als je de PIC steeds spanningsloos maakt.

zie ik minder als een uitdaging, maar dat kan hij ook zeker proberen.

verder heb je nog de optie om de Key uit de PIC te halen. lijkt me niet zinnig. het is misschien mogelijk, maar een eenmalige actie, (PIC herprogrammeren en EEPROM dumpen,of decappen). als je die key hebt, moet je hem vervolgens wel zelf in de skymedi controller krijgen. dus moet je het protocol hebben...

Lemmings, ik zie 6 keys:
a="Sleutel"
b="0|1"
c="2|3"
d="4|5"
e="6|7"
f="8|9"

hoe toets je de de PIN 2345 in? C+C+D+D? of C + CC + D + DD??
kun je dat eens uitschrijven? hoeveel keer drukken is PIN 1111?

Even snel twee foto's tussendoor :)
Ik ga nu meten.

http://s27.postimg.org/6cxuvsf37/IMG_0816.jpg
http://s13.postimg.org/6q9f8xm47/IMG_0820.jpg

"hoe toets je de de PIN 2345 in? C+C+D+D? of C + CC + D + DD??
kun je dat eens uitschrijven? hoeveel keer drukken is PIN 1111?"

2345 wordt C+C+D+D
1111 is 4x "B" drukken.

[Bericht gewijzigd door Lemmings op (38%)]

Op 11 september 2014 17:26:22 schreef Lemmings:
[...]
De data is geheel anders. Na de full format zijn alleen de eerste 512 bytes (de MBR dus) gevuld met waardes en de rest zijn 0-en. Ook wanneer ik een dump terugplaats zodat ik zeker weet dat de data op de NAND gelijk is blijft de data verschillen. Het lijkt erop dat de AES key elke keer wordt gegenereerd.

Dat is een mogelijkheid, maar anderzijds kan er ook een algoritme in de controller zitten die voor "data spreading" zorgt, om zodoende voor een gelijkmatige 'slijtage' van de cellen in de NAND door schrijfacties te zorgen.

Ik heb even gemeten welke "buttons" er zijn aangesloten op de PIC:

De UFD heeft 5 buttons. Van boven naar onderen:

KEY is aangesloten op PIC 2 (RA5/T1CKI/OSC1/CLKIN)
0/1 is aangesloten op PIC 13 (RA0/AN0/C1IN+/ICSPDAT/ULPWU)
2/3 is aangesloten op PIC 12 (RA1/AN1/C1IN-/VREF/ICSPCLK)
4/5 is aangesloten op PIC 11 (RA2/AN2/T0CKI/INT/C1OUT)
6/7 is aangesloten op PIC 13 (RA0/AN0/C1IN+/ICSPDAT/ULPWU)
8/9 is aangesloten op PIC 3 (RA4/AN3/T1G/OSC2/CLKOUT)

Edit: rew thanks! Post aangepast.

Enig idee waarom beide, 0/1 en 6/7, is aangesloten op dezelfde PIN? Heb het nog eens gemeten, maar klopt wel. Wat me ook opvalt is dat button 6/7 niet is aangesloten op GND.

[Bericht gewijzigd door Lemmings op (15%)]

De pins van microcontrollers hebben vaak meerdere functies. Dus naast RA0 kan die pin misschien ook "SCL" doen als de I2C module actief is.

Idem kan je twee pins gebruiken om een kristal op aan te sluiten. In die functie heten die pins "CLKIN" en "CLKOUT", maar dat wordt in de huidige toepassing niet gebruikt. Je kan ze in dit geval dus beter bij hun andere naam noemen.

[off topic]
Hebben jullie gezien op welke USB-sticks de miljoenennota is uitgedeeld aan de kamerleden? Dat was net op het 8 uur journaal.

Even doorwerken... dan hebben we een primeur. ;-)

Edit: LOL

http://nos.nl/artikel/697486-uit-de-schaduw-van-de-crisis.html

De stukken staan op usb-sticks, die zo zijn beveiligd dat printen of downloaden niet kan. Het aantal ubs-sticks verschilt per fractie. De grootste fracties, VVD en PvdA, hebben er beide vijf gekregen.

[Bericht gewijzigd door Henry S. op (35%)]

kijk, dat is interessant!

dus jij bedoelt dat PIN 0000 hetzelfde is als 1111?

dat zou betekenen dat de hoeveelheid Pins nog maar de helft is.

laten we de toetesen even aangeven met letters:

a="Sleutel"
b="0|1"
c="2|3"
d="4|5"
e="6|7"
f="8|9"

ik vind het raar dat ze 2 toetsen op een pin hebben aangesloten. je kan met een matrix wel 1 of 2 pinnen besparen, maar dan zouden er meer pinnen aan elkaar hangen.

probeer dit eens: pin 1234 zou je dus kunnen toetsen als bbcc, maar ook als becc of ebcc.

als dit echt zo is heb je dus maar 4 toetsen in plaats van 10, en is het aantal mogelijke PINs gigantisch veel lager dan we eerst dachten.

helaas zie ik dat je bij 20x verkeerde PIN de key alsnog kwijt bent. daar zal je iets op moeten vinden, maar dat komt wel.

even terug naar de pins, kun je ook de leds opmeten? zoals het er nu voor staat hebben we RC0..5 nog niet bekend. RA3/MCLR is ook niet bekend, maar ik gok dat die nog als reset werkt.

kun je dat eventueel testen door halverwege de pin de reset laag te maken?

"probeer dit eens: pin 1234 zou je dus kunnen toetsen als bbcc, maar ook als becc of ebcc."

Dit werkt niet. Ik heb het nog eens gecontroleerd en beide pins zitten inderdaad op dezelfde pin aangesloten. Als ik deze twee pinnen meet dan zijn ze inderdaad met elkaar verbonden.

Ik ga de LEDS opmeten.

Edit: Mooi document gevonden :)

http://ww1.microchip.com/downloads/en/devicedoc/reset.pdf

Als ik MCLR verbind met VDD dan geeft die gelijk aan dat de code niet goed is. Dus ik toets 1 code in en dan verbind ik MCLR met VDD en dan gaat het rode LEDje knipperen (verkeerde code).

Edit: LEDs lijken alleen aangesloten te zijn op PIN 1 (VDD).

kun je uitleggen hoe je meet? en waarmee je meet?

waarschijnlijk zit er een weerstand aan de led. meet je die?

wel raar dat ie aangeeft dat die code onjuist is. als ik je pdf goed lees begint het programma aan het begin, dus zou hij moeten wachten op de "sleutel" button om een pin in te geven.

Ik meet met een goedkoop multimeter. Als er volledige ontsluiting is piept die (geen weerstand). Ik meet de min kant van de LED en check dan op welke PIN die is aangesloten op de PIC.

"kun je dat eventueel testen door halverwege de pin de reset laag te maken?"

Dit doe ik door de KEY in te drukken, 1 button in te drukken en dan MCLR te ontsluiten op VDD. Dan springt die gelijk naar 'verkeerde code' door rood te knippen.

Volgens mij doe ik het niet goed? Sorry man :(

[Bericht gewijzigd door Henry S. op (30%)]

welke stand gebruik je? je moet wel de ohm stand (Ω) gebruiken. de stand waarin hij piept is de stand om kortsluiting te detecteren. die werkt maar tot een ohm of 50. een weerstand je voor een led is meestal 60-300 Ω dus die zal je gewoon niet zien ('1' in het scherm?)
begin op de 2000 stand in Ω-bereik. mocht de waarde onder de 200 zijn, kun je een standje lager.

verder lijkt het er dus op dat de MCLR geen input is maar echt een reset geeft.

volledige ontsluiting

als je usb stick last van ontsluiting heeft, is er een ander probleem, je krijgt kleine stickjes :D

Deed ik ook, maar lijken toch echt niet aangesloten te zijn op de PIC?

http://s12.postimg.org/r2iwaegnx/image.jpg

USB Stick heeft 5mm ontsluiting. Nog een paar uur en ik heb mini usbtjes! :D
Bedoelde continuity ;)

Op 12 september 2014 20:06:17 schreef Lemmings:
De stukken staan op usb-sticks, die zo zijn beveiligd dat printen of downloaden niet kan.

Yeah, right! Waarschijnlijk betekend dat dat het PDF documenten zijn met het "we vragen u vriendelijk dit document niet te printen" bitje aan. Sommige PDF readers geven je dan een melding, met de vraag of je toch wilt doorgaan, aangezien een dergelijke "beveiliging" alleen kan werken als de software het betreffende bitje respecteert.

Sowieso is het mogelijk om screenshots te maken terwijl de documenten getoond worden, tenzij er echt een OS op die sticks staat waarvan je moet booten om de documenten te kunnen zien, maar dat gaan die papierschuivers natuurlijk nooit snappen.

Goed kans dat de hele bende alsnog uitlekt omdat een van de "hooggeplaatste dames en heren" op alle links klinkt in alle mailtjes die binnenkomen, en daarmee in het bezit is gekomen van een formidabele verzameling malware.

Op 12 september 2014 20:10:02 schreef Progger:
dat zou betekenen dat de hoeveelheid Pins nog maar de helft is.

En de rest! Aangezien de pincode 4-10 cijfers lang mag zijn, zijn er met 10 toetsen ongeveer 10 ^ 10 * 2 = 20.000.000.000 mogelijkheden, en met 5 toetsen nog maar 5 ^10 * 2 ~= 20.000.000 mogelijkheden; dat scheelt dus een factor 1000.

@Progger: je mist nog een mogelijke vulnerability die ik al eerder genoemd heb, en die naar mijn idee veruit de meeste kans op succes geeft; dat het code pad in de PIC afhankelijk is van de ingevoerde code, en dat deze dus via verschillen in timing of stroomverbruik verraad welke cijfers van de code goed zijn; op die manier krijg je dus geen naive brute-force aanval, maar min of meer een spelletje Mastermind (voor wie dat nog kent)

Als je steeds de pincode moet afsluiten met het indrukken van de 'key' toets, zal vermoedelijk dan pas de PIN-code vergeleken worden met de eerder ingestelde code omdat het geen zin heeft om dat eerder te doen.

Hooguit zou je het aantal juiste cijfers (of de positie van het eerste foute cijfer) uit de timing kunnen halen vanaf het indrukken van de 'key' tot het moment dat de fout-LED knippert.

Overigens vraag ik me ineens heel hard af of het zinvol is om weerstand te meten met een aangesloten batterij.

Het is natuurlijk alsnog mogelijk dat de PIN cijfer voor cijfer wordt gecontrolleerd tijdens het invoeren, en dat de correctheid "tot dusver" wordt bijgehouden in een boolean. Dan hoeft hij dus bij het afsluiten alleen te controleren of het einde van de pincode is gehaald, en die boolean nog steeds aangeeft dat de cijfers correct zijn.

Wellicht is dit niet de meest voor de hand liggende methode, en aangezien het maar 10 cijfers zijn, is het ook prima mogelijk om de hele PIN op te slaan, en pas te gaan controleren zodra deze afgesloten wordt.

In het laatste geval zie ik in ieder geval 2 voor de hand liggende mogelijkheden om die PIN te controleren; zoiets als dit:


PIN_Correct = 1;
for( Index = 0; Index < PIN_Length; Index++ )
  if( PIN[ Index ] != Input[ Index ] )
    PIN_Correct = 0;


Index = 0;
while( PIN[ Index ] && ( PIN[ Index ] == Input[ Index ] )
  Index++;
if( !PIN[ Index ] )
  // PIN correct

In beide voorbeelden is de executietijd afhankelijk van de correctheid van de ingevoerde PIN; in het eerste voorbeeld is er per verkeerd cijfer een extra branch (de if-statement waarvan de inhoud wordt uitgevoerd), waardoor deze mogelijk informatie lekt over het aantal juiste cijfers van de PIN. De tweede is nog wat dramatischer, want de loop stopt zodra er een onjuist cijfer is gevonden; deze zou dus informatie kunnen lekken over het aantal juiste cijfers vanaf het begin van de PIN.

Het is me nog niet duidelijk of de PIC nu op een interne of externe clock draait; de interne clock loopt gelukkig niet heel erg hard, en als het een externe clock is, zou je die natuurlijk kunnen manipuleren of gewoon gebruiken als tijdbasis voor de meting.

Om dit te kunnen onderzoeken heb je toch wel een logic analyser nodig met een sample frequentie van minimaal 4x de clock frequentie van de PIC; een Saleae Logic of Zeroplus die op 100MHz kan samplen lijkt me dus het meest geschikt.

Een instructie op een PIC duurt 4 clock-cycli...

Ik denk dat je met de Pickit voorlopig nog even wegkomt.

SparkyGSX: Ik kan een Saleae Logic 8 overnemen van iemand voor 80 euro. Veel geld, maar kan deze ook na dit project gebruiken uiteraard.

Edit: Ik ga eerst even kijken met de PicKit. Duurt wel even gezien ik geen ervaring heb met analysers.

Op 13 september 2014 10:51:22 schreef Lemmings:
SparkyGSX: Ik kan een Saleae Logic 8 overnemen van iemand voor 80 euro. Veel geld, maar kan deze ook na dit project gebruiken uiteraard.

Je kan ook de Chinese cloon kopen voor een tientje: http://www.dx.com/nl/p/logic-analyzer-w-dupont-lines-and-usb-cable-for…

De Chinese clone koop je voor zes euro en een beetje op Banggood.

Maar dan heb je wel de Saleae software nodig... en een paar posts geleden heb ik nog gelinkt naar een reactie van de makers van de Saleae hierover.

Het zit een beetje in dezelfde categorie als andere namaakproducten en illegale software...

[EDIT]
En ik wil zeker niet de moraalridder uithangen. Maar het is misschien wel goed om te weten. En daarna kan ieder voor zich de keuze maken.

[EDIT2]
DX levert USBee software mee inclusief een keygen zie ik net... Dat is weliswaar iets anders dan Saleae software meeleveren maar lijkt me nog steeds niet kloppen.

[Bericht gewijzigd door Franzki op (16%)]

Franzki: Ik ben het helemaal met Saleae eens. Het kost mij meer, maar ik wil hun supports en mits nodig zal ik ook gewoon de Saleae kopen en geen clone.

De PicKit lijkt te werken. Ik heb de demoboard net bekeken en kan met de analyser data opvangen. Moet alleen even uitzoeken welke channels en sample rate ik moet hebben.

Ik zie niet dat ik de data kan saven als "platte" data. Alleen een screenshot. Had handig geweest als de data gesaved kon worden als hex (of bit notation).

Voor het meten van timing kun je de PicKit goed gebruiken... voor het analyseren van protocollen heb je iets nodig als de Saleae. Daarvan heeft de meegeleverde software heel goede mogelijkheden.

Ik ga dan toch de Saleae bestellen.

De Saleae software werkt vrij simpel op de USBee van DX. Alleen even de Vid/Pid aanpassen.

Je kunt een USBee-clone vermoedelijk eenvoudig aanpassen naar een Saleae clone. Ik las dat iemand dat deed via de driver van de controller.

Je kunt ook meteen een Saleae clone voor 6 euro en een beetje kopen op Banggood (inclusief Dupont kabel en USB-kabel).

En persoonlijk zie ik het probleem ook niet als een enkeling dat doet voor een eenmalig projectje. Maar ik wil het ook niet teveel gaan promoten omdat je dan wel de originele software gebruikt en de ontwikkelaars van de software hier geen cent voor vangen.