@thunfisch i always wondered if the “use vendor box > vendor box forces you to use their app” is because there is some password derivation algs, or server side lookup, for the user and mfr areas of the sfp’s eeprom, rather than the default. but i have yet to try writing to an FS. I have seen other tools have to implement brute force on the password 😭

@thunfisch ah, i do not see anything from my little mastodon server, so maybe i am preaching to the choir. please excuse my half-asleep typing and verbal soup.

that is an incredibly useful datapoint on fs.com, i was collecting some known passwords at work, for science. well, specifically reprogramming in-situ using broadcom debug shell on juniper devices, we do not often have remote hands at some sites.... netapp QSFP DACs are our worst offender for 'has only 6g-sas coding' and they somehow made their way to network-land, with strange behaviours between junos versions until reprogrammed.

you have probably already read somewhere that the keyspace is two, because the same position is used for user vs mfr password.

i was building a brute-force tool a while ago, very similar to your cage. I used an aliexpress media converter so I could have power and enclosure already handled. the cage had to be desoldered, then I accessed the pins for the connector with kynar to tap i2c before putting the cage back. i glued a cheap micropython board on top, although I am no programmer...

so far my experiments let me poke at it via a repl, I got a bit more stuck building a web interface for optic-mangling....

in the process i was having some thoughts, specifically around bus speed. my hypothesis is that the p/w check is probably fast. there's a bit you can read for success/fail iirc, but maybe i need to reread my notes. i was pondering performing a bunch of reads at varying speeds to infer maximum possible bus speed... then using that to derive speed the bruteforce should take. maybe that speeds it up.... but i am just thinking out aloud at this point.