hp bios 去白名单方法 (转载）Insyde BIOS Modding: WIFI and WWAN Whitelists
One of the most annoying features about current HP BIOS are their implemented whitelists. These prevent you from using hardware that HP doesn't approve. This works by checking the UUID of the hardware in question at boot. If it doesn't match any of the acceptable ones listed in a BIOS lookup table, then it will produce an error and refuse to boot. HP currently uses a whitelist for both WIFI and WWAN cards. Here's a common error for having an unauthorized WIFI card installed:
I wasn't aware of this back in January when I was searching for a WIFI card with built in Bluetooth that was fully compatible with hackintosh and aircrack. These requirements lead me to buy an Atheros AR9285 and AR3001 BT combo card. So as soon as I installed it, my laptop, an HP dv7t-4100, produced the 104-Unsupported wireless network device error. This event was what lead me to get involved with modding Insyde BIOS in the first place.
As I've said before, it's usually impossible to keep these tutorials as generic as I would like. Rarely do two different BIOS implement this restriction in the exact same way, so don't expect that following this tutorial verbatim will remove the whitelists in your specific BIOS.
Lets get started with the tutorial. If you'd like to follow along by using the same BIOS that I am, then here's where you can download it. I'll assume that by now you've read a few of my other tutorials, so I don't have to go over some of the basic things anymore. Just like in all the others, unpack your BIOS installer so that you have access to the BIOS rom. Open the rom in Andy's tool and press the Structure button. We want to locate the module that contain the "104-Unsupported" string, so lets extract the DXE Core module and open it with a hex editor. You can get the same hex editor that I use, HxD, here. You can also get the latest version of Andy's tool here.
Remember, Insyde BIOS uses Unicode characters in its strings, which are 16 bits long. This extra byte is most often just an empty byte, so separate all the character in the string your searching for by 00s. This makes more sense if you look at what I'll be searching for. It found it at offset 0x323C2E.
Now lets search for the byte sequence that marks the beginning of a module, 4A 5D. That way we can see the name of the previous module, which is the one that contains the string we found.
So that string is located in the BiosLockPcie module. Your's might be in a different module. Lets go back to Andy's tool to find out that module's GUID. Mine is E62F9F2F-4895-4AB5-8F1A-399D0D9C6B90.
Now use IDA Pro to open that module's corresponding file in the DUMP folder produced by Andy's tool. Remember to open the file with the largest size. As you can see here, there are several E62F9F2F-4895-4AB5-8F1A-399D0D9C6B90 file, but I'm only opening the 8 kB one.
Now lets use the default file format that IDA Pro determine for us. Mine was Portable executable for AMD64.
This ended up being a real small module on mine. This leads me to assume that BiosLockPcie's only task is to enforce the BIOS WIFI whitelist. This check will most likely happen after the error's address is loaded into one of the CPU registers. Lets find that string in the data section of this module and see where it is referenced from. I find this easier to do in IDA Pro's hex view. Mine was at offset 0x18000120E.
Now switch back to assembly view to see what references this offset. Hmmm.... that's weird, nothing references this offset.
So Insyde BIOS have several different supported languages. To optimize this, the compiler they used bunched all the different language strings together. So now only the first part of this bunch is referenced by any code, then a different variable determines where in this bunch to start displaying. So lets scroll up a bit until we see an address that is referenced. You'll know when you find one because there'll be blue text to its right showing the offsets of these calling function. After scrolling up about 50 - 100 bytes, I found it.
Normally we'd go to all the different calling location, but our work is a lot easier now since there's only one. Double click on the blue text to jump there. Lets see what calls this new function that we're now in. Right click on its name, and select Xrefs to. By examining the chart that popped up, we can see that this function is called directly by the entry point of this module.
How about we look at the entry point of this module. Double click on the DllEntryPoint in IDA Pro's function window. This function is pretty straight forward compared to most you'll see. Since I said before that this module will load the text prior to preforming the whitelist check, then lets see what functions are called after the one that loaded the text. Now it turns out that there are multiple ways of referencing functions is IA-64 assembly. One is to call it, another is to jump to it, and a third is to use the lea opcode. Lea stands for load affective address, which can be used to computer the address's expression then move a pointer to that value into a specified register. As it turns out, there are several lea commands used after loading the text. So here's all our possible options:
Lets eliminate some of the possibilities. The first call command is call qword ptr [rax+80h]. This means that it's calling the function at the offset of the value in the rax register plus 80 in hex. After working with Insyde BIOS for several months, I've determined that it'll do these types of calls to access functions in other modules. It is kind of difficult to follow where that call is going, so I'm not going to go into how to do that in this tutorial. Anyway, we know that the whitelist check happens in this module's code and not some other module's, so there is no need to see where that call goes to. Lets look at the second call function which calls 0x180000D08.
So this function has two lea commands and one call command before returning. The first lea command is to a null location, and the call command is calling a function in a different module. So potentially the second lea command is the only lead from this function that could be our whitelist. Lets check out what 0x180016A0 is.
This location is just data. So programs are broken up into a few different segments, but the main ones are the text segment and the data segments. The text contains the actual code that is run, and the data contains the data that is used by the code. If you don't know anything about assembly language, then I highly recommend you read this book. For any kind of software reverse engineering, you need to know the assembly language of the processor that your target application runs on. Since our BIOS run on Intel or Intel compatible processors, we should know IA-64 and IA-32 assembly. Otherwise this BIOS modding stuff will be pretty difficult. So go read that book. Back to the tutorial, so no whitelist being implemented here because it's in the data section.
So lets go back for the entry point to see what our remaining options are based on our assumptions and what we have checked:
So the whitelist happens in one of these four lea command. To accomplish this with lea, as opposed to a call or jump command, the function that it is referencing would have to contain an infinite loop. This way when the processor tries to load the affective address of the result of that function, it will get stuck in an infinite loop and never be able to finish. So lets check out the parameters of each of the lea commands so that we can eliminate more choices.
So now there's just two possible choices. Lets choose 0x1800004A8 because it's referenced first. Remember we're looking for an infinite loop, so if we don't find any in this function, or any in the functions that it leads to, then this isn't the one we're looking for.
Based off of what we can see in IDA Pro's graph view, we can see there's now infinite loops. Also after looking though all the functions that it leads to, I can confirm that there are no infinite loops in this function. Lets check out our final option based on what we've eliminated I down to. Our last hope is the function at address 0x1800003E8. Here's the entire function so we can better see it:
And as expected, there is an infinite loop. So one of the functions it calls before the jnz statement must compare our WIFI card's UUID to a whitelist, and it moves a non-zero value into al if it fails the check. The test assembly command will set the zero flag if its two parameters are both equal to zero. Since we we're trying to use a WIFI card that wasn't in the list, we were send down the branch with an infinite loop at the bottom. Lucky for use because we were kind of out of options after this function.
So as the picture says, lets avoid that branch. This will avoid the infinite loop altogether. Lets change that from a jump if not zero to an unconditional jump, jnz to jmp. That was it'll always go to the branch at offset 0x1800004A0. So the hex values for that jump are 0F 85 9A 00 00 00. The first two bytes are the type of jump, the reset are the jump location. The hex value for an unconditional jump is E9. That's only one byte, so we also need a no operation, 90, in there. So the resulting jump will be 90 E9 9A 00 00 00. Go into IDA Pro's hex view, right click and select edit, apply changed, then right click and press commit changes. IDA Pro doesn't actually write these changes to the original file, so we'll have to do that later with a hex editor. Here's the actual changes:
Now the function looks like this, and it successfully avoid the infinite loop. Whitelist finally removed!
Now lets apply these patches to the file. This next part is the same as in my previous tutorials. I hope you guys don't mind that I'm just going to just copy and paste it. Produce a DIF file in IDA Pro by going to File | Produce file | Create DIF file. I recommend you don't save it in the DUMP folder because it will most likely be deleted by Andy's tool at some point. A DIF file contains the offsets and changes that we made in IDA Pro. IDA Pro can't physically edit a file, so we have to use the information in the DIF file and a hex editor to apply the changes. You can close IDA Pro now. Before actually applying the changes with a hex editor, go back to Andy's tool and press the Advanced button. We want to enable the ability to make modifications to the modules. So these are the settings I changed. I also checked No SLIC because otherwise we would have to select a SLIC table in order to repack our changes. I'm fine with my BIOS current SLIC table.
Press Done to get back to the main screen of Andy's tool. Then press the Go button. When this message comes up, don't press Ok yet.
We need to modify the setup utility module first. So open the same file we disassembled with a hex editor and apply the changes based on what the DIF file says.
Save the file. Now you can press Ok on the message from Andy's tool, and it should repack your BIOS with your modified module. Lets try it out. Rename Andy's tool's outputted file, mine's named 01448F13_SLIC.bin, to what the original rom was called, mine's 01448F13.bin. This'll replace the original rom with the modified one. Now run InsydeFlash.exe. Press Start, wait for it to initialize, then press Ok. It will now flash your computer with you modified BIOS then restart. Now you can install any WIFI card you want without getting an error while booting.
I though I'd squeeze in a little bit more about the WWAN whitelist since we're already in this mind set. Now this same procedure was almost identically for removing the WWAN whitelist. If you want to remove this, then search for the string, 105-Unsupported wireless broadband device detected, in your DXE Core module. My WWAN whitelist ended up being implemented in my BiosLockUsb module whose GUID was 7FA4AE0A-1404-4DCC-BE28-CE58029CF5D1. I preformed the same methods of finding an infinite loop and avoiding it. Even though I can't personally confirm that this does remove the WWAN whitelist, I would assume that it does.
I do try to make these tutorials as generic as possible, but that usually fails because no two BIOS are exactly alike. Because of this, I purposefully went to every incorrect function before finding the one that actually implements the whitelist. I wanted you guys to see more useful ways to approach disassembled code, and hopefully these techniques will help you remove the whitelists from your BIOS. Hope you enjoyed this tutorial.
