About the Flash Descriptor :

Hello

Someone could explain to me if he can the reasons that can explain : why is a modification of the Flash Descriptor not taken into account ?

Indeed, my tests indicate that an old version of the FD remains in a memory outside the BIOS itself […].

I will be very curious to know the boot process via an organization chart, I can provide you with documentation on Intel hardware…

Unsure what you are asking here. Some systems may store copy of FD or ME on another chip, for recovery or forced recovery purposes (Like HP’s SureStart)

Did you see this thread, we do discuss FD often in BIOS mods - [Guide] Unlock Intel Flash Descriptor Read/Write Access Permissions for SPI Servicing



Thank you @Lost_N_BIOS yes I noticed the discussion, and I chose this topic to stay specific.

You explain “Some systems may store copy of FD or ME on another chip…” that’s exactly what I was getting at.

A - In my example, I programmed a bios with FD unlocked (hexa code method).

B - However, in the meantime I reprogrammed with a locked FD this time.

despite this, the machine starts natively unlocked even though it has a “B” program…only if I perform a hard reset I definitely switch back to B.

I was able to verify via an dump with the command “fpt -d xxx.bin” the raw bios with FD locked…while the machine is however well unlocked.

In short, it would be interesting to know precisely the hexa code linked to the copy of the FD in this other memory because this is a vulnerability and boot failure factor.

When you did the “B” programming, how did you put that BIOS on, with programmer or flash via software or BIOS interface etc? If with anything other than programmer this is normal, since FD is rarely flashed by normal flash methods (without user intervention/mod etc)
If you flashed “B” same as “A” then outcome should have = exactly what you programmed in there. If “A” programmed in unlocked FD and it saved it somewhere else, then “B” programmed in using exact same manner then “B” FD should have copied out to wherever same as with "A"

If you’ve not rebooted yet after flash, then always you are on current BIOS already loaded - what you flash it is not in use yet, this way you can reflash before reboot to fix anything if needed (ie you know you flashed in a bricked BIOS, but hadn’t rebooted yet, this leaves you chance to reflash again before rebooting)

I think maybe this is not happening how you think, but I am not certain how you are putting on any of these BIOS.
Program in A BIOS, reboot, then dump BIOS and check FD - should = what you programmed in for A.
Now do same for B, reboot, should = what you programmed in for B
This is expected, to have to reboot before new BIOS is in use, however you can dump before reboot and it too should also = what you just programmed in



with an external programmer in any case



I agree with the description of this logical process, AND it is precisely because it doesn’t work that I opened this post and I would like to understand.



precisely and it’s the only way out of a bricked bios, which means without this procedure (concretely a “hard reset” to simplify) a reprogramming does not change the bricked status.



perfect match



perfect match



I am systematically obliged to perform a hard reset for a support of the last programmed FD, otherwise the FD could not match.

I believe that there is a close relationship between the rom bios and the expected FD and if the occurrences are not good then the anomalies I have observed follow:

-Bricked
-Black screen
-Boot but stop to start P.O.S.T logo
-Abnormally long boot time
-Multiple auto shutdown/restart at boot
-Illuminated display that displays an artifact loop as if an element were in constant reset

So how can we avoid such inconvenience for sure (not to mention the security problem it represents ? = a user who believes he or she is secure when he or she is not)

Programming externally does not guarantee a perfect match just after the 1st restart AND it would be advisable if this were the case (and therefore without being forced to systematically perform a hard reset manually).

In short, how would it be possible to simply automate the hard reset ?
(I add that the hard reset procedure does not work systematically in the same way from one PC to another, and even sometimes it is a procedure that is not found (not to say impossible)).