Page 2 of 3
Re: Writing protected SFP / QSFP / XFP and searching password (brute force method)
Posted: Mon Jul 18, 2022 9:57 am
by thankfly
veegee wrote:thankfly wrote:siedar wrote:I'm looking for someone who passed program Sumitommo Electric (for Alcatel Lucent) SFP+ 10G SPP52000ER-A8 with Revelprog?
I can read A0/A2 but programing isn't possible. Access to memory is very slow to use BF.
Any ideas?
Best regards
Darius
Sumitomo need special hareware program to write.
Can you elaborate on this? What makes those transceivers special? Also, are HP transceivers different in any way?
Sumitomo need a special hareware to program. They are not only protected by password. And HP 10G SFP+ also need SPECIAL FIRMWARE to work with switch.
Re: Writing protected SFP / QSFP / XFP and searching password (brute force method)
Posted: Fri Jul 22, 2022 12:16 pm
by veegee
Hmm, I successfully found the password for my Kiam XQX2502 modules, but it seems like after power cycling the module, changes are lost and the original data shows up. Is there a specific process to commit the writes to the module? I used the password tool to search for the password, then entered the found password and pressed execute, then made the needed changes to the vendor information and pressed "write buffer to memory". It appeared to have worked, because when I performed a "read memory to buffer", my changes showed up. But when power cycling the module, the changes were lost.
Re: Writing protected SFP / QSFP / XFP and searching password (brute force method)
Posted: Fri Jul 22, 2022 1:07 pm
by ArT
I had few similar cases, it can be 2 reasons:
1. there are few passwords with different access levels - you have found password which not allows for permanent changes - you need to search next password with higher priviliges
2. please try to write to single page of qsfp and byte by byte, you can do that by selecting QSFP[USER] and then select
Area: Page Select (128 bytes), select
page 0 and check "
BP" checkbox. Please note that each page has 128 bytes and it will be second 128 bytes from standard 256 bytes read so please read single page before overwriting it (more details about memory map
viewtopic.php?f=32&t=529 upper page 00h). You can also try single page write without BP checkbox. Any difference?
![2022-07-22 130709.jpg](./download/file.php?id=1393&sid=c6062177cd637b50aa405748e075d4f1)
- 2022-07-22 130709.jpg (59.05 KiB) Viewed 10674 times
Please let me know if it helped.
Re: Writing protected SFP / QSFP / XFP and searching password (brute force method)
Posted: Sat Jul 23, 2022 2:56 am
by veegee
ArT wrote:I had few similar cases, it can be 2 reasons:
1. there are few passwords with different access levels - you have found password which not allows for permanent changes - you need to search next password with higher priviliges
2. please try to write to single page of qsfp and byte by byte, you can do that by selecting QSFP[USER] and then select
Area: Page Select (128 bytes), select
page 0 and check "
BP" checkbox. Please note that each page has 128 bytes and it will be second 128 bytes from standard 256 bytes read so please read single page before overwriting it (more details about memory map
viewtopic.php?f=32&t=529 upper page 00h). You can also try single page write without BP checkbox. Any difference?
Please let me know if it helped.
Thanks for the reply! The single page/byte-by-byte had no effect. I think you're right about the access levels. The password that was found was 0xABCD1234, so it makes sense that it would be something like a test password. I'll let you know when the second password is found.
Re: Writing protected SFP / QSFP / XFP and searching password (brute force method)
Posted: Mon Aug 08, 2022 5:15 am
by veegee
It turns out that the KIAM XQX2502 doesn't have any other password. I think there is a non-standard protocol to program it, for example, something similar to the concept of port knocking. Not a big deal, it's trivial to make an I2C proxy chip to sit between the transceiver and the hardware.
I was able to find the password successfully for a couple of other modules though, which is convenient.
Re: Writing protected SFP / QSFP / XFP and searching password (brute force method)
Posted: Fri Apr 14, 2023 1:33 pm
by barhom
Quick question,
Is setting the password for SFP to FFFFFFFF the same thing as the SFP being unprotected?
Re: Writing protected SFP / QSFP / XFP and searching password (brute force method)
Posted: Mon Apr 17, 2023 10:19 am
by ArT
barhom wrote:Quick question,
Is setting the password for SFP to FFFFFFFF the same thing as the SFP being unprotected?
It depends. Some transceivers ignore password at all, some are using default password like 00 00 10 11 or FF FF FF FF or 00 00 00 00 (entering wrong password will lock transceiver, even if it was unlocked at the beginning).
Re: Writing protected SFP / QSFP / XFP and searching password (brute force method)
Posted: Mon Feb 26, 2024 6:48 pm
by snurre
veegee wrote:It turns out that the KIAM XQX2502 doesn't have any other password. I think there is a non-standard protocol to program it, for example, something similar to the concept of port knocking. Not a big deal, it's trivial to make an I2C proxy chip to sit between the transceiver and the hardware.
I was able to find the password successfully for a couple of other modules though, which is convenient.
Hi.
Did you find any solution for the KAIAM XQX2502 ? I didn't get any password at all when searching (took 17 days).
Can you elaborate "it's trivial to make an I2C proxy chip to sit between the transceiver and the hardware".
I want to use these with Arista hardware, but they complain about being not qualified.
Anyone else having any good ideas ?
Re: Writing protected SFP / QSFP / XFP and searching password (brute force method)
Posted: Wed Apr 17, 2024 9:13 pm
by aaron
ArT wrote:The other solution is to buy OEM unprotected transceiver. There are many SFP/QSFP/XFP manufacturers which offer unprotected modules in MSA standard. You can read protected transceiver and you can copy it to other, not protected transceiver. It will work in most cases.
Does anyone have any suggestions on where to buy such unprotected modules? We are looking for the following types:
- QSFP28 100GBASE-LR
- QSFP28 100GBASE-CU (passive DACs)
- SFP28 25GBase-LR
- SFP+ 1/10GBase-T
Out of concern about human rights abuses and infringement political freedoms in China, we would prefer to avoid transceivers manufactured there, but we realize that's not always an option or easily determined, so we would be grateful to hear about any manufacturers that people have had success with. If there are manufacturers for which the passwords are well-known or easily brute-forced, we would be happy to hear about those too.
Thanks!
Re: Writing protected SFP / QSFP / XFP and searching password (brute force method)
Posted: Wed Aug 07, 2024 9:14 pm
by dstachur
> Out of concern about human rights abuses and infringement political freedoms in China, we would prefer to avoid transceivers manufactured there
I like your way! I would suggest Source Photonics which I believe belongs to SkHynix, but unfortunately these are protected and I did not find an manufacturer password :-/
My issue is related to HP Aruba SFPs - Aruba (formerly HP) network devices accept only HP marked SFPs. I am working on some project currently and I need quite a lot of 10G Single Mode SFP for HP Aruba devices (HP p/n J9151A). I bought an original J9151A and found it is not a Finisar as it was previously, but Source Photonics. So, I found these Source Photonics on eBay with an idea to reprogramm all of them using original HP microcode to convert these to HP J9151A. Unfortunately none of my known manufacturer passwords worked, so I spent about 18 days trying to brute force Source Photonics SPP-LR-CDFP. I tried 80000000-FFFFFFFF and 00000000-7FFFFFFF with no luck... Standard 00001011 pass is working as user password only which doas not allow me to write J9151A.
I was wonder how this is possible I did not find a correct password sequence? Is there possible some newer concept of securing SPFs? Similar to what we have for account lock after a few incorrect passwords? Do you guys think such mechanism would be tweaked by i.e. fully disconnecting SPF after each unsuccesful sequence?
![SPvsHPSP.jpg](./download/file.php?id=1591&sid=c6062177cd637b50aa405748e075d4f1)
- SPvsHPSP.jpg (191.68 KiB) Viewed 2957 times