RUNNINGSERVER.com
Stoppt die Vorratsdatenspeicherung! Jetzt klicken & handeln!Willst du auch bei der Aktion teilnehmen? Hier findest du alle relevanten Infos und Materialien:
StartseiteDownloadThE lAb!LinksImpressumFaq
GO!
Menü:

Interessantes
The Lab - Das Labor
The Lab - Das Mikorwellenmessgerät
The Lab - Die Volksleinwand
The Lab - EL84 Roehrenverstaerker
The Lab - BodyElectric
The Lab - Mikrowelle schlachten
The Lab - pdp8-Panel
The Lab - pdp8-Panel
The Lab - Röntgenstrahlung
The Lab - Omi´s Teletype
The Lab - MBS128
The Lab - Das Datenklo
The Lab - Teleschirm 101

Nützliches
The Lab - Das Serielle Terminal
The Lab - Röhrenmonitor kalibrieren
The Lab - Der Infrarot Repeater
The Lab - Der Infrarot Repeater 2
The Lab - Der Nokia 3330 Fernschalter
The Lab - SGI Adapter
The Lab - Dornroeßchenschaltung
The Lab - RFID-Zapper
The Lab - Siemens P1 entsperren
The Lab - Die Wetterstation
The Lab - Die Wetterstation 2.0
The Lab - Kolophoniumkombüse

Lustiges
The Lab - Mykro Fernseher
The Lab - Das Kressexperiment
The Lab - Der Mini Hochspannungstrafo
The Lab - Monitor und Anlage verbinden
The Lab - Chaos Remote

Chipkarten
The Lab - ChicardLab
The Lab - DeveloperCard
The Lab - geekKarte
The Lab - Xcos
The Lab - Magnetkarten
The Lab - Datengarten
The Lab - rfidLab

Platinenfertigung:
The Lab - Tonertransfer
The Lab - Platinen belichten
The Lab - Platinen Ätzen
The Lab - SMD Löten

DEC:
The Lab - Vax Adapter
The Lab - QBus Vorlage
The Lab - QBus Vorlage
The Lab - pdp11tool

Laser:
The Lab - Laser
The Lab - Laser Leistungsbegrenzer
The Lab - Laser Spiegelhalter
The Lab - Laser Strahlschalter
The Lab - ALC60 Gold Control
The Lab - Vectorchrom
The Lab - Diode-Controller
The Lab - ilda2signleened

Bildschirmtext:
The Lab - Bildschirmtrix
The Lab - DBT-03 Modem
The Lab - miniBTX
The Lab - mikroPAD

Funk:
The Lab - Usrp external Clock
The Lab - Die Funkantenne
The Lab - Lband Empfang

Bitte wählen Sie das Projekt aus das Sie ansehen möchten.
Info:
Willkommen im Lab, dem Labor von Runningserver.com. Diese Seiten sollen ihnen Einblick in meine Arbeit verschaffen und zeigen was alles möglich ist und wie man Spaß mit Technik haben kann.

Wenn Sie noch Fragen zu den hier gezeigten Versuchen haben schreiben sie mir einfach eine Email. Diese Seiten befinden sich zur Zeit noch im Aufbau.

Email Bitte Beachten Sie auch die Hindweise in Faq und Impressum bevor Sie sich die Programme herunterladen.

Achtung, ein Teil der hier gezeigten Experimente ist nicht unbedingt ernst gemeint und teilweise lebensgefährlich, ich rate vom nachmachen bestimmter Experimente ab und hafte weder für etwaige Personenschäden oder Schäden die durch das nachmachen eines der hier gezeigten Experimente entstehen könnten.
The Lab - das dbt03

Das dbt03:
Klicken Sie auf das Bild um es zu vergrößern Um auf das BTX-Netz der Bundespost zugreifen zu können benötigte man eine spezielle Anschlussbox. Die Post nannte das Gerät "DBT-03" Was die Bezeichnung genau bedeutet ist nicht überliefert. Das dbt03 war im Grunde nichts anderes als ein Modem des V.23 Standarts. Die Übertragungsgeschwindigkeit beträgt 1200 Baud von der Zentrale zum Teilnehmer und 75 Baud vom Teilnehmer zur Zentrale. Allerdings war das Modem kein richtiges, jedenfalls kein Modem das für andere Dinge außer BTX brauchbar gewesen wäre. Man konnte damit nicht einfach eine beliebige Nummer anwählen sondern nur die fest einprogramierten Anwahlnummern der BTX-Zentrale. Einen Luxus wie AT-Kommandos kannte das dbt03 nicht. Eine Anwahl funktionierte in etwa so: Das Terminal teilte sein Wählbedürfnis mit in dem es einen I/O Pin auf High-Pegel zog. Dann fing das Modem an zu wählen und tauschte eine geheime Hardwarekennung aus. Erst wenn die Kennung ausgetauscht war und damit das Login in der BTX-Zentrale erfolgt war folgte die eigentliche Benutzeridentifikation in form einer normalen BTX-Seite bei der dann das Kennwort eingegeben wurde. Im Netz findet man viel oberflächliche Informationen über die Funktionsweise des dbt03. Wir wollen hier einmal hinter die Kulissen schauen und ein par Dinge aufarbeiten bisher viel zu kurz gekommen sind. Außerdem ist das ganze eine schöne Übung aus dem Bereich Reverse-engeneering.

Öffnen verboten:
Klicken Sie auf das Bild um es zu vergrößern Da wie schon erwähnt die Hardwarekennung oder auch Anschlusskennung im Modem gespeichert war, war es strengstens verboten das Modem zu öffnen. Auf der Vorderseite stand eine deutliche Warnung: "Unberechtigtes Öffnen wird strafrechtlich verfolgt" Die Gehäuse waren sogar richtig verblompt. Neue Geräte hatten eine gelbe Plombe und instand gesetzte eine blaue. Natürlich war hin und wieder die Neugier einfach größer als die Angst vor Strafen. Die Standartausrede war übrigens das das Gehäuse des Modems durch einen herabfallen Gummibaum zerstört worden sei. Heute ist die Post Geschichte und wir können, ohne Strafen befürchten zu müssen, das Gehäuse öffnen. Genau das werden wir jetzt tun: Die Plombe sollte möglichst erhalten bleiben und mit etwas Fingerspitzengefühl schafft man das auch. Das Gehäuse hat an den Seiten keine Klickmotageähnlichen Einrastungen. Lediglich hinten auf der Seite wo sich der Testknopf befindet sind zwei Einrastungen. Diese kann man leicht mit einem Plektum oder vergleichbarem zum ausrasten bringen. Dann kann man das Gehäuse an der Stelle auseinanderbiegen und die Plombe mit einem langen Schraubenzieher von innen herausdrücken. Man muss allerdings sehr aufpassen da die Blombe schell bricht da sie aus einem spröden Kunststoff gefertigt ist. Hat man die Blombe draußen kann man die kleine Verriegelung mit etwas spitzem in Richtung Testknopf drucken und den Deckel abnehmen. Die Platine ist ebenfalls im Gehäuse verklickt, wir können sie leicht herausnehmen.

Platinenlesen:
Klicken Sie auf das Bild um es zu vergrößern Nun wollen wir uns die Platine einmal genauer ansehen und darin lesen: Die Platine ist aus Hartpapier, einseitig. Auf der Rückseite vollverzinnt - kein Lötstopplack. Auf der Rückseite finden wir die Stempel die den Abschluss eines Produktionsschrittes markieren. Die Platine ist mit Kabeln gepatcht. Der Schalter der zwischen den zwei festen Anwahlnummern hin und herschaltet ist mit Kabeln angeschlossen und mit Heißkleber auf die Platine geklebt Dann gibt es noch eine kurze Drahtbrücke. Folgt man der betreffenen Leiterbahn stellt man fest das sie absichtlich unterbrochen wurde. Offenbar wurde hier ein Layoutfehler korrigiert. Das betreffende Modem scheint also aus einer frühen Serie. Reversengeneering ist ein bisschen wie eine Schnitzeljagt. Wir wollen wissen wo die Hardwarekennung herkommt und noch mehr, wir wollen sie auslesen. Wir lassen den Blick über die Platine schweifen. Halb unter dem Lautsprecher versteckt ist ein großer IC mit der Bezeichnung TMS1000N. Internetrechere ergibt das es sich um einen 4-Bit Mikrocontroller handelt - ein möglicher Ort für die Hardwarekennung. Allerdings ist es aus Produktionsslogistischen Gründen schlecht veränderliche Daten mit im Programmspeicher eines Mikrocontroller unzerzubringen. Zumal es bei vielen Herstellern eine beliebte Dienstleistung ist die Mikrocontroller schon bei der Produktion mit der Firmware des Kunden zu bespielen. Wenn das Firmwareimage jedes mal ein anderes ist muss der Programmierprozess für jeden einzelnen Controller mit einem neu gepatchten Binary erfolgen. Manchmal ist es einfacher Dinge in einem externen Speichermedium unterzubringen. Wir lassen also den Blick weiter nach programmierbaren Bausteinen schweifen. Direkt neben dem Controller befindet sich ein verdächtiger Baustein mit einer aufgeklebt Nummer. Die Nummer ist zehnstellig, ob es wohl die gesuchte Hardwarekennung ist? Wir ziehen den Aufkleber ab und finden einen TBP18SA-030 vor. Das ist ein OTP-Eprom, 8-Bit breit, 32 tief. Damit können jetzt mit großer Wahrscheinlichkeit sagen das dieser Baustein womöglich die Hardwarekennung enthält. Und wir können noch mehr sehen: Laut Datenblatt sind Pin 10-14 (Man zählt die Pins U-Förmig wenn die Kerbe oben ist) die Adressleitungen. Pin 10 ist A0 und Pin 14 ist A4. Pin 14 ist durch die Drahtbrücke an VCC. Das schränkt den Adressraum in dem gültige Daten stehen schon mal gewaltig ein, es gibt jetzt nur noch 16 gültige Adressen. Weiter sehen wir das die oberen 4 Datenleitungen (Pin 5,6,7 und 9) nicht angeschlossen sind. Das bedeutet das nur die unteren 4 Bit des Roms genutzt werden. Das macht auch einen gewissen Sinn, denn der Controller ist eine 4-Bit Maschine und 4 Bit reichen auch allemal aus um Zahlen von 1-10 zu codieren. Man denke an die BCD-Codierung. Es ist etwas Abenteuerlich die letzen 4 verbliebenden Datenleitungen zu verfolgen, aber über Umwege landen sie letztendlich wieder beim Controller. Wahrscheinlich sind die I/O Pins des Controllers mehrfach belegt - aber das kann der angehende reverse Engeneer als Hausaufgabe herausfinden. Man sieht also, man kann durch scharfes hinsehen schon viel über eine Hardware in Erfahrung bringen. Bis hier hin haben wir noch nicht ein Messgerät benutzt und wissen schon eine Menge

Auslesen der Hardwarekennung:
Klicken Sie auf das Bild um es zu vergrößern Die Kennung war geheim. Davon erhoffte man sich einen Sicherheitsvorteil, der allerdings dadurch wieder zu nichte gemacht wurde das die Kennung im Klartext übertragen wurde. Man brauchte nur die Töne in der Telefonleitung mitzuören und konnte daraus problemlos die Kennung rekonstruieren. Der einzige Abhörschutz war das die Kennung selbst mit 7e1 anstat 8n1 übertragen wurde. Die Frames sind also gleich lang, soetwas sieht auf den ersten Blick so aus als sein eine Verschlüsselung im Spiel. Dieses Konzept nennt man in der Fachwelt auch "Security by Obscurity" Allerdings hat die Zeit gezeigt das dieser Ansatz nicht funktioniert, dennoch kommt es hin und wieder vor das man versucht durch Taschenspielertricks und Geheimhaltung Sicherheit zu erzeugen. Im übrigen wäre im Falle von BTX ein brauchbares Sicherheitslevel erst mit einer Ende-Ende Verschlüsselung eingetreten - damals auf Grund mangelnder Rechenleistung fast unmöglich. Wir werden in unserem Fall einen ungewöhnlichen Weg gehen, wir lesen die Hardwarekennung einfach manuell, das heißt ohne einen speziellen Eprombrenner oder ähnliches zu benutzen, aus. Dazu löten wir das Eprom von der Platine und stecken es auf ein Breadboard. Da wir nur 16 a 4-Bit mit 4-Bit Worten überprüfen müssen legen wir jede einzelne Adresse mit Steckdräten manuell an und lesen das Ergebnis Bit für Bit mit einem Logiktester ab. Es ist überliefert das die Hardwarekennung eine 12 stellige Nummer gewesen ist und tatsächlich, wir erhalten eine 12 stellige Zahl mit führenden Nullen: 000001A191A51A923 (Die letzte Zahl beflügelt unsere Phantasie besonders ;-) Um auf Nummer sicher zu gehen müsste man das Rom jetzt wieder einbauen, einen Linienstrom in das Modem einprägen und dem Modem eine erfolgreiche Einwahl vortäuschen. Dann müsste man mit einem Audio-Spektrumanalyser (z.B.: Baudline) die Hardwarekennung direkt sehen können.

Protokoll:
Klicken Sie auf das Bild um es zu vergrößern Im Hinblick auf eine Implementation die mit alten BTX-Terminals interagiert und dort BTX-Seiten anzeigt war das Kommunikationsprotokoll zwischen dbt03 und BTX-Terminal von großer Wichtigkeit. Die Hackerbibel lässt sich knapp über die Signale des dbt03 in schlecht formulierten Textbrocken aus. (Die original POST-Doku ist übrigens auch nicht besser!) Das an sich recht einfach geartete Protokoll des DBT-03 ist in der Hackerbibel leider etwas verwirrend dargestellt. Aber schauen wir es uns einfach an: Zunächst muss gesagt werden das der Ausgang des Modem sich wie ein Open-collector Ausgang verhält. Damit man Daten vom Modem bekommt muss man diesen mit einem 10k Widerstand auf auf high-pegel ziehen. Gestartet wird das Modem in dem man die Start-Leitung (pin-7) auf High zieht. Die ED (Empfangsleitung 1200Baud, 8n1, pin-5) geht dann auch sofort auf (hochohmig) high. Dieser Zustand bleibt etwa 3 Sekunden erhalten bis das Modem nach 3 Sekunden abhebt. Und jetzt kommt etwas wirklich pfiffiges: Der Wählton der jetzt vom Modem empfangen wird, wird mit in Form eines Rechteckssignals am ED-Port ausgegeben. Die Periodendauer entspricht den normalen 425Hz, also ca. 2,35ms. Nur halt als Rechteckssignal. Das BTX-Terminal hört sozusagen den Wählton mit und erkennt so ob die Leitung frei ist. Hört der Wählton auf weiß das Terminal das der Anwahlprozess begonnen hat. Nach der Anwahl hört das Terminal den Klingelton. Jetzt ist klar: Gleich werden die ersten Daten eintreffen. Hebt die BTX-Zentrale ab, sendet sie einen 1300Hz Trägerton. Dieser kommt zunächst auch beim Terminal an. Hat das Modem den Träger erkannt, tauscht es noch schnell die geheime Benuzerkennung aus und zieht die SD-Leitung dann auf Masse. Jetzt ist alles bereit und es können Daten an das Terminal gesendet werden. Übertragen werden die Daten mit invertiertem Uart-Pegel. Invertiert bedeutet das der Ruhezustand der Leitung Low und nicht High, wie man das eigentlich von Uart-Pegeln gewohnt ist, die mit TTL-Pegeln abgewickelt werden. Interessanterweise ist es beim Rückkanal genau umgekehrt, hier finden wir ein gewöhnliches TTL-Uart vor. Zum besseren Verständnis habe ich mal ein Diagramm von dem Protokoll erstellt. Man kann das ganze auch selbst beobachten: Hängt man ein dbt03 ganz normal an die Telefoneitung kann man auf einem Oszilloskop die Hörtöne der Telefonleitung sehen. Leider kann man heute nicht mehr den kompletten Einwahlvorgang beobachten da es BTX nicht mehr gibt. Fairerweise muss man auch erwähnen das es in der Hackerbibel auch hilfreiches steht. Zum beispiel ist dort ausformuliert wie man ein String abgefasst werden muss der auf dem Terminal dargestellt werden soll. Nur wurde vergessen zu dem CRC16 Polynom zu ewähnen das der inital-value 0x0000 entspricht und das das niderwertige Byte zuerst übertragen wird. Auch das die Kommunikation nicht in RS232 sondern TTL abgewickelt wird ist schlicht unterschlagen worden. Im übrigen hat meine Erfahrung gezeigt das man sich bei BTX die komplette Sicherrungsschicht auch schenken kann. Es reicht einfach Zeichen an das Terminal zu senden. Das Bild zeigt übrigens ein BTX-Terminal (BtxTV von Siemens) das eine von einem Mikrocontroller (miniBTX) ausgegebene Testseite anzeigt.

Fazit:
Klicken Sie auf das Bild um es zu vergrößern Das manuelle auslesen der Hardwarekennung hat Spaß gemacht. Es war interessant mal nachgeschaut zu haben und den angenehmen Schauer genießen zu können der einen überkommt wenn man daran denkt das man vor nicht allzu langer Zeit für soetwas hätte ins Gefängnis kommen können. Von großer Wichtigkeit war jedoch die Protokollanalyse zwischen Terminal und Modem um ein virtuelles dbt03 in einem Mikrocontroller implementieren zu können. Bemerkenswert ist übrigens das das Modem mit aus dem Telefonnetz mit Strom versorgt wird, das bedeutet das es nicht mehr als 60mA verbrauchen durfte - das ist schon eine technische Leistung.

trust-us.ch/... - Hackerbibel: dbt03 Signale
computerwoche.de/... - COMPUTERWOCHE 49/1983 zum dbt03
trust-us.ch/... - Hackerbibel: BTX Das Unsicherheitsystem
de.wikipedia.org/... - Wikipedia: Bildschirmtext

(c)2001-2015 Philipp Maier, Hohen Neuendorf