@incud2

I tried finding some solid ground for the patch, but I can only find bits and pieces. It is as I suspected, there is no pointer/offset to those strings. You can use AMIBCP to remove or add chars from them (thus changing the offset of all following strings), there are no other changes to AMITSE apart from size and checksums. This proves that only a handler will be used, with those 4 strings having the handlers 80h-83h. I am seeing a function where they are all involved, but no proof and no way of knowing what to patch. That AB checkpoint is produced by CORE_DXE, with a generic function:

mov al, cl
out 80h, al ; manufacture's diagnostic checkpoint (POST code)
out 90h, al

Not much you can use or patch. I have found the place from where the checkpoints are loaded, but the same messy situation. I don't see an easy way out, not even if you would donate your board for the research cause. The only way I could step further is to have more details. Can you check what are the printed message before and after that selection? I have seen some messages in AMITSE executable section that might be related to this issue, having a solid hook could point me in the right direction.

Hello again

First of all, @lordkag @CodeRush thank you very much for your effords. I really really - really - appreciate that.

Here's the news: a friend of mine is helping me with the task. He has much more experience than me, and he noticed that if I remove the first bytes until the "MZ" character, my module becomes a PE32+ (Windows 64bit) executable. It makes perfectly sense because UEFI specification were written (also) by Microsoft. I opened it in Ida PRO, and it can start its autoanalysis.

Now the problem is this: the analysis truncates the executable at address 63000 insted of address 85330. The truncated part contains the string "bios has been reset...". I found on the net that sometimes Ida truncates the file. But that's not the case: watch the PE Header:

dd 4CAA0h               ; Size of code
dd 160C0h               ; Size of initialized data
...
dd 62E00h               ; Size of image
 

Size of the image = 0x62300. That differs from the size of the module. I thought that maybe the last part containing the strings in unicode was a sort of resource file. However, there is no segment .rsrc (according both to Ida and to the PE header). Do you have any idea about how to adjust this things?

Zitat von lordkag im Beitrag #16

---

This proves that only a handler will be used, with those 4 strings having the handlers 80h-83h.
I am seeing a function where they are all involved, but no proof and no way of knowing what to patch.

---

Zitat von lordkag im Beitrag #16

---

That AB checkpoint is produced by CORE_DXE, with a generic function:

---

Zitat von lordkag im Beitrag #16

---

Can you check what are the printed message before and after that selection?

---

This is what I was saying in the first message. If you open your BIOS file in UEFITool and search for AMITSE in Unicode, you will see that the file has several sections. This is a standard for AMI, not a special case for your board. From those sections, only the body of PE32 can be analysed by IDA, there is no direct link to the others. From IDA point of view, the rest is just padding/garbage. To reference them, AMITSE is using (I guess) the handler of the string. To find this connection, you have to search for 80h, 81h, 82h, 83h - nothing more than that to use. You can use AMIBCP to alter the length of the strings, nothing will change in the code, evidence that only the handler is used for referencing. If you search for hex E609E497C14CD91181F6000000000000 (the GUID that stores your message), only CORE_DXE seems to load it. But there are more than one sections with that GUID, not sure which one is loaded.

Yes, it is my guess that CORE_DXE has a part in displaying that message and will be involved in patching. What I really need is the messages displayed on screen. Try to disable all UEFI options, leave it to legacy and slow Boot, to have the POST messages. There has to be something printed, besides that reset message.

Zitat von lordkag im Beitrag #18

---

1. If you open your BIOS file in UEFITool and search for AMITSE in Unicode, you will see that the file has several sections.
2. To reference them, AMITSE is using (I guess) the handler of the string.
3. To find this connection, you have to search for 80h, 81h, 82h, 83h - nothing more than that to use.
4. If you search for hex E609E497C14CD91181F6000000000000 (the GUID that stores your message), only CORE_DXE seems to load it.
5. But there are more than one sections with that GUID, not sure which one is loaded.
6. Try to disable all UEFI options, leave it to legacy and slow Boot, to have the POST messages. There has to be something printed, besides that reset message.

---

2. When you open the file in AMIBCP, each string has a handle (Setup Configuration) or a token (BIOS Strings). Your desired strings are in the range B2h-B5h when all setup strings are concatenated and displayed by AMIBCP. If you use the options "Extract Strings", they will be in range 80h-83h. I'm thinking that AMITSE will only deal with the strings it contains, thus 80h-83h seems more likely. AMIBCP can extract this handle/token from file, it can also display the setup strings in the right visual order, even though the tokens and strings are stored in a different order. I'm guessing that AMIBCP can access these values from a table or something that contains the handles/tokens. If this is not the case, then I don't know what else to follow.
3. See above.
4. The strings are placed in a GUIDed section. That GUID is 97E409E6-4CC1-11D9-81F6-000000000000 or E609E497C14CD91181F6000000000000 in hex.
6. I don't know what your system does or displays. That is why I asked you to look into the messages. Having a message that can be traced by IDA could narrow the field of search.
7. Please understand that my time is limited, I have no obligation to help you, I'm not a patient man. Asking questions that have no relevance in solving this problem are only taking from the time I dedicate to your issue. We haven't even located the responsible code, wasting time with small details is wasting time. Providing the details to my request (nr 6.) is the most (and only) lucrative approach.

Zitat von lordkag im Beitrag #20

---

Please understand that my time is limited, I have no obligation to help you, I'm not a patient man. We haven't even located the responsible code, wasting time with small details is wasting time.

---

Zitat von lordkag im Beitrag #20

---

The strings are placed in a GUIDed section. That GUID is 97E409E6-4CC1-11D9-81F6-000000000000 or E609E497C14CD91181F6000000000000 in hex.

---

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.

EDIT:
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

The more time I spend on CORE_DXE, the more I belive that the module we need to modify is this.

CORE_DXE contains HII (human interface infrastructure) implementation, the UEFI protocol that manages with strings and user interface in general (AMITSE does another thing in my opinion - it only displays the strings). Here'a an >explanation of HIIS<. The author said:

Zitat

---

UEFI platform firmware provides two key facilities:

The HII Database. The database acts a repository for all sorts of configuration and user-interface resources, including forms, fonts, strings, images, animations, and keyboard layouts. The platform and individual drivers can install and remove these resources.
The HII Forms Browser. The browser is the platform-provided user interface where the forms are displayed and input from the user is taken in order to update configuration settings.

The platform firmware decides when the user interface should be displayed.

---

Here's the HII String Protocol (the explanation of the specification): >link<
Here's the HII Database: >link<
And here's the code in HiiString.c, that shows the way CORE_DXE module > HII functions retrives the string

//----------------------------------------------------------------------------
//  Procedure:   AmiHiiGetString
//
//  Description:
//  This function is HII String protocol function GetString implementation 
//
//  Input:
// 	IN EFI_HII_STRING_PROTOCOL *This - Pointer to EFI_HII_STRING_PROTOCOL structure
// 	IN CHAR8 *Language - Language definition
//  IN EFI_HII_HANDLE PackageList - Handle of package list
//  IN EFI_STRING_ID StringId - String Id
//  OUT EFI_STRING String - Pointer to output string
//  IN OUT UINTN *StringSize - Pointer to string size value
//  OUT EFI_FONT_INFO *StringFontInfo - Pointer to returned string font info
//
//  Output:
//  EFI_SUCCESS - Function executed successfully
//  EFI_INVALID_PARAMETER - String or StringSize or Language is NULL
//  EFI_NOT_FOUND - String not found
//  EFI_BUFFER_TOO_SMALL - Allocated buffer too small
//
//----------------------------------------------------------------------------
//<AMI_PHDR_END>
EFI_STATUS AmiHiiGetString(
	IN CONST EFI_HII_STRING_PROTOCOL *This,
	IN CONST CHAR8					 *Language,
	IN EFI_HII_HANDLE				 PackageList,
	IN EFI_STRING_ID				 StringId,
	OUT EFI_STRING					 String,
	IN OUT UINTN					 *StringSize,
	OUT EFI_FONT_INFO				 *StringFontInfo OPTIONAL)
{
	PACKAGE_LIST_RECORD *Record = (PACKAGE_LIST_RECORD *)PackageList;
	STRING_RECORD DbKey;
	INT8 Vicinity;
	STRING_RECORD *Found;
    UINTN *FindRecord;
	UINT32 Size;
	EFI_STATUS Status;
	LANGUAGE_LINK *Ptr;
	UINT32 i;
	UINT16 SaveLanguage;
 
    if (Language == NULL || StringId < 1 || StringSize == NULL || PackageList == NULL)
        return EFI_INVALID_PARAMETER;
 
    if (String == NULL && *StringSize != 0)
        return EFI_INVALID_PARAMETER;
 
	if (Record->Signature != PACKAGE_LIST_RECORD_SIGNATURE)
		return EFI_NOT_FOUND;
 
	DbKey.StringId = StringId;
	Status = GetLanguageId(Record, Language, &(DbKey.LanguageId), &Ptr);
	if(EFI_ERROR(Status))
		return EFI_INVALID_LANGUAGE;
 
	Status = DbeLocateKey(&(Record->StringDb), 0, &DbKey, &FindRecord, &Vicinity, NULL);
	if(EFI_ERROR(Status))
    {
        //string not found in database, try different languages
		SaveLanguage = DbKey.LanguageId;
		for(i = 0; i < Record->LanguageList.Size; i++)
		{
			if (i == SaveLanguage)
				continue;
			DbKey.LanguageId = (UINT16)i;
			Status = DbeLocateKey(&(Record->StringDb), 0, &DbKey, &FindRecord, &Vicinity, NULL);
			if(!EFI_ERROR(Status))
				return EFI_INVALID_LANGUAGE;    //string exists but with different language
		}
		
		return EFI_NOT_FOUND;
    }
 
    Found = (STRING_RECORD *)(UINTN)(*FindRecord);
 
	Size = StrSize16(Found->String);
    
	if(Size > *StringSize)
	{
		*StringSize = Size;
		return EFI_BUFFER_TOO_SMALL;
	}
 
	StrCpy16(String, Found->String);
	*StringSize = Size;
 
	return EFI_SUCCESS;
}
 

While I agree that providing extra details can help you to follow / participate in this research, or even help you to solve / finding a trace to the solution, it still doesn't change the fact that I have to reply to questions that seem elementary in my book.

B1DA0ADF-4F77-4070-A88E-BFFE1C60529A is AMITSE. The name is just for human readability, the machine only knows and cares about the GUID. All strings are placed in sections with GUID 97E409E6-4CC1-11D9-81F6-000000000000, how it would help to have that repeating X times in the saved strings? The parent file is more important and unique in a volume, thus it is used. 97E409E6-4CC1-11D9-81F6-000000000000 is E609E497C14CD91181F6000000000000 in hex string, how else do you store that GUID in binary form? The questions to the above answers is the exact thing I tried to avoid. They can be easily answered with simple logic and EFI basics, they bring nothing new or helpful to the table.

The codes 0xB2 - Legacy Option ROM Initialization, 0xA2 - IDE Detect, 0xA9 = Start of Setup can be used to trace the code a little better than 0xAB - Setup Input Wait, because those codes are linked to more complex and better documented actions. However, here is the bad news. Without having an immediate and secure hook to base my research, I will have to decline or heavily postpone this task. Having the source code is not as important as it sounds, because: a) I have to read it thoroughly and b) understand it. Which is not the case, as: a) I'm deeply covered in some personal projects and b) I can understand C code, but not cover complex sources. Even if I had the time and skill to cover this first step, I would hit wall number two: trying to match this code to some assembly instructions. Which is not the case, again, as I don't have: a) enough time and b) enough knowledge. I can understand basic instructions, but not convert from C code to assembly or vice-versa.

I'm not sure that following generic functions like the ones from HiiString or ConSplitter would help. Even if you find them in IDA, how would you link them to your issue? You should search something that it is as close as possible to that 0xAB checkpoint, while still being easily traceable in IDA (or your favourite disassembler). It gets even more complicated when you don't know which module to inspect: is it AMITSE, CORE_DXE, any other involved? For instance, AMIBCP is loading the tree (most likely) from the third section of AMITSE. The keywords to search next in sources is STRING_TOKEN and $SPF. But as I said, you need someone that knows C/C++, knows the sources, knows assembly, has the time and will to implement a patch. Humanity's last hope may be in CodeRush. And the joke is not so much of a joke, as there are only a few independent researchers investigating UEFI (to my knowledge), even fewer that would provide a patch for a specific issue, for a specific user. This brings me to what should have been my first question: have you tried asking Gigabyte for a patched BIOS?

Zitat von lordkag im Beitrag #23

---

This brings me to what should have been my first question: have you tried asking Gigabyte for a patched BIOS?

---

Zitat von lordkag im Beitrag #23

---

But as I said, you need someone that knows C/C++, knows the sources, knows assembly, has the time and will to implement a patch. Humanity's last hope may be in CodeRush. And the joke is not so much of a joke, as there are only a few independent researchers investigating UEFI (to my knowledge), even fewer that would provide a patch for a specific issue, for a specific user.

---

How do you add INT 3 to a compiled file and where do you add it, in your specific case? This is not so much a question towards you, but rather a rhetorical one, as I have no knowledge of doing that.

Zitat von lordkag im Beitrag #25

---

How do you add INT 3 to a compiled file and where do you add it, in your specific case? This is not so much a question towards you, but rather a rhetorical one, as I have no knowledge of doing that.

---

Going on with the project:
1. Before continuing, I tried to force a DualBIOS recovery. You just need to play a little with the power button and the reset button, and a prompt will appear on the screen saing "bios is corrupted..." and it will restore the backup version it has (F1 or F2, I don't know). I'm sure I'll need it.
2. The strategy

The strategy
This method will be applied to the modules CORE_DXE and AMITSE
Do you know PE code injection? Let me make an example:

Before:
0: instruction_0
2: instruction_1
6: instruction_2
...
 

Later:
0: jmp myroutine
2: instruction_1
6: instruction_2
...
myroutine:
    move dx, mycode ; display a checkpoint defined by me on port 80
    out 80h, dx
    move eax, 0x7FFFFFFF ; add a sort of delay - I want 10 second more or less, I'll have to guess this number
myroutine_delay_loop:
    sub eax, 1
    jnz myroutine_delay_loop
    ; delay ended
    instruction_0 ; do the instruction(s) you removed from the top
    jmp 2; jump back to the code
 

Now, where to put myroutine? There's no "free space" in both modules, right?
But in both modules there are some strings in the .data section. Substituting the strings with random bytes is not a big problem, I suppose. In the worst case, I will see bad-formatted strings. If the platform does not check the permissions (.data should be r/w but not x) this can work. What do you think guys?

At the same time, I'm having a look at the Intel PCH NM70 datasheet. Probably there's a register memory mapped or I/O mapped that reads if the CMOS battery is present or not. Finding the address/port could bring me to the solution.