The tale of how I put an unsupported Wimax / Wifi card in Lenovo X201

    I somehow fell into the hands of a personal use laptop Lenovo X201 - an excellent working machine.
    Everything in it seems to be good and everything seems to be there, but as usual I want more - I wanted to have a built-in WiMax (I already have a 3G modem in it and it works pretty well).

    image

    For WiMax, an Intel WiMax / Wifi Link 5150 PCIe Mini Card was purchased.
    After installation, it turned out that it turns out most modern laptops (Lenovo in particular) have a White-list of devices that they support. This is done apparently so that users buy only branded devices in company stores. Honestly, I would be glad to buy such a device if they were freely sold with us (correct me, if so, maybe I was not looking well enough).
    In particular, my laptop was upset when I saw that the card that I slipped in was not in the White-list and gave a message:
    1802: Unauthorized network card is plugged in - Power off and remove the miniPCI network card.
    In case of installing an unsupported 3G modem, you will receive a message:
    1804: Unauthorized WAN card is plugged in - Power off and remove the WAN card.

    I want to pay attention to one feature right away , for those who don’t know. In fact, WiFi and WiMax being on the same board are connected via two different channels - one PCIe, the second USB, respectively.

    Maybe this will surprise someone (as, for example, me earlier) - WiMax is connected via the USB bus, although both devices are on the same board. Such a connection is not obvious and most importantly - the presence of a USB pin on the PCIe connector is optional (which is what I pushed into the Lenovo x61s laptop) - you need to check it either with a tester or read the internal docks.
    Some information on USB on the mini-PCIe connector is onWikipedia - conclusions 36, 38.

    And by the way, such a hybrid card (at least mine) cannot work in two modes at once. Those. or wifi or wimax, software switching. This in theory can cause problems with turning on the power to the card. Judging by the forums, problems can be solved, but it seems like you can’t do without a soldering iron. Luckily, it worked out for me.

    So if this article suddenly prompts someone to buy a Wifi / Wimax card, you first need to make sure that there really is a USB in the PCIe connector, otherwise you will have to get a little overboard.
    Despite the lack of USB, some craftsmen still managed to split USB to MiniPCI - for this, you just need a desire, hands, wires, a soldering iron and a circuit, but this is already extreme.

    The investigation of the problem began with the forum:
    (1) forum.thinkpads.com/viewtopic.php?t=55837
    and later
    (2) www.thinkwiki.org/wiki/Problem_with_unauthorized_MiniPCI_network_card
    (3) http://web.dodds.net/ ~ vorlon / wiki / blog / Upgrading_a_ThinkPad_BIOS.html
    (4) www.endeer.cz/bios.tools
    (5) www.endeer.cz/bios.tools/bios.html
    (6) http://forums.mydigitallife.info /threads/20223-Remove-whitelist-check-add-ID-s-to-break-hardware-restrictions-mod-requests.?p=338719#post338719
    (7) www.endeer.cz/bios.tools/modz. html? machine = ALL

    I had a rather complicated case - the BIOS of the new modification and methods like editing a couple of bytes in CMOS no longer worked, and there was also no ready BIOS for my model by reference (7). In my case, there were 3 ways to solve the problem:
    1. Turn off white-list validation
    2. Writing VEN / DEV / SUBSYS from my card in the white-list in exchange for some unnecessary card
    3. Change VEN / DEV / SUBSYS in my map to those that are already in the white-list.

    The third method looked somehow not beautiful and threatened to cause problems with firewood.
    The second method was seductive and seemed easier - because don’t bother with searching for an ASM code and making a patch, but still I aimed at the first method - because It is more versatile and beautiful.

    Decide which way you choose. Method 3 is described by reference (2).
    Method 2 - stupidly replacing the byte sequence with the ones of interest. The BIOS checksum, as I understand it, is not particularly verified anywhere, at least for my version. There may be some traps, but because I have not tried to go this way - I do not know about them.

    After reading links (4), (5) I was kind of inspired by the idea of ​​making a patched bios myself, but after several hours of working with tools on the 4th link + IDA, I was a little tired and thought to hammer on this idea.
    However, the line seen at link (3) suddenly opened a second wind
    image

    Once again I read the contents of links (4) and (5) more carefully and slowly began to pick the BIOS. I will not translate what is written there, because Unfortunately, the author of these pages, in my opinion, is not doing very well with the availability of the presentation and generally the availability of information (although the articles are literate), and I did not quite understand the part of the article relating to actually searching for the code and thinking over the replacement. Probably, being an avid connoisseur of IDA and assembler, you can understand what he writes - but in bios issues I would rather measure it several times than once unsuccessfully cut it off (there was a sad experience). There is also a feeling that the information in the article is a little outdated. Of course, I had little knowledge of assembler, but it was clearly not enough to understand what needs to be done.

    In general, my research did not lead to anything understandable, but fortunately at the right time, when I almost dropped my hands a second time, a good friend of kmeaw helped me - and pretty quickly found the White-list check function in the right file and tweaked some byte. On this lyric part, I will probably finish and proceed to describe my actions.

    A little warning.

    ALL FURTHER ACTIONS YOU DO AT YOURSELF AND RISK !!!


    Working with the BIOS (especially if you do everything yourself) is a very responsible and dangerous process.
    All the actions described below apply to BIOS v1.22 for Lenovo X201 and may differ from the actions required for other laptops, although I will try to describe the general principle.
    All utilities for working with BIOS can be found at the link at the end of the article.

    The BIOS hack consists of several stages:
    1. Downloading, unpacking, decomposition into modules.
    2. Search for verification functions (for WAN - one function, for WWAN - another)
    3. Organization of bypass verification functions
    4. Fit the packed version of the file to the size of the original version (the size must match)
    5. Making changes to the main BIOS module by comparing the original and patched versions of the module.

    Let's get started.
    1. Downloading, unpacking, decomposition into modules.

    The first thing to do is to get the actual BIOS file itself for further work. There are two ways to do this:
    * Make a backup of the current BIOS and work with it. For some reason, I decided not to use this method, and I can’t tell anything about it.
    * Download the firmware file from the official website , unzip.

    The $ 01C2100.FL1 file of interest will be located at \ DRIVERS \ FLASH \ 6quj08us \ 6QET52WW
    This file is a compressed image of the system BIOS. All other files (other than FL1) belong to some other parts of the system that I was not interested in and I don’t know what they are intended for - in the future they are not particularly needed.

    After the file of interest is found, it will be necessary to unzip it.
    To do this, enter the command:
    phcomp /D $01C2100.FL1
    Then you need to gut the resulting file into modules with the command
    phnxsplit.exe $01C2100.FLh
    (for phnxsplit.exe necessary library cygwin1.dll)
    I think there should pay attention to the fact that most of the files have been unpacked by the algorithm lzint and to return everything is back - you need to pack the corrected file back - but more on that later.
    2. Search for verification functions (for WAN - one function, for WWAN - another)

    After executing the command, you will get a bunch of files with the * .rom extension. Among this disgrace, you need to find the desired file, which we will continue to scoff at. First of all, you need to find a device that is 100% in the while-list. To do this, you need (the method for XP will be described below, if you have a different OS - try to find a way to find out the data yourself) go to
    "device manager \ (wifi device or 3G modem) \ information \ device instance code"
    Let, for example, it be :
    Intel Wifi Link 1000BGN, PCI\VEN_8086&DEV_0084&SUBSYS_13158086&REV_00
    Interesting data is:
    VEN_8086&DEV_0084&SUBSYS_13158086
    From this we get the following line for searching:
    0x8680840086801513
    In the case of a 3G modem,
    0xc6050592
    I think it’s clear how it turned out (reverse order of bytes for each part of the record).
    You can use this line from the example directly, I think it should be in your BIOS.

    After receiving such a line, you need to somehow search in all the unpacked files. Most likely it will be a single BIOSCODEXX.rom file.
    I personally did this using FAR (Alt + F7, look for hexadecimal code).

    In my case, the file with the verification function of interest was the BIOSCODE06.rom file.
    Here the fun begins.
    Opening it through the IDA for quite a while I tried to understand what is said by reference (5). By the way, you need to open the BIOS file by first renaming the source file to a file with the .hex extension.
    The file consists of a 27-byte header and the body of a binary hexadecimal application. The header contains an indication of the offset relative to the main BIOS. What I understood is that the offset is indicated there, since when working all the modules are in the same memory area and pointers to functions in the module are referenced taking into account the offset.
    3. Organization of bypass verification functions

    In practice, it turned out that in the part of the code that interests us, all the jmp on the function are relative and the offset does not play any value.
    Attempts to understand the module on their own did not lead to anything - due to the lack of even minimal experience in disassembling, despite the small knowledge of assembler, I had to turn to a friend for advice.
    After 10 minutes, he sent me such a screenshot. The
    image
    screenshot actually contained what needs to be fixed.

    Having seen the screenshot, I decided to use hiew 6.50 (which can be found in the archive) to edit the file, as It turned out to be easier than IDM.
    A little help on using HIEW:
    F4 - Изменение режима (Text, Hex, Decode)
    ------ Изменения удобней вносить в режиме Hex
    ------ Анализировать работу кода - в режиме Decode
    ------ В режиме Hex доступна комбинация Ctrl+F5
    Ctrl+F5 - Установка смещений. На скриншоте указаны адреса без учёта 27-байтового заголовка. Для установки таких же смещений, необходимо указать смещение -1B
    F5 - Переход на смещение (указывается в hex)
    F3 - Редактирование
    F9 - Сохранение.


    The editing shown in the screenshot is quite understandable and simple, after the white-list check function was found.
    The function is called only from one place, it has clear boundaries. The change is that at the beginning of the function, jmp occurs at the end of the function. The output at the same time looks like the card successfully passed the test.
    It seems that the verification function was killed, everything seemed to be, but no - the function was responsible only for Wifi / Wimax cards (error 1802). There is another function - to check the WAN (error 1804). It didn’t take a lot of time to search for it - the principle turned out to be identical, but the patch took a considerable time, because after editing, the module in a compressed form did not want to become the right size (the same size as it was before the changes).

    The same size is necessary due to the fact that the phnxmod.exe utility, which later replaces the module in the $ 01C2100.FLh file, cannot work with files if the new one differs from the old one by at least byte.

    Actually, in order to make the necessary change and adjust the size, I had to fix a lot and erase a piece of the verification function (fortunately, after adding jmp, it was no longer required).
    Result in the picture: The
    image
    top screenshot is a workaround for the WAN-card verification function.
    The bottom screenshot is a workaround for the functions of checking Wfi / Wimax cards.

    4. Fit the packed version of the file to the size of the original version

    The change was made to the file, after the file was back packed.
    It is worth noting that the file is not packaged by the phcomp command, as you might think. A set of commands from the kit to the BIOS. You can determine the old from the new - by what comes with the BIOS, in the \ DRIVERS \ FLASH \ 6quj08us folder. In general, I spent a lot of time with this, until I realized. At the end of the article there is a ready-made set of utilities for packing a patched file, in particular for my BIOS with a bat nickname (based on logo.bat). Also, I need to pack the source file, which I called BIOSCODE06.rom. As a result, I got two files BIOSCODE06.rom-lz (patched), BIOSCODE06.rom-orig-lz (original) of the same size.
    Для старых это - prepare.exe
    ------ файл обычно есть в комплекте с скачанным биосом, для упаковки, нужно создать файл-скрипт.
    ------ Пример скрипта можно найти так же в комплекте с биосом, называется logo.scr. В файле нужно
    ------ заменить "LOGO logo.." на "BIOSCODE file.rom"
    Для новых это - fi.exe, fp.exe, ceimain.bin, rom2mod.exe
    ------ файлы обычно есть в комплекте с скачанным биосом, для упаковки, нужно создать файл-скрипт.
    ------ Пример скрипта можно найти так же в комплекте с биосом, называется logo.scr. В файле нужно
    ------ заменить"LOGO logo.." на "BIOSCODE file.rom"
    ------ Пример скрипта для linux с использованием wine можно взять тут






    5. Making changes to the main BIOS module by comparing the original and patched versions of the module.

    The last step on the way to the finished patched BIOS is to replace the module in the compiled main BIOS file $ 01C2100.FLh

    To do this, use the command:
    phnxmod.exe 01C2100.FLh BIOSCODE06.ro2 BIOSCODE06.ro2.patched
    The syntax is:
    phnxmod.exe (unpacked version $ 01C2100.FL1) (original packed module) (modified packed module )

    After executing the command, you should see something like this: This is the last stage of the hack. The resulting patched file $ 01C2100.FLh can be used for flashing using WinPhlash. To do this, I took the archive from the link (6), corrected the rom-file and config, and reflashed my laptop.
    Okay, all files open.
    ROM size 200000h, old module 7B66h+1Bh, new module 7B66h+1Bh.
    Loading data...Old module (without header) found at 1EA565h. Replaced.
    Writing modified ROM back... Done.

    ---------------- WARNING! ----------------
    If you don't know what you're doing there's a very high risk of rendering your
    computer unusable by flashing a modified BIOS. This is not a safe playground.
    ---------------- WARNING! ----------------






    After flashing, I successfully launched an unsupported Wimax / wifi card on my laptop, checked the connection to Wifi, Wimax (Comstar, Yota) - everything is fine.

    The Sierra MC8775 3G module was also tested, which should not be supported on this model. The laptop booted successfully. After installing the drivers, it was possible to successfully connect to the 3G network.

    Files:
    1. Ready-made archive with patched BIOS 1.22 for Lenovo X201 (no white-list) bypass 1802/1804 error 2. Patched BIOSCODE06.rom file ($ 01C2100.FLh in the archive is already patched) 3. A set of utilities for working with BIOS 4 . for packing module Utilities
    Инструкция по установке:
    Запустить WinPhlash.exe из архива. Открыть "Advanced Settings" и проверить соответствие чек-боксов и параметров обновления:

    ("Flags" Tab):
    [ ] Verify BIOS part number
    [ ] Flash only if BIOS version is different
    [ ] Flash only if BIOS version is newer
    [ ] Verify BIOS image size
    [ ] Verify BIOS checksum
    [ ] Zero block before erasing
    [x] Verify block after programming
    [x] Disable Axx swaping automatic detection (if present)
    [ ] Clear CMOS Checksum

    ("DMI" tab)
    "Update": Select "Update the BIOS and not DMI"





    In conclusion, I want to remind once again that everything you do with the BIOS is very responsible and serious. If there is uncertainty about something, it is better to double-check a hundred times and make sure that you are doing everything correctly. When flashing, be sure to turn off all programs and applications (if you are flashing from windows), or better, flashing from a bootable CD or flash drive. Also, it is better to use already patched and verified BIOS versions (you can try to find the link (7), than do them yourself, and if you do, read as much information as possible, except for this article at least at the links above.

    Ps Thank you kmeaw for helping me edit the ASM code and instructing you on the true path.

    Also popular now: