Qué checksums de la EEPROM hay que recalcular después de editar el nombre de vendedor y el PN en una imagen SFP
Trabajo de banco: recodificando un pequeño lote de módulos SFP+ para que lleven la cadena de vendedor y el número de parte que espera el equipo del cliente. La edición en sí es trivial en un editor hexadecimal, la escritura pasa, la lectura de vuelta coincide byte a byte con lo que escribí, y el host de todos modos rechaza el módulo.
- módulos SFP+ genéricos, página A0 editada a mano
- programador basado en CH341 con la herramienta que trajo
- campos editados: nombre de vendedor y número de parte de vendedor, nada más tocado
- un dump sin tocar escrito de vuelta al mismo módulo funciona bien, así que la ruta de escritura en sí no es el problema
Lo que comparé después de la edición:
edited fields : vendor name, vendor PN
byte 63 CC_BASE : identical to the original image
byte 95 CC_EXT : identical to the original image
host : rejects the module, checksum errorAsí que los bytes de suma claramente no se movieron cuando sí lo hizo el contenido. Antes de ponerme a escribir mi propia herramienta para esto: ¿qué rangos de bytes cubren realmente esas dos sumas, son sumas aditivas simples o algo con forma de CRC, y hay alguna utilidad mantenida que las recalcule para que no tenga que hacer aritmética a mano en cada módulo?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 4
Tu programador está haciendo lo que normalmente hacen las herramientas basadas en CH341, que es nada. Escriben los bytes que les das y nunca tocan los campos de checksum. Los programadores de vendedor recalculan al escribir, por eso la gente que solo usa esos nunca se topa con esto y está convencida de que todo el tema es imaginario.
Dos cosas vale la pena fijar antes de escribir cualquier herramienta. Primero, qué leyó la imagen de vuelta después de la escritura, ¿la misma herramienta que la escribió, o algo independiente? Un lector que te sirve su propio caché va a mostrarte felizmente un byte que nunca se quedó en el chip. Segundo, ¿calculaste tú mismo la suma sobre los bytes 0 a 62 de la imagen editada y la comparaste con el byte 63, o solo estás comparando el byte 63 contra el dump original? Sin cambios y correcto no son la misma prueba, y tus notas solo muestran la primera.
También vale la pena nombrar al host que lo rechaza. Algunos leen los campos de identidad y no verifican nada, otros validan estrictamente y descartan el módulo en cuanto una suma está mal. Misma imagen, veredicto distinto.
Son dos y son sumas tontas de 8 bits, sin ningún CRC involucrado en ninguna parte.
El nombre de vendedor y el PN de vendedor viven ambos en el área base, así que tu edición invalidó CC_BASE mientras CC_EXT se quedó legítimamente correcto. Las ediciones de número de serie y código de fecha en cambio caen en el rango extendido, y ahí es el byte 95 el que queda desactualizado. Recalcular cualquiera de los dos son dos líneas sobre el buffer: suma el rango, aplica máscara con 0xFF, guarda en el byte de suma.
Si prefieres no hacerlo a mano, hay herramientas. py-sfp-eeprom construye y valida imágenes de EEPROM desde Python (
python3 -m sfp_eeprom), ysfppicorre en una Raspberry Pi, revisa las sumas y se ofrece a arreglarlas. Cualquiera de las dos es mejor hábito que editor hexadecimal más aritmética mental, porque el modo de falla es silencioso, el módulo se lee de vuelta exactamente como lo escribiste y solo el host llega a quejarse.Que las dos sumas MSA estén bien es necesario y, según a qué puerto te estés conectando, no suficiente.
Cisco es el ejemplo bien conocido: la verificación de identidad no son solo las cadenas. Alguien descubrió hace años que el valor que lleva un módulo codificado por Cisco se puede reproducir con nada más exótico que
xxd -r -p | md5sum, alimentado con el byte de código de vendedor y luego los bytes del nombre. En esos dumps el código y el nombre están atados entre sí, Finisar está detrás de 02, Methode detrás de 0E. Deja que los dos no coincidan y un Catalyst 2960X escupe el módulo de nuevo, con o sin comandos de desbloqueo.Esa suele ser la razón por la que un dump copiado de un módulo funcionando deja de funcionar en cuanto alguien le pegó una cadena de vendedor distinta. Las sumas están bien, la identidad ya no es autoconsistente.
Pequeña corrección al planteamiento de "arregla las dos sumas y ya está": eso vale para los campos MSA, no para la idea de cada vendedor de lo que es una imagen válida.
HP es el contraejemplo de siempre. Edita el número de serie en una imagen J4858B, bytes 68 a 83, y los bytes 124 a 127 de A0 también cambian, un checksum propio de HP que se sienta más allá de los bytes MSA CC_BASE y CC_EXT. Eso se discutió largo y tendido y nadie publicó jamás el algoritmo; la gente confirmó que esos bytes importan y el hilo terminó ahí. Misma historia reportada alrededor del J4859C y el J9150A. El equipo posterior de HP y Aruba pasó a un esquema de desafío-respuesta (HPIDv2), que no se puede falsificar en una EEPROM en absoluto.
Así que antes de invertir en herramientas, averigua qué valida el host de destino: dos sumas aditivas para un host simple, una identidad internamente consistente para Catalyst, y en algunas piezas HP un campo sin documentar que no vas a reproducir.