Posts mit dem Label HackStick werden angezeigt. Alle Posts anzeigen
Posts mit dem Label HackStick werden angezeigt. Alle Posts anzeigen

Sonntag, 20. März 2011

HackStick Update

Heute geht es um ein Projekt das nun seit mehr als einem Jahr ohne nennenswerten Fortschritt in der Ecke lag, dem "HackStick". In meinem letzten Post habe ich darüber berichtet, dass ich den ursprünglich eingesetzten ATMega8 durch einen ATMega168 ersetzen würde. Das ist längst geschehen und nich mehr aktuell. Nachdem die Ideen für viele neue Features in der Firmware nur so sprudelten, musste unbedingt zunächst ein neuer Mikrocontroller her, um den gestiegenen Anforderungen gerecht zu werden.

Der zuvor verwendete Mega168 war mit seinen 16kB Flash und den vorhandenen 1kB SRAM schon zu jeweils etwa 80% gefüllt. Was aber leider keine weiteren großen Schritte zulies. Abhilfe schafft "der Neue". Ein ATMega328P-PU. Dieser besitzt im Vergleich zu dem vorher verfügbaren Flash, RAM und EEPROM jeweils die doppelte Kapazität. Also 32kB Flash, 2kB SRAM und 1kB EEPROM. Die Bauform und Pinbelegung ist dabei zu der Mega8 Reihe identisch (P-DIP28).

In der Firmware sind jedoch ein paar kleinere Änderungen notwendig gewesen um die USART-Schnittstelle verwenden zu können. Hilfrech ist hierbei die aktuelle UART Library von Peter Fleury. Unter Ubuntu 10.10, mit einem avr-gcc-4.3.5 und der avr-libc-1.6.8-2 musste jedoch das ein oder andere Register, sowie die Interrupt Vektoren, angepasst werden. Leider ist mit dieser Library das Senden von Daten per USASRT (out of the Box) mit dem Mega328p nicht per Interrupt möglich gewesen, was aber an dieser Stelle nicht weiter stört und mich daher auch nicht genötigt hat zu prüfen, warum dieses Feature nicht funktioniert.

Ein weiteres Software-Update hat der Bootloader erfahren, dass ohne Probleme verlief. Lediglich die Fuse-Bits mussten angepasst werden, da ich nicht bei jedem Flashen der Firmware das EEPROM neu beschreiben wollte. Lediglich die Konfigurations-Einstellungen des Bootloaders, sowie eine kleinere Anpassung im Code, mussten durchgeführt werden, um den Bootloader auch aus der eigentlichen Firmware heraus, software-seitig über den AVR internen Watchdog starten zu können. Die vorher vorhandene Möglichkeit den Bootloader zu starten, indem ein Jumper vor dem Einstecken gesetzt wird, bleibt dabei bestehen.

Neben diesen beiden Updates von Firmware-Teilen und der generellen Umstrukturierung, haben sich jedoch noch weitere neue Features ergeben. Die Liste ist lang und daher soll die folgende Liste nur einen Sichpunktartigen Überblick bringen.
  • Setzen, Aanzeigen und Senden aller USB-spezifischen Daten über das TTY. Mit USB-spezifischen Daten sind alle USB Descriptoren, Strings, Vendor-/Device-ID, USB Daten und Sequenzen von zu sendenden USB Daten gemeint.
  • Ein Interpreter mit dem die oben genannten USB Daten-Sequenzen interpretiert und gesendet werden können. Hier stehen, je nach Datenmenge und Headerinformationen, ca. 794 Byte zur verfügung.
  • Es kann festgelegt werden ob auf eingehende Daten reagiert werden soll. Die Reaktion darauf wäre das Starten der Interpretation der aktuellen USB Daten Sequenz.
  • Alle Daten können in das EEPROM gespeichert und daraus geladen werden.
  • Das Startverhalten der Firmware kann in einem im EEPROM abgelegten Konfigurations-Wort festgelegt werden. Es kann hier festgelegt werden, welche Daten beim Start geladen werden sollen, ob die Sequenz-Daten direkt nach dem Start interpretiert werden sollen und ob auf eingehende Daten reagiert werden soll.
  • Eine Online-Hilfe mit Beschreibung aller verfügbaren Kommandos.
  • Wie oben schon erwähnt kann der Bootloader aus der Firmware heraus gestartet werden.

Da die Benutzerfreundlichkeit dieser Features, auf dem TTY, aber leider aufgrund dessen, dass nur unnötig weiterer Speicherplatz im Flash verschwendet werden würde, leidet, habe ich eine kleine GUI geschrieben, um speziell die Sequenzen von USB Daten komfortabler erzeugen und an den HackStick übertragen zu können. Geschrieben ist die Software in Java. Die mit der GUI erzeugten KeyCode-Sequenzen können z.B. bei der Verwendung eines im HackStick festgelegten Hid Keyboard Descriptors, als Tastatureingaben einer Tastatur an den Host gesendet werden. Die Daten werden bei der Erzeugung differentiell in der Sequenz abgelegt. Wer jedoch auf die GUI verzichten möchte kann die im Projekt enthaltene HackStick Klasse auch auf der Kommandozeile zum Übertragen von Dateien verwenden. Zu den Sequenzen muss hierbei gesagt werden, dass der Inhalt der Sequenz-Daten erst in Verbindung mit einem gültigen USB Hid Descriptor für den Host einen Sinn ergeben. So macht es keinen Sinn, KeyCodes an den Host zu senden, wenn der HackStick sich per Hid Maus Descriptor als Maus ausgibt.

Zum Abschluss gibt es, wie so häufig, ein kurzes Video.

 

Der Stick wurde hier so konfiguriert, dass er sich als Hid Keyboard ausgibt und im EEPROM wurden Daten abgelegt, die gesendet werden sobald der Status einer aktivierten NumLock-Taste vom Betriebssystem an die neu angeschlossene Tastatur übergeben wurde. Das ganze kann beliebig oft getriggert werden in dem diese Taste mehrfach betätigt wird.

Edit (2011-05-04 19:46): Bilder der ersten Platinen gibt es hier.

Edit (2011-06-06 22:57): Seit heute gibt es ein GitHub Repository.

Mittwoch, 10. Februar 2010

USBaspLoader und der GCC-AVR (4.3.3) in Verbindung mit Ubuntu 9.10 (amd64)

Habe ich mich doch vor ein paar Monaten dazu entschlossen mein altes 8.10 Ubuntu (32Bit) durch die neue Ubuntu 9.10 (64 Bit) zu ersetzen. Bisher war ich auch weitgehend überzeugt von der Performance und der Verfügbarkeit der Softwarepakete. Sicher gibt es das eine oder andere Problem, wie zum Beispiel das kein Flash Plugin für den Firefox richtig läuft [solved] oder das manche Programme die libSDL verwenden sich nur mit kill -9 beenden lassen...

Alles in allem aber zu verkraften, Programme die nicht funktionieren werden ggf. aus den Sourcen kompiliert und das Problem ist erledigt.

Aber an manchen Stellen gibt es dann das eine oder andere Tool das einen Stunden seines Lebens kostet. So zum Beispiel der GCC (4.3.3) Compiler aus dem gcc-avr Paket.
Dieser beinhaltet laut diversen einschlägigen Foren eine bessere Optimierung des erzeugten Binary Codes. Optimiert wurde also auch die Option, welche beim übersetzen einer Firmware für Microkontroller normalerweise immer verwendet wird. Die Option -Os. Diese wird an den gcc übergeben um die "kleinstmögliche" Firmware zu generieren. Leider geht der löbliche Optimierungswahn der GCC Entwickler hier ganz klar am Ziel vorbei. Der optimierte Binary-Code ist wesentlich größer als der von älteren gcc-Versionen - tolle Sache...

Mein ATMega168 für den HackStick besitzt 16KB Flash Speicher wovon 2KB für einen Bootloader reserviert werden können. In meinem Fall soll im Bootloader die Firmware des USBaspLoader-Projektes laufen um den HackStick direkt per USB flashen zu können.
Da ist es nicht gerade förderlich, dass der gcc nicht dazu überredet werden kann den, in diesem Fall um 140 Byte(!!!) größeren Binary Code auf die ursprüngliche Größe von 2002 Byte zu verkleinern.

Die Firmware des Bootloaders ist durch das Überschreiten der 2048 verfügbaren Bytes natürlich nicht übertragbar. Zum Glück besitzt man ja nicht nur einen Rechner und so konnte ich die Firmware auf einem anderen kompilieren und übertragen, ohne mir einen älteren GCC installieren zu müssen. Über kurz oder lang kommt man aber bei Ubuntu 9.10 (amd64) nicht drum herum.

Schlussendlich ergab sich aus all dem ein Patch gegen die mittlerweile doch in die Tage gekommenen Version der Firmware des USBaspLoader vom 20.3.2009. Zum einen beinhaltet dieser Patch nun den neuesten Release von V-USB und kleinere Änderungen um den USBaspLoader auf einem ATMega168 lauffähig zu bekommen.

Freitag, 22. Januar 2010

klaute's HackStick (v0b00000010)

Lange ist es her das ich über den Stick geschrieben habe, es hat sich auch nicht all zu viel getan.

Die Firmware hat ein paar neue Features bekommen und wurde, gerade was die Performance und Speichernutzung angeht, optimiert.

Eine wesentliche Änderung ist eine kleine Platine die auf den Stick gesteckt wird und die Pegelwandlung von den +5V des AVR's auf die bipolaren Spannungen einer RS232 Schnittstelle angleicht.

Oder kurz und einfach gesagt, ich habe einen MAX232 angeschlossen ;-)

Im Moment arbeite ich an dem Fuzzer und demnächst wird der ATMega8-16PU (8kB flash) durch einen ATMega168-20 ersetzt, wodurch sich der Flashspeicher verdoppelt und die Taktfrequenz von 16MHz auf 20MHz erhöht. Der neue Mikrocontroller sollte ein gutes Stück weniger mit der USB-Verbindung ausgelastet sein als vorher und zudem steht das doppelte an Flash zur Verfügung. Allerdings ist die Firmware mittlerweile ~8 kB groß, was mich auf die Idee zum wechseln gebracht hatte... ;)

Montag, 12. Oktober 2009

klaute's HackStick

Eigentlich wollte ich erst darüber schreiben sobald er fertig ist, allerdings hat sich das ganze als ein recht anspruchsvolles und vor allem zeit intensives Projekt entpuppt.
Es geht um meinen USB HackStick an dem ich nun schon seit Anfang April mehr oder weniger regelmäßig arbeite. Die Idee so ein Tool zu entwickeln kam während einem Gespräch auf einem treffen der LUUG-HN. Es ging im Laufe dieses Gesprächs zunächst um die Sicherheit bzw. Angreifbarkeit von Modulen im Linux-Kernel.
Die Idee war zunächst, sich dabei die Module im Linux-Kernel heraus zu picken, welche seit mehr als 12 Monaten nicht mehr "gefixt" wurden, um sie gründlich auf etwaige sicherheitskritische Probleme zu untersuchen. Besonders auffällig wurden uns, nach kurzer Suche, die Module für den Parallel- und USB.-Port Da jedoch die Parallelports am aussterben waren bzw. bereits ausgestorben sind wanderte der Fokus schnell auf die USB Schnittstelle. Es kam also die Frage auf ob der USB-Stack von außen, also per USB-Device , angreifbar ist. Um dies herauszufinden könnte man nun den Code des USB-Stack durchgehen und daraufhin dann ein Device für den daraus resultierenden Exploit ggf. herzustellen. Oder man dreht das ganze um, baut erst die Hardware und lässt diese gezielt den USB-Stack auf Lücken untersuchen (Fuzzing).

Der HackStick ist also ein Device welches dazu verwendet werden, kann händisch oder automatisch, per TTY direkt den USB-Stack zu penetrieren.

Was die Hardware für den HackStick angeht, sie ist recht simpel gehalten. Im groben besteht diese aus einem Atmel AVR-Mikrocontroller mit 16 MHz Taktung, ein paar Widerständen, LED's zur Statusanzeige und verschiedenen Schnittstellen. Die Software/Firmware auf dem Stick beinhaltet einmal einen USB Stack für HID Devices (V USB) und ein TTY welches auf das per RS232 zugegriffen werden kann. Die Firmware ist größtenteils in C geschrieben. Je nachdem welche Funktionen in der Firmware aktiviert wurden kann der Stick direkt per USB (USBASP kompatibel) oder per ISP programmiert werden. Da in der aktuellen Version noch kein TreiberIC für RS232 enthalten ist muss noch eine Treiberplatine an den Stick angeschlossen werden um auf das TTY zugreifen zu können. Der Stick ist momentan in den letzten Schritten, um mit dem Fuzzing effektiv starten zu können.

Um eine grobe Vorstellung zu bekommen wie das ganze Live aussieht hier noch ein paar Videos...
Das erste der beiden folgenden Videos zeigt einen Teil der Grundfunktionen des TTY sowie der entsprechenden Syslog ausgaben. Das zweite wie mit dem HackStick ein USB GamePad nachgebildet wird.








PowerMgr: Mein selbst gebautes Energie- und Smart-Home-System

PowerMgr: Mein selbst gebautes Energie- und Smart-Home-System PowerMgr ist mein eigenes Home-Energy-Management-System. Es verbindet Photov...