USB Flash Drive Security Challenge #1

[Squ1zZy]

USB FLASH DRIVE SECURITY CHALLENGE #1

INLEIDING

Mijn interesse is altijd uitgegaan naar security. Het leek mij leuk om te sparren met mensen die dezelfde interesse delen en kennis uit te wisselen via het forum. Ik ben toen op het idee gekomen om een security challenge te beginnen. Na contact opgenomen te hebben met enkele moderators van Tweakers is er een goedkeuring om deze challenge te starten.

Dit zal de eerste challenge zijn en bij genoeg interesse volgen er hopelijk meer.

De eerste challenge reeks zal een 'USB Flash Drive Security Challenge' worden. De challenges zal door mijzelf gesponsord worden. Het is de bedoeling om kennis uit te wisselen via het forum en de uiteindelijke challenge succesvol af te ronden of met de deelnemers overeenkomen dat met de aanwezige kennis en beschikbare hardware de USB stick niet gekraakt kan worden.

DE CHALLENGE

De eerste challenge is de 'Locker+ G3 8GB' van Kingston. Zelf heb ik vijf 'Kingston Locker+ G3 8GB' USB sticks aangeschaft die ik graag wil uitdelen aan 5 deelnemers die mee willen doen aan de challenge. Uiteraard is het dan wel de bedoeling je bevindingen te posten op het forum.

De USB stick maakt o.a. gebruik van een wachtwoord, door middel van een programma, om toegang te krijgen tot de USB stick. De gebruikte encryptie is hardware en software encryptie en de USB stick zal geformateerd worden wanneer het wachtwoord tien keer verkeerd wordt ingevoerd.

De challenge is om een security flaw te vinden!

Het zou bijvoorbeeld mogelijk zijn om via de tool toch de USB stick te unlocken zonder het juiste wachtwoord of het omzeilen van de intrusion detectie.

HET SLACHTOFFER

Link

HET SLACHTOFFER SPECIFICATIES

Van de vendor website:

Hardware encryption: the best in personal security to keep your data safe
Superior password protection: user sets a password to prevent unauthorized access
Easy to use: no application installation required
Versatile: works interchangeably between Mac OS X and Windows systems
Secure: drive locks down and reformats after 10 invalid login attempts
Stylish: durable metal casing with built-in key loop
Co-Logo Program available: customize DataTraveler Locker+ G3 by adding your logo and/or digital files and instantly increase your organization’s brand recognition. The Customization Program offers unique packaging, custom profiles, color adjustments, content loading and more, all with easy and convenient ordering.
Supports: Windows® 8, Windows® 7, Vista®, XP & Mac OS X
Guaranteed: five-year warranty with free technical support
Capacities2: 8GB, 16GB, 32GB, 64GB
USB 3.0 speed: 8GB: 80MB/s read, 10MB/s writ
USB 2.0 speed: 8GB: 30MB/s read, 10MB/s write
Dimensions: 60.56mm x 18.6 mm x 9.75 mm
Minimum System Requirements: USB 3.0 compliant and 2.0 compatible
Operating Temperature: 32°F to 140°F (0°C to 60°C)
Storage Temperature: -4°F to 185°F (-20°C to 85°C)

HARDWARE

Omdat waarschijnlijk niet iedereen beschikt over de juiste hardware heb ik wat hardware beschikbaar als bruikleen voor diegene die meedoen aan de challenge. Denk hierbij aan PIC microcontroller programmers en debuggers, logic analysers en multimeters.

DEELNEMERS

Gezien ik persoonlijk de challenge sponsor, zijn er maar beperkte USB stick's beschikbaar. Laat mij weten of je mee wilt doen aan de challenge. Gezien het niet de bedoeling is om USB sticks gratis weg te geven zijn er richtlijnen wie mee kan doen aan de challenge. De richtlijnen zijn:

* De deelnemer heeft minimaal 5000 karma.
* De deelnemer kan overtuigen de kennis en kunde te hebben om mee te dragen aan de challenge.
* De deelnemer is minimaal een jaar lid.

DEELNEMERSLIJST

0. Squ1zZy
Anoniem: 495051

DE WINNAAR

De winnaar is diegene die het meeste heeft bijgedragen aan de challenge. De bedoeling is dat bevindingen die gedaan zijn door de deelnemers zo snel mogelijk worden gepost. Het is een challenge, maar het gaat er natuurlijk ook om om kennis te delen en samen bekijken of er security flaws gevonden kan worden.

PRIJS

Naast eeuwige roem zal ik persoonlijk een tegoedbon weggeven van een welbekende webshop.

DISCLAIMER

Deze challenge heeft geen enkele comerciele band met de leverancier van de USB stick of tegoedbon.

[Squ1zZy]

UPDATES

7/7/2015: USB sticks zijn binnen.
7/11/2015: Executable is op te starten van HDD > LINK.
7/13/2015: NAND is te dumpen met dd door een truukje > LINK.

[ Voor 246% gewijzigd door Squ1zZy op 13-07-2015 19:17 ]

[furian88]

wow super idee, ik vroeg me altijd al af of er niet een manier zou zijn om de beveiliging te omzeilen.. het password zal toch ergens in een chip opgeslagen moeten worden. misschien dat er simpel door de chip te omzeilen ook het password gedeelte genegeerd kan worden.

[Squ1zZy]

furian88 schreef op maandag 06 juli 2015 @ 14:29:
wow super idee, ik vroeg me altijd al af of er niet een manier zou zijn om de beveiliging te omzeilen.. het password zal toch ergens in een chip opgeslagen moeten worden. misschien dat er simpel door de chip te omzeilen ook het password gedeelte genegeerd kan worden.

Dat is inderdaad het leuke eraan. Echter is dat juist de vraag. Certificaten is theoretisch ook eenvoudig, maar moeilijk te "kraken"

Ik heb al veel ervaring met USB flash drives en heb zelf ideeën over de bovengenoemd stick

[furian88]

Squ1zZy schreef op maandag 06 juli 2015 @ 16:33:
[...]


Dat is inderdaad het leuke eraan. Echter is dat juist de vraag. Certificaten is theoretisch ook eenvoudig, maar moeilijk te "kraken"

Ik heb al veel ervaring met USB flash drives en heb zelf ideeën over de bovengenoemd stick

Al zou ik er de tijd voor hebben heb ik de kennis er niet voor Ik wens je echter wel heel veel succes met deze actie, ook blijf ik de topic volgen! Wie weet leer ik er nog wat van

[Zeehond]

furian88 schreef op maandag 06 juli 2015 @ 14:29:
wow super idee, ik vroeg me altijd al af of er niet een manier zou zijn om de beveiliging te omzeilen.. het password zal toch ergens in een chip opgeslagen moeten worden. misschien dat er simpel door de chip te omzeilen ook het password gedeelte genegeerd kan worden.

Ik heb de reactie van furian88 verkeerd begrepen zie mijn post van 06-07-2015 22:30 uur. Hieronder de oorspronkelijke post van deze reactie.

Ik vermoed toch dat het wachtwoord niet als platte tekst in een chip wordt opgeslagen en vervolgens zomaar valt uit te lezen als je de chip uitleest, maar dat het wachtwoordt toch eerst gehashed zal worden voordat het wordt opgeslagen. Als het dan zou lukken om het wachtwoord te vinden in bijvoorbeeld de chip, is het nog gehashed, en weet je dus nog niet zomaar wat je nu als wachtwoord moet intypen.

[ Voor 10% gewijzigd door Zeehond op 06-07-2015 22:50 . Reden: correctie ]

[Squ1zZy]

Zeehond schreef op maandag 06 juli 2015 @ 21:04:
[...]


Ik vermoed toch dat het wachtwoord niet als platte tekst in een chip wordt opgeslagen en vervolgens zomaar valt uit te lezen als je de chip uitleest, maar dat het wachtwoordt toch eerst gehashed zal worden voordat het wordt opgeslagen. Als het dan zou lukken om het wachtwoord te vinden in bijvoorbeeld de chip, is het nog gehashed, en weet je dus nog niet zomaar wat je nu als wachtwoord moet intypen.

De hash is ook ergens opgeslagen

Sta niet te kijken hoe makkelijk het is om zonder het juiste password een USB stick te unlocken.

[Kecin]

Leuk topic, ik ga dit volgen en proberen ook te helpen!

[Zanbee]

Heel interessant vraag me altijd al af hoe veilig dergelijke sticks nou werkelijk zijn. Ik ga het topic zeker volgen.

[Zeehond]

Squ1zZy schreef op maandag 06 juli 2015 @ 21:09:
[...]


De hash is ook ergens opgeslagen

Sta niet te kijken hoe makkelijk het is om zonder het juiste password een USB stick te unlocken.

Klopt, maar wat ik wil zeggen is dat als je het wachtwoord alleen gehashed hebt, Je dus niet meteen zomaar het wachtwoord wat ingevoerd moet worden in leesbaare vorm hebt en even kunt lezen welk wachtwoord er ingetyped moet woorden.

Maar goed ik ben uiteraard benieuwd wat de uitkost is van jouw onderzoek. zoals ik namelijk al eerder schreef ik vermoed dat het wachtwoord eerst gehashed wordt. Ik weet dus niet zeker of het wachtwoord eerst gehased wordt voordat het wordt opgeslagen. Ik weet ook niet of het mischien mogelijk is om het invoeren van een wachtwoord te omzijlen en meteen het wachtwoord gehased in te voeren zodat de hashes meteen vergeleken worden en de gegevens op de USB-stick onsleuteld worden. Ik zal dit topic dan ook graag gaan volgen.

[ Voor 35% gewijzigd door Zeehond op 06-07-2015 22:01 ]

[Squ1zZy]

Kecin schreef op maandag 06 juli 2015 @ 21:14:
Leuk topic, ik ga dit volgen en proberen ook te helpen!

Zou leuk zijn. Gaat mij om dat ik zelf wat wil leren en dat andere er iets van kunnen oppikken.

Edit: Je kan ook gewoon meedoen

[ Voor 6% gewijzigd door Squ1zZy op 06-07-2015 22:07 ]

[johnkeates]

Lijkt me heel interessant! Is ook wat diepgaander dan de cybercrime challenge, gezien je hier lekker diep op 1 ding in kan gaan.

Ik kan me zo voorstellen dat de drive een controller aan boord heeft die de features implementeert naast de standaard flash controller functies die de flash chip aanspreken die ook in de stick zit. Gezien multiplatform support is het misschien 100% software-based of anders d.m.v. USB vendor extensions zoals dat met UMTS sticks gebeurt die zo'n virtuele CD-drive aan boord hebben en de modem hardware pas na een paar semi-geheime commando's beschikbaar stelt.

Qua beveiliging zou het intern daadwerkelijk om een ingebouwde AES engine gaan, maar om dat je ook iets tegen write amplification en wear levelling moet doen zou die flash controller best wel eens intern iets bij moeten houden om dat toch nog goed te kunnen doen als je op file basis een wijziging maakt. Of de controller zou het filesysteem niet moeten versleutelen maar alleen de files. Of alleen non-FS blocks. Of alleen cellen die per transactie geschreven worden. Of gewoon een of ander ander chunk-based systeem. Ergens is dus systeemdata om dat chipje te vinden over wat waar staat, en dat is vast niet gecodeerd!

[Squ1zZy]

johnkeates schreef op maandag 06 juli 2015 @ 22:16:
Lijkt me heel interessant! Is ook wat diepgaander dan de cybercrime challenge, gezien je hier lekker diep op 1 ding in kan gaan.

Ik kan me zo voorstellen dat de drive een controller aan boord heeft die de features implementeert naast de standaard flash controller functies die de flash chip aanspreken die ook in de stick zit. Gezien multiplatform support is het misschien 100% software-based of anders d.m.v. USB vendor extensions zoals dat met UMTS sticks gebeurt die zo'n virtuele CD-drive aan boord hebben en de modem hardware pas na een paar semi-geheime commando's beschikbaar stelt.

Qua beveiliging zou het intern daadwerkelijk om een ingebouwde AES engine gaan, maar om dat je ook iets tegen write amplification en wear levelling moet doen zou die flash controller best wel eens intern iets bij moeten houden om dat toch nog goed te kunnen doen als je op file basis een wijziging maakt. Of de controller zou het filesysteem niet moeten versleutelen maar alleen de files. Of alleen non-FS blocks. Of alleen cellen die per transactie geschreven worden. Of gewoon een of ander ander chunk-based systeem. Ergens is dus systeemdata om dat chipje te vinden over wat waar staat, en dat is vast niet gecodeerd!

Je komt al aardig in de buurt denk ik

Als er gebruik gemaakt wordt van AES dan zie je vaak dat ze een controller, nand en een PIC gebruiken. De sleutel staat dan in de PIC. Hier staat eigenlijk altijd de security bit aan, maar zelfs die heb ik eruit gekregen met salpeterzuur en een UV lamp.

[Onbekend]

Leuk idee.

Ik ga er vanuit dat hier ongeveer het zelfde zit als standaard usb-sticks. Dus een flash-chip + usb-chipje met beveiligingssoftware.
En na 10 keer een verkeerd wachtwoord invullen gaat denk ik de key in de chip verloren gaat i.p.v. dat het flash-geheugen wordt gewist.

Eenvoudig een backup van de key maken gaat waarschijnlijk niet. Een kopie van de flash-chip maken zou wel moeten lukken.

[Zeehond]

Excuses, ik heb de reactie van furian88 verkeerd begrepen. Ik begreep eerst of het mogelijk zou zijn het paswoordt van de chip uit te lezen en vervolgen intevoeren om zo bij de gegevens op de usb-stick te komen.

Maar als je het invoeren van het password probeerd helemaal te negeren/ te omzeilen, zullen denk ik als de gegevens op de stick versleuteld worden, en een passwordt echt nodig is om de bestanden op de usb-stick te laten ontsleutelen (en het wachtwoord dus niet enkel nodig is om bij de bestanden te komen), de gegevens op de usb-stick waarschijnlijk nog steeds versleuteld zijn.

[Squ1zZy]

Onbekend schreef op maandag 06 juli 2015 @ 22:27:
Leuk idee.

Ik ga er vanuit dat hier ongeveer het zelfde zit als standaard usb-sticks. Dus een flash-chip + usb-chipje met beveiligingssoftware.
En na 10 keer een verkeerd wachtwoord invullen gaat denk ik de key in de chip verloren gaat i.p.v. dat het flash-geheugen wordt gewist.

Eenvoudig een backup van de key maken gaat waarschijnlijk niet. Een kopie van de flash-chip maken zou wel moeten lukken.

Die 10x wordt vaak door de software bijgehouden. Makkelijk te testen door 9x het wachtwoord verkeerd in te voeren en de applicatie opnieuw op te starten

[Thralas]

johnkeates schreef op maandag 06 juli 2015 @ 22:16:
Gezien multiplatform support is het misschien 100% software-based of anders d.m.v. USB vendor extensions zoals dat met UMTS sticks gebeurt die zo'n virtuele CD-drive aan boord hebben en de modem hardware pas na een paar semi-geheime commando's beschikbaar stelt.

Dat is het geval. Volgens reviews wordt er een virtuele CD-drive aangeboden.

Qua beveiliging zou het intern daadwerkelijk om een ingebouwde AES engine gaan,

En dat maakt het model met de PIC (of vergelijkbaar) problematisch. De encryptie kan alleen in de controller zelfs plaatsvinden, anders is het nooit snel genoeg.

Wat verder Googlen suggereert dat er een Phison flashcontroller. Ik heb daar nul ervaring mee, dus inhoeverre die dingen door de vendor (Kingston) helemaal customizable/flashable zijn, of dat het logischer is dat een extern uC'tje een AES-key inschiet weet ik niet.

(Ik vermoed dat Squ1zZy al meer weet )

Kunnen we eens beginnen met een dump van de USB descriptors & de inhoud van de aangeboden virtuele CD-drive? Ik kan de software zo 123 niet online vinden...

[johnkeates]

Phison schijnt hackable te zijn. Voornamelijk door hun vendor-specific USB commands.

De firmware is ook niet echt waterdicht, kwestie van de ODM software ergens opscharrelen (meestaal chinees of chinglish qua GUI ) en kijken wat voor controller het is en wat er op staat.

Als we de firmware van de controller kunnen vinden komen we er wel achter hoe het zit, dan is het ook meteen duidelijk hoe het werkt. Als de USB stick niet warm wordt tijdens gebruik is het waarschijnlijk een AES encrypted key, en de key wordt dan met een of andere xor gebruikt om de data gecodeerd te laten lijken in-flash.

Stel dat het mogelijk is de controller in bypass te krijgen zodat we de flash contents kunnen dumpen is er misschien op dat niveau wat te doen. Het kan natuurlijk zijn dat de controller het ingebouwd opslaat, maar het zou ook kunnen dat systeemdata in de flash chip bijgehouden wordt.

[Squ1zZy]

Thralas schreef op dinsdag 07 juli 2015 @ 18:14:
[...]


Dat is het geval. Volgens reviews wordt er een virtuele CD-drive aangeboden.


[...]


En dat maakt het model met de PIC (of vergelijkbaar) problematisch. De encryptie kan alleen in de controller zelfs plaatsvinden, anders is het nooit snel genoeg.

Wat verder Googlen suggereert dat er een Phison flashcontroller. Ik heb daar nul ervaring mee, dus inhoeverre die dingen door de vendor (Kingston) helemaal customizable/flashable zijn, of dat het logischer is dat een extern uC'tje een AES-key inschiet weet ik niet.

(Ik vermoed dat Squ1zZy al meer weet )

Kunnen we eens beginnen met een dump van de USB descriptors & de inhoud van de aangeboden virtuele CD-drive? Ik kan de software zo 123 niet online vinden...

Wil je op de deelnemerslijst?

[Thralas]

Lijkt me opzich erg leuk, ik heb alleen nogal wisselend tijd. En ik ben bang voor hardware hacks

Vandaar dat ik stiekem al een beetje info probeerde los te peuteren om te zien wat voor vlees we uberhaupt in de kuip hebben, but that kind of defeats the point, right

[Squ1zZy]

Of het hardware is of software. Al heb je niet alle kennis. Het gaat er mij om dat je effort wilt steken om mee te doen, iets te leren, iets bij te dragen aan de topic

Ik kan je verzekeren dat 90% van de USB sticks softwarematig gekraakt kunnen worden

[Thralas]

Ik heb nog even wat verder gegoogled, en kwam (o.a.) deze thread tegen, die suggereert dat deze drive de Phision PS2251-13 gebruikt.

Over die bewuste controller (PS2251) is genoeg te vinden, alleen betreft dat andere varianten, bijvoorbeeld de PS2251-03. Van veel uitvoeringen zijn ook firmware files te vinden, maar de -13 ontbreekt hier.

Gezien password protection een universele feature van die controller lijkt (over SCSI vendor commands?) vermoed ik ook dat je er niet aan ontkomt om een bug/'feature' in de firmware te vinden, aangezien er geen sprake lijkt te zijn van een split uC/controller design.

Dan is die -13 wel een lastig target; gezien de availability van tools (-03) en firmware (een boel anderen) lijkt het stukken handiger qua testing/reversing om eerst een ander device te bekijken, in de hoop dat eventuele ontdekte functionaliteit ook op de -13 werkt.

Een firmwaredump zou dat natuurlijk allemaal oplossen, maar uit die Github repo haal ik dat de gedocumenteerde procedure voor de -03 is om eerst een 'Burn image' vanaf de bootrom te booten, om vanaf daar de main firmware te dumpen. Maar voor de -13 is die er niet..

[Trommelrem]

Goed om dit uit te testen. Interessant topic ook.
De SecuStick die Tweakers een poos geleden testte was niet zo veilig

[Squ1zZy]

Thralas schreef op dinsdag 07 juli 2015 @ 23:58:
Ik heb nog even wat verder gegoogled, en kwam (o.a.) deze thread tegen, die suggereert dat deze drive de Phision PS2251-13 gebruikt.

Over die bewuste controller (PS2251) is genoeg te vinden, alleen betreft dat andere varianten, bijvoorbeeld de PS2251-03. Van veel uitvoeringen zijn ook firmware files te vinden, maar de -13 ontbreekt hier.

Gezien password protection een universele feature van die controller lijkt (over SCSI vendor commands?) vermoed ik ook dat je er niet aan ontkomt om een bug/'feature' in de firmware te vinden, aangezien er geen sprake lijkt te zijn van een split uC/controller design.

Dan is die -13 wel een lastig target; gezien de availability van tools (-03) en firmware (een boel anderen) lijkt het stukken handiger qua testing/reversing om eerst een ander device te bekijken, in de hoop dat eventuele ontdekte functionaliteit ook op de -13 werkt.

Een firmwaredump zou dat natuurlijk allemaal oplossen, maar uit die Github repo haal ik dat de gedocumenteerde procedure voor de -03 is om eerst een 'Burn image' vanaf de bootrom te booten, om vanaf daar de main firmware te dumpen. Maar voor de -13 is die er niet..

Footprinting... Heel goed

Firnware is 1 optie en leuk om te zien dat hiernaar verwezen wordt. Zou mooi zijn om via footprinting de theorie op tafel te krijgen voor een goede aanval. Software waarmee het geopend moet worden zou een andere kunnen zijn.

Interessant blijft ook altijd dat een wachtwoord zo sterk is als de gekozen wachtwoord van de gebruiker. Je zou een extreem moeilijke encryptie kunnen gebruiken, controllers die niet te kraken zijn, maar wanneer het wachtwoord"password" wordt gebruikt, hoe veilig is dan de encryptie?

[Squ1zZy]

Bij te weinig animo zal ik de challenge helaas af moeten zeggen. Jammer. Leek me leuk om met andere te sparren.

[Onbekend]

Helaas heb ik momenteel te weinig vrije tijd om mij met zo'n project bezig te houden, anders was dit vast een leuk project geweest.
Ik had gehoopt dat als anderen hieraan meededen we hier mooi de voortgang tussentijdse resultaten konden zien.

[masauri]

Ik vind het ook wel boeiend en volg het al sinds ge de startpost gepost hebt.
Maar mijn kennis op dat vlak is 0.
Ik kan wel creatief denken maar daar is ook alles mee gezegd.
En dat is wat je zelf ook aangaf te willen vermijden in de TS, personen zoals mij.
Anders deed ik graag is wat "pogingen"

[Squ1zZy]

Ik heb wat "bekende" benaderd en die geven eigenlijk hetzelfde aan. De een heeft een kleine en de ander gaat 4 weken op vakantie

Wat ik eventueel kan doen is zelf de challenge accepteren en mijn bevindingen te plaatsen. Dan kan iedereen mee discussiëren/mee denken

[masauri]

Squ1zZy schreef op vrijdag 10 juli 2015 @ 08:21:
Ik heb wat "bekende" benaderd en die geven eigenlijk hetzelfde aan. De een heeft een kleine en de ander gaat 4 weken op vakantie

Wat ik eventueel kan doen is zelf de challenge accepteren en mijn bevindingen te plaatsen. Dan kan iedereen mee discussiëren/mee denken

Vind ik een goede tussenoplossing, ik zou er voor gaan als ik jou was, misschien springen er nog mensen op de kar.
De timing was misschien niet geheel goed gekozen met de vakantieperiode nu?
Maar ach, dat zijn nog maar een paar maand

[Anoniem: 495051]

Jammer dat ik niet voldoe aan de karma score
Ik zou een heel eind komen denk ik

The crack relies on a weakness so astoundingly bone-headed that it's almost hard to believe. While the data on the drive is indeed encrypted using 256-bit crypto, there's a huge failure in the authentication program. When the correct password is supplied by the user, the authentication program always send the same character string to the drive to decrypt the data no matter what the password used. What's also staggering is that this character string is the same for Kingston, SanDisk and Verbatim USB flash drives.

Cracking the drives is therefore quite an easy process. The folks at SySS wrote an application that always sent the appropriate string to the drive, irrespective of the password entered, and therefore gained immediate access to all the data on the drive.

[Squ1zZy]

Anoniem: 495051 schreef op vrijdag 10 juli 2015 @ 14:03:
Jammer dat ik niet voldoe aan de karma score
Ik zou een heel eind komen denk ik

The crack relies on a weakness so astoundingly bone-headed that it's almost hard to believe. While the data on the drive is indeed encrypted using 256-bit crypto, there's a huge failure in the authentication program. When the correct password is supplied by the user, the authentication program always send the same character string to the drive to decrypt the data no matter what the password used. What's also staggering is that this character string is the same for Kingston, SanDisk and Verbatim USB flash drives.

Cracking the drives is therefore quite an easy process. The folks at SySS wrote an application that always sent the appropriate string to the drive, irrespective of the password entered, and therefore gained immediate access to all the data on the drive.

Deze key staat niet meer online
Is ook niet toepasbaar op deze USB stick denk.ik. Maar je mag mee doen als je wilt hoor.

Ik ga zelf dit weekend beginnen denk ik

[Anoniem: 495051]

Squ1zZy schreef op vrijdag 10 juli 2015 @ 14:23:
[...]


Deze key staat niet meer online
Is ook niet toepasbaar op deze USB stick denk.ik. Maar je mag mee doen als je wilt hoor.

Ik ga zelf dit weekend beginnen denk ik

Het lijkt mij een super leuke uitdaging!
Ik zal vanavond even mijn gegevens via PM sturen

[Squ1zZy]

Anoniem: 495051 schreef op vrijdag 10 juli 2015 @ 14:35:
[...]


Het lijkt mij een super leuke uitdaging!
Ik zal vanavond even mijn gegevens via PM sturen

Ok cool! Ik heb al veel ideeën die ik wil delen. Ik wacht je DM af. Stick gaat gelijk op de bus

[Squ1zZy]

Verkeerde post ge-edit.

[ Voor 255% gewijzigd door Squ1zZy op 11-07-2015 07:57 ]

[Anoniem: 495051]

Squ1zZy schreef op vrijdag 10 juli 2015 @ 15:13:
[...]


Ok cool! Ik heb al veel ideeën die ik wil delen. Ik wacht je DM af. Stick gaat gelijk op de bus

Zie PM

Nogmaals bedankt!

[Squ1zZy]

Ik wilde de executable graag vanaf HDD starten. Dit omdat ik dan meerdere executables kan gebruiken en natuurlijk wijzigingen toepassen. Nu kreeg ik eerst de melding:



Bij het debuggen kwam ik tegen dat de support files werden gebruikt. Na het kopieren van de support files kreeg ik de volgende melding:



De executable wordt ook gecontrolleerd of de naam is gewijzigd. Het bestandsnaam moet dus zijn 'DTLplus_Launcher.exe'.

Gezocht in de string references, maar daar kwam ik de melding niet tegen. De executable die wel werkt (op de stick) kan natuurlijk ook geopent worden (niet gepacked overigens). Door er doorheen te stappen kwam ik een jump tegen die in de executable op de USB stick niet werd genomen, maar op de gekopieerde executable wel (klikbaar):



Na het zetten van de zero flag werd de jump niet genomen in de gekopieerde executable en start de executable gewoon op:



Nu even patchen en dan met deze executable verder

Edit: Wanneer er 9x verkeerd wordt ingelogged en ik stop de USB stick in een andere laptop onthoud de stick hoe vaak er verkeerd is ingelogged. Dus hij geeft dan aan dat er al 9x verkeerd is ingelogged. Wordt dus op de stick opgeslagen. Eens kijken of ik de NAND kan dumpen met DD.

[ Voor 20% gewijzigd door Squ1zZy op 11-07-2015 11:37 ]

[Thralas]

Die counter had ik eigenlijk niet verwacht, maar verder denk ik dat het ding geen losse uC aan boord heeft. Hij kan immers de desbetreffende key toch direct aan de controller voeren dmv. wat SCSI vendor commands?

Je Ollyscreenshot is op postzegelformaat

[Squ1zZy]

Thralas schreef op zaterdag 11 juli 2015 @ 11:29:
Die counter had ik eigenlijk niet verwacht, maar verder denk ik dat het ding geen losse uC aan boord heeft. Hij kan immers de desbetreffende key toch direct aan de controller voeren dmv. wat SCSI vendor commands?

Je Ollyscreenshot is op postzegelformaat

Wat ik zie is dat de volgende 2 volumes worden gemount:

\\.\Volume{6bd2291e-23ae-11e5-b306-c0335e10924a}\
link to \\?\Device\HarddiskVolume21
removeable media
Mounted on \\.\e:

\\.\Volume{6bd2291c-23ae-11e5-b306-c0335e10924a}\
link to \\?\Device\CdRom0
CD-ROM
Mounted on \\.\d:

De E drive is niet te dumpen met DD. Ik krijg dan de melding:

"Error reading file: 21 The device is not ready"

De applicatie kan het wel. Op deze volume staat de informatie. Ik heb een breakpoint gezet op het moment dat er bestanden worden gelezen en toen geprobeerd te dumpen, maar dan krijg ik de melding:

"Error opening input file: 32 The process cannot access the file because it is being used by another process"

Commando:
dd if=\\.\Volume{6bd2291e-23ae-11e5-b306-c0335e10924a} of=c:\users\username\downloads\usb1.img bs=1M

P.s. Olly screenshot is nu klikbaar

[ Voor 6% gewijzigd door Squ1zZy op 11-07-2015 11:36 ]

[Thralas]

Squ1zZy schreef op zaterdag 11 juli 2015 @ 11:32:
"Error reading file: 21 The device is not ready"

De applicatie kan het wel. Op deze volume staat de informatie.

Interessant. Je zou verwachten dat dat de uiteindelijke partitie met al je files is (volgens wat info die ik vond over die Phision controller zijn er 2 LUNs in 'mode 21', 1 CDFS, 1 data), en dus niet leesbaar iot de controller de AES key heeft ontvangen, maar als jij zeker weet dat er succesvol van gelezen wordt is er iets niet helemaal juist aan die theorie..

En dan hoop ik dat er in totaal 3 LUNs zijn, en niet maar 2

Vwb. die error, ik zou een bp op CreateFile gooien en dwShareMode=FILE_SHARE_READ meegeven als hij de 'interessante' device opent, dan zou dd meer succes moeten hebben, mits die niet OOK exclusive access claimt (oh Windows..)

[Squ1zZy]

Thralas schreef op zaterdag 11 juli 2015 @ 11:47:
[...]


Interessant. Je zou verwachten dat dat de uiteindelijke partitie met al je files is (volgens wat info die ik vond over die Phision controller zijn er 2 LUNs in 'mode 21', 1 CDFS, 1 data), en dus niet leesbaar iot de controller de AES key heeft ontvangen, maar als jij zeker weet dat er succesvol van gelezen wordt is er iets niet helemaal juist aan die theorie..

En dan hoop ik dat er in totaal 3 LUNs zijn, en niet maar 2

Vwb. die error, ik zou een bp op CreateFile gooien en dwShareMode=FILE_SHARE_READ meegeven als hij de 'interessante' device opent, dan zou dd meer succes moeten hebben, mits die niet OOK exclusive access claimt (oh Windows..)

Je hebt gelijk. Er zijn 2 LUN's in mode 21. De partitie waar naar verwezen wordt is de partitie die uiteindelijk geopend wordt.

De Phison controllers kunnen gedumped worden. Ik heb nog 1 voordeel: Ik spreek Russisch (usbdev.ru)

Edit: Volgens jou zou er op de PCB alleen een Phison controller zitten en een NAND? Dan moet de key worden gegenereerd aan de hand van een serial?

Dit bedoel ik:



Op de stack wordt de volume E gepushed en vervolgens wordt er een file aangemaakt door de kernel.

Edit: Lijkt erop of er wordt gecontrolleerd of het een Kingston USB stick betreft.

[ Voor 16% gewijzigd door Squ1zZy op 11-07-2015 12:10 ]

[azerty]

Interessant topic! Ik ga het blijven volgen

[Thralas]

Zoals te zien is op 0x44ee46 wordt daar al FILE_SHARE_READ | FILE_SHARE_WRITE klaargezet (en later als argument meegegeven).

Dus dd is je probleem in de device read-kwestie.

Edit: Volgens jou zou er op de PCB alleen een Phison controller zitten en een NAND? Dan moet de key worden gegenereerd aan de hand van een serial?

Nee, adhv. user input, en dat direct in een SCSI vendor command aan de controller voeren.

Maar het feit dat jij aantoont dat die 2e LUN al eerder wordt geopend (tenminste, ik neem aan dat je het password niet hebt ingevuld) doet vermoeden dat er meer aan de hand is.

Worst case scenario: inderdaad een key die niet afhankelijk is van user input, zodat hij later (software based) bookkeeping van het aantal 'tries' en het werkelijke 'password' (niet key) kan doen.

Maar dat zouden ze nooit doen, toch.

Je kunt ook die hele applicatie aan de kant schuiven en kijken wat er aan SCSI commands over de lijn gaat.

[ Voor 69% gewijzigd door Thralas op 11-07-2015 12:48 ]

[Squ1zZy]

Thralas schreef op zaterdag 11 juli 2015 @ 12:42:
Zoals te zien is op 0x44ee46 wordt daar al FILE_SHARE_READ | FILE_SHARE_WRITE klaargezet (en later als argument meegegeven).

Dus dd is je probleem in de device read-kwestie.


[...]


Nee, adhv. user input, en dat direct in een SCSI vendor command aan de controller voeren.

Maar het feit dat jij aantoont dat die 2e LUN al eerder wordt geopend (tenminste, ik neem aan dat je het password niet hebt ingevuld) doet vermoeden dat er meer aan de hand is.

Worst case scenario: inderdaad een key die niet afhankelijk is van user input, zodat hij later (software based) bookkeeping van het aantal 'tries' en het werkelijke 'password' (niet key) kan doen.

Maar dat zouden ze nooit doen, toch.

Je kunt ook die hele applicatie aan de kant schuiven en kijken wat er aan SCSI commands over de lijn gaat.

Waar wordt het wachtwoord opgeslagen? In de ASIC? In de Phison controller staat wel AES enabled, en 10 password attempts.

Hier meer info over de Phison:





Edit: AES wordt door de controller als pass-trough gedaan denk ik. Dus on-the-fly. Vraag me af of de data op de NAND daadwerkelijk AES encrypted is. Als je de NAND van de PCB kan krijgen en deze uit zal lezen zal het platte data zijn vermoed ik.

Edit: Wat als de controller alles doet? Als daar het wachtwoord opgeslagen... Dan krijg je weinig uit de applicatie zelf. De applicatie geeft de user-input door en de controller controlleerd of het goed is.

Edit: Ok, de controller doet al het werk. Bij het debuggen van de applicatie kom ik niet achter het wachtwoord of zal ik de USB LUN kunnen unlocken.

Deze versie Phison (2251-13) is ook niet te dumpen. Een mogelijkheid is om de NAND eraf te halen en deze uit te lezen. Sprite heeft dit al eens gedaan.

10 verkeerd inloggen en de key wordt herschreven. De data staat waarschijnlijk gewoon nog op de NAND.

Vraag me af wat er mogelijk is met een logic analyser.

[ Voor 49% gewijzigd door Squ1zZy op 11-07-2015 19:02 ]

[Squ1zZy]

Ik kan met Wireshark capturen. Misschien kan ik wat interessante SCSi commands vinden:

[ Voor 47% gewijzigd door Squ1zZy op 12-07-2015 15:43 ]

[Anoniem: 495051]

Yes, na een weekeind soort van camperen (Lang leven de regen) ben ik ook in de running.

Als ik de USB inplug krijg ik de volgende gegevens te zien.

Description
Kingston DTLocker+G3 USB Device (dat wisten we natuurlijk al )

Drive Letter
E:/F:

Serial Number
0018F30BFDE7BF61A139F379 (niet het nummer wat op de usb gegraveerd staat)

Driver Version
6.1.7601.17577

Instance ID
USB\VID_0951&PID_169D\0018F30BFDE7BF61A139F379


e:\ laat wel een dump maken. en het is ook mogelijk om de RAW data te exporteren die de usb stick communiceert bij het invoeren van een valse login, ik zal later vandaag een dump online zetten.

[Squ1zZy]

Anoniem: 495051 schreef op maandag 13 juli 2015 @ 10:48:
Yes, na een weekeind soort van camperen (Lang leven de regen) ben ik ook in de running.

Als ik de USB inplug krijg ik de volgende gegevens te zien.

Description
Kingston DTLocker+G3 USB Device (dat wisten we natuurlijk al )

Drive Letter
E:/F:

Serial Number
0018F30BFDE7BF61A139F379 (niet het nummer wat op de usb gegraveerd staat)

Driver Version
6.1.7601.17577

Instance ID
USB\VID_0951&PID_169D\0018F30BFDE7BF61A139F379


e:\ laat wel een dump maken. en het is ook mogelijk om de RAW data te exporteren die de usb stick communiceert bij het invoeren van een valse login, ik zal later vandaag een dump online zetten.

E is de CDFS partitie? Die is wel te dumpen, maar daar heb je weinig aan ben ik bang

Edit: Ik vraag me af hoeveel de ASIC in de maling gehouden kan worden. Wat als ik de ASIC vertel een nieuw wachtwoord in te stellen via de applicatie, een bp zet en vervolgens de stick eruit trek. Is de partitie dan te benaderen met het nieuw ingestelde wachtwoord? Met de data gebeurt niets lijkt me..

Met de applicatie kan je een nieuw wachtwoord instellen en daarna wordt de drive geformatteerd.

Edit 2: Helaas, daar trapt de stick niet in:



Ik heb nu het wachtwoord gewijzigd, maar niet de NAND geformatteerd.

Edit 3: Gek genoeg kan ik nu de E drive dumpen met dd?

Even kijken wat daarin staat. Ik heb een text bestand op de E schijf geplaatst. Even kijken of ik die uit de dump kan herleiden.

Edit 4: Ik heb nu een 8GB file met encrypted data ... Klikbaar

[ Voor 42% gewijzigd door Squ1zZy op 13-07-2015 18:04 ]

[Squ1zZy]

Dus een recap:

- Applicatie is aangepast dat de applicatie wel van HDD gestart kan worden.

- Ik kan met een "truukje" wel de 8GB partitie dumpen. Echter is deze wel encrypted. De data moet door de controller heen en die encrypt de data.

Edit1: Als ik met openssl het bestand decrypt krijg ik 10GB terug

C:\OpenSSL-Win32\bin>openssl enc -aes-256-cbc -salt -a -in c:\Users\username\Downloads\usb1.img -out c:\Users\username\Downloads\USB2.img -k 0018F30BFDE7BF61A139F309 < Serienummer USB stick

Was te proberen

Edit2: Het wachtwoord wat wordt ingevoerd in de applicatie wordt naar de controler gestuurd. Ik kan eens kijken hoe dat naar de controller wordt verzonden. Misschien dat de applicatie een encryptie doet en dat naar de controller stuurt. Geloof niet dat dat in platte text wordt verzonden.

[ Voor 71% gewijzigd door Squ1zZy op 14-07-2015 08:24 ]

[Squ1zZy]

Helaas erg weinig animo voor de challenge

Ik stop dan ook met de challenge. Ik heb het in ieder geval geprobeerd

Voor diegene die de DataTravaler willen starten vanaf een andere partitie zonder de file te "patchen" kan 2 parameters meegeven aan de applicatie.

De applicatie doet een check of "DTG2" wordt meegegeven evenals de folder waarin het start.

Dus:

DTLplus_Launcher.exe "DTG2" "C:\Whatever\"

Dan start de applicatie op zonder melding ...

[Donvermicelli]

Ik zou zeer benieuwd zijn naar de uitkomst van deze challenge, helaas dat jullie er mee gestopt zijn. Ik had graag mee gedaan maar voldoe helaas niet aan de deelname eisen.

[azerty]

Spijtig, want het zag er wel interessant uit hoor!

[Squ1zZy]

Vergeten te zeggen dat de applicatie gebruik maakt van OutputDebugString.

Dus je zou debugview mee kunnen laten draaien voor meer info

00000002 0.85805976 [6724] DTG2 get!
00000003 0.85808933 [6724] MutexToDTG2-C
00000004 0.85815626 [6724] Vista
00000005 0.85834062 [6724] C:\Users\Username\Downloads\DTLplus_Launcher.exe
00000006 3.37480140 [6724] Admin
00000007 3.92486477 [6724] Start check device~
00000008 3.92489624 [6724] GetLogicalDrives= 0x0000001C
00000009 3.92496037 [6724] current check c = = C
00000010 3.92505383 [6724] find DeviceHandle == INVALID_HANDLE_VALUE continue~
00000011 3.92507648 [6724] current check c = = D
00000012 3.92605209 [6724] D:\
00000013 3.92611408 [6724] current check c = = E
00000014 3.92891669 [6724] E:\
00000015 3.92894769 [6724] MutexToDT4KRemovable-E
00000016 3.92900753 [6724] find device driveType==DRIVE_REMOVABLE, TargetDrive = C , TargetRemoveable = E
00000017 3.92903495 [6724] CheckDeviceExist OK , TargetDrive = C
00000018 3.94638324 [6724] UID = 0
00000019 3.95295286 [6724] Removable drive E:\ , SN=0018F30BFDE7BF61A139F309
00000020 3.95297742 [6724] MutexToDT4KRemovable-E
00000021 3.95303941 [6724] TargetRemoveable = E
00000022 3.95308900 [6724] ** OpenSecureSession
00000023 4.50205135 [6724] MyDefaultSetting READ fail!
00000024 4.50233650 [6724] ** OpenSecureSession
00000025 5.05088139 [6724] ** OpenSecureSession