Opdracht 2
Niet alle zaken zijn zo makkelijk te hacken als de uC uit opdracht 1. Zo nu kom je een microcontroller tegen die (gasp!) geen obvious fout in de beveiliging heeft. Je hebt echter wel toegang tot de hardware, en die toegang is (natuurlijk) te misbruiken.Geschiedenis
Een hoop van deze security-hacks komen oorspronkelijk weg van het PayTV-circuit. Net zoals nu had je voor bijvoorbeeld satteliet-ontvangst een decoder nodig, waar je een smart-card inschoof. De smart-card was bedoeld als 'sleutel': alleen als de smartcard bepaalde berekeningen voor de decoder kon uitvoeren, kon het signaal gedecrypt worden. Vroeger waren de smartcards nog vrij simpele dingetjes: bijvoorbeeld een PIC16C84 of een AT90S2313 waren vrij standaard. (Tegenwoordig zitten er best brute cryptoprocessoren in die je niet zo 123 meer op deze manier hackt.)Een abonnement op een sattelietkanaal heb je natuurlijk niet voor het leven: zodra je stopt met betalen moet de sattelietzender ervoor zorgen dat je decoder z'n ding niet meer kan doen zodat je geen TV meer kan kijken. Dit gebeurt door een soort van 'kill-signal' met het TV-signaal mee te sturen: via het TV-signaal word de smartcard verteld dat z'n diensten niet meer nodig zijn. De smartcard zette dan een bitje in z'n geheugen en weigerde verder te werken. Vaak gebeurde dit ongeveer als volgt:
code:
1
2
3
4
5
6
7
8
9
10
| void commitSuicide() { writeEeprom(disabledBit, 1); } void main() { if (readEeprom(disabledBit)==1) { while(1); } goDecryptSignal(); } |
Het niet-eindigende while-loopje werd hierbij door de compiler omgezet in een enkele 'hang: jmp hang'-assembly-instructie; de smartcard reageerde hierdoor compleet niet meer en kon weggegooid worden.
Of niet? Slimme hackers kwamen erachter dat je een aantal truukjes kon uitvoeren om uit de oneindigende loop te komen: het zogenaamde unloopen van een card. Een ervan is...
Voltage-glitching
De truuk hierachter is dat een microcontroller rare dingen gaat doen als je er een voedingsspanning opzet die buiten z'n bereik ligt. Vaak is het zo dat je uC tijdelijk helemaal niets meer doet als de spanning constant te laag is en permanent niets meer doet als 'ie te hoog is, maar als je spanningsdip of -piek maar klein genoeg is, komen slechts gedeeltes van de chip onder een te lage (of te hoge) spanning te staan. Daar kunnen enkele... interessante... resultaten uitkomen.Praktijk
Hoewel een glitch een makkelijke manier is om een microcontroller net een instructie iets anders uit te voeren dan bedoeld is, is het daadwerkelijke uitvoeren wat lastiger: om een glitch net op het punt actief te krijgen waar je gewenste instructie uitgevoerd word is niet heel makkelijk, en dan hebben we 't niet eens over de precieze spanningsnivo's die nodig zijn, brown-out-detectoren, whatever.Een unloop-glitch is echter erg voordelig: als er niets gebeurt kan je 't nog een keer proberen, als je uC reset kan je het nog eens proberen, als je uC wel glitcht ben je er.
De Opdracht
Wat, zonder meer info nu al een opdracht? Yep, deze is namelijk bedoeld om aan te geven hoe makkelijk het kan wezen, en er zijn vele manieren om deze code te glitchen. De volgende code vraagt om een twee-cijferig password en heeft geen anti-bruteforce-delay, maarrrrrr.... de firmware 'brickt' de chip na 5 pogingen. Aan jullie om toch het password te bruteforcen. (Of meteen al het password in 5 pogingen te gokken... maar kijk dan toch ff of je 't kan kraken.) Ter voorkoming van stukke AVRs: de glitches hoeven alleen 'naar beneden' te zijn, er is geen noodzaak om meer dan 5V op de AVR te zetten.Het schema is hetzelfde als bij de eerste opdracht. De firmware is gecompileerd voor de ATTiny2313 of de ATMega88.
Succes. Als je 'm hebt zet dan meteen in een spoiler wat je gebruikt hebt.
Relaxen und watchen das blinkenlichten. | Laatste project: Ikea Frekvens oog