I've tried to brute force the manufacture password on one of the SFP+:s that I have in store. The SFP+ in question is from ProLabs and is of the model EX-SFP-10GE-SR-C.
I used the following settings in the program:
Code: Select all
Location: A2h, 7Bh (SFP)
Access Type: Manufacture (no limit access)
Range Limit: User Defined
80 00 00 00 - FF FF FF FF
Apply range to single bytes: No
Store password in manufacturer name: Yes
Write delay: Auto adjust (lowest possible delay)
Start From: 80 00 00 00
I'm not 100% sure if I checked the "Apply range to single bytes" flag or not. But I don't know if that made any change or not as the amount of passwords to test seemed to be the same? (it was 2 147 483 648 passwords both with and without it.)
I let it go until it was done, which took about a week (at ~3725 passwords/second). But when it was done it said "Not found in selected range".
I've read a little about this, and please correct me if I'm wrong, but a manufacture password "should" be in the range above according to the MSA specification, right? So I don't think that I've actually missed to test the password. But I'm wondering if the write delay could be affecting the accuracy of the brute force? As I've also read on this forum that the MSA standard specifies that the write delay for a password protected SFP should be below 80ms. Aka. there is no guarantee that the SFP will have enough time to write and verify that the write was correct if the write delay is set below 80ms? I don't know exactly how the auto adjust setting works, but I'm guessing that the problem with testing to many passwords at once either results in totally missing the correct password. Or that the program can't accurately specify which of the passwords that work? But I assume that it isn't the later case, as it would be possible to run the brute force again on a much smaller range once you know that the password is somewhere in the range of these 10 000k passwords (or whatever the range would be). So am I correct when I'm assuming that the write delay is set to short for my SFP+:s?
Or could there be another reason for not finding the password? I read somewhere that the SFP memory could be a ROM (Read Only Memory) where it only could be written to once at the factory? Could this be the reason for not finding the password?
Or do I just need to check the other half of the range too?
Another thing that might be good to know is that I tried to change the range to "ASCII letters, numbers and special chars" with a write delay of 0.10ms and the SFP timed out. But then I changed it to 0.11ms and it seemed to run as it should. But I still don't know if that is enough time for the SFP to accurately report if the password was correct or not?
I also set the software to log part of the brute force and noticed that it didn't log every password that it should have tested. Instead it logged every 501:st password. (I put the log file into excel and compared every line with the line before) Did also notice that it sometimes logged the same password twice? And some times it was 1002 or 1503 passwords in between the logged rows. But it was never anything else! The difference was always either 0, 501, 1002 or 1503. So always a multiplier of 501. It might just be that the log functions are written to not fill the logs to unreasonable sizes, but I added this here in case it was not programmed to do so.
I can't attach the log files as they are to large but you can find them here: https://ufile.io/8ydpi2hb
Thanks in advance for any help!
