Aus Linux-Magazin 06/2010

Hardware-Debugschnittstelle JTAG auslesen

© Ewa Walicka, Fotolia.com© Vindicator, CC-BY 3.0

Versierte Anwender machen sich den Firmware-Update-Mechanismus von WLAN-Routern und anderen Geräten zunutze, um ein eigenes Linux aufzuspielen. Besitzt ein Gerät keine Update-Möglichkeit, aber eine JTAG-Diagnose-Schnittstelle, lässt es sich oft dennoch ein Linux transplantieren .

Nicht nur der Gerätehersteller kann versuchen fremde Firmware zu verhindern. Auch mancher User sperrt sich bisweilen selbst aus, wenn er beim Update den Bootloader schrottet. In beiden Fällen schafft eine in vielen Chips hart verdrahtete JTAG-Schnittstelle (Joint Test Action Group) Abhilfe [1]. Sie arbeitet auch ohne funktionstüchtige Software auf dem Gerät. Dazu wird die oft als Lötpunkte herausgeführte Schnittstelle des Geräts über einen JTAG-Adapter mit einem PC verbunden. Mit passender Software greifen Bastler dann via JTAG-Protokoll auf das Zielgerät zu.

Neben dem Wiederbeleben von Geräten mit defekten Bootloadern verwenden sie JTAG auch noch dazu, um Zugriff auf Geräte ohne serielle Schnittstelle zu erhalten oder bei ihnen die Software zu verändern – denn die beruht immer öfter auf eingebettetem Linux. So lassen sich manche Zusatzfunktionen wie Set-top-Boxen oder Flachbildschirme bis hin zu Mobiltelefonen nutzen.

JTAG ist bei solchen Systemen eigentlich nur für den Hersteller zum Programmieren der Geräte und für die Fehlersuche gedacht. Daher besteht die erste Herausforderung darin, die Schnittstelle im Innern der Geräte zu lokalisieren, wobei Kenntnisse über die Funktionsweise der Schnittstelle hilfreich sind.

Den Eingang finden

Hinter der Abkürzung JTAG verbirgt sich ein 1985 gegründetes Herstellerkonsortium, das die Schnittstelle ursprünglich entwickelte, um elektrische Verbindungen auf bestückten Platinen automatisiert zu prüfen. Offiziell standardisiert IEEE 1149.1 das Verfahren und dessen Schnittstelle.

Die zunehmende Miniaturisierung integrierter Schaltkreise erfordert einen definierten Zugang, da sich Leiterbahnen bei mehrlagigen Platinen zu Testzwecken oft nicht mehr direkt kontaktieren lassen. Mit JTAG dürfen Entwickler an allen Ein- und Ausgängen des Chips einen High- oder Low-Pegel anlegen oder den anliegenden Wert messen. So prüfen sie Verbindungen zwischen den einzelnen Chips.

Dank dieser Funktionalität können sie von einem Chip mit JTAG-Schnittstelle aus auch auf Bausteine ohne solche Schnittstelle zugreifen. Sie nutzen die JTAG-Schnittstelle eines Mikrocontrollers dazu, an den Controller angeschlossenen Flashspeicher zu lesen und zu beschreiben. Auf diesem Weg lässt sich sogar ein Bootloader in den Flashspeicher des Controllers programmieren. Dieses Verfahren erfordert jedoch sehr viel Zeit, da es die entsprechenden Anschlüsse des Chips fortlaufend via JTAG aktualisieren und abfragen muss.

Heute existieren für JTAG eine Vielzahl von herstellerspezifischen Erweiterungen, die derartige Buszugriffe beschleunigen und weitere nützliche Funktionen wie etwa Debugging bereitstellen. Damit lesen und ändern versierte Entwickler bei den meisten Microcontrollern im laufenden Betrieb auch den RAM-Speicher und die Register des Chips. Selbst das Setzen von Breakpoints via JTAG ist bei aktuellen Controllern möglich.

Ein schmaler Pfad

Um möglichst wenig Pins am Controller zu belegen, die sich nicht als normale Ein- und Ausgänge nutzen lassen, hat das Konsortium die Schnittstelle synchron und seriell realisiert. Sie ist an einen Zustandsautomaten gekoppelt und benötigt lediglich vier Pins, sie tragen die Kürzel TCK, TMS, TDI und TDO. Der Pin TCK (Test Clock) taktet die Schnittstelle. TMS (Test Mode Select) dient der Navigation im Zustandsautomaten. Über TDI (Test Data In) übertragen Anwender Daten zum Gerät hin, während TDO (Test Data Out) die Datenleitung für die Rückrichtung darstellt.

Die optionale Leitung TRST (Test Reset) dient dazu, die Schnittstelle in einen definierten Ausgangszustand zu versetzen. Da keine einheitliche Steckerbelegung für JTAG-Anschlüsse existiert, besteht bei fremden Geräten die erste Herausforderung darin, die Kontakte für TCK, TMS, TDI und TDO auf der Platine zu finden.

Geräte in Ketten aufreihen

Um die Anschlüsse zu lokalisieren, ist es zunächst nötig, die Funktionsweise von JTAG detaillierter zu verstehen. In aktuellen Geräten finden sich häufig mehrere Chips mit JTAG-Schnittstellen. Dabei genügt ein Anschluss auf der Platine, um alle Interfaces zu bedienen. JTAG fasst die einzelnen Chips zu einer so genannten Scan Chain zusammen. Die Kette entsteht, indem Hersteller den TDO-Ausgang eines Chips mit dem TDI-Eingang des nächsten Chips verbinden. Diese Kaskade lässt sich, wie in Abbildung 1 dargestellt, prinzipiell beliebig um weitere Chips erweitern.

Abbildung 1: Einzelne JTAG-Bausteine lassen sich zu einer Kette zusammenschalten. Dazu verbinden Entwickler jeweils den TDO-Ausgang mit dem TDI-Eingang des nächsten Geräts.

Abbildung 1: Einzelne JTAG-Bausteine lassen sich zu einer Kette zusammenschalten. Dazu verbinden Entwickler jeweils den TDO-Ausgang mit dem TDI-Eingang des nächsten Geräts.

In jedem Chip liegt zwischen TDI und TDO ein Schieberegister, in das Anwender die Daten über TDI mit TCK getaktet hineinschieben. Am gegenüberliegenden Ende des Schieberegisters lässt die Kette die Daten über TDO aus dem Register wieder hinaus. Durch das Verbinden von TDO eines Chips mit TDI des nächsten Chips entsteht daher insgesamt wieder ein längeres Schieberegister, das sich aus den Registern der einzelnen Chips zusammensetzt. Jeder Baustein beinhaltet mehrere dieser Schieberegister. Auf welches davon der Zugriff via TDI und TDO erfolgen soll, kontrolliert der Zustandsautomat aus Abbildung 2.

Die Navigation zwischen den Zuständen erfolgt über TMS. Der für den jeweiligen Zustandsübergang nötige Wert für TMS lässt sich an den entsprechenden Kanten der Abbildung 2 ablesen. Mittels TRST kann der Entwickler den Zustandsautomaten jederzeit in den Zustand »Test-Logic-Reset« versetzen.

Abbildung 2: Ein Zustandsautomat kontrolliert, auf welches Schieberegister Anwender über die Ketten von TDI- und TDO-Anschlüssen Zugriff erhalten.

Abbildung 2: Ein Zustandsautomat kontrolliert, auf welches Schieberegister Anwender über die Ketten von TDI- und TDO-Anschlüssen Zugriff erhalten.

Bei näherer Betrachtung des Zustandsautomaten stellt sich außerdem heraus, dass sich dieser Zustand ebenfalls aus jedem anderen Zustand erreichen lässt, wenn der Eingang TMS fünf TCK-Takte lang auf »1« liegt. Daher ist der TRST-Pin funktional optional.

Im Zustandsautomaten ähneln sich zwei längere Zustandsfolgen. Sie dienen dem Zugriff auf Instruktionsregister (IR) und Datenregister (DR), beides Schieberegister. Im »Capture«-Zustand lädt der Chip das Schieberegister zunächst mit dem Wert, den der Anwender anschließend in »Shift« ausliest. Für jedes via TDO gelesene Bit schiebt er ein neues Bit in das Schieberegister nach, sodass ein reiner Lesezugriff nicht ohne Weiteres möglich ist. Der Chip übernimmt im »Update«-Zustand den ins Register geschobenen Wert und wertet ihn aus.

Rundreise für Bits

Wer ein Bit über TDI in das Instruktions- oder Datenregister schiebt, erhält es an TDO wieder, nachdem es alle verketteten Schieberegister durchlaufen hat. Die dafür nötige Anzahl an TCK-Takten ist um einen größer als die Länge der verketteten Register. Diese Eigenschaft lässt sich ausnutzen, um die richtige Kontaktbelegung effizient zu ermitteln.

Jede mögliche Kombination aus TCK, TMS und TDI prüfen Interessierte mit folgendem Verfahren: Sie halten zunächst TMS für fünf Takte auf »1«, um in den Test-Logic-Reset-Zustand zu gelangen. Ausgehend davon wechseln sie wieder mittels TMS in den Zustand Shift-IR. Wählen die Hardwaredetektive für TCK und TMS die richtigen Pins, liegt zwischen TDI und TDO jetzt das Instruktions-Schieberegister.

Geräteforscher versuchen nun über einen TDI-Kandidaten Daten zu shiften, die aus mehreren Nullen und Einsen bestehen. Anschließend beobachten sie, ob die Folge nach einigen Takten an einem anderen Pin des Geräts erscheint. Der ist dann TDO – und die korrekte JTAG-Belegung mit hoher Wahrscheinlichkeit ermittelt.

Der JTAG-Finder implementiert das beschriebene Verfahren und ist in der Lage, innerhalb einiger Minuten aus bis zu 30 Pins die richtigen JTAG-Pins zu ermitteln [2]. Zur Kontaktierung der zu testenden Pins nutzen viele den beliebten und universell einsetzbaren ATMega32-AVR-Mikrocontroller, der via RS232 mit einem PC kommuniziert [3]. Auf dem läuft der JTAG-Finder mit seiner grafischen Oberfläche (Abbildung 3). Die unter der GPL stehende Software haben ihre Programmierer als Proof of Concept entwickelt [4]. Sie richtet sich vorwiegend an Anwender mit Elektronik- und Mikrocontroller-Kenntnissen.

Abbildung 3: Der JTAG-Finder hat eine grafische Oberfläche, mit der Anwender prüfen, ob eine in den Pin TDI geschobene Bitfolge an Pin TDO wieder auftaucht.

Abbildung 3: Der JTAG-Finder hat eine grafische Oberfläche, mit der Anwender prüfen, ob eine in den Pin TDI geschobene Bitfolge an Pin TDO wieder auftaucht.

Das Quellarchiv benötigt das Paket »libglade2-dev« für die GTK-Oberfläche, anschließend baut »make« das Programm. Vor seinem Start erwartet »jtagscan« den Pfad zum seriellen Port, an dem der Mikrocontroller hängt, in der Umgebungsvariablen »JTAGSCAN_DEVICE«. Die Zuordnung von Controllerausgängen zu logischen Pins legt »relocations.avr« Zeile für Zeile fest. Ist alles verdrahtet, probiert ein Klick auf »Scan« die möglichen Permutationen durch und protokolliert die Aktivitäten in einem Fenster.

Meist sehen Hersteller ein- oder zweireihige Stiftleisten mit fünf bis 20 Pins für JTAG-Schnittstellen vor. Allerdings bestücken sie diese aus Kostengründen in der Serienproduktion auf den Platinen oft nicht, sodass handwerklich begabte Bastler selbst eine passende Stiftleiste einlöten (siehe Abbildung 4).

Abbildung 4: Haben Hersteller für die Serienfertigung auf Stiftleisten für den JTAG-Anschluss verzichtet, sind eine ruhige Hand und ein Lötkolben nötig.

Abbildung 4: Haben Hersteller für die Serienfertigung auf Stiftleisten für den JTAG-Anschluss verzichtet, sind eine ruhige Hand und ein Lötkolben nötig.

Verbindungen herstellen

Bevor Anwender den Finder benutzen, treffen sie eine Vorauswahl möglicher JTAG-Pins. Trotz fehlender Standards haben sich einige Belegungen in den letzten Jahren durchgesetzt, die fleißige Entwickler zusammengetragen haben [5]. Bei zweireihigen Stiftleisten enthält eine der Reihen üblicherweise mehrere Masseverbindungen (GND). Sie dienen dazu, Störungen auf den Signalleitungen zu reduzieren. Mit einem Durchgangsprüfer lassen sich die GND-Verbindungen einfach identifizieren. Anwender verbinden mindestens eine der GND-Leitungen mit dem JTAG-Adapter.

Die meisten JTAG-Stecker verfügen über einen zusätzlichen Pin namens Vref oder Vsupply. Dieser stellt die Versorgungs-, beziehungsweise Referenzspannung für den JTAG-Adapter bereit. Über diesen Pin passt der JTAG-Adapter die Spannung für die Signalleitungen an die des Zielsystems an. Dies ist erforderlich, da es Mikrocontroller mit unterschiedlichen Versorgungsspannungen gibt. Üblich sind 1,2 Volt bis 3,3 Volt. Eine zu hohe Spannung an den JTAG-Anschlüssen kann zumindest die JTAG-Schnittstelle des Mikrocontrollers irreversibel beschädigen.

Vorsichtig stöbern

Um Störungen auf den JTAG-Anschlüssen zu vermeiden, solange kein Adapter angeschlossen ist, befinden sich an den Signalleitungen oft Pullup-Widerstände mit Werten zwischen 1 und 100 Kiloohm. Sie verbinden die Signalleitungen mit Vref beziehungsweise Vsupply, wodurch an den Leitungen ohne Programmieradapter eine Eins anliegt. Die Widerstände finden sich oft in der Nähe der Stiftleisten und sind mit einem Messgerät oder gar mit bloßem Auge zu erkennen.

Dann grenzen erfahrene Anwender die möglichen JTAG-Belegungen auch ohne JTAG-Finder ein und probieren die Belegungen manuell durch. Zum Testen benutzen sie einen gängigen JTAG-Adapter. Er sollte jedoch nicht direkt mit dem Zielsystem verbunden werden, da es sonst bei einer falschen Kontaktbelegung ebenfalls zu irreparablen Defekten am Gerät oder dem Adapter kommt.

Entdeckungen erkunden

Dieses Risiko lässt sich deutlich reduzieren, indem Vorsichtige die TCK-, TMS- und TDI-Leitungen des Adapters zunächst nur über in Serie geschaltete Widerstände mit dem Gerät verbinden. Der Widerstand begrenzt den maximalen Strom, der zwischen Adapter und dem Gerät fließt. Bei 3,3 Volt limitiert ein 330-Ohm-Widerstand den Strom auf 10 Milliampere. Dies gilt meist als sicherer Wert. Auch der JTAG-Finder verwendet ihn. Dennoch bleibt bei derartigen Hardware-Eingriffen naturgemäß immer ein Restrisiko.

Haben sie die Pins erst einmal identifiziert, greifen Anwender über einen Adapter vom Linux-Rechner auf das zu untersuchende Gerät zu. Die zwei wichtigsten Softwarepakete dazu sind Ur-JTAG [6] und Open OCD [7]. Bei der Wahl des JTAG-Adapters sollten sich Hardware-Forscher daher für einen Typ entscheiden, den sowohl Ur-JTAG als auch Open OCD unterstützen. FT2232-basierte Adapter, die diesen Konverter-Chip von FTDI verbauen, sind eine kluge Wahl, da beide Programme ihn unterstützen. Eine Liste weiterer Adapter findet sich ebenso wie Schaltpläne und Platinenlayouts für den Eigenbau auf einer Seite der Hochschule Augsburg [8].

Nachdem Entwickler den JTAG-Adapter wie beschrieben mit den wahrscheinlichen JTAG-Pins verbunden und Ur-JTAG installiert haben, testen sie den JTAG-Zugriff. Dazu starten sie – mit den erforderlichen Zugriffsrechten auf den USB-Bus versehen – Ur-JTAG mit dem Kommando »jtag«. Mit dem Kommando »cable FT2232« initialisieren sie dann den JTAG-Adapter.

Mit dem Befehl »detect« lassen sich die in der JTAG-Kette vorhandenen Chips identifizieren und anzeigen. Dazu nutzt Ur-JTAG die »IDCODE«-Anweisung. Die meisten Chips laden sie automatisch in das Instruktionsregister, sobald der Zustandsautomat in den Test-Logic-Reset-Zustand gelangt. Im Datenregister befindet sich dann die 32-Bit-Identifikationsnummer. Sie setzt sich aus einer Hersteller- und Chip-ID sowie einer Revisionsnummer zusammen.

Zeigt die Software keine Device-IDs an, ist der JTAG-Adapter entweder falsch angeschlossen oder die Chips geben den »IDCODE« nicht von sich aus preis. Zeigt Ur-JTAG nicht zumindest die Länge der Instruktionsregister an – beispielsweise durch die Ausgabe »IR length: 14« -, so ist der Adapter höchstwahrscheinlich falsch angeschlossen oder die JTAG-Schnittstelle des Geräts deaktiviert.

Belegungen nachschlagen

Kann Ur-JTAG dagegen nur die Komponenten nicht identifizieren, gibt der Anwender den Chip mit dem »include«-Kommando notfalls von Hand an. Ur-JTAG unterstützt bereits einige Chips und lässt sich gut erweitern. Das Programm kennt beispielsweise auch Dateien der Boundary Scan Description Language (BSDL). Sie beschreiben Chips und die von ihnen unterstützten Instruktionen in einer standardisierten Form und finden sich als Online-Sammlung [9].

Ur-JTAG vermag auch auf viele Flashspeicher via JTAG zuzugreifen und unterstützt das Serial Vector Format (SVF), das zusätzlich den Zugriff auf FPGAs ermöglicht. Die jeweilige Vorgehensweise hängt immer vom vorliegenden Chip ab, aber der Funktionsumfang von Ur-JTAG und seine Dokumentation helfen Anwendern mit einer Befehlsreferenz und einigen Anwendungsbeispielen.

Neben Ur-JTAG lässt sich JTAG unter Linux auch mit der Open-OCD-Software nutzen. Sie widmet sich primär ARM-Controllern und beherrscht im Gegensatz zu Ur-JTAG auch On-Chip-Debugging mit GDB. Auch dieses Projekt verfügt über detaillierte Erläuterungen verschiedener Chips und eine gute Einleitung [10].

Verborgene Funktionen erkunden und aktivieren

Da nicht nur bei Netzwerkgeräten, sondern auch bei allgemeiner Unterhaltungselektronik häufig Linux zum Einsatz kommt, lohnt sich ein näherer Blick auf das Innenleben der Geräte. Oft werden Technik-Forscher auf der Suche nach JTAG-Schnittstellen fündig. Mit den beschriebenen Methoden sind sie in der Lage, auf Interna der Systeme, etwa Flashspeicher, Funktionsregister oder Steuerlogik zuzugreifen, sie zu erweitern und besser an eigene Wünsche anzupassen. (mg)

Infos

[1] Felix Domke, “Blackbox JTAG Reverse Engineering”: 26c3, 2009:[http://events.ccc.de/congress/2009/Fahrplan/attachments/1435_JTAG.pdf]

[2] JTAG-Finder: [http://www.c3a.de/wiki/index.php/JTAG_Finder]

[3] Benedikt Sauter, “Zwerg am Drücker: Universeller USBprog-Adapter”: Linux-Magazin 03/08, S. 82

[4] Download des JTAG-Finder: [http://verbosemo.de/~hunz/jtagscan.tar.bz2]

[5] Zusammenstellungen typischer Pinouts: [http://www.jtagtest.com/pinouts/]

[6] Ur-JTAG: [http://urjtag.org]

[7] Open OCD: [http://openocd.berlios.de]

[8] Übersicht von JTAG-Adaptern:[http://www.hs-augsburg.de/~hhoegl/proj/usbjtag/usbjtag.html]

[9] JTAG-Funktionen in der Boundary Scan Description Language (BSDL):[http://bsdl.info/index.htm]

[10] Einführung in Open OCD: [http://www.hs-augsburg.de/~hhoegl/tmp/epjournal-1/oocd.html]

Der Autor

Benedikt Heinz arbeitet als wissenschaftlicher Mitarbeiter und beschäftigt sich mit der Sicherheit eingebetteter Systeme. In diesem Bereich liegt sein Interessenschwerpunkt derzeit auf Seitenkanal-Angriffen.

DIESEN ARTIKEL ALS PDF KAUFEN
EXPRESS-KAUF ALS PDFUmfang: 4 HeftseitenPreis €0,99
(inkl. 19% MwSt.)
LINUX-MAGAZIN KAUFEN
EINZELNE AUSGABE Print-Ausgaben Digitale Ausgaben
ABONNEMENTS Print-Abos Digitales Abo
TABLET & SMARTPHONE APPS Readly Logo
E-Mail Benachrichtigung
Benachrichtige mich zu:
1 Kommentar
Älteste
Neuste Beste Bewertung
Inline Feedbacks
Alle Kommentare anzeigen
Evi1M4chine
3 Jahre her

Und was macht man danach? Sagen wir ich hab jetzt Ur-JTAG am Laufen und eine Liste von Chips wird darin angezeigt. … Und nu? Der Schlußsatz „Mit den beschriebenen Methoden sind sie in der Lage, auf Interna der Systeme, etwa Flashspeicher, Funktionsregister oder Steuerlogik zuzugreifen, sie zu erweitern und besser an eigene Wünsche anzupassen.“ war eigentlich, warum ich herkam, und was ich wissen wollte. Ich hab den Artikel gelesen, kann aber jetzt nicht daraus schließen, wie ich das jetzt konkret mache? Ich kann irgendwelche Register setzen, und dann mit Update sagen der Chip soll was machen. Wo steht denn was… Mehr »

Nach oben