Turning off the white list Wifi in HP laptops
To write this topic I was pushed by my thorny experience of installing wifi on the 802.11n board, which was not available in the whitelist BIOS in my laptop. Giving motivation and confidence given post Installing unsupported Wifi card in HP Pavilion dv6-1319er
When I first put another wifi board and saw this message:
The first thought was that it was some kind of hardware incompatibility of devices and that the issue of replacing the board was completely hopeless. But Google search made it clear that all is not lost. Internet solutions offered not a lot of solutions:
1. Flush the BIOS with the correct patch, which disables whitelist completely or adds / replaces VEN, DEV, SUBSYS with whitelist for the required board.
2. Reflash the wifi board itself to replace VEN, DEV, SUBSYS in it with those in the whitelist, which are used to verify the possibility of installing a particular board.
')
The process of getting wifi-n fees was dirty and criminal, so I will not describe it, thanks to Dr. Marteens for their assistance. The motherboard in the laptop was Intel WM3945ABG. To replace it, it was produced Intel Wifi Link 5100 AGN. Began to act in steps described in the post above.
When I first started working on this issue 3 months ago, Internet searches made it clear that it was not possible to reflash a wifi card from intel, but I didn’t find a ready-to-get BIOS patch ... maybe I was looking bad.
Unpacking the BIOS using the Phoenix Tool failed. The bios was compiled on some older basis.
I have never done programming bios, and I am also with YOU with assembler. The search for the Compaq BIOS unpacking utility yielded no results, and it was decided to pick the bios live, using WinHEX. The firmware is a HPQFlash.exe flasher and a CAB archive with firmware files.
I native equipment wifi wifi
PCI \ VEN_8086 & DEV_4222 & SUBSYS_135C103C
values in the firmware are stored in reverse order:
VEN_8086 -> 8680
DEV_4222 -> 2242
SUBSYS_135C103C -> 3C105C13
Search for the first two values gave a lot of results, but for 3C105C13 none, there were suspicions and thoughts that the ROM.bin firmware was somehow packed or encrypted. The next brainstorming, googling, and for several hours a map of addresses with the desired values was compiled and the whitelist location 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 remaining values seemed to be substituted by the algorithm.
where the green highlighted Intel motherboard, blue Broadcom . Separate values are modifications to the boards 5C, 5D, 5E, 5F. And similarly recorded Broadcom.
open the .inf file of Intel drivers and find the same VEN, DEV, SUBSYS
And it seems that everything is already quite simple, we replace some values with others, we save everything and reflash the BIOS. However, the Intel 3945 modifications are only 5 different, and the Intel 5100 modifications, judging by the INF file of the drivers, as much as 8. Although in theory it is enough to write the ID of only one board. Naturally to find out VEN, DEV, SUBSYS, it must be inserted 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 / overwrites the CRC, and in my case it would have to be done by hand.
Changing a couple of bytes in ROM.bin, another question emerged: how to put all this back into the CAB archive? After all, the standard set of archivers works only with its own formats, plus 3 - 4 third-party ones, and the CAB format was developed by Microsoft, and is not specifically supported by anyone for packing. After some time, the 2007 program Cab Maker 2.0.0.120 was found, with which I compiled the first modified BIOS archive.
Where the BIOS checksum is stored, I did not know, I could not find any information about the firmware structure.
Suspicions fell on the ROM.sig file, but there was nothing to check. Attempts to find a hash file by hashing ROM.bin with different algorithms (CRC32, MD5, SHA1 - SHA512 and a few more), both in him and ROM.sig were unsuccessful, which is not surprising.
The idea of how to proceed was born instantly. If the flasher checks the CRC, it means that it takes or calculates it somewhere, and compares it with another value. It means that HPQFlash.exe should be disassembled and in the Debug mode, step by step, find the algorithm or the place where this checksum test passes.
There was also an idea in the flasher to turn off the CRC check, however it was fraught with killed iron in general, in case the BIOS checks its CRC when the laptop starts.
There was another option , as 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 was stored so that the CRC of the Rom.bin file did not change. And apparently they did it.
As I wrote above, with ASM, everything is very bad for me and the maximum I can get to the bottom is in the IDA Pro Advanced disassembler, in debugging mode, find the place where the checksum test runs, but could not find the CRC values. Then I turned for help to a friend who had been writing to ASM for a long time in order to find the same checksum. However, this was not the case. The next storming of Google gave a link to the wailing wall , where users ask to patch the BIOS of their laptops. I decided to stop further exploration, because it was not advisable to fight like a fly into the glass when the window was open next to it.
List of already patched BIOSes for HP with whitelist disabled
When I first put another wifi board and saw this message:
104-Unsupported wireless network device detected.
System halted. Remove device and restart.The first thought was that it was some kind of hardware incompatibility of devices and that the issue of replacing the board was completely hopeless. But Google search made it clear that all is not lost. Internet solutions offered not a lot of solutions:
1. Flush the BIOS with the correct patch, which disables whitelist completely or adds / replaces VEN, DEV, SUBSYS with whitelist for the required board.
2. Reflash the wifi board itself to replace VEN, DEV, SUBSYS in it with those in the whitelist, which are used to verify the possibility of installing a particular board.
')
The process of getting wifi-n fees was dirty and criminal, so I will not describe it, thanks to Dr. Marteens for their assistance. The motherboard in the laptop was Intel WM3945ABG. To replace it, it was produced Intel Wifi Link 5100 AGN. Began to act in steps described in the post above.
When I first started working on this issue 3 months ago, Internet searches made it clear that it was not possible to reflash a wifi card from intel, but I didn’t find a ready-to-get BIOS patch ... maybe I was looking bad.
Unpacking the BIOS using the Phoenix Tool failed. The bios was compiled on some older basis.
I have never done programming bios, and I am also with YOU with assembler. The search for the Compaq BIOS unpacking utility yielded no results, and it was decided to pick the bios live, using WinHEX. The firmware is a HPQFlash.exe flasher and a CAB archive with firmware files.
I native equipment wifi wifi
PCI \ VEN_8086 & DEV_4222 & SUBSYS_135C103C
values in the firmware are stored in reverse order:
VEN_8086 -> 8680
DEV_4222 -> 2242
SUBSYS_135C103C -> 3C105C13
Search for the first two values gave a lot of results, but for 3C105C13 none, there were suspicions and thoughts that the ROM.bin firmware was somehow packed or encrypted. The next brainstorming, googling, and for several hours a map of addresses with the desired values was compiled and the whitelist location 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 remaining values seemed to be substituted by the algorithm.
where the green highlighted Intel motherboard, blue Broadcom . Separate values are modifications to the boards 5C, 5D, 5E, 5F. And similarly recorded Broadcom.
open the .inf file of Intel drivers 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 some values with others, we save everything and reflash the BIOS. However, the Intel 3945 modifications are only 5 different, and the Intel 5100 modifications, judging by the INF file of the drivers, as much as 8. Although in theory it is enough to write the ID of only one board. Naturally to find out VEN, DEV, SUBSYS, it must be inserted 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 / overwrites the CRC, and in my case it would have to be done by hand.
Changing a couple of bytes in ROM.bin, another question emerged: how to put all this back into the CAB archive? After all, the standard set of archivers works only with its own formats, plus 3 - 4 third-party ones, and the CAB format was developed by Microsoft, and is not specifically supported by anyone for packing. After some time, the 2007 program Cab Maker 2.0.0.120 was found, with which I compiled the first modified BIOS archive.
Where the BIOS checksum is stored, I did not know, I could not find any information about the firmware structure.
Suspicions fell on the ROM.sig file, but there was nothing to check. Attempts to find a hash file by hashing ROM.bin with different algorithms (CRC32, MD5, SHA1 - SHA512 and a few more), both in him and ROM.sig were unsuccessful, which is not surprising.
The idea of how to proceed was born instantly. If the flasher checks the CRC, it means that it takes or calculates it somewhere, and compares it with another value. It means that HPQFlash.exe should be disassembled and in the Debug mode, step by step, find the algorithm or the place where this checksum test passes.
There was also an idea in the flasher to turn off the CRC check, however it was fraught with killed iron in general, in case the BIOS checks its CRC when the laptop starts.
There was another option , as 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 was stored so that the CRC of the Rom.bin file did not change. And apparently they did it.
As I wrote above, with ASM, everything is very bad for me and the maximum I can get to the bottom is in the IDA Pro Advanced disassembler, in debugging mode, find the place where the checksum test runs, but could not find the CRC values. Then I turned for help to a friend who had been writing to ASM for a long time in order to find the same checksum. However, this was not the case. The next storming of Google gave a link to the wailing wall , where users ask to patch the BIOS of their laptops. I decided to stop further exploration, because it was not advisable to fight like a fly into the glass when the window was open next to it.
List of already patched BIOSes for HP with whitelist disabled
Source: https://habr.com/ru/post/114502/
All Articles