Around two years ago, I posted this article decrying the whole situation where several laptop manufacturers have imposed artificial restrictions in the BIOS firmware against replacement of wireless cards (and other hardware) with other physically compatible units from other sources, or of different models not originally equipped as standard. This prevents one from replacing a poor “single” stream, single-band 150Mbit/s 802.11n 2.4Ghz wireless card with a much superior 867Mbit/s 802.11ac dual-band card even though such cards are inexpensive (under AU$30), and such improvements benefit the end user and network administrators alike, alleviating bandwidth bottlenecks and reducing interference problems.
The article itself did explore the possibility of breaking whitelist protection using a method that donovan6000 posted extensively about, but the project hit a stumbling block when the modified BIOS could not be loaded back onto the hardware due to the use of RSA key signing on the flasher itself. Not knowing any more, I abandoned the project and continued with my life.
Fast forward to May 2016, and I was contacted by a reader by the name of Dragy who was also facing some whitelisting problems. He was adventurous enough to take things further, and was able to develop a successful method to overcome the whitelist protection. He was also able to overcome some issues which I wasn’t aware of, with reference to Russian sources which I wasn’t aware of and couldn’t directly understand which proved pivotal to actually making the modifications work on more recent BIOSes.
He generously sent me a few long e-mails detailing the whole procedure, with explanations about why things were done in certain ways. He very generously volunteered the information in the hope that I could independently verify that the procedure works, and post about it so that others may have a chance to address their own problems. The following post could not have been made without his help.
Before continuing on with this article, all readers should note the following:
- The information provided is mostly based upon information that is publicly available elsewhere (see BIOS Modification Resources at the end), but collated together and independently verified by myself. The information is supplied in good faith, however, I cannot be held responsible for any omissions or errors.
- Users who choose to follow these instructions do so at their own risk. No liability is accepted for any damage incurred, be it direct or consequential, or the ability or inability to use the information provided.
- BIOSes from other models and vendors may share some similarities, however, because each BIOS is different, there is a good chance that blindly making the same changes to other BIOSes is not a good idea. You do so at your own risk.
- Modified BIOSes may introduce defects and bugs which may affect the functionality, stability and reliability of the laptop, and potentially cause hardware damage in the worst case. No implication is made that such modifications are free of side-effects.
As usual, readers should think for themselves before taking any action, and furthermore, have appropriate back-up plans for when things go wrong or get damaged. I will not be held responsible for anything that ends up happening.
Furthermore, please don’t post requests for me to look at your particular BIOS – you’re on your own.
As the former effort was thwarted by the process of actually restoring the BIOS to the laptop, Dragy thought to bypass the whole flashing issue by using a few tools.
The first was a SOIC/SOP8 test clip, from eBay for about AU$4.22. This is basically a special clip with springy pins at the ends which can clip over the BIOS flash chip while it is on its board, and read/program it without desoldering.
The output is to a DIP row of pins, which fits into a programmer. Pin 1 is identified by the red stripe. Although the IDC header is 10-pins, only the top 8 are used, which is normal.
The second thing that’s needed is a programmer. The CH341A programmer is only AU$3.70, making it very cheap, and comes with a breakout board that isn’t needed. This unit basically repurposes a WinChipHead USB to Parallel chip with additional functionalities as a programmer. The top half of the socket is for 24 series I2C chips, whereas the bottom half is for 25 series SPI chips.
The unit doesn’t come with any software, so you will have to download your own – find all download links at the end of the article. Total cost is around AU$8, which is hardly expensive.
In some other cases, you might find that a hot-air rework station is necessary as the chip might need to be desoldered and then resoldered after reprogramming (as some boards don’t like being “clipped to”). For the 4525s, it seems that this isn’t strictly necessary, as using the “clip” was sufficient with the CH341A. Of note was that it wasn’t possible to get the clip working with the TL866 universal programmer, probably because there were other motherboard components drawing power and the TL866 wasn’t able to supply enough voltage, thus was getting “random” IDs and data.
Of course, aside from that, you will also need a compatible wireless card that you want to use in the system that is affected by the whitelist protection.
I didn’t bother searching for any manuals to find out how to take the unit apart. I followed my intuition, but sadly, the design was done so that the BIOS chip was really inaccessible, so you’d probably want to get it right the first time. I sadly didn’t, so I ended up doing this at least three times over.
To begin, we have to pull everything apart. First step is to take out the battery, and then undo the four screws which allow for the decorative panel with the power button to slide off.
Two screws have to be undone to allow the keyboard to slide up and then out. The flexible flat cable needs to be unclipped and removed.
Another screw needs to be undone, to allow the protective plate on the left to be removed.
Unclip the two antenna leads, and unscrew the two screws to release the current wireless card.
Install the new wireless card, and temporarily attach the keyboard flex again. Plug in AC power and boot the machine to confirm it is blocked by the whitelist. Make an exact note of the message.
Continue tearing the unit apart by removing the keyboard again.
Unclip the touchpad FFC, and undo three screws to slide the palmrest and touch-pad assembly off to the right.
Remove the hard drive cage entirely, by undoing three screws, sliding to the right and lifting.
Undo all the flexible cables connected to the motherboard, including the display cable, the webcam USB lead, two antenna leads, power button PCB and speakers.
Also remove any Expresscard/34 cards in the slot.
The two speaker assemblies have to be removed, by undoing two screws in the corner.
The screen assembly then has to be completely detached from the base by undoing six Torx screws.
Now, the plastic “inner” frame has to be removed. Twelve Torx screws and one Philips have to be removed, then the sides carefully unclipped.
Now we’ve got a clean look at the top side of the motherboard. Problem is, the BIOS chip isn’t here and the casing has no access hatches on the rear. To continue, two screws need to be undone – one releases the audio jack board, and the flexible connector needs to be unclipped. The other screw releases the motherboard assembly from the case.
To completely free the motherboard from the case to make our job easier, two cables have to be detached.
At long last, 38 screws later, we have a clear look at the BIOS chip. The chip is partly covered by a label, which normally says the revision that was flashed at the factory (F.09).
Dumping the BIOS
To dump the BIOS, first you need to get appropriate software for the CH341 programmer (see link). The driver must be installed first, then the software run.
Because it’s all in Chinese with no help, it can be a bit intimidating. The language feature on this version doesn’t work, but it would help if you first selected the type to be 25 SPI Flash. I found a screenshot of the English version here, so at least you can refer to that to help understand the software.
The adapter needs to be fitted in the lower half of the socket closest to the USB connector, with pin 1 oriented away, like so. The voltage on the adapter was pre-configured correctly.
Then it’s a matter of clipping the clip onto the chip.
The arrangement is quite precarious, so it pays to have everything on some steady bench with a USB extension lead. Positioning is crucial, and bad contacts will lead to unusual behaviour.
To check if your contact is good, you should click on the Detect (D) button, where it should show the correct manufacturer. If it’s a strange chip which isn’t supported, as long as the ID, Type, Capacity values are not $00, $FF or random values if you hit detect over and over, then you have good contact. If not already, set the chip type to the correct (or closest match).
It takes about 20 seconds to read the chip out, and then you can save it as a .bin file for patching. You might want to try dumping several times and comparing, just in case you have any contact issues.
To do the patching, you’ll need a copy of PheonixTool (I used Version 2.66), IDA Pro and a hex editor of some sort (I used WinHex).
First load your BIOS file into the tool by clicking on the … button and browsing for the BIOS dump. It is preferable to run the tool on fast storage (e.g. SSD) as it will create thousands of files as it decompresses and breaks down the BIOS image into its constituent modules.
Once loaded, you will have a few dialog boxes which inform you about the recovery image name and SLIC details. Just hit OK and you will be returned to the main window.
Clicking on the structure button allows us to see the internal structure of the BIOS image.
If you don’t know which modules are responsible for your whitelist, you should tick both check-boxes on the middle right, and then select DXE Core and extract it. A .MOD file should appear with the UUID name in the folder that PheonixTool is in. Examine the MOD file in a hex editor and search for the error message (Unicode, so every second byte is 0x00 for ASCII).
To find the module the error resides in, you will have to find the header of the next module, which is denoted by the letters “MZ”. The name that appears just before it is the module responsible. In my case, it is ErrorLog.
At this point, I like to go back to PheonixTool and extract the module, so that I have the UUID filename for copying and pasting later.
Dragy informed me that the HP BIOS has another protection, namely one against BIOS modification. This is in a module called SecureUpdating. In this particular model, the module exists as a PEI Module and also needs some attention.
First step is to select the correct manufacturer, which will unlock the other buttons at the bottom.
Click on the Advanced button and then configure it to allow for modifying modules, and for no SLIC. It should look as follows.
Then we can click on the Go button so everything gets put into the /DUMP/ folder and we can then do some modifications and patching.
The first module to deal with is the whitelist. Open IDA Pro and load the appropriate file by searching the UUID in the dump folder and choosing the one with the largest file size (e.g. the search for the UUID of SecureUpdating module gives three results).
Accept the automatically detected load options.
Then IDA will show the default view once the file has been loaded.
If you are following donovan6000’s instructions, as I had in the past, the next step is to search for the message, and then determine which subroutine references it. For a complicated module, that would be the best. But because I’ve analyzed this one before, and the main entrypoint runs through a list of set-variables-and-call in a linear fashion, it’s easier just to jump through each of the subroutines looking for the one with the “nasty” loop. In this case, it was sub_10000A18.
Due to my unfamiliarity with x86 assembly, while I recognized the jz is probably something we wanted to avoid, I didn’t know what to replace it with.
Dragy informed me that the instruction was coded as 0x74, and that would need to be replaced with 0xEB for an unconditional jump.
To do that, highlight jz, and change over to the hex view.
The new function looks like this, and has nothing pointing into the nasty loop.
As IDA doesn’t actually modify the files themselves, we have to create a .dif file listing differences, so do that through the File menu.
Examine the .dif file manually using a text editor and make the changes in the hex editor.
If we stopped here, we would find that it still didn’t work, because of BIOS modification protection. Dragy let me know that the secure updating module needed to be examined. The actual full information is provided in the BIOS Modification Resources section, but to simplify our life, we needed to find 0x750733C0 and replace it with 0x909033C0. In older versions of the BIOS, just one instance exists and is preceded by 0xFEFFFF11 Unfortunately, there are two instances in the latest version (F.62) of the BIOS. As it turns out, the latter instance is what needed to be changed.
Now that that’s done and saved, we can click on the OK button and the BIOS should be repacked and a new file created.
Sometimes, you will get an error about a problem with headers – this seems to be a bug as deleting the DUMP directory and then quickly performing the same changes succeeds. If you forget to close an editor and it retains a lock on the file, then you will also end up failing this procedure. It’s probably best to take a copy of the modified modules just in case it doesn’t build the first time to save your effort.
Reconnect the programmer if you had disconnected it, and test the connection using the Detect (D) button. If all looks well, load the modified file, and then select erase, then program. The unit appears to verify after program automatically. If you receive the left message, everything went well, but if you receive the right message, then verification failed.
If things aren’t really working out, try the Auto button, as it seems to fix everything by itself quite nicely. It can take about two minutes to do a full erase, program, verify cycle.
Then it’s just a case of reversing the procedure and reconstructing the laptop, hoping that you don’t misplace any screws, and you don’t forget to connect any flexible cables.
Overall, I was pleased, as the modifications effectively bypassed the whitelist. I tried it on the original shipped F.09 ROM as well as the latest May/June 2016 F.62 ROM with the same success.
Because I can now harness the 5Ghz wireless N capabilities of my home AP, the transfer rates have gotten much better – on 2.4Ghz, 2.4Mb/s is the realistic limit.
Through experimentation, I proved to myself that just changing the whitelisting module was not sufficient to get a working solution, as BIOS tamper protection needed to be overcome.
With the modifications, the old F.09 ROM blinked the Caps Lock LED during BIOS indicating that the BIOS still probably detected an error, but just didn’t halt due to the modifications made, allowing us to boot. Under the newer F.62 ROM, this behaviour doesn’t exhibit itself.
The biggest caveat seems to be the loss of working S3 “sleep” mode functionality. If you let the laptop go to sleep, it will not be able to wake again. I hypothesize this is due to the S3 resume taking a different code path, which results in the whitelist or tamper protection taking effect again and hanging the BIOS to the point that only an AC+Battery removal will restore the unit to bootable status. In F.09, this “stuck” on wake behaviour had the Caps Lock LED cycling permanently, whereas in F.62, it doesn’t come on, but the same inability to resume from sleep is experienced.
As a result, users should configure their power settings not to sleep on lid closure. It was found that S5 hibernate still performs correctly, and should be used in preference.
It also goes to show that even though the modifications might seem successful at first, there is still the possibility for problems to occur. But given the amount of time and effort taken on a 5-year-old laptop, I really don’t think it’s worth the time and hassle to fix this issue. Other BIOSes with whitelist protection probably won’t have the same issue depending on their codebase and age.
It is with great thanks to Dragy’s comprehensive instructions and pointers to specialist information that I was able to finally enjoy a decent wireless card in my HP Probook 4525s. Even though I don’t use the unit as much as I used to, and it’s getting a little dated, it’s still good to know that it can be defeated (to some degree) at last.
It is a combination of breaking the white-list protection and the BIOS anti-tamper arrangements, while circumventing the need for signed binaries to flash by directly flashing to the chip that made it successful. If any one of these elements were not present, the result would be negative.
It was not without caveats, but at this stage, the fact that it works is a boon for me, and the fact that I reassembled it without any missing screws or misconneted flex is a bit of a miracle as well. It’s a shame that it took this long for me to get around the protection, and it’s a shame it takes this much work to make it happen. I don’t think your average consumer would be able to know enough to safely conduct the modification, or be game enough to try and even I didn’t know enough to even attempt to do it from scratch.
Other BIOSes may be similar, but it’s more likely that there will be differences which makes this approach fail with other units. I will make another posting when a second Intel Wireless-ac 7260 card arrives and I attempt to get that into my HP dm1, the other whitelist-affected laptop I own (aside from the Lenovo E431, which I don’t feel confident even opening).
BIOS Modification Resources
The whole method was a culmination of information available from different postings around the internet which address parts of the “puzzle”. Further to that, there are some other resources which can prove handy for those with other similar laptop BIOSes or if they run into a different situation. Reading these resources can help you with different strategies if you find that your situation differs. Note that quite a few resources are in Russian, but Google Translate does a decent job of making readable sense of it.
- Insyde BIOS Modding: WIFI and WWAN Whitelist details patching the module in the BIOS that contains the whitelist, although later BIOSes have a different loop structure, which the present article addresses.
- Insyde BIOS Modding: Getting Started details modifying InsydeFlash so as to be able to flash non-signed BIOSes by patching iscflash.dll, although this was not applicable to this model.
- Reverse Engineering UEFI PEI-modules details how to defeat one type of BIOS tamper protection.
- Simple Methods of Reverse-Engineering UEFI PEI-modules details defeating another type of BIOS tamper protection.
- PheonixTool is a tool which can be used to inspect and modify such UEFI BIOSes.
- UEFITool is another alternative, with inbuilt search capabilities, but I’m less familiar with this one.
- Universal BIOS Backup Toolkit allows you to backup the BIOS without opening the machine, which can be good for an initial explore, although the backups are not as guaranteed as reading straight off the chip. It also seems to trigger some anti-viruses due to the packer used, so maybe avoid it unless you really need it.
- Patched HPQFlash/EROMPAQ might allow you to downgrade to an older BIOS or flash a different BIOS provided it is in the right format. I didn’t use this but it seems quite model-specific.
- Jump if condition is met shows various x86 opcodes for different types of jumps.
USB EEPROM Programmer and CH341A has download links for the CH341 programmer driver and Chinese-only software. There are alternatives that may work equally well, if you can find them.
- CH341 EEPROM and SPI Flash Programmer has a more up-to-date version of the software for the CH341A programmer, and in English as well. Choose CH341A Programmer 1.29.