# Delving Deep into Reverse Engineering of UEFI Firmwares via Human Interface Infrastructure
## 4 Case Studies
### Password Policy Analysis
#### 4.1.2 Analysis of SuperServer 6028U-TR4T+ UEFI Password Policy  
The UEFI firmware of SuperServer 6028U-TR4T+ is different from that of r240 in that there is no way to find the function that implements the UEFI password input via the same string search method. Therefore, this paper proposes a targeted method to solve this situation. The steps of this method are as follows:  
* Obtain the GUID of the protocol that implements the keycode input. In this paper, we obtained the AMI EFIKEYCODE PROTOCOL GUID 0x0 ADFB62D, 0 xFF74, 0x484C, {0x89, 0x44, 0 xF8, 0x5C, 0x4B, 0 xEA, 0x87, 0 xA8}.
* Retrieve the module that implements the password logic from the UEFI image. In this paper, we obtained AMISetup, which in some firmware is known as BdsDxe.
* Considering the impact of endianness, we need to search for the GUID in the module using both big-endian and little-endian formats.
* After locating the GUID, we validate whether this protocol has been invoked here.
* After determining that there is an input operation on the interface, we check the context to confirm if it is the part where a password is being entered. For example, we can look to see if there is an operation that converts characters into asterisks (*).
* After confirming that it is the part where a password is entered, we iteratively examine the original function to observe the program's logic.  
Figure 8: Password Strings in UEFI UI. We can find it by searching for strings in IDA.  
Figure 9: System Locked In Dell R240. The v22 contains the count of password entry attempts; when the number exceeds 3, the system gets locked.  
Through searching for the AMI EFIKEYCODE PROTOCOL GUID, we locate this line of code as shown in Figure 10.  
We find that qword 1 AB8 indeed matches 2D B6 DF 0A 74 FF 4C 48 89 44 F8 5C 4B EA 87 A8. So, we continue to confirm this point. By translating this code into assembly language as demonstrated in Figure 11, we identify a call instruction, of which we suspect this instruction calls the HandleProtocol function. Further analysis of this assembly instruction reveals an offset of 98 h. We searched the UEFI specification and discovered that the EFI BOOT SERVICES structure is defined within it, containing numerous function pointers. These function pointers are arranged in a specific order in the UEFI firmware. Hence, each function has an offset corresponding to its position in the structure. The offset of the HandleProtocol function in the EFI BOOT SERVICES structure under the X64 architecture is precisely 98 h. Therefore, this code is calling AMI EFIKEYCODE PROTOCOL.  
Then, we start looking for the context of this code and find some keyboard code information and the implementation of converting characters into asterisks, as shown in Figures 12 and 13.  
Figure 11: Assembly Code Representation.  
Figure 10: System Calls The AMI EFIKEYCODE PROTOCOL. We located this spot by tracing the GUID.  
if (HIMORD(v17)==8) { if (v9) { -v9; -v7; a1[v9] = 0; } goto LAREL_23; } if (HIMORD(v17)==13) { (**(void(_fastcoll ***)(_QuORD,_QuORD))&word_28[4])(*(_QuORD *)&word_28[4],0164); sub_6088(&v18); goto LAREL_32; } ```
Figure 12: Keyboard Code Information. HIWORD(v17)==8\({}^{}\) means that when the keyboard code of the character entered by the user is equal to 8, then the backspace operation is executed. HIWORD(v17)==13\({}^{}\) means that when the keyboard code of the character entered by the user is equal to 13, the system performs a confirmation operation.  
Figure 13: Converting The Password Input Chars With The Hidden Mark *\".  
where *a2 is located. Since the value of v4 is 3, we can conclude that the maximum number of password attempts is 3. Finally, we find the number of password attempts using this protocol-centric static analysis method. All the AMI standard interface UEFI firmware we have tried can find the maximum number of password attempts using this method.