I understand that completely. I really appreciate your help, and it’s not my intetion neither to test your patient nor to take advante of your help. However, I don’a agree with the last sentence. These small details helped me to continue this work a bit more independently so that’s not a waste of time from my point of view, but a huge advantage.
Without your help I would still be at the beginning of this task, but without my contribution it becomes your work, not mine.
Well, I tried to open AMIBCP > “Extract Strings”, I can see the handle/token is 80h (absolute 00B2h) but it’s in the GUID [B1DA0ADF-4F77-4070-A88E-BFFE1C60529A] (the AMIBCP one), not in E609E497C14CD91181F6000000000000.
I tried on UEFITool and I found:
Unicode text "bios has been reset" found in 97E409E6-4CC1-11D9-81F6-000000000000 at offset 175Ch
And that's ok, but not in E609E497C14CD91181F6000000000000
However, our point 6:
Here's the list of CHECKPOINT it prints before the message:
--, [too fast, 0x18 I think - I filmed it with the smartphone but that's too fast even for it], 0x15, 0x3B, 0x32, 0x4F, [2-3 very fast], 0x62, 0x88, 0x72, [...], 0x99, 0x88, 0x9C, [...], 0xB2, 0x24, 0xA2, 0xA9, 0xAB. Some where so fast that I weren't able to film them. However, it freezes at 0xAB, it displays the message and waits for the input.
On the screen, it does not display absolutely nothing. Before the message, black screen.
I've got CORE_DXE source. Do you think it's reasonable to look in the source before, and in the disassembled code then? OEM should not customize this module, right? The code is >here< in Core > CORE_DXE