The text of the error occurs in two files. We extract them into a separate folder for convenience and open them in any hex editor. Now we need to find all segments with error text. In the first file there were 4 occurrences with the text of the error, in the second 1.
To understand which file checks the cards and displays the error text in case of failure, let’s number all occurrences of the error text in both files directly in the text itself, replacing part of it. Do not forget that you need to specify the utf-16 character code, and not just a number (1,2,3 …)
Having numbered all the sections with the text of the error, I collected the BIOS (more on this later), flashed it and turned on the laptop. During initialization, I received an error message with the number that I had previously set in the editor. Okay, the circle is narrowing. Thus, I found that the file I was looking for is A6F691AC-31C8-4444-854C-E2C1A6950F92_2_86.ROM. Now it is clear where the check of cards takes place.
Step 3. Analysis and modification of the card verification module code.
Then IDA Pro x64 comes into play. Open this file in it. My processor type was automatically determined and all that was left was to click OK.
I will say right away that I am not familiar with assembler at all and I do programming as a hobby (so do not judge strictly). Based on this, I understand that picking in the entire code of the file will not give me anything. But there is an assumption that the list of allowed cards is stored somewhere in the data segment in this file. To check, I conduct a search in the hex editor for VEN of popular manufacturers. Broadcom has 14 E4, while Intel has 80 86. But the order in the hex file is reversed, so we swap places and get E4 14 and 86 80. A search on Intel did not give anything, but on Broadcom a white list was found at offset 324C0 from the beginning file.
It was possible at this stage to substitute the data of your card and, I think, everything would have worked, but this is a crutch solution and I decided to go ahead and cut out the check in the code.
Now we go to IDA Pro and go to this offset (relative to the beginning of the file !!! there are many other options) find the beginning of the white list and climb up to the name of the first variable – unk_180032490. This variable is used to validate maps. We put the cursor on it and press the X key. IDA Pro will show where this variable is used.
.Double click on the function in the pop-up window to go to the code of this function. For further analysis of the algorithm, a schematic representation is more convenient. Therefore, we press the spacebar and the code becomes presented in the form of blocks and links between them. The code shows a validation loop. It is also worth paying attention to what is done before the block with ret, that is, before returning from the function.
And we do the following: the flag is set or removed in the al register. When the check is passed, 1 is written to it through the bl register (highlighted in blue), otherwise (I assume that if there is no equipment in this port), it is reset (red). Our task is to bypass the verification cycle and bypass it to go to the label loc_18001D902: . We rise above the code and look for a convenient place where to do this. I chose the line jz short loc_18001D8CE. Here you need to replace the conditional transition with an unconditional one and jump immediately to setting the al flag and exiting the procedure. Put the cursor on the desired line and go Edit->Patch Program->Assemble... Change the line to jmp short loc_18001D902
To save changes go Edit->Patch Program->Apply Patches to input file
Now the check cycle is not involved and the program goes immediately to setting the flag and exiting the procedure.
Save the file and exit IDA, you won’t need it anymore. But it’s better to open the modified file again and make sure everything is as intended.
Step 4. Assembling the modified BIOS.
Half done. Now it remains to assemble the BIOS with the modified file and flash it into the flash programmer. You can also try to flash a new dump through winFlash from under the OS, but I have not tested this option. We delete everything from the folder with the disassembled dump, except for the folder with the modified module for convenience, since PhoenixTool creates a lot of garbage in the dump folder.
Run PhoenixTool, again select the dump from the manufacturer’s website
Click Advanced->Set checkboxes as in the screenshot->Done
Now the most important thing. Press GO. A You can now make… popup window will appear with an Ok button.
DO NOT PRESS OK!!!!
The DUMP folder with the disassembled BIOS will appear again. We take the file that was modified and copy it to this folder with a replacement. Here now
PhoenixTool will rebuild the BIOS with our changes, recalculate the checksums and spit out the file with the _SLIC postfix – this is the long-awaited dump ready for flashing.
PS I forgot to say that when flashing, it is very desirable to transfer the serial numbers from the dump merged from the laptop to a new one, so that later you do not bother and do it with utilities. Serials are located at the addresses h20000-h200FF.
In conclusion, I want to say that an Intel 4965AGN MM2 card was installed in the laptop, which successfully passed the POST and was picked up by the system. The OS even found drivers for it. Wi-fi works flawlessly. A Broadcom BCM94313HMGB card was also inserted, which was successfully detected by the system, but there were no drivers in the OS, and it was too lazy to look, so the performance was not checked.
Also subjectively, POST began to go much faster, but this may be due to the replacement of the flash with a new one, because the old one was read and sewn intermittently.
That’s all. All the best!
The file of the factory update, the finished dump and the modified module can be taken here