Skipped password

[zburget]

Hi,
I am dealing with an interesting situation.
I'm looked for password of one SFP module and an interesting thing happened. First letter of manufacturer was changed to T. E.g. OEM was changet to TEM (I don't want to write a real vendor). I assume that the password was basically found, but only the first letter of the string "Test" was written. For some reason the string didn't write in full and the write was blocked again - by typing the wrong write password? …and the password search process continued.
I noticed that the automatic Write delay was set to 0.00 ms. Could this have anything to do with it?

Now I have an SFP module with a bad checksum in my hand.

What can I do to find my password?

Thanks,

[ArT]

Write delay may be to slow. Automatic delay is not working in every case. When delay is set to 0.00ms (not e.g. 0.08ms) it means that probably it's working directly on RAM and you should not relay on it, you can test with it, but on second step should be manual delay.
Check logs to find out in which range this happen and next find password in this range with manual delay 40ms.

The second case may be that password is changing by MCU every single write. In such case even if you find password, it will be not valid for next write (but it's limited number of passwords in quene). I've never had such case but I heard about it once.

[zburget]

What exactly should I look for in the log?

My log is 250MB in size

[zburget]

Hmmm
I couldn't find anything in the log. But I know, that the write occurred somewhere in password range BB000000 - FFFFFFFF or 00000000 - 65000000
I try to run search in this ranges again with delay 0.08 ms. Will it be right?

[ArT]

Hmm it may be not registered in log... If automatic delay sets it to 0.00ms you can try 0.08ms because there is different method for password searching for <0.08ms and for >=0.08ms

But if 1st letter of manufacturer name was changed it found password but from some reason it couldnt write 2nd letter and not registered it.

Just in case from time to time stop brute forcing and read manufacturer data to check if it's not changed again to limit possible range (and later to increase write delay to 40ms when range will be small).

Let me know when you test it, I'm very curious!

[zburget]

If first letter of manufacturer is "T", what letter does it change to?

[ArT]

It will be "U" or "F" but it may vary, depends on your manufacturer name.
Generally - it will by changed from T to other value so you will see the difference

[zburget]

O.K. I fount the password. But it's still kind of weird.

Revelprog reports the found password. I've checked "Store password in manufacturer name", but the password is not stored there. At begin of manufacturer name is savet string "TEST" or "FND?". On the first search the first of them, on the next search the second, on the next again the first.

And even though I theoretically know the password, I am unable to write the A0 block. It just won't write.
I try to check ND, BP, both of them, try to write immediately after finding password, remove SFP module, put back to programmer and then write, in no case did I manage to write anything to the A0 block (I tried to overwrite the manufacturer to at least match the checksum).

Any idea what else I can try?

[ArT]

It seems like after first write, even internal process (in brute force) can not overwrite manufacturer name second time (that's why you see TEST value). Is it paged SFP module? If yes, you can try to reprogram single page instead of A0 block. Any difference?
I did not have such case, for further diagnostics I'll need to make some own tests with debugging and datalogic connected.

[zburget]

Into block A2 is possible to write data without write password. By password is protected block A0 only.
Password is located on address A2/7B. After entering the password, it remains permanently stored at addresses 7B-7E (even if I remove the module and return it to the programmer).