EEPROM-hercodering: wachtwoorden en werkwijze

Het belangrijkste inzicht uit jaren van technische discussie: compatibiliteit van een transceiver zit niet in firmware, maar in identificatietekenreeksen in EEPROM, die via I²C worden gelezen. Een switch weigert een module alleen omdat hij de tekenreeks van de fabrikant niet herkent. Dat verklaart zowel de gangbare praktijk om ‘alles als Cisco te coderen, want dat werkt bijna overal’ als de volledige markt voor codeertools.

Waar de wachtwoorden staan

Voor schrijven naar beveiligde delen van het modulegeheugen is een wachtwoord van 4 byte nodig, dat vóór het schrijven op een vast adres wordt ingevoerd:

Veelgenoemde wachtwoorden

Sommige QSFP-DD-modules van fabrikanten worden met eigen vaste standaardwaarden geleverd. Enkele modules met microprocessor gebruiken een variabel wachtwoord dat verandert, een valkuil voor wie brute force probeert.

Waarom brute force niet het antwoord is

Een wachtwoord op fabrikantniveau dat de volledige geheugenkaart beschermt, vergt in de orde van 100+ dagen brute force; zelfs een ASCII-wachtwoord op hostniveau duurt tot ongeveer drie dagen. In de praktijk werkt een database met bekende codes en wachtwoorden die uit originele modules zijn verzameld. Daarin schuilt de werkelijke waarde van een codeertool, niet in de eenvoudige I²C-hardware.

Valkuilen van zelfbouwprogrammers

• Goedkope CH341A-programmers berekenen de SFP-checksum niet. Een image zonder geldige CC_BASE/CC_EXT schrijven levert een module op die de switch weigert. U hebt een tool nodig die checksums automatisch opnieuw berekent.
• Sommige switches schrijven alleen naar adres 0x50, dus het wachtwoord op 0x51 is niet vanaf de switch zelf bereikbaar. Daarvoor is een geschikt programmeerboard nodig.
• De EEPROM-schrijfbeveiligingspin: sommige fabrieken verbinden WP met Vcc, zodat de module in het veld tegen schrijven is vergrendeld.

Gevallen uit de praktijk

• Modules die voor één fabrikant waren gecodeerd, voerden geen autonegotiatie uit op een switch van een andere fabrikant. Na hercodering met de fabrikanttekenreeks van de switch kwamen zij direct op.
• Sommige leveranciers van optische modules leveren bewust ongecodeerde modules en verwachten dat de koper ze voor het doelplatform codeert.
• DWDM-modules worden op golflengte afgestemd via dezelfde beheerinterface die ook voor codering wordt gebruikt.

Werken in CodingBox

1. Lees de module; deze wordt automatisch opgeslagen in de Code database en vóór elke schrijfactie wordt een back-up gemaakt.
2. Stel het tabeladres, wachtwoordadres en de wachtwoordwaarde in bij Beveiligd geheugen en wachtwoorden. Bekende wachtwoorden uit de database worden automatisch toegepast.
3. Bewerk de fabrikant, het artikelnummer en andere identiteitsvelden in de EEPROM editor. CC_BASE en CC_EXT worden voor u opnieuw berekend.
4. Schrijf de geselecteerde pagina's en lees ze daarna terug ter controle. Controleer de module op de switch met de opdrachten in Optische modules verifiëren.

Codeer modules alleen voor interoperabiliteit waartoe u gerechtigd bent en volg het beleid van uw organisatie en de fabrikanten.

De regels voor een correcte hercodering, de veldindelingen, de in te stellen bits en de te herstellen sommen staan in Fabrikantvelden, Conformiteitscodes en Checksums.

Wat de fabriek in dezelfde stap doet en welke gebieden kalibratie bevatten die een onzorgvuldige schrijfactie kan vernietigen: Productie en testen, Controller en firmware.

Welke byte wat bevat vóór u bewerkt: SFF-8472 A0h-kaart, SFF-8636-kaart van de bovenste pagina, CMIS-kaart van de bovenste pagina's, XFP-kaart.

Doelartikelnummers en hun grammatica per fabrikant: OEM-artikelnummers. Wat elke platformklasse na het schrijven controleert: Hoe elk NOS een module valideert.