This sums up discussion related to Lenovo P14s Gen5 in this thread. Credits go to Sbaro and especially Maxpower3. The locked dump is attached.
The device is based on NM-F871 motherboard with Nuvoton NPCK397 series controller. The motherboard also contains three BIOS chips: two different Winbond chips for main BIOS and external EC flash, and also a Gigadevice chip which purpose I do not know. The password information is contained directly in controller and thus can be manipulated by reprogramming it, so reprogramming BIOS chips is technically not required, however you may wish to make backups thereof to use them in case of unforeseen emergencies.
To read and write NPCK397 I used Vertyanov SUCCESSOR BASE4, however other programmers may be also applicable. The supplied dicumentation suggests to remove the EC BIOS chip prior to working with the EC, however I did not find that necessary.
The EC firmware dump is 256 KB of size, of which first 248 KB are not used. The remainder of 8 KB is split in two 4 KB sections which are used somehow in conjunction: some parts of them match between each other. The first section starts at 0x0003E000 while the second one starts at 0x0003F000. Each of the two sections starts with the 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. I suppose these sequences serve as some kind of state registers, in addition to them being section dividers. In particular I observed some XX of the second section change from FC to 00 when the the laptop is started after the EC is reprogrammed.
Another sequence of interest is located at 0x0003F050, and is of the general pattern 00 27 00 27 ... and ends generally with 0xFC. I suspect this to be some kind of restart record, because when the laptop is restarted, chunks of the pattern 00 1A are being either inserted into it or cut from it closer to the end of the sequence.
The ending of the second section starting roughly at 0x0003FB20, and being slightly over 1 KB in size, is likely used as some form of internal log or integrity check mechanism. Initially unused, it becomes populated with data after the EC has been reprogrammed and even (although to a lesser extent) when the EC is subsequently restarted without new reprogramming.
The "main" password-related data is supposed to be contained in the region starting at 0x0003F420.
Lenovo continuously improves password protection, and in this new laptop model it is not sufficient to simply erase this region, because integrity check mechanism is in place. While the password-related sequences are supposed to be 32 byte long (which suggests they are SHA-256 hashes of the SVP), they are being several times repeated throughout the two 4KB sections, sometimes in a disjoint fashion. All those (or at least most of them, see below) need to be located and erased. In addition, there are one-byte sequences here and there likely being a product of CRC-16-IBM checksums of the password sequences. Hereinafter I refer to them as "checksums".
In my case, the following was detected upon investigation.
Password lines:
0x0003F430-0x0003F44F
0x0003F450-0x0003F46F
0x0003F4A0-0x0003F4BF
(two lines sequence repeated thrice).
The corresponding "checksum line" is immediately preceding and starts at 0x0003F420. It runs thus:
FF FF BE BE FF BE FF FF FF FF FF FF FF FF FF FF
The two lines of the "password" are repeated verbatim starting at 0x0003E4A0.
Then the two lines of the "password" are repeated in reverse starting at 0x0003E6E0 (meaning second line comes first).
Also, the first line of the "password" is repeated at 0x0003E930 (one "checksum" is found in the preceding 0x0003E920 line), 0x0003EC70 (two "checksums" are found in the preceding 0x0003EC60 line), and 0x0003EC90 (three "checksums" are found in the preceding 0x0003EC80 line).
And the second line of the "password" is additionally repeated at 0x0003E9A0, 0x0003FA00, 0x0003FA60 and 0x0003FAC0.
Overall, the first password line is encountered 8 times, while twe second line is encountered 9 times throughout the entire dump.
Basically you have to locate all those repeated password lines and associated "checksums" and erase them (substitute with 0xFF). Some "checksum" lines contain data other than checksums in question. To distinguish them, start with the 0x0003F420 and note the checksum sequence, in our case 0xBE. In all other "checksum" lines the "checksums" should be 0xBE likewise. E.g. the 0x0003EC60 line runs as:
FF FF BE FF FE FF FF FF FF FF FF FF FF FF FF FF
so you know that BE is the "checksum" which you need to erase, while FE is some other data which you leave intact.
It is not clear which exactly repetitions and checksums are crucial for the SVP unlock. In my case, the 0x0003E4A0 - 0x0003E4BF lines were not erased, and neither was the 0x0003FAC0 line. On the other hand, the 0x0003F4E0 - 0x0003F4FF were erased which do not match the password lines and the purpose of which is unclear to me. I did not test the scenario where it would be vice versa, since the modifications that Maxpower3 suggested led to immediate success. Apparently, the process requires a bit of try-and-change.
If you get "Bad SVP data" error, this most probably means that you missed some checksum somewhere. Either try to locate it and erase it, or try to leave the respective password lines (for which you're unable to locate the checksum) intact. As proven above, not all password lines act towards the actual SVP lock.
If you had the SVP retry counter exceeded, the respective error will be displayed upon successful unlock as well, but it will have no actual effect and will go away when you turn ithe counter off in BIOS.
After the unlock the BIOS behaves unstable, you may get write protection errors. This is solved by updating BIOS via the official update utility.
Good luck.
The device is based on NM-F871 motherboard with Nuvoton NPCK397 series controller. The motherboard also contains three BIOS chips: two different Winbond chips for main BIOS and external EC flash, and also a Gigadevice chip which purpose I do not know. The password information is contained directly in controller and thus can be manipulated by reprogramming it, so reprogramming BIOS chips is technically not required, however you may wish to make backups thereof to use them in case of unforeseen emergencies.
To read and write NPCK397 I used Vertyanov SUCCESSOR BASE4, however other programmers may be also applicable. The supplied dicumentation suggests to remove the EC BIOS chip prior to working with the EC, however I did not find that necessary.
The EC firmware dump is 256 KB of size, of which first 248 KB are not used. The remainder of 8 KB is split in two 4 KB sections which are used somehow in conjunction: some parts of them match between each other. The first section starts at 0x0003E000 while the second one starts at 0x0003F000. Each of the two sections starts with the 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. I suppose these sequences serve as some kind of state registers, in addition to them being section dividers. In particular I observed some XX of the second section change from FC to 00 when the the laptop is started after the EC is reprogrammed.
Another sequence of interest is located at 0x0003F050, and is of the general pattern 00 27 00 27 ... and ends generally with 0xFC. I suspect this to be some kind of restart record, because when the laptop is restarted, chunks of the pattern 00 1A are being either inserted into it or cut from it closer to the end of the sequence.
The ending of the second section starting roughly at 0x0003FB20, and being slightly over 1 KB in size, is likely used as some form of internal log or integrity check mechanism. Initially unused, it becomes populated with data after the EC has been reprogrammed and even (although to a lesser extent) when the EC is subsequently restarted without new reprogramming.
The "main" password-related data is supposed to be contained in the region starting at 0x0003F420.
Lenovo continuously improves password protection, and in this new laptop model it is not sufficient to simply erase this region, because integrity check mechanism is in place. While the password-related sequences are supposed to be 32 byte long (which suggests they are SHA-256 hashes of the SVP), they are being several times repeated throughout the two 4KB sections, sometimes in a disjoint fashion. All those (or at least most of them, see below) need to be located and erased. In addition, there are one-byte sequences here and there likely being a product of CRC-16-IBM checksums of the password sequences. Hereinafter I refer to them as "checksums".
In my case, the following was detected upon investigation.
Password lines:
0x0003F430-0x0003F44F
0x0003F450-0x0003F46F
0x0003F4A0-0x0003F4BF
(two lines sequence repeated thrice).
The corresponding "checksum line" is immediately preceding and starts at 0x0003F420. It runs thus:
FF FF BE BE FF BE FF FF FF FF FF FF FF FF FF FF
The two lines of the "password" are repeated verbatim starting at 0x0003E4A0.
Then the two lines of the "password" are repeated in reverse starting at 0x0003E6E0 (meaning second line comes first).
Also, the first line of the "password" is repeated at 0x0003E930 (one "checksum" is found in the preceding 0x0003E920 line), 0x0003EC70 (two "checksums" are found in the preceding 0x0003EC60 line), and 0x0003EC90 (three "checksums" are found in the preceding 0x0003EC80 line).
And the second line of the "password" is additionally repeated at 0x0003E9A0, 0x0003FA00, 0x0003FA60 and 0x0003FAC0.
Overall, the first password line is encountered 8 times, while twe second line is encountered 9 times throughout the entire dump.
Basically you have to locate all those repeated password lines and associated "checksums" and erase them (substitute with 0xFF). Some "checksum" lines contain data other than checksums in question. To distinguish them, start with the 0x0003F420 and note the checksum sequence, in our case 0xBE. In all other "checksum" lines the "checksums" should be 0xBE likewise. E.g. the 0x0003EC60 line runs as:
FF FF BE FF FE FF FF FF FF FF FF FF FF FF FF FF
so you know that BE is the "checksum" which you need to erase, while FE is some other data which you leave intact.
It is not clear which exactly repetitions and checksums are crucial for the SVP unlock. In my case, the 0x0003E4A0 - 0x0003E4BF lines were not erased, and neither was the 0x0003FAC0 line. On the other hand, the 0x0003F4E0 - 0x0003F4FF were erased which do not match the password lines and the purpose of which is unclear to me. I did not test the scenario where it would be vice versa, since the modifications that Maxpower3 suggested led to immediate success. Apparently, the process requires a bit of try-and-change.
If you get "Bad SVP data" error, this most probably means that you missed some checksum somewhere. Either try to locate it and erase it, or try to leave the respective password lines (for which you're unable to locate the checksum) intact. As proven above, not all password lines act towards the actual SVP lock.
If you had the SVP retry counter exceeded, the respective error will be displayed upon successful unlock as well, but it will have no actual effect and will go away when you turn ithe counter off in BIOS.
After the unlock the BIOS behaves unstable, you may get write protection errors. This is solved by updating BIOS via the official update utility.
Good luck.
Comment