PIC Uitlezen Code Protection

Op 13 januari 2012 19:08:16 schreef SparkyGSX:
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.

Nogmaals dat is niet waar! Je weet duidelijk niet het fijne hiervan af, je bent overtuigt van iets wat niet klopt.

Voorbeeld van overeenkomst die je verbied om de software aan te passen in wat voor vorm dan ook buiten de uitgezonderde onderdelen, of reverse engineering uit te voeren op de software.
http://www.axigen.com/legal-product-license.html

Consequently, you are strictly forbidden to add, change, modify, erase features and / or interfaces related to the SOFTWARE PRODUCT, or to any other way create or alter such features and / or interfaces, except for changes to the HTML pages with the exception of preservation of the GECAD Technologies LTD copyright to the HTML help and "about us" pages.

Reverse Engineering
You may not modify, translate, reverse engineer, recompile, disassemble or create derivative works based on the SOFTWARE PRODUCT, or any portion thereof."

En nog voorbeeld, sandersoftware mag je officieel niet aanpassen. Als je dat pakket gebruikt stem je dus in met de overeenkomst.
http://sandersoft.freehostia.com/licentie.htm

"Het is niet toegestaan om de software op welke manier dan ook te veranderen, uit te breiden of te verbeteren. "

Edit/
Niet dat ik er grote problemen mee heb dat iemand het aanpast voor eigen gebruikt. Maar officieel mag het dus niet altijd.

Zoals ik al zei, een bedrijf kan dat wel beweren, maar dat betekend nog niet dat het ook echt verboden is. Ik kan ook wel opschrijven dat het voor jouw verboden is om te schijten met volle maan. Ga jij je daar dan ook aan houden?

De zogenaamde click-trough licenties zijn sowieso dubieus; er worden nog eisen gesteld nadat de koop al gesloten is, en een bedrijf kan niet garanderen dat ik die.tekst correct te zien gekregen heb, ik zelf op akkoord heb geklikt, niet dronken en oud genoeg was om die overeenkomst aan te gaan, etc.

Maar, zoals ik eerder zei: "ze kunnen het toch proberen".

Een ander voorbeeld: ik heb hier een electromotor liggen waar op staat dat het verboden is hem te demonteren, vanwege zogenaamde beschermde technologie.

De algoritme wordt gedaan door de controller vermoed ik. De PIC houd denk ik de sleutel vast en wordt alleen gebruikt bij het encrypten en decrypten.

Ik heb al na zitten denken om een bruteforce te doen op de NAND dump. De MBR is bekend en ik weet wat het moet worden. Als ik nou de eerste 512 bytes van die dump pak en daar een bruteforce op ga doen dan moet het wel lukken, maar ik ben bang dat het niet snel genoeg is. Het kan max 10 cijfers zijn, maar de uitdaging voor ons zit het hem in een 4 cijferige code die elk 0-9 kan zijn. 10.000x een code proberen en controleren of het klopt gaat lang duren. Dit is wel plan B :)

Hardwarematig zijn er ook nog wel mogelijkheden denk ik. De USB stick wordt gelocked wanneer je de stick uit de poort trekt. De PC herkent op dat moment niet de USB stick en mijn vermoeden is dat de NAND op dat moment nog decrypted is. Wanneer je een reset uitvoert dan verwijder je de code van de PIC en wordt de stick niet meer herkent door de PC omdat de NAND encrypted is. De stick wordt dan wel gevonden, maar geeft Windows of Linux aan dat er geen bekend bestandsformaat op staat en dat de stick moet worden geformatteerd. Dit kan wel kloppen omdat de data encrypted is.

Waarom de USB stick niet wordt herkent weet ik nog niet. Ik had verwacht dat er geen spanning meer op staat zodat de stick niets meer of minder is als een stuk ijzer. Echter staat er nog wel spanning op, maar komt er geen data doorheen. Ik vermoed dat dit door de controller wordt tegengehouden.

Hier is mijn plan A though:

Na een reset is de NAND uit te lezen, maar is ge-encrypt. Gezien de algoritm bekend is, is het mogelijk om de data te decrypten met de juiste sleutel. Die sleutel moet bijna wel in de PIC staan.

Plan B zou zijn:

Bruteforce de eerste 512 bytes gezien het bestandsformaat bekend is (FAT).

[Bericht gewijzigd door Jeroen op (99%)]

Op 14 januari 2012 10:49:37 schreef SparkyGSX:
Zoals ik al zei, een bedrijf kan dat wel beweren, maar dat betekend nog niet dat het ook echt verboden is. Ik kan ook wel opschrijven dat het voor jouw verboden is om te schijten met volle maan. Ga jij je daar dan ook aan houden?

De zogenaamde click-trough licenties zijn sowieso dubieus; er worden nog eisen gesteld nadat de koop al gesloten is, en een bedrijf kan niet garanderen dat ik die.tekst correct te zien gekregen heb, ik zelf op akkoord heb geklikt, niet dronken en oud genoeg was om die overeenkomst aan te gaan, etc.

Maar, zoals ik eerder zei: "ze kunnen het toch proberen".

Een ander voorbeeld: ik heb hier een electromotor liggen waar op staat dat het verboden is hem te demonteren, vanwege zogenaamde beschermde technologie.

Je mag dan gewoon het productie niet meer gebruiken want je verbreek de overeenkomst. En kopie maken van software is sowieso niet toe gestaan in Nederland, wel dvd en cd. Software mag je ook niet downloaden of in je bezit hebben zonder overeenkomst als die erop berust.

Er is nik dubieus aan een overeenkomst, als je iets koopt in winkel of waar dan ook ga je altijd overeenkomst aan(met winkel en fabrieknt 9 van de 10 keer). JIJ stemt ermee in, niemand die je dwingt om het product te kopen en dus in te stemmen met overeenkomst.

Ik accepteer de voorwaarden die bekend zijn als ik het product in de winkel koop, geen voorwaarden die later nog gesteld worden. Ik ben toch zeker niet verplicht het product op een windows pc te installeren (en dat heb ik ook nooit gezegd). Ik mag de cd of dvd gewoon lezen, al dan niet met een ander OS, en zolang ik het niet installeer of gebruik waar het voor bedoeld is, heb ik niet op "ik accepteer de voorwaarden" geklikt, en kan dus ook niet aan die voorwaarden gehouden worden. De fabrikant van een apparaat kan mij ook niet verbieden het apparaat open te maken, behalve dat de garantie dan vervalt. De informatiedrager is mijn eigendom, en daar mag ik dus mee doen wat ik wil, behalve namaken natuurlijk.

Als elke vorm van reverse-engineering verboden zou zijn, zouden projecten als Wine nooit kunnen bestaan.

@TS: alle mogelijke sleutels van de AES encryptie proberen kun je mooi vergeten, dat zijn er veel te veel. Het lijkt me sterk dat er ooit iets zonder encryptie in de NAND zou staan; dat is onzinnig, zeer onveilig, en zou de wear-leveling verpesten. Alle encryptie en decryptie wordt waarschijnlijk on-the-fly gedaan.

Maar wordt die PIC nu geblokkeert na een aantal pogingen, of niet? Zit er nu iets van een status LED op, of niet? Kun je de opgenomen stroom meten, en verschillende situaties bekijken?

Je snapt het echt niet he, je mag de software niet in je bezit hebben of kopiëren zonder toestemming! Het is verboden in Nederland om software te kopiëren zonder toestemming! Muziek is uitgezonderd maar software is per wet verboden om te kopiëren zonder toestemming!

Je stemt in met de voorwaarde die gesteld worden, je bent dan ook dom als je de voorwaarde niet leest wat die is bindend. Je hebt alleen te kiezen of instemmen met voorwaarde of gewoon niet gebruiken. Zolang de overeenkomst niet in strijd is met de wet heb je daar aan te houden wat je ermee ingestemd. Is zelfde als handtekening zetten onder een contract, zolang het niet in strijd is met de wet moeten ze zelf weten wat ze onderling afspreken. Anders moeten ze de deal gewoon niet maken, er is geen tussenweg of mazen die je mag gebruiken.

Ik heb nooit gezegd dat reverse-engineering verboden is. Maa als jij product wilt gebruiken dan dien je wel aan de voorwaarden te houden in de overeenkomst die je aangaat als je het product gaat kopen/gebruiken/lenen/ect.

Sommige licentie staat er duidelijk dat je het wel mag aanpassen, of tot zekere hoogte, dat dien je respecteren anders breek je contractbreuk en heb je geen recht meer op je licentie en dus geen recht meer om de code in je bezit te hebben(dat is ook een kopie, lezen op je pc(dus ook schrijven nee ik aan, er alleen erna kijken heb je niks aan) naar je pc toe is ook een kopie).

Dat mensen tegenwoordig allemaal hun eigen opvatting erop na houden is triest zat.

Toch jammer dat je dat "triest zat" vindt, terwijl de Europeese wetgever het duidelijk niet met je eens is. Om het geblaat zonder referenties (ook van mijzelf, overigens) af te kappen, hieronder een paar relevante stukjes van de betreffende Europeese richtlijn.

Richtlijn 91/250/EEG van de Raad van 14 mei 1991 betreffende de rechtsbescherming van computerprogramma's

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31991L0250…

Artikel 5.2.
Het maken van een reservekopie door een rechtmatige gebruiker van het programma kan niet bij overeenkomst worden verhinderd indien die kopie voor bovenbedoeld gebruik nodig is.

Artikel 5.3
3. De rechtmatige gebruiker van een kopie van een programma is gemachtigd om zonder toestemming van de rechthebbende de werking van het programma te observeren, te bestuderen en uit te testen, ten einde vast te stellen welke ideeën en beginselen aan een element van het programma ten grondslag liggen, indien hij dit doet bij het rechtmatig laden of in beeld brengen, de uitvoering, transmissie of opslag van het programma.

Artikel 9.1
Elk contractueel beding dat strijdig is met artikel 6 of met de in artikel 5, leden 3 en 5, bedoelde uitzonderingen, is nietig.

Het is een beetje vaag omschreven, maar in mijn interpretatie valt het draaien van een programma in ongewijzigde vorm in een debugger ook onder "observeren".

Daar komt nog bij dat de waarde van bepalingen zoals in een EULA (end-users license agreement) in Europa nog onduidelijk zijn, omdat deze over het algemeen pas ingezien kunnen worden nadat de koop gesloten is. Je kunt na het ondertekenen van een contract niet zomaar voorwaarden toevoegen.

Ik meen me te herinneren dat er ook nog ergens een uitzondering was voor het reverse-engineeren en (let op) publiceren van de verkregen informatie als dat in het algemeen belang is, zoals bij fouten in de beveiliging van systemen (OV-chipkaart, bijvoorbeeld).

Kortom: niemand kan je iets maken als je maar een licentie voor dat stuk software hebt, en de informatie niet gebruik om kopieerbeveiligingen te omzeilen of illegale kopieën van de software te verkopen. Er is een soortgelijke regeling voor halfgeleiders en andere elektronica.

Dit alles gaat natuurlijk om gelijk hebben, en niet om gelijk krijgen. Als een groot bedrijf het op je voorzien heeft, ga je nooit je gelijk krijgen, zij kunnen een rechtszaak betalen, en jij niet.

[Bericht gewijzigd door SparkyGSX op (16%)]

Op 14 januari 2012 17:33:23 schreef peter79:
[...]
En kopie maken van software is sowieso niet toe gestaan in Nederland, wel dvd en cd. Software mag je ook niet downloaden of in je bezit hebben zonder overeenkomst als die erop berust.

Het is in correct Nederlands niet toegestaan om een spatie in toegestaan te schrijven, maar dat terzijde.

Indien het ondanks het verwijzen naar de betreffende wetsartikelen toch zou kloppen wat jij denkt, heeft iedereen die zijn computer correct gebruikt en dus backups achter de hand heeft, een gigantisch probleem.

Ik heb nog even opgezocht hoe het nu zat met de uitspraak in de rechtszaak van NXP vs. de Radbout Universiteit, over het publiceren van de tekortkomingen in de beveiliging van de OV-chipkaart.

Deze uitspraak (dat de RU de resultaten mag publiceren) komt voort uit de academische vrijheid (die grondwettelijk geregeld is), wat betekend dat resultaten van wetenschappelijk onderzoek gepubliceerd mogen worden, tenzij er een zwaarwegend maatschappelijk belang is. Daarbij is er wel een maatschappelijk belang dat mensen op de hoogte worden gesteld van de tekortkomingen van beveiligingen waar zij op vertrouwen. De schade die NXP daardoor lijdt, komt volgens de rechter niet door het publiceren van het onderzoek, maar door het produceren van een slecht ontworpen chip.

Wil niet lullig doen maar dat is een richtlijn uit 1991 die verouderd is. :D

Er zijn in 2009 en 2010 en wellicht nog meer uitspraken geweest van hof dat software niet goed beschermt was, en dat ging dus over de richtlijn van 2009.

Je moet denk ik 23 april 2009 hebben, waarschijnlijk is deze zelfs al verouderd omdat software nog steeds te kwetsbaar en makers niet goed beschermd werden, maar die zaken kunnen nog lopen. ;)
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32009L0024…

2009
http://tweakers.net/nieuws/71548/softwarerichtlijn-biedt-geen-bescherm…

2010
http://webwereld.nl/nieuws/66803/eu-hof-moet-oordelen-over-auteursrech…

In Nederland hebben we het zo geïnterpreteerd dat je voor als eindgebruikers wel een back-up mag make maar dan alleen als je origineel in huis heb voor elke backup die je maakt van de code.

Ik wil het hier bij laten, gaat namelijk nergens meer over en ik ben er nog geen eens op tegen als het voor thuis gebruik is, maar ik werk er in ieder geval niet aan mee om chips te kraken, zou mensen sieren als ze dat ook niet zouden doen zonder te weten dat je niet meewerkt aan iets illegaals.

@maarten
Doe is niet zo vervelend, we zitten hier toch niet op het forum tien voor taal of zo. Pak me aan op het onderwerp niet op de man spelen graag. :(

Edit/
@SparkyGSX
Kon het niet laten na de hele richtlijn te hebben gelezen. :)

In de oude richtlijn die jij linkt stond toch ook duidelijk.

Artikel 4 Handelingen waarvoor toestemming vereist is

Onverminderd de artikelen 5 en 6 omvatten de exclusieve rechten van de rechthebbende in de zin van artikel 2 het recht de volgende handelingen te verrichten of het verrichten daarvan toe te staan:

a) de permanente of tijdelijke reproduktie voor een deel of het geheel van een computerprogramma, ongeacht op welke wijze en in welke vorm. Voor zover voor het laden of in beeld brengen, of de uitvoering, transmissie of opslag van een computerprogramma deze reproduktie van het programma noodzakelijk is, is voor deze handelingen toestemming van de rechthebbende vereist;

b) het vertalen, bewerken, arrangeren of anderszins veranderen van een programma, en de reproduktie van het resultaat daarvan, onverminderd de rechten van degene die het programma verandert;

Ik had inderdaad niet gezien dat de richtlijn herzien was, maar volgens mij veranderd er niets aan mijn argumentatie.

Over dat artikel 4a en b; in artikel 5.1 en 5.2 wordt dat nog wat verscherpt; in 5.2 staat in ieder geval dat het recht op het maken van een reservekopie niet in een overeenkomst teniet gedaan kan worden.

maar ik werk er in ieder geval niet aan mee om chips te kraken, zou mensen sieren als ze dat ook niet zouden doen zonder te weten dat je niet meewerkt aan iets illegaals.

Daar ben ik het niet mee eens, en daarom zal ik hier ook gewoon aan meewerken.

Ten eerste moeten we dan alles wat mogelijkerwijs voor illegale doeleinden gebruikt kan worden, van deze site verwijderen; het zal wel een beetje leeg worden, denk ik.

Kijk nou bij de schakelingen: de motorregeling, thermostaat, uitschakelvertraging, en nog een aantal andere kunnen bijvoorbeeld gebruikt worden voor wietkwekerij. Weg ermee, dus. Sommige schakelingen kunnen gebruikt worden om andere mensen af te luisteren, opruimen! Zo kan ik nog wel even doorgaan.

Het punt is dat bijna alles voor goed en kwaad gebruikt kan worden, zo ook dit.

Maar mijn tweede, voor mij veel zwaarder wegende argument is het volgende: de hele beveiligingswereld is AFHANKELIJK van mensen die proberen dingen te kraken! Hoe kun je stellen dat een slot veilig is, als je nooit iemand toestaat om het proberen het zonder sleutel open te maken? Als het slot echt deugt, durf je iedereen het te laten proberen. Als het niemand lukt om het slot binnen een bepaalde tijd open te maken, kun je voorzichtig concluderen dat het slot mogelijkerwijs afdoende is om bepaalde zaken mee te beveiligen.

Ik krijg het gevoel dat, als het aan jou lag, we helemaal niet meer zouden mogen rommelen met dingen die ONS EIGENDOM ZIJN.

Er wordt ons al veel te veel verboden; Homebrew op de Wii mag niet meer, OtherOS op de PS3 mag niet meer, ik zie steeds vaker stikkers met "disassembly prohibited" op allerlei producten staan, etc. Nog even en het wordt ons verboden om defecte apparaten zelf te repareren, of te gebruiken voor onderdelen.

Als een bedrijf mij iets verkoopt, mag ik het gebruiken waar het voor bedoeld is, of het open maken, er een scope en logic analyser aan hangen, uren naar kijken en dingen proberen, etc. Het is VAN MIJ. Als dat bedrijf niet wilde dat ik ermee ging prutsen, hadden ze het niet aan mij moeten verkopen. Als tijdens dat prutsen blijkt dat het product niet veilig is, is dat HUN schuld, en niet de mijne. Zij hebben hun werk niet goed gedaan, en ik heb dat enkel vastgesteld. Sommige mensen kunnen daar blijkbaar niet mee omgaan. Als ze zelf hun werk goed hebben gedaan, hebben ze van mij niets te vrezen, want dan valt er ook niets te ontdekken.

Kan het niet laten om toch te reageren, hou het wel kort. :)

In jou eigen link staat duidelijk dat je toestemming nodig hebt op paar uitzondering na voor de rechthebbende eindgebruiken en bakcup van zijn originele software waarvan die geldig rechten heeft om er gebruik van te maken.

Lees artikel 4 a en b en dan 5, je licht er namelijk deel uit die misleidend is zonder de andere bepalingen vooraf te lezen.

Wat jij doet moet je zelf weten, ik werk er niet aan mee, voor hetzelfde geldt zitten jullie nu mijn chip te kraken, al gebruik ik alleen AVR's dus lijkt me sterk. :) Maar wie weet de volgende keer als je er weer aan mee werkt dat je werk van mede forum lid aan het kraken bent waar hij/zij zijn brood mee moet verdienen, en dat het dan wel een persoon is die kwaad wilt en deel van inkomen van mede lid wegkaapt door chip te kraken.

Edit/
Je mag van mijn gerust rommelen, ben er helemaal niet op tegen zoals ik al steeds zeg. Gaat mijn om de correctheid. En dat je niet kan weten wat de intentie zijn aan de andere kant van het internet lijntje. Ik ben er dus niet op tegen als mensen rommelen, steker nog ik moedig het aan dat ze zelf doen thuis voor eigen gebruik, modden is hartstikke leuk, maar of het altijd mag is tweede. En ik werk er pas aan mee als ik kan bepalen dat het ook voor dat doel word gebruikt en dat kan ik niet via forum.

@maarten
Doe is niet zo vervelend, we zitten hier toch niet op het forum tien voor taal of zo. Pak me aan op het onderwerp niet op de man spelen graag.

De backups zijn elders al verduidelijkt (waarvoor mijn dank), dus bleef alleen dit zinnetje, dat ik zelfs terzijde schoof, over om tegen mij op de persoon te spelen kennelijk :+ :9 >:)

Het gaat jou en mij om de correctheid, en dat is nu geillustreerd:

Ten eerste dat correctheid richting wetten (taal of anders; uitsluitend natuurwetten lijken onbuigbaar) soms overdreven kan zijn (zijn doel voorbijschiet, en zo vatte je het ook meteen op hoewel dat niet eens direct de bedoeling was).

Ten tweede dat het nut heeft een betoog in een discussie zorgvuldig te schrijven (zorgvuldiger dan een reparatieverslag of een tip), dus ook met bronverwijzingen als er over en weer maar wat geroepen wordt. Dat is inmiddels prima in orde, maar was wel wat mijn kritische aandacht hier trok.

Nogmaals, mijn opmerking was niet bedoeld om op de man te spelen (ik zeg toch niet dat je dom bent omdat je fouten maakt?): Ik maak ook in het algemeen wel eens op merkingen over spatie fouten en over andere dingen die rot lezen of onduidelijk zijn.

P.S. Om alle misverstanden te voorkomen: ik vind niet dat je met de aan mij gerichte opmerking op de persoon speelde, zelfs al stond mijn naam ervoor ;)

Zoals ik al zei, artikelen 4 en 5 lijken wat tegenstrijdig. Zoals ik het lees gaat artikel 5.2 over de reservekopie, en artikel 4 over elke andere vorm van een kopie en de distributie daarvan. Ik kon toch moeilijk de hele tekst citeren, vandaar ook de link ernaar.

Ik ben met je eens dat het mogelijk is dat ontwikkelaars die dergelijke chips gebruiken hier de dupe van kunnen worden, maar dat is dan wel deels hun eigen schuld. Als hun werk zoveel waard is, hadden ze geen gewone controller moeten gebruiken, maar een "secure" uitvoering, zoals o.a. Atmel in het assortiment heeft. Als het goed is, zijn die beter bestand tegen diverse aanvallen.

Daarbij lijkt het erop dat het al niet echt meer gaat over het kraken van de chip zelf, maar de combinatie van deze chip en de firmware.

Als iemand je werk kaapt, kun je ze aanklagen, eisen dat ze ermee stoppen, en een schadevergoeding eisen. Stoppen moet zoeken naar fouten in de controllers is wat mij betreft geen optie. Het is een illusie dat kwaadwillenden dat niet zonder hulp kunnen, dus iedereen is erbij gebaat dat er kritisch naar die dingen gekeken wordt, en dat mogelijke problemen publiekelijk bekend worden gemaakt. Ik ben een groot voorstander van Full Disclosure, want als we het aan de fabrikanten overlaten, gebeurd er niets. Een defecte chip fixen kost geld, het is veel goedkoper om zo lang mogelijk het probleem onder het tapijt te vegen. In de tussentijd wordt en op grote schaal misbruik gemaakt van de gevonden fouten, zonder dat het publiek daarvan op de hoogte wordt gesteld.

@TS: heb je de mogelijkheid om er een logic analyser of zo aan te hangen? Het is goed mogelijk dat de ingevoerde pincode cijfer voor cijfer wordt gecontroleerd in een loop, waar er uit de loop gesprongen wordt zodra een cijfer niet klopt. Als dat zo is, kun je misschien met een timing attack (tijd tussen het indrukken van de laatste toets en de reactie van de controller) de code 1 cijfer per keer vaststellen. Het aantal pogingen dat je nodig hebt wordt dan veel kleiner.

Het lijkt me ook vrij essentieel dat je op de een of andere manier kun voorkomen dat de foutieve pogingen in de EEPROM worden opgeslagen (want dat ligt wel voor de hand), misschien door de voeding op het juiste moment te onderbreken of zo.

Sommige mogelijke side-channel attacks (zoals de timing attack die ik noemde) zijn te ondervangen in software, maar niet allemaal. Power analyse, bijvoorbeeld, is niet echt in software te ondervangen, en aangezien de chip niet specifiek gemaakt is voor zulke toepassingen, zullen daar ook geen voorzieningen voor zijn.

@Lemmings: Je maakt er wel een soepje van!

Na 2 jaar ben je plots terug met dezelfde vraag?
En dat terwijl op sommige vragen nog steeds geen antwoord komt van jou kant in je andere topics over hetzelfde...
Nu moet iedereen steeds maar weer opnieuw alles intikken en uit leggen aan je.

Hoever sta je nu eigenlijk na 2 jaar?
Heb je al iets aan de antwoorden gehad, en kun je eens een foto posten voor meer duidelijkheid.

CrossFireX: Je hebt gelijk. Ik was dit topic helemaal vergeten. Ik ben langdurig ziek geweest en helaas vanwege gezondheidsredenen moeten stoppen met mijn werkzaamheden. Gezien ik langzaam weer wat kan doen probeer ik het weer op te pakken. Vind het een leuk project, maar helaas door een vervelende ziekte niet veel kunnen doen :(

http://www.circuitsonline.net/forum/view/121727

Dit topic is gesloten en wil ik ook mijn excuses voor aanbieden. Ik had hier inderdaad verder moeten gaan... Ik zal eerst reageren op de topic die is gesloten :)

[Bericht gewijzigd door Jeroen op (97%)]

SparkyGSX: Ik wilde nog even reageren op de vorige topis die ik had aangemaakt :)

Hier wat opmerkingen:

- De USB stick accepteerd geen PIN codes meer nadat je 6x een foutieve code hebt ingevuld. Het duurt dan 3 minuten voor je het weer mag proberen.

- De USB stick kan alleen "gereset" worden wanneer er een PIN op staat. 2x resetten lukt dus niet. Je moet eerst een nieuwe code invullen.

- De dump van de DATA is anders als ik een PIN zet, reset, nieuwe PIN erop zet, PIN reset en de dumps vergelijkt.

Vooral het laatste is wel gek. Ik had verwacht dat alleen de PIN wordt verwijderd, maar de DATA gelijk blijft.

Bij het zetten van een PIN kan de DATA nooit ge-encrypt worden. Dat gaat echt veel te snel (seconde).

Vanavond weer even verder stoeien. Probeer dan ook een foto te maken van de PCB :)

[Bericht gewijzigd door Jeroen op (98%)]

Dat suggereert dat de PIN ofwel helemaal niet gebruikt wordt om een sleutel te genereren, en alleen om te bepalen of de sleutel vrijgegeven mag worden, of dat de PIN slechts een deel van de sleutel is. Als het instellen van een nieuwe PIN betekend dat "de rest" van de sleutel ook opnieuw (random) gegenereerd wordt, zou het veranderen van de PIN dus altijd alle data onbruikbaar maken.

@REW (in vorige topic): op zich is het niet eens dramatisch slecht om de AES sleutel gewoon plain-text naar de controller te sturen, aangezien je dat toch alleen doet als de PIN correct is. De gebruiker heeft die AES sleutel dan helemaal niet nodig; hij kan de data immers op de normale manier lezen.

@TS: wat gebeurd er als je een PIN instelt, data schrijft, en daarna een andere PIN instelt? Geeft je OS daarna aan dat het ding geen bestandssysteem bevat? Wat gebeurd er als je vervolgens de originele PIN weer instelt? Kun je dan de oorspronkelijke data weer lezen, of niet?

Waar het om gaat, is de vraag of de AES sleutel meer entropie bevat dan je PIN. Als blijkt dat dat niet zo is (als je met 2x dezelfde PIN ook 2x dezelfde AES sleutel krijgt), zou dat betekenen dat er een of ander algoritme gebruikt wordt om vanuit de PIN een sleutel te berekenen, en dat betekend natuurlijk dat het aantal mogelijke sleutels VEEL kleiner is dan de 256 bit lengte suggereert. De volgende vraag is dan hoe die sleutel berekend wordt, zodat je weet welke sleutels je, buiten de PIC om, moet proberen om de data te ontcijferen.

Een andere manier zou kunnen zijn om de beperking van 6 pogingen te omzeilen; waarschijnlijk kun je het direct (zonder 3 minuten te wachten) weer proberen als je de PIC een reset geeft, direct op de reset pin als je daar bij kunt, of door de voeding van het hele ding te onderbreken. Wat gebeurd er als je de stick binnen die 3 minuten uit de USB poort trekt en weer terug steekt?

Op 2 september 2014 18:06:32 schreef SparkyGSX:
Dat suggereert dat de PIN ofwel helemaal niet gebruikt wordt om een sleutel te genereren, en alleen om te bepalen of de sleutel vrijgegeven mag worden, of dat de PIN slechts een deel van de sleutel is. Als het instellen van een nieuwe PIN betekend dat "de rest" van de sleutel ook opnieuw (random) gegenereerd wordt, zou het veranderen van de PIN dus altijd alle data onbruikbaar maken.

Ik ben geen encryptie expert...

Maar is het niet zo dat de drive met een sterk (random) AES-wachtwoord is versleuteld en dat dat sterke AES-wachtwoord met een PIN-code wordt versleuteld en opgeslagen (in de PIC of op de schijf).

Dat betekent dat als de PIN wijzigt, alleen het AES-wachtwoord opnieuw hoeft te worden versleuteld.

[EDIT]
In de praktijk zou je gewoon de AES key kunnen XOR-en met de PIN.

SparkyGSX: Bedankt voor het beantwoorden. Leuk om met iemand te kunnen sparren over dit onderwerp. Zoals gezegd doe ik dit uit interesse en eventueel de vendor op de hoogte brengen wanneer ik een zwakheid vind.

"@TS: wat gebeurd er als je een PIN instelt, data schrijft, en daarna een andere PIN instelt? Geeft je OS daarna aan dat het ding geen bestandssysteem bevat? Wat gebeurd er als je vervolgens de originele PIN weer instelt? Kun je dan de oorspronkelijke data weer lezen, of niet?"

Als je een PIN instelt, data schrijft en een andere PIN instelt is er niets aan de hand. Je data blijft gewoon bestaan.

Al zal er gebruik worden gemaakt van een salt, zelfde PIN zou dan de dezelfde data op dezelfde manier moeten encrypten zou ik denken.

"De volgende vraag is dan hoe die sleutel berekend wordt, zodat je weet welke sleutels je, buiten de PIC om, moet proberen om de data te ontcijferen"

Dit zal in de controller zitten en zeer moeilijk uit te lezen zijn. Ik probeer de epoxy eraf te krijgen om meer duidelijkheid te krijgen over de controller. Helaas zijn er geen datasheets beschikbaar voor de controller.

"Een andere manier zou kunnen zijn om de beperking van 6 pogingen te omzeilen; waarschijnlijk kun je het direct (zonder 3 minuten te wachten) weer proberen als je de PIC een reset geeft, direct op de reset pin als je daar bij kunt, of door de voeding van het hele ding te onderbreken. Wat gebeurd er als je de stick binnen die 3 minuten uit de USB poort trekt en weer terug steekt?"

Goeie vragen en toevallig vandaag getest. Het onderbreken van de batt. is genoeg om de "brute-force" lock te omzeilen. Echter betekent dit wel dat ik met de hand alle codes moet proberen. Hier zit echter nog een staartje aan:

Ik zat te denken aan brute-forcen in het begin. AES brute-forcen is mogelijk, maar dat gaat lang duren (praktisch onmogelijk). Bij AES zou 115792089237316195423570985008687907853269984665640564039457584007913129639936 er mogelijkheden zijn namelijk.

ECHTER! Het is een hardware code die je moet intikken. Je hebt dus "maar" 10 cijfers die je max kan gebruiken! Gezien er minimaal 4 wordt gevraagd zijn de mogelijkheden echter een STUK minder:

5^4+5^5+5^6+5^7+5^8+5^9+5^10 wat uitkomt op 12206875 mogelijkheden. Nog steeds veel, maar aanzienlijk minder dan de vendor durft te beweren.

Stick locken, uit de USB en in de USB is niet genoeg. Batt. loskoppelen echter wel :)

Edit: Ik zit echter nog wel et een vraag. Als de USB stick is gelocked dan wordt de stick niet herkend door de PC. Echter staat er wel een voltage op de het juiste pinnetje op de USB poort. Ik ben nu aan het lezen of ik daar niet iets mee kan. Ik kan echter nog niet echt vinden wat ik zoek (technisch hoe de PC precies de USB niet wordt herkend al staat er een spanning op).

Edit: Ik heb iets interessants gevonden:

"When the software requires data transfer to occur between itself and the USB, it sends a block of data called an I/O Request Packet (IRP) to the appropriate pipe, and the software is later notified when this request is completed successfully or terminated by error."

Het zou kunnen beteken dat de controller geen packet verstuurd zolang de juiste code niet is ingevoerd. Echter moet ik nog nadenken hoe het wordt onthouden zonder batt :)

Source: http://www.geoffknagge.com/uni/elec101/essay.shtml

[Bericht gewijzigd door Jeroen op (100%)]

Op 2 september 2014 19:44:06 schreef Lemmings:
5^4+5^5+5^6+5^7+5^8+5^9+5^10 wat uitkomt op 12206875 mogelijkheden. Nog steeds veel, maar aanzienlijk minder dan de vendor durft te beweren.

Zie ook mijn eerdere post...

Als er bij het formatteren of in de fabriek een random AES-sleutel wordt gegenereerd en als die wordt versleuteld met de PIN-code, dan kun je je data niet decrypten met alleen de PIN-code.

Dan moet je ook de versleutelde AES-sleutel hebben en weten welk algoritme wordt gebruikt om de AES-sleutel te encrypten.

Pas dán kun je een bruteforce met alle pincodes proberen rechtstreeks op de data.

Hardwarematig bruteforcen met alle pincodes lijkt nog steeds een mooie optie als je de time-out kunt omzeilen.

Hoi Franzki,

Bedankt voor je reactie :)

De vraag is wel "wat gebeurt er bij het "resetten" van de USB stick? Ik zit namelijk met het volgende:
Als je de USB stick reset dan is deze klaar in een enkele seconde, maar hetzelfde geldt dus ook voor het zetten van de PIN. Dit wordt gedaan in een split van een seconde.

De aanname die ik doe is dat de data op de Samsung NAND dus niet wordt ge-encrypt of de-crypt tijdens 1 van deze handelingen. 16GB zou een tijd duren namelijk en de USB zal ongetwijfeld gloeiendheet worden. Mooiste zou zijn als ik de NAND kan desolderen en uitlezen, maar dat is voor nu wat te enthousiast :P

[Bericht gewijzigd door Jeroen op (97%)]

Wat ik denk:

In de fabriek wordt een unieke AES-sleutel gegenereerd, hiermee wordt de drive versleuteld en die AES-sleutel verandert nooit meer.

Dat is geen ramp zolang die sleutel niet uitgelezen kan worden.

Op 2 september 2014 15:11:21 schreef Lemmings:
- De dump van de DATA is anders als ik een PIN zet, reset, nieuwe PIN erop zet, PIN reset en de dumps vergelijkt.

Op 2 september 2014 19:44:06 schreef Lemmings:
Als je een PIN instelt, data schrijft en een andere PIN instelt is er niets aan de hand. Je data blijft gewoon bestaan.

Ok,

ik vermoed dat de stick alvolgt werkt:

stick werkt gewoon als USB. maar inplaats van direct doorgeven wordt de data eerst gecodeerd/decodeerd tijdens het schrijven/lezen.

de PIC vertelt tegen de controller wat de key is. dat doet hij pas na ingeven van de PIN. ook geeft hij aan dat hij de computer mag antwoorden. voor die tijd herkend de PC de key niet.

de vraag is nu:

is de key altijd het zelfde (ook na het wijzigen van de PIN) of niet? als je de pin wijzigdt en je data blijft toegankelijk, heeft iedere stick dus een permanente key.

als je na het wijzigen van de pin ineens andere data krijgt (en dus ook moet formatteren) betekend dit dat de key wijzigt als je de pin wijzigt.

andere verklaring is dat de PIC een random (ongeldige) key naar de controller zend na een pin-fout. om een simpele DD voor de gek te houden.

kun je de reset/inlog procedure eens volledig uitschrijven?

Het gaat om de Padlock 2 van Corsair:
http://www.corsair.com/media/cms/manual/PadlockUserManual.pdf

Ik merk net op dat op de PIC pootje 5 en 10 geen spanning staat na invoeren juiste PIN:

RC5/RX/DT
RC0/AN4/C2IN+

Datasheet:
http://ww1.microchip.com/downloads/en/DeviceDoc/41203B.pdf

[Bericht gewijzigd door Jeroen op (0%)]