Lenovo ThinkPad L15 Gen 4

[Sbaro]

Ok guys I just manage to unlock it. It was pretty easy when you know what to do. For those who might need it, here is the unlocked EC file for a Model : ThinkPad L15 Gen4, Type Number : 21H8-S17L00

What worked for me was to put 00 instead of these lines in the EC file :

Thanks for all the information available in this forum !

[Syseng]

Hi, thanks for sharing. Did you zero the region from 0x0003F420 to 0x0003F48F manually as well, or that happened automatically after the power-on?

I am struggling to restore the SVP on P14s Gen5, serial PF-4XL6BX, the MB is NM-F871 Rev 1.0 and the EC is NPCK397KA08, dump attached.



The problem is additionally complicated by the "Supervisor password retry count exceeded error." So far I was unable to locate the position of this counter in the dump.

I noticed that the dump for P14s G5 is structured pretty in the same way as for L15 G4, only that fields like serial and the like are not exposed directly but are probably encrypted somehow. That made me hope I may succeed in applying the same method, however I did not. Here's what I tried so far:

1. Zero the region from 0x0003E420 to 0x0003E47F. -> No effect.

The idea why I opted not to zero the 0x0003E48x line is that in the dump there is a clear separation in two sections, one starts at 0x0003E000, another at 0x0003F000, and each one is 4 KB in length. Quite a bit of information matches between these two sections, so I suspect that these two parts act somehow in conjunction. In particular, in the beginning of each of the sections there is a 80 byte sequence of the pattern XX 00 XX 01 XX 02 ... XX 27, where XX mostly stands for FC, but can become 00 in certain (unclear) circumstances. Since this pattern is easily detectable, I suspect it serves for some kind of state register.

So, returning to the password, while regions 420 to 47F do NOT match between the two sections, the line starting at 480 does match. That is why I omitted it initially. As I said, that did not work.

2. Then I zeroed the entire region from 0x0003E420 to 0x0003E48F, as you did. -> Still no effect.

3. Tried to zero both 0x0003E420 to 0x0003E48F and 0x0003F420 to 0x0003F48F, as actually shown in your unlocked dump. The retry count exceed error still remained, and the additional "Bad SVP data" error appeared, terminating the POST sequence immediately before the password entry field is even provided.

4. Then I tried to "mend" the register sequences by simply bringing them to exactly same appearance as in your dump, while still zeroing both "password" regions. Again, no effect, "Bad SVP data" and "Retry counter exceeded" remain.

I noticed that while your dump has leading 00 at 0x0003F000 while having leading FC at 0x0003E000, mine does it vice versa. I have some ideas in this respect which I will test.

Any help is much appreciated.

[Maxpower3]

Hi, thanks for sharing. Did you zero the region from 0x0003F420 to 0x0003F48F manually as well, or that happened automatically after the power-on?

I am struggling to restore the SVP on P14s Gen5, serial PF-4XL6BX, the MB is NM-F871 Rev 1.0 and the EC is NPCK397KA08, dump attached.



The problem is additionally complicated by the "Supervisor password retry count exceeded error." So far I was unable to locate the position of this counter in the dump.

I noticed that the dump for P14s G5 is structured pretty in the same way as for L15 G4, only that fields like serial and the like are not exposed directly but are probably encrypted somehow. That made me hope I may succeed in applying the same method, however I did not. Here's what I tried so far:

1. Zero the region from 0x0003E420 to 0x0003E47F. -> No effect.

The idea why I opted not to zero the 0x0003E48x line is that in the dump there is a clear separation in two sections, one starts at 0x0003E000, another at 0x0003F000, and each one is 4 KB in length. Quite a bit of information matches between these two sections, so I suspect that these two parts act somehow in conjunction. In particular, in the beginning of each of the sections there is a 80 byte sequence of the pattern XX 00 XX 01 XX 02 ... XX 27, where XX mostly stands for FC, but can become 00 in certain (unclear) circumstances. Since this pattern is easily detectable, I suspect it serves for some kind of state register.

So, returning to the password, while regions 420 to 47F do NOT match between the two sections, the line starting at 480 does match. That is why I omitted it initially. As I said, that did not work.

2. Then I zeroed the entire region from 0x0003E420 to 0x0003E48F, as you did. -> Still no effect.

3. Tried to zero both 0x0003E420 to 0x0003E48F and 0x0003F420 to 0x0003F48F, as actually shown in your unlocked dump. The retry count exceed error still remained, and the additional "Bad SVP data" error appeared, terminating the POST sequence immediately before the password entry field is even provided.

4. Then I tried to "mend" the register sequences by simply bringing them to exactly same appearance as in your dump, while still zeroing both "password" regions. Again, no effect, "Bad SVP data" and "Retry counter exceeded" remain.

I noticed that while your dump has leading 00 at 0x0003F000 while having leading FC at 0x0003E000, mine does it vice versa. I have some ideas in this respect which I will test.

Any help is much appreciated.

JUST NEED TO DECODE

[Syseng]

Ah thanks, seems better than I thought :-)

[Maxpower3]

Ah thanks, seems better than I thought :-)

LOOK

[Maxpower3]

It is written here 3 times but there are also several other repetitions

[Syseng]

LOOK

Which encoding is this?

Meanwhile, continuing to attack the problem.

6. Returned to my original dump and zeroed 0x0003E420 to 0x0003E48F only. No way: "Retry counter exceed" and "Bad SVP data".
7. Same as attempt 4, "mended" register sequences but only the first "password" region zeroed. This is closest to what succeeded for L15 G4. No way: "Retry counter exceed" and "Bad SVP data".

Something tricky is going on. I suspect that the retry counter messes the password check, probably if it's exceeded then the password cannot be zeroed. And probably some kind of password integrity mechanism is in place.

[Syseng]

It is written here 3 times but there are also several other repetitions

Well spotted, thanks. Especially those small squares, these are clearly pointers.

[Maxpower3]

Which encoding is this?

Meanwhile, continuing to attack the problem.

6. Returned to my original dump and zeroed 0x0003E420 to 0x0003E48F only. No way: "Retry counter exceed" and "Bad SVP data".
7. Same as attempt 4, "mended" register sequences but only the first "password" region zeroed. This is closest to what succeeded for L15 G4. No way: "Retry counter exceed" and "Bad SVP data".

Something tricky is going on. I suspect that the retry counter messes the password check, probably if it's exceeded then the password cannot be zeroed. And probably some kind of password integrity mechanism is in place.

Lenovo has changed the password for the latest firmware. We've been noticing this for some time. Deleting the lines under "CON" is no longer sufficient, as they are full of repetitions and checksums.
Solutions: upgrade to an older firmware or run with clean FF or 00 ,
check the various threads, or compare cleaned EC.
It's normal that you get bad SVP data

[Maxpower3]

try maybe bad svp

[volinakis]

Ok guys I just manage to unlock it. It was pretty easy when you know what to do. For those who might need it, here is the unlocked EC file for a Model : ThinkPad L15 Gen4, Type Number : 21H8-S17L00

What worked for me was to put 00 instead of these lines in the EC file :

Thanks for all the information available in this forum !

[object Object]

what programmer did you use to read NPCK397KA08? Thank you.

[Syseng]

[object Object]

what programmer did you use to read NPCK397KA08? Thank you.

Vertyanov SUCCESSOR BASE4. As the MB connection description file of the programmer suggests, it does not support NM-F871, only NM-F871P (dunno if the difference matters), but anyway the settings for NM-F871P sufficed. Also, the description suggests to remove EC flash (if I understood it correctly), but I managed to read the EC without desoldering its external flash. Also note that the motherboard KB connector is 36 pin, but if you look attentively you see that the last 5 pins are not used. So you do not need a 36 pin cable, the 32@0.5mm cable which ships with Vertyanov suffices.

[Syseng]

try maybe bad svp

OK I see the logic. Sweep the supposed password fields and the pointers as well. Many thanks, that brought great progress. Here's what happened:

1. Initial state: CMOS battery disconnected, SSD disconnected.
2. EC patched
3. Power supplied, the laptop loads with SVP retry count error, but without bad SVP data error. SVP not requested, can enter BIOS. Power disconnected.
4. CMOS battery connected, power supplied. SVP retry count error persists. Enter BIOS. Set date and time, turn off the SVP retry counter. Save changes (successful). Restart.
5. SVP retry count error disappears. Enter BIOS. No changes added. When pressing F10, numerous errors shown sequentially, of the pattern:

Formset (Security) <some UUID>
Failed to save storage: <type of config> Status: Write Protected (or variation: Status: Security)

Now, these errors are displayed on pressing F10 each time if no changes have been made to settings and sometimes when some changes have been made to settings. Now, apparently the ability to save settings from time to time is a lamentful breach of write protection when it's in place, to begin with, but the question is how to get rid of this.

I haven't connected the SSD back yet, so don't know if Windows launches or not.

[Maxpower3]

OK I see the logic. Sweep the supposed password fields and the pointers as well. Many thanks, that brought great progress. Here's what happened:

1. Initial state: CMOS battery disconnected, SSD disconnected.
2. EC patched
3. Power supplied, the laptop loads with SVP retry count error, but without bad SVP data error. SVP not requested, can enter BIOS. Power disconnected.
4. CMOS battery connected, power supplied. SVP retry count error persists. Enter BIOS. Set date and time, turn off the SVP retry counter. Save changes (successful). Restart.
5. SVP retry count error disappears. Enter BIOS. No changes added. When pressing F10, numerous errors shown sequentially, of the pattern:

Formset (Security)
Failed to save storage: Status: Write Protected (or variation: Status: Security)

Now, these errors are displayed on pressing F10 each time if no changes have been made to settings and sometimes when some changes have been made to settings. Now, apparently the ability to save settings from time to time is a lamentful breach of write protection when it's in place, to begin with, but the question is how to get rid of this.

I haven't connected the SSD back yet, so don't know if Windows launches or not.

Errors sometimes appear, it's common. If there is no more password and error message, update your bios (EC). Otherwise, save the information and clean the eprom with LMU. Then re-enter them.

All informations is present on the first page ??

attached file uncrypt mod to better understand what I did

I forgot one here.
For the 82.
41+41 I also thought it was a checksum

[Syseng]

All informations is present on the first page ??

Yes, everything, the model, serials, UUID, license etc.

41+41 I also thought it was a checksum

Maybe. A one-byte checksum is not the best integrity protection, but one may try to calculate it on the "password" lines and see if it matches.

The write protection errors appeared somewhat intermittently, sometimes they were shown, sometimes they were not. The setting that I changed (for testing purposes) on and subsequently off (the Fn button role) also showed weird behavior. Sometimes it was in fact enforced although in BIOS is was shown as off. All in all, BIOS appeared unstable after this EC patch.

Worth noting that this weird behavior might be attributed to the main battery still being disconnected.

Anyway, when I connected the SSD, the OS launched seamlessly. After that I updated BIOS (main and EC) via the official Lenovo utility, and the write protection issue now seems to be gone. I will observe if it returns or not.

A bit later I will sum the things up for those who may face the SVP problem later with P14s G5 (quite new model still).

Maxpower3 thanks again, that's what I call experience. Dunno how much time it would have taken me to nail it myself. Probably a month LOL, if not more. Community is power!

Technically the problem could have been solved just by programming the EC which does not require much disassembly. However, I took trouble to make backups of all three BIOS chips in advance. Just out of curiosity, beside two Winbond BIOS chips (main and EC), there's the third BIOS chip on the board - the Gigadevice one. Does anybody know of its purpose?