EEPROM umkodieren: Passwörter und Mechanik

Die zentrale Erkenntnis aus jahrelangen technischen Diskussionen: Transceiver- Kompatibilität ist keine Firmware-Frage — es sind Identifikationsstrings im EEPROM, ausgelesen über I²C. Ein Switch weist ein Modul allein deshalb zurück, weil er den Herstellerstring nicht erkennt. Genau diese Tatsache erklärt die verbreitete Praxis, „alles als Cisco zu codieren — das funktioniert fast überall“, und den gesamten Markt der Coding-Tools.

Wo die Passwörter liegen

Das Schreiben in geschützte Bereiche des Modulspeichers erfordert ein 4-Byte-Passwort, das vor dem Schreiben an einer festen Adresse eingegeben wird:

Häufig genannte Passwörter

Manche Hersteller liefern ihre QSFP-DD-Module mit eigenen festen Standardwerten aus, und einige mikroprozessorbasierte Module verwenden ein variables Passwort, das sich ändert — eine Falle für alle, die Brute-Force versuchen.

Warum Brute-Force nicht die Lösung ist

Ein Passwort auf Herstellerebene, das die gesamte Speicherbelegung schützt, benötigt in der Größenordnung von 100+ Tagen für einen Brute-Force-Angriff; selbst ein ASCII-Passwort auf Host-Ebene braucht bis zu etwa drei Tage. Der praktikable Weg ist eine Datenbank bekannter Codes und Passwörter, erfasst von Originalmodulen — genau darin liegt der eigentliche Wert eines Coding-Tools, nicht in der I²C-Hardware (die einfach ist).

Fallstricke bei selbstgebauten Programmiergeräten

• Günstige CH341A-Programmiergeräte berechnen die SFP-Prüfsumme nicht. Das Schreiben eines Abbilds ohne gültiges CC_BASE/CC_EXT erzeugt ein Modul, das der Switch zurückweist. Erforderlich ist ein Tool, das Prüfsummen automatisch neu berechnet.
• Manche Switches schreiben nur an Adresse 0x50, sodass das Passwort bei 0x51 vom Switch selbst nicht erreichbar ist — ein richtiges Programmiergerät ist nötig.
• Der Schreibschutz-Pin des EEPROMs — manche Hersteller verbinden WP fest mit Vcc, sodass das Modul im Feld gegen Schreiben gesperrt ist.

Fälle aus der Praxis

• Module, die für einen Hersteller codiert waren, autonegotiierten nicht an einem Switch eines anderen Herstellers; nach Neucodierung auf den eigenen Herstellerstring des Switches kamen sie sofort hoch.
• Manche Optik-Hersteller liefern uncodierte Module bewusst aus und erwarten, dass der Käufer sie für die Zielplattform codiert.
• DWDM-Module werden auf die Wellenlänge abgestimmt über dieselbe Management-Schnittstelle, die auch für die Codierung genutzt wird.

So geht es in CodingBox

1. Das Modul lesen; es wird automatisch in der Code-Datenbank gespeichert, und vor jedem Schreibvorgang wird eine Sicherung angelegt.
2. Tabellenadresse, Passwortadresse und Passwortwert unter Geschützter Speicher & Passwörter festlegen — bekannte Passwörter aus der Datenbank werden automatisch angewendet.
3. Hersteller, Teilenummer und andere Identitätsfelder im EEPROM-Editor bearbeiten. CC_BASE und CC_EXT werden automatisch neu berechnet.
4. Die ausgewählten Seiten schreiben, dann zur Kontrolle zurücklesen. Das Modul am Switch mit den Befehlen unter Optik überprüfen prüfen.

Module nur für Interoperabilität codieren, zu der Sie berechtigt sind, und die Richtlinien Ihrer Organisation und der Hersteller einhalten.

Die Regeln hinter einer sauberen Neucodierung — Feldformate, welche Bits zu setzen und welche Summen zu korrigieren sind — stehen in Vendor-Felder, Compliance-Codes und Prüfsummen.

Was die Fertigung im gleichen Schritt tut und welche Bereiche Kalibrierdaten enthalten, die ein unvorsichtiger Schreibvorgang zerstören kann: Fertigung & Test, Controller & Firmware.

Welches Byte was enthält, bevor Sie bearbeiten: SFF-8472-A0h-Map, SFF-8636-Upper-Page-Map, CMIS-Upper-Pages-Map, XFP-Map.

Ziel-Teilenummern und ihre Grammatik je Hersteller: OEM-Teilenummern; was jede Plattformklasse nach dem Schreiben prüft: Wie jedes NOS ein Modul validiert.