Wireless Card Whitelists: Failed Attempt at a HP Pavillion dm1-4108AU

After successfully bypassing the whitelist in my Probook 4525s with the help of Dragy, I felt that it was probably worth trying the same technique on my other whitelisted HP, a Pavillion dm1-4108AU. While other pre-patched BIOS for certain dm1s exist, none of them are for this exact SKU, and I had previously ended up in BIOS recovery after flashing them, so I knew that route was ineffective. I wondered if the same principles or techniques would be effective against my particular dm1.


Where some people have been lucky to find their BIOS flash chip is in plain sight and easily accessible, it seems that I’ve been cursed to play with models where the chip is on the other side of the board. As a result, a full disassembly is required, which is risky, potentially damaging and requires some intuition.


The first step is to slide the latch across to release the battery and remove it. Sliding the latch further to the left allows for the rear vanity cover to be slid off.


At this point, you can install the new wireless card and take note of the whitelisting message. As I have previously done this, I didn’t bother doing it again. To continue disassembly requires taking off the self-adhesive rubber feet by carefully peeling them off.


At this point, it’s best to remove everything within reach – unscrew and remove the wireless card, carefully unclipping the antenna leads and unthreading it from the case. Remove the screw for the hard drive tray and remove the plug connector from the board. Uninstall the SODIMMs, and unplug the display connector. Remove the display by undoing the two hinge screws and lifting the screen slightly.


We can begin removal of the internal plastic shell by undoing all the circled screws. Then, we need to proceed with disassembly by turning the laptop base over.


Remove the keyboard by prying around the edges, and unclip the flexible flat cable. Undo the screws circled in red and undo all flexible flat cable connectors. This should allow the top black plastic and aluminium cover to separate from the base.


The power plug retainer and Kensington lock mechanism has to be removed, then the board comes free.


It’s also good practice to remove the power plug connector entirely from the board. The BIOS flash chip can be seen in the bottom left.


We can see it’s a little skewed and it’s soldering isn’t that great. The board must have shipped with F.13 revision BIOS, but has since been upgraded to F.19.


The chip appears to be marked cFeon QH16-104HIP, an EN25QH16 16Mbit serial flash with 4kB sector size.

Chip Reading Problems

Where the Probook 4525s was forgiving in allowing “test clip” in circuit read-outs and programming, this board wasn’t as friendly. It seemed that the power draw of the components on the board itself or a failure to properly tri-state the bus meant that it was impossible to read-out the chip with the CH341A programmer, resulting in “random” output at best.


I also tried with the MiniPro TL866CS programmer, which was capable of identifying the chip in-circuit, but also made some strange noises from the switching converter, implying the load was high.


Actually reading out the chip was not possible, and resulted in random bytes being returned. If the chip cannot be backed up, it’s not really wise to flash anything as it may become impossible to recover.

Alternative Route? Fail.

At this point, I wondered if an alternative “non-opening” route was the best. I was able to back-up the BIOS using the Universal BIOS Backup Toolkit, along with a flurry of possible malware detections. The backed-up BIOS was able to be patched (see next section), but flashing it back to the board was the problem.


As it is an “older” product, it uses InsydeFlash with encrypted payload. An error message occurs if you try to substitute the .bin file for something else.

Patches to the iscflash.dll file to enable flashing again and bypass the error message were shown on donovan6000’s blog, although this particular version of the DLL appeared different, and an attempt at patching the dll proved unsuccessful.

The Hard Way – Desoldering

As a result, I was bought back to the “hard way” of doing things, namely carefully desoldering the chip with a hot air gun.


After it was desoldered, read-out and programming were immediately successful, showing that the “board” interference was the cause of the errors and random data, not the programmers.


Patching was undertaken with the same methodology using Pheonix Tool, looking for module and patching the flow.

modified-flowThe module in question was StartUpMenu, and was patched in an identical way.


This particular BIOS did not contain any named PEI modules, which made the BIOS security issue a little trickier. However, the Russian reference did show the module by ID, and identical ID module with the target sequence of bytes were seen. As a result, I believed the same patch to be applicable and applied it anyway.


The BIOS was repacked and the chip was flashed. As the version of CH341A programmer software I used didn’t have the exact match for the chip, the closest one was used with no ill effect. Program and verify were successful.


The chip was then hastily, and rather messily soldered back into place, and the laptop reassembled for testing. While no screws were left over or lost, there was a few bent plastic bits … which is inevitable.



With the original “approved” wireless card, the system booted normally, which means the BIOS wasn’t “bricked” by the modification.

Replacing the wireless card with an unapproved card did not work properly, however. It would start the BIOS enough to show the “Press <ESC> for …” line at the bottom, but then would go to a black screen without printing the whitelisting message. It would just sit there … crashed.

I tried clearing the CMOS by physically removing the battery. That didn’t help. Attempts to enter the BIOS failed as the system “hung” before the BIOS was to come up, even though the system acknowledged the pressing of <ESC>.

Unfortunately, it seems, even with all this effort, it was not to be.


I tried to follow the scientist in me and try reproducing the success of bypassing the whitelist protection for a different model of HP laptop which I own. Unfortunately, it appears that it was incomplete and unsuccessful. Even though there is quite a bit of knowledge out there, I just don’t have enough myself to conquer it, and it seems there may be something else which is preventing this from working correctly.

Regardless, it was worth a try anyway, just to see if it would work. However, given the amount of work required to take it apart and desolder/re-solder the chip, I don’t think I’ll ever bother attempting this again. With every desolder, there’s a chance of bumping adjacent SMD components, or tearing off a pad if you overheat the PCB or are a bit too hasty in removing the chip. I’d rather a working laptop, rather than a dead laptop, even if it is somewhat crippled.

HP, you win this time! *shakes fist*

About lui_gough

I'm a bit of a nut for electronics, computing, photography, radio, satellite and other technical hobbies. Click for more about me!
This entry was posted in Computing, Telecommunications and tagged , , , , , , , , , , . Bookmark the permalink.

2 Responses to Wireless Card Whitelists: Failed Attempt at a HP Pavillion dm1-4108AU

  1. David Lindsay says:

    Maybe you could make some flyleads with enamel wire and hot-glue the BIOS to the unused area on the motherboard around the “HannStar” text. If the system can successfully/consistently read/boot from the BIOS ROM without too much RFI susceptibility, maybe you could figure out some way to switch the BIOS from being in-circuit/out-of-circuit.

    I also found this, which might be interesting: http://www.logicalsys.com/graphics/soicheader1.jpg

  2. sparcie says:

    Personally I think the manufacturers are being incredibly stupid locking out new wireless cards from their systems. You’d think being able to replace the wireless card would be a positive marketing wise. I can’t think of a good reason to _not_ allow the upgrade. Luckily this doesn’t seem to be a thing in the desktop market.

Error: Comment is Missing!