FS.COM SFP+ self destruction

Here you can ask technical questions about REVELPROG-IS and device/memory programming.
Popdog
Posts: 3
Joined: Sat Sep 19, 2020 9:59 am

FS.COM SFP+ self destruction

Postby Popdog » Sat Sep 19, 2020 10:09 am

Hi!

I’m using Revelprog IS 1.8.2,

I tried to reprogram a SFP+ 10G-LR 10km transceiver from FS.COM.

Since it was locked, I tried the brute force method to find the manufacturer password.
After a few minutes, it stopped with a device timeout. I replugged the transceiver and started password search again. It succeeded immediately with this result: 80:81:81:29.

But: the manufacturer string was automatically changed from FS to TEST.
And the found password does not unlock. I wasn’t able to write the backup I made to the transceiver.

I started password search again and now it found it at 80:00:01:F4... this password doesn’t work either...
When I set the starting position to FF:FF:00:00 it finds the password at FF:FF:01:F4 and so on.

What happend? Do the have countermeasures for brute forcing the manufacturer password?

Any ideas?

ArT
Posts: 1495
Joined: Wed Mar 25, 2015 8:54 am
Location: Warsaw, Poland
Has thanked: 51 times
Been thanked: 160 times

Re: FS.COM SFP+ self destruction

Postby ArT » Mon Sep 21, 2020 8:56 am

When you have "TEST" in manufacturer name than it found password and it was unlocked for a moment and it should stay unlocked until you disconnect power from SFP (after disconnecting power it will require password again). If it's microprocessor based SFP then password may be variable, it means that when you enter password you should write data in the same write cycle and then SFP requires restart/power reset (otherwise it will be time out every time). It's very uncommon but I sometimes it occurs.

REVELPROG-IS write "TEST" during password searching and when it found password it detects that manufacturer name changed (to "TEST") and then it write password as string to manufacturer name (so you should not have TEST, but password in this place). Since you have timeout during password searching, it does not changed TEST to password in manufacturer name. This timeout may occurred due to some password protection in SFP.

Do you remember what password did it found at first time? (when time out occurred and when it changed manufactured name to TEST)?

What happen now if you disconnect SFP, connect it and try to find manufacturer password in this range (+/- 1000 passwords)?

Popdog
Posts: 3
Joined: Sat Sep 19, 2020 9:59 am

Re: FS.COM SFP+ self destruction

Postby Popdog » Mon Sep 21, 2020 2:08 pm

The password found is 80 81 81 29.

Unfortunately, I didn’t write down the value where the time out occurred.

Unlocking with the password above returns “Executing operation 1/1...success”, but writing results in a verification error at address 0x14 (the first byte of the manufacturer name).


Password search finds the password at every starting point (checked 1 from...)
Maybe it thinks it found the password because there is already TEST in the EEPROM?

ArT
Posts: 1495
Joined: Wed Mar 25, 2015 8:54 am
Location: Warsaw, Poland
Has thanked: 51 times
Been thanked: 160 times

Re: FS.COM SFP+ self destruction

Postby ArT » Mon Sep 21, 2020 2:50 pm

Popdog wrote:Unlocking with the password above returns “Executing operation 1/1...success”, but writing results in a verification error at address 0x14 (the first byte of the manufacturer name).

Password search finds the password at every starting point (checked 1 from...)
Maybe it thinks it found the password because there is already TEST in the EEPROM?


Exactly. It should not left "TEST" in this field, in first step it writes "TEST" but in second step (when found password) it writes password to manufacturer name immadiately, but you had timeout and it found password, executed step 1, but never executed step 2, now it sees "TEST" and it's thinkg that he found password (every time you start brute force)

Popdog wrote:The password found is 80 81 81 29.
Unfortunately, I didn’t write down the value where the time out occurred.


Any suspection about range? When you had timeout it displayed on what password it ended but probably without information that found password.

You can also try with 80 81 81 28 or even 80 81 81 27 - when you had timeout and restarted bruteforce it probably started where it stopped with error so maybe 1 or 2 passwords earlier is your password.

I think that you already hacked this SFP and found correct password but due to timeout it left "TEST" in manufacturer name and not displayed info that it found password. Now we need to run brute force again to write down what password it was. But we can not do that when you have "TEST" in manufacturer name so I'll prepare you custom firmware where it will not check "TEST" but other phrase so you can brute force again, please give me some time for firmware customization.

Popdog
Posts: 3
Joined: Sat Sep 19, 2020 9:59 am

Re: FS.COM SFP+ self destruction

Postby Popdog » Thu Sep 24, 2020 9:20 am

I tried several different passwords before, but I had no luck.

A custom firmware would be really nice. Thank you.

ArT
Posts: 1495
Joined: Wed Mar 25, 2015 8:54 am
Location: Warsaw, Poland
Has thanked: 51 times
Been thanked: 160 times

Re: FS.COM SFP+ self destruction

Postby ArT » Thu Sep 24, 2020 11:28 am

I prepared you custom firmware - please check your PM for more details.

Probably you will need to brute force from beginning.
If it found password it will be stored in manufacturer name.
If you will have timeout again please remember to write down last password it checked - just in case.

Please check it and let me know about results!

longwaytojersey
Posts: 1
Joined: Tue Apr 20, 2021 2:54 pm

Re: FS.COM SFP+ self destruction

Postby longwaytojersey » Tue Apr 20, 2021 2:57 pm

Hi,

could you tell me the password for the fs transciever?

BlackMage
Posts: 2
Joined: Thu Jun 30, 2022 10:35 am

Re: FS.COM SFP+ self destruction

Postby BlackMage » Thu Jun 30, 2022 7:49 pm

any news for this? I think the same thing happened with my SFP module from fs.com

ArT
Posts: 1495
Joined: Wed Mar 25, 2015 8:54 am
Location: Warsaw, Poland
Has thanked: 51 times
Been thanked: 160 times

Re: FS.COM SFP+ self destruction

Postby ArT » Fri Jul 01, 2022 11:22 am

Have you tried v1.9.0 software? What issues do you have exactly, could you record a screen, please?

ArT
Posts: 1495
Joined: Wed Mar 25, 2015 8:54 am
Location: Warsaw, Poland
Has thanked: 51 times
Been thanked: 160 times

Re: FS.COM SFP+ self destruction

Postby ArT » Thu Nov 10, 2022 1:06 pm

I've ordered 2 SFP modules from FS.com for tests:

1. Generic Compatible 10GBASE-SR SFP+ 850nm 300m DOM Duplex LC MMF Optical Transceiver Module

2. Cisco SFP-10G-LR Compatible 10GBASE-LR SFP+ 1310nm 10km DOM Duplex LC SMF Optical Transceiver Module

According to your question - do you have "generic" type or branded (cisco or other) ordered from FS.com?

I'll make tests when they arrive and back to you with information.

update: SR type is working without issues, it found default password 00 00 10 11, after entering password I can change all manufacturer data. LR type has different password. I do not know if this is because it's "CISCO" type not "GENERIC", but without password it's not possible to change manufacturer data. I'm currently searching password for other FS transceiver (I'm testing QSFP-DD board), I'll share info when I find something

update2: I found password for QSFP-DD module from FS. It's 07 04 04 01. But for SFP+ LR this password does not work, so it seems that they are using different passwords for different transceivers. When I'll have some time I can try to find password for SFP+ LR but it's time consuming process and at the moment I do not need it. Anyway - any self destructing does not happend in my case.


Return to “Technical Support”

Who is online

Users browsing this forum: No registered users and 1 guest