Disable Wifi whitelist in HP laptops
To write this topic, I was pushed by my thorny experience installing a wifi 802.11n board, which was missing from the whitelist BIOS in my laptop. Motivation and confidence gave the post Install an unsupported Wifi card in the HP Pavilion dv6-1319er
When I put another wifi card for the first time and saw this message: the first thought was that it was some kind of hardware not compatible devices and that the issue of replacing the card is completely hopeless. But a Google search made it clear that not everything is still lost. The Internet did not offer many solutions: 1. Flash the BIOS with the correct patch, which disables whitelist completely or adds \ replaces VEN, DEV, SUBSYS in whitelist with the necessary board. 2. Reflash the wifi board itself in order to replace VEN, DEV, SUBSYS in it with those that are in the whitelist, by which the ability to install one or another board is checked. The process of obtaining a wifi-n board was dirty and criminal, therefore I will not describe it, thanks Dr. Marteens
for assistance. The motherboard in the laptop was Intel WM3945ABG. To replace it, Intel Wifi Link 5100 AGN was obtained. He began to act according to the steps described in the post above.
When I just started to deal with this issue 3 months ago, searches on the Internet made it clear that it was not possible to reflash a wifi card from intel, and somehow I could not find a ready-patched BIOS at all ... maybe I was looking badly.
Unpacking the BIOS using the Phoenix Tool failed. The bios was collected on some older basis.
I've never done BIOS programming, and I'm with YOU as an assembler. The search for a utility for unpacking the Compaq BIOS did not yield any results, and it was decided to pick the BIOS live using WinHEX. The firmware is an HPQFlash.exe flasher and a CAB archive with firmware files.
The native wifi board of the equipment ID had this
PCI \ VEN_8086 & DEV_4222 & SUBSYS_135C103C the
values in the firmware are stored in the reverse order:
VEN_8086 -> 8680
DEV_4222 -> 2242
SUBSYS_135C103C -> 3C105C13 A
search for the first two values yielded a lot of suspicions, and 3 and 13 did not have a chance of 10 and 13 thoughts that ROM.bin firmware is still somehow packed or encrypted. Another brainstorming, googling, and within a few hours an address map was compiled with the desired values and the location of the whitelist in the firmware was localized. In order not to use a lot of space, BIOS programmers decided to save a couple of bytes and completely recorded SUBSYS only for 3C105B13, and the rest of the values seemed to be substituted by the algorithm.
where are highlighted in greenIntel motherboard, Broadcom blue . Individual values are modifications of boards 5C, 5D, 5E, 5F. And similarly recorded Broadcom.
open the Intel driver .inf file and find the same VEN, DEV, SUBSYS
And it seems that everything is already quite simple, we replace one value with another, save everything and reflash the BIOS. However, there are only 5 different Intel 3945 modifications, and Intel 5100 modifications, judging by the driver INF file, as many as 8. Although, in theory, it is enough to register the ID of only one board. Naturally, in order to know VEN, DEV, SUBSYS, you need to insert it into another laptop in which there is no whitelist. I decided to postpone this venture and check one important point: does the CRC flasher check the firmware? After all, the Phoenix Tool utility itself collects everything back and recounts / rewrites the CRC, and in my case it would have to be done by hand.
Having changed a couple of bytes in ROM.bin, another question arose: how can I put all this back into the CAB archive? After all, the standard set of archivers works only with its own formats and plus 3–4 third-party ones, and the CAB-format was developed by Microsoft, and is not particularly supported for packing by anyone. After some time, the 2007 Cab Maker 2.0.0.120 program was found, with which I collected the first modified BIOS archive.
Where the BIOS checksum is stored, I did not know, I could not find any information about the structure of the firmware.
Suspicions fell on the ROM.sig file, but there was nothing to check. Attempts to find the file hash by hashing ROM.bin with different algorithms (CRC32, MD5, SHA1 - SHA512 and several more), both in it and ROM.sig, failed, which is not surprising.
The idea of how to proceed further was born instantly. If the flasher checks the CRC, then it takes it somewhere or calculates it, and compares it with a different value. So you need to disassemble HPQFlash.exe and in Debug mode, find the steps in the steps or the place where this checksum check takes place.
There was also an idea in the flasher to disable CRC checking, but this was fraught with dead hardware in general, if the BIOS checks its CRC when the laptop starts.
There was another optionas the Germans did on one site. They also did not find where the checksum is stored, but somewhere they found out or picked up the algorithm for calculating it, and decided to slip the correctly calculated values into the remaining bytes where the information about the Broadcom board is stored so that the CRC of the Rom.bin file does not change in the end. And apparently they did it.
As I wrote above, with ASM everything is very bad and the maximum I could get to the bottom of is in the IDA Pro Advanced disassembler, in debug mode, find the place where the checksum goes through, but could not find CRC values. Then I turned for help to a friend who wrote for a long time on ASM to find the same checksum. However, this did not come to this. The next assault on Google gave a link to the wailing wall, where users are asked to patch the BIOS of their laptops. I decided to stop further research, for to beat like a fly in the glass, when the open window next to it was considered not advisable.
List of already patched BIOS for HP with whitelist disabled
When I put another wifi card for the first time and saw this message: the first thought was that it was some kind of hardware not compatible devices and that the issue of replacing the card is completely hopeless. But a Google search made it clear that not everything is still lost. The Internet did not offer many solutions: 1. Flash the BIOS with the correct patch, which disables whitelist completely or adds \ replaces VEN, DEV, SUBSYS in whitelist with the necessary board. 2. Reflash the wifi board itself in order to replace VEN, DEV, SUBSYS in it with those that are in the whitelist, by which the ability to install one or another board is checked. The process of obtaining a wifi-n board was dirty and criminal, therefore I will not describe it, thanks Dr. Marteens
104-Unsupported wireless network device detected.
System halted. Remove device and restart. for assistance. The motherboard in the laptop was Intel WM3945ABG. To replace it, Intel Wifi Link 5100 AGN was obtained. He began to act according to the steps described in the post above.
When I just started to deal with this issue 3 months ago, searches on the Internet made it clear that it was not possible to reflash a wifi card from intel, and somehow I could not find a ready-patched BIOS at all ... maybe I was looking badly.
Unpacking the BIOS using the Phoenix Tool failed. The bios was collected on some older basis.
I've never done BIOS programming, and I'm with YOU as an assembler. The search for a utility for unpacking the Compaq BIOS did not yield any results, and it was decided to pick the BIOS live using WinHEX. The firmware is an HPQFlash.exe flasher and a CAB archive with firmware files.
The native wifi board of the equipment ID had this
PCI \ VEN_8086 & DEV_4222 & SUBSYS_135C103C the
values in the firmware are stored in the reverse order:
VEN_8086 -> 8680
DEV_4222 -> 2242
SUBSYS_135C103C -> 3C105C13 A
search for the first two values yielded a lot of suspicions, and 3 and 13 did not have a chance of 10 and 13 thoughts that ROM.bin firmware is still somehow packed or encrypted. Another brainstorming, googling, and within a few hours an address map was compiled with the desired values and the location of the whitelist in the firmware was localized. In order not to use a lot of space, BIOS programmers decided to save a couple of bytes and completely recorded SUBSYS only for 3C105B13, and the rest of the values seemed to be substituted by the algorithm.
where are highlighted in greenIntel motherboard, Broadcom blue . Individual values are modifications of boards 5C, 5D, 5E, 5F. And similarly recorded Broadcom.
open the Intel driver .inf file and find the same VEN, DEV, SUBSYS
; HP_3945_ABG
%NIC_MPCIEX_3945ABG% = Install_MPCIEX_HP_3945_ABG_VISTA64_MOW1 , PCI\VEN_8086&DEV_4222&SUBSYS_135B103C ; MOW1
%NIC_MPCIEX_3945ABG% = Install_MPCIEX_HP_3945_ABG_VISTA64_MOW2 , PCI\VEN_8086&DEV_4222&SUBSYS_135C103C ; MOW2
%NIC_MPCIEX_3945ABG% = Install_MPCIEX_HP_3945_ABG_VISTA64_RoW , PCI\VEN_8086&DEV_4222&SUBSYS_135D103C ; RoW
%NIC_MPCIEX_3945ABG% = Install_MPCIEX_HP_3945_ABG_VISTA64_JPN , PCI\VEN_8086&DEV_4222&SUBSYS_135E103C ; JPN
%NIC_MPCIEX_3945ABG% = Install_MPCIEX_HP_3945_ABG_VISTA64_KRA , PCI\VEN_8086&DEV_4222&SUBSYS_135F103C ; KRAAnd it seems that everything is already quite simple, we replace one value with another, save everything and reflash the BIOS. However, there are only 5 different Intel 3945 modifications, and Intel 5100 modifications, judging by the driver INF file, as many as 8. Although, in theory, it is enough to register the ID of only one board. Naturally, in order to know VEN, DEV, SUBSYS, you need to insert it into another laptop in which there is no whitelist. I decided to postpone this venture and check one important point: does the CRC flasher check the firmware? After all, the Phoenix Tool utility itself collects everything back and recounts / rewrites the CRC, and in my case it would have to be done by hand.
Having changed a couple of bytes in ROM.bin, another question arose: how can I put all this back into the CAB archive? After all, the standard set of archivers works only with its own formats and plus 3–4 third-party ones, and the CAB-format was developed by Microsoft, and is not particularly supported for packing by anyone. After some time, the 2007 Cab Maker 2.0.0.120 program was found, with which I collected the first modified BIOS archive.
Where the BIOS checksum is stored, I did not know, I could not find any information about the structure of the firmware.
Suspicions fell on the ROM.sig file, but there was nothing to check. Attempts to find the file hash by hashing ROM.bin with different algorithms (CRC32, MD5, SHA1 - SHA512 and several more), both in it and ROM.sig, failed, which is not surprising.
The idea of how to proceed further was born instantly. If the flasher checks the CRC, then it takes it somewhere or calculates it, and compares it with a different value. So you need to disassemble HPQFlash.exe and in Debug mode, find the steps in the steps or the place where this checksum check takes place.
There was also an idea in the flasher to disable CRC checking, but this was fraught with dead hardware in general, if the BIOS checks its CRC when the laptop starts.
There was another optionas the Germans did on one site. They also did not find where the checksum is stored, but somewhere they found out or picked up the algorithm for calculating it, and decided to slip the correctly calculated values into the remaining bytes where the information about the Broadcom board is stored so that the CRC of the Rom.bin file does not change in the end. And apparently they did it.
As I wrote above, with ASM everything is very bad and the maximum I could get to the bottom of is in the IDA Pro Advanced disassembler, in debug mode, find the place where the checksum goes through, but could not find CRC values. Then I turned for help to a friend who wrote for a long time on ASM to find the same checksum. However, this did not come to this. The next assault on Google gave a link to the wailing wall, where users are asked to patch the BIOS of their laptops. I decided to stop further research, for to beat like a fly in the glass, when the open window next to it was considered not advisable.
List of already patched BIOS for HP with whitelist disabled