Hspumanti's guide is really awesome, but I ran into some issues and had to imrovise. I figured I'd post what I did to get it working on my bios.
HP DV7-1273cl
Okies... To preface this: I'm not in any way a programmer.. I did my best to understand this process to the best of my ability. Undoubtedly I'm probably off a bit in my thinking... but wtf I hacked my bios and that's like... as l337 as it gets...
So here's how I got this baby working..
I started off by downloading my bios from HP's site.. It downloaded as a single executable file that could only be ran. I extracted the executable using winrar and was presented w/ this.
Inside were 3 .FD files, from which I could conclude that the first was in fact NOT my bios because my laptop is the 30F4 model. I decided to take a gander inside the platform.ini and see if there was anything inside that could give me a clue as to which of the two that remained was the correct bios.
Right away I noted that the [FDFile] string listed the F260 as the filename to use. Ultimately that was good enough for me. Also worth noting if you add any text to the BackupName section it will create a backup of the current ROM inside of your bios before patching it with the new one. This is useful if you have to use the recovery method that I had to use, I'll talk about that at the end of this tutorial.
Now that I acquired the bios I needed, I decided to follow
hspumanti's guide. I started up EzH20.exe and did a File - Load File - and selected my bios '30F4F260.FD' if successful you should get 'Program Load file finished' at the bottom left of the EZH20 window.
We are now going to use WinHex to edit the EZH20.exe Processes' RAM, which is just badass btw... I had to purchase the full version of Winhex in order to actually edit the RAM, but the free version will display all the information you need so you can at least see that the hack is possible before you buy.
Start up WinHex, goto Tools - Open RAM, select Ezh2o expand it and select Entire Memory. So we need to find the section of RAM that has our BIOS whitelist. You might as well get used to the Hex Value search(keyboard shortcut is Ctrl + Alt + X) because you will use it frequently. You can find the whitelist by
hspumanti's method: hex string «31 00 30 00 34 00 2d 00 55» or by searching for your original wifi cards device id.
My original card was the Intel 5100 PCI\VEN_8086&DEV_4237&SUBSYS_12118086&REV_00
Which after taking out the strings of text becomes: 8086 4237 1211 8086
the assembler parses the device differently, it basically swaps the byte order of each section and flips the last 2. End result should look like this:
8680374286801112
I searched for the hex : 8680374286801112
and was placed right at the 104 error.(I'm quite sure that if you replaced the hex of your original card at this location w/ whatever your new card devid's are, you would successfully patch your whitelist, but I also believe patching it entirely makes more sense.) From there I scrolled up around 3 pages or so to find the start of the program, the MZ.. (4D5A). I then proceeded to look for bytes «55 8b ec» so I could debug the whitelist the way hspumanti described. Unfortunately I could not locate the bytes mentioned and I have windows 7 which does not have debug.exe. I tried a couple of things on my XP machine but got weird 'Cannot Find File' errors with the com I created.
So I decided I would try to use the debugging image hspumanti posted to see if I could get anything from that.
He did a good job explaining what was going on in this check wireless routine.
1823:02E6 is an infinite loop that jumps to itself so we need to make sure that the program does not get to this point.
1823:02BF This JNZ is a conditional statement which will determine if check wireless routine needs to be ran, but we want to change the condition to never run. The bytes store in 02BF are 7527 if we change the 75 to EB it will change the JNZ condition to a JMP, therefore always skipping the wireless check routine no matter what card is in.
So we just need to find the 75 that has to be modded to EB... Since I couldn't debug my own code I started looking for similar bytes in his. The preceeding bytes of 75 in his example was 84C0 so I decidied I would check the Whole whitelist MZ for bytes 84C075
I highlighted from the start of the MZ to the beginning of the next MZ(around 4 pages total), and searched for hex 84C075 while checking the 'Search in block only' box so it only searches w/in my highlight.
Victory! now of course this proved nothing, but I was very doubtful that this kind of a byte coincidence could happen in such a small section of code.
(Oops looks like I can't attach more than 5 pics.. guess you'll have to use your imagination).
Anyway... I made the change, clicked the disk icon, switched over to EZh20 did a File - Save As - named it the same as the original and saved it onto my desktop. I then moved the 3 .FD files into a different folder and moved the modified .FD in their place. I tried running InsydeFlashx64(Windows 7 64 bit on my machine) but it would not prompt for a flash. I figured it was because I was attempting to flash to the same bios version F.26 so I deleted the platform.ini file and tried again. It auto flashed my bios w/o prompting me so be sure that every thing is correct before you do this.
The flash was successful and ever since I have not seen that stupid 104 bullshit.
WOW, that was long, lemme know if the guide helps anyone! =)
I've got work now, so i'll edit the post later with the recovery method.
Grammar is not my forte, lemme know if something is tough to understand.
-eliquel