No password found?

Here you can ask technical questions about REVELPROG-IS and device/memory programming.
hackerman
Posts: 3
Joined: Tue Jul 12, 2022 10:34 am

No password found?

Postby hackerman » Tue Jul 12, 2022 2:08 pm

Hi!

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! :D

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

Re: No password found?

Postby ArT » Wed Jul 13, 2022 11:03 am

Hi,

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.)


With checked option or not "Apply range to single bytes" for this range (80 00 00 00 - FF FF FF FF) - it does not matter, because 2nd, 3rd and 4th bytes are from min to max range (00 to FF)

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?


If transceiver is password protected, this password is on most cases in this range. MSA standard tells that it has to be in this range, but I know cases when password is not in this range, but in first half (00 00 00 00 - 7F FF FF FF) or transceiver is protected on other way. It's not MSA compilant, but sometimes it happen (unfortunately not every manufacturer follows MSA standard). If you have so high speed (this is "only" a week for all combinations) I recommend to check also range for a first half. If it will not find - it means that transceiver is protected on other way or it has implemented brute force protection (e.g. it requires power supply reset every entering 3 wrong passwords) - this happen rarely but sometimes it is te case.

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?


Yes it can be a reason too, but it's not often case. I recommend to check also first half of range

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?


If you do not have timeout, selected write delay time should be fine. I always set as low as possible until I have time out. Sometimes timeout occurs after few tries - in such case I inrease time slightly (10-20%).

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.


Don't worry with that, search password tool is optimized to be efficent and most hard work is doing on programmer side. PC logs can not record any checked password, because files will be huge. It records last password checked every (500*n + 1) just in case PC restarts or power supply failure so you can check where it ended. You can ask why there is (500+1) - it's because log is recorded every received status from the programmer. Status with additional information (e.g. tranmission speed, success/error, last password checked) is sending from programmer every X passwords + 1, where X depends on checking speed (if search speed is low, it will be more often). You can decrease write delay to 80ms and you should see that logs will be more often.

So in conclusion - If you have time I recommend to check also range 00 00 00 00 - 7F FF FF FF. I hope it will find, but if it will not find in this range too, I worry it's protected on other way. Please let me know about results.

hackerman
Posts: 3
Joined: Tue Jul 12, 2022 10:34 am

Re: No password found?

Postby hackerman » Wed Jul 13, 2022 1:06 pm

ArT wrote:Hi,

If transceiver is password protected, this password is on most cases in this range. MSA standard tells that it has to be in this range, but I know cases when password is not in this range, but in first half (00 00 00 00 - 7F FF FF FF) or transceiver is protected on other way. It's not MSA compilant, but sometimes it happen (unfortunately not every manufacturer follows MSA standard). If you have so high speed (this is "only" a week for all combinations) I recommend to check also range for a first half. If it will not find - it means that transceiver is protected on other way or it has implemented brute force protection (e.g. it requires power supply reset every entering 3 wrong passwords) - this happen rarely but sometimes it is te case.

Is there anyway to configure the programmer to cut power to the SFP for a brief moment automatically after X amount of retries? I assume that it will take some time to make sure that the SFP has no power, but maybe one could make sure that the SFP consumes the power with some command and directly after executing that command, cut the power? Just to speed things up?
ArT wrote:If you do not have timeout, selected write delay time should be fine. I always set as low as possible until I have time out. Sometimes timeout occurs after few tries - in such case I inrease time slightly (10-20%).

Can I rely on the auto adjust time setting or should I set a delay myself and find one that doesn't timeout? There is a pretty huge difference in speed between the delay I set myself and the auto adjust.
ArT wrote:So in conclusion - If you have time I recommend to check also range 00 00 00 00 - 7F FF FF FF. I hope it will find, but if it will not find in this range too, I worry it's protected on other way. Please let me know about results.

Alright I will run a brute force on the first half too! I'll get back with the results!


I also noted that the brute force part of the program says that the SFP password is located in the A2h part of the memory. But if I try to read that page, I get an error stating that no device was found. Is that expected or should one be able to read that page too for the brute force to work? I can read A0h which in the brute force part of the program is listed as QSFP/XFP. Has something been mixed up here or is the password supposed to be in a part of the memory that you can't read at all? Maybe that is how the SFP protects its memory?

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

Re: No password found?

Postby ArT » Thu Jul 14, 2022 10:43 am

Ahhh, if A2 area is not implemented (device not found = address does not exists) then password is also not implemented. As you observed, password is stored in A2 area, if this area not exists then password can not be stored. In such case it's protected in other way.

But I checked specs of this EX-SFP-10GE-SR-C
https://apps.juniper.net/hct/model/?com ... &tab=oView
and page tells that it's SFP+ with implemented Digital Diagnostic Monitoring (Transceiver temperature, Transceiver supply voltage, TX bias current, TX output power, RX received optical power). All these informartion are stored in A2 area (page 10/43 https://members.snia.org/document/dl/25916) so it has to read A2 block.

It's strange. Do you selecting EEPROM -> Transceivers -> SFP[A2] ? Are you using v1.9.0? (because in v1.8.x was bug that standard read may not work after brute forcing - need to restart application and then read)

hackerman
Posts: 3
Joined: Tue Jul 12, 2022 10:34 am

Re: No password found?

Postby hackerman » Tue Jul 19, 2022 2:11 pm

ArT wrote:Ahhh, if A2 area is not implemented (device not found = address does not exists) then password is also not implemented. As you observed, password is stored in A2 area, if this area not exists then password can not be stored. In such case it's protected in other way.

But I checked specs of this EX-SFP-10GE-SR-C
https://apps.juniper.net/hct/model/?com ... &tab=oView
and page tells that it's SFP+ with implemented Digital Diagnostic Monitoring (Transceiver temperature, Transceiver supply voltage, TX bias current, TX output power, RX received optical power). All these informartion are stored in A2 area (page 10/43 https://members.snia.org/document/dl/25916) so it has to read A2 block.

It's strange. Do you selecting EEPROM -> Transceivers -> SFP[A2] ? Are you using v1.9.0? (because in v1.8.x was bug that standard read may not work after brute forcing - need to restart application and then read)


Hi again! Sorry for the late reply, on vacation and haven't had time to look into this until now.

I've tested my way around, and found that if I select EEPROM -> Transceivers -> SFP[user] and then in the "Area" field below select A2h. I'm getting an error on half of my attempts to read. But if I select EEPROM -> Transceivers -> SFP[A2] directly I'm able to read the A2 memory page every time without error. Could this be affecting the success rate of the brute force?

This is what the script log looks like when I get the errors:

Code: Select all

13:15:30.916: Executing script started.
13:15:31.087: Setting hardware (I2C 3.2V SLOW)...success
13:15:31.259: Executing operation 1/2...success
13:15:31.306: Executing operation 2/2...success
13:16:09.058: Executing script started.
13:16:09.066: Setting hardware (I2C 3.2V SLOW)...success
13:16:09.234: Executing operation 1/2...fail
   2 bytes instr , 128 bytes read , 0 bytes write
   DBO 0 ms , DAI 0 ms , DAW 0 ms , DAO 0 ms
   BSYO 0 ms , TOUT 1000 ms
   INSTR: A2 00
   DATA: NULL
13:16:09.351: Script execution cancelled.
13:16:09.403: DEVICE TIMEOUT
13:16:12.462: Executing script started.
13:16:12.469: Setting hardware (I2C 3.2V SLOW)...success
13:16:12.636: Executing operation 1/2...success
13:16:12.668: Executing operation 2/2...success
13:16:19.774: Executing script started.
13:16:19.781: Setting hardware (I2C 3.2V SLOW)...success
13:16:19.967: Executing operation 1/2...fail
   2 bytes instr , 128 bytes read , 0 bytes write
   DBO 0 ms , DAI 0 ms , DAW 0 ms , DAO 0 ms
   BSYO 0 ms , TOUT 1000 ms
   INSTR: A2 00
   DATA: NULL
13:16:20.093: Script execution cancelled.
13:16:20.149: DEVICE TIMEOUT
13:18:15.275: Executing script started.
13:18:15.278: Setting hardware (I2C 3.2V SLOW)...success
13:18:15.450: Executing operation 1/1...fail
   2 bytes instr , 0 bytes read , 4 bytes write
   DBO 80 ms , DAI 0 ms , DAW 40 ms , DAO 0 ms
   BSYO 0 ms , TOUT 500 ms
   INSTR: A2 7B
   DATA: 00 00 10 11
13:18:17.427: DEVICE TIMEOUT
13:18:22.824: Executing script started.
13:18:22.830: Setting hardware (I2C 3.2V SLOW)...success
13:18:23.004: Executing operation 1/1...success
13:18:29.435: Executing script started.
13:18:29.439: Setting hardware (I2C 3.2V SLOW)...success
13:18:29.611: Executing operation 1/1...fail
   2 bytes instr , 0 bytes read , 4 bytes write
   DBO 80 ms , DAI 0 ms , DAW 40 ms , DAO 0 ms
   BSYO 0 ms , TOUT 500 ms
   INSTR: A2 7B
   DATA: 00 00 10 11
13:18:31.597: DEVICE TIMEOUT


This is the whole log, so the start-up is part of the log. The first attempt to read A2h fails, the second works, the third fails and the fourth works etc.

And this is consistent between reboots and different host computers.

Didn't catch this behaviour first, as I assumed that it was the same code being run where the only difference was that it was a simple vs. more advanced mode of the program. But I'm not so sure about that any more.

I've also noticed that the script log comes up when I start the brute force. So I'm wondering if it could be running in the mode that only seems to work half of the times?

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

Re: No password found?

Postby ArT » Wed Jul 20, 2022 1:29 pm

The difference between SFP[A2] and SFP[USER] + selecting A2 is that 1st one is reading 256 bytes at once (in single i2c transmission) and 2nd one is reading 2x 128 bytes with custom script tool and short pause between readings (in two i2c transmissions). Maybe this pause is too long or to short. You can test read with ND option (No Delay) and you can also test with BP option (byte by byte - 256 transmissions) - any difference? Brute force is also communicating with not single, but many I2C tranmissions. It seems to me that this SFP is occasionally not responding for I2C transmission (timeout). To confirm that I'll need to check transmission with data logger analyzer. I worry that without this SFP for tests I will not be able to resolve this issue. Maybe do you have possibility to send one of these sfp to us?


Return to “Technical Support”

Who is online

Users browsing this forum: No registered users and 2 guests

cron