August 16, 2013 at 23:03New arguments in battle with Insyde UEFI BIOS settings
Not so long ago, a detailed article was published on Habré about changing the hidden Insyde BIOS settings . Without claiming the laurels of its author and all other people working on the topic ( modifying the grub UEFI shell and the pioneers of menu parsing ), I want to describe several problems (and ways to solve them) that people who want to put this information into practice may encounter:
It is worth noting that I personally encountered all these problems (and spent a lot of effort on them) in trying to activate the RAID mode for the SATA controller instead of AHCI (for the subsequent inclusion of Intel SRT ) on the fairly fresh DTR laptop HP Envy 17-j005tx (i7-4700MQ, 16gb, GT740M 2gb, 2x1000gb).
And in the article on the hub and in other places on the Internet, the only mentioned way to get the dump of the decrypted (if it is not encrypted on the manufacturer’s website there is no problem) BIOS for subsequent unpacking and parsing the menu is a modification of the platform.ini file in the firmware folder.
Unfortunately on my laptop (and I’m pretty sure that on all other new HP models) this method doesn’t work anymore - I suspect that the BIOS was closed for reading even for my own firmware to avoid future problems. All attempts to change the .ini file and launch the firmware lead to the same result (that on the original x64 Win 8, that from the PE x32 / x64 distributions, i.e. the problem is not in the system) - the error "IHSI: flash read error in SMI! "(For Google). By the way, don’t be scared when you see such a restart of the laptop, you can only turn off the power and remove the battery:
But, what’s important, the BIOS firmware itself happens (usually) not directly, but using UEFI - i.e. the firmware transfers the BIOS UEFI image to the utility (as it turned out to be decrypted), and we just have to find where it is stored. Perhaps you have already paid attention to several small additional hidden partitions on the main HDD / SSD (and this is in addition to the rather large (24 GB, with win8 source) visible Recovery partition), in my case they are of the Recovery Partition (400mb) type and the EFI System Partition ( 260mb, then we need it). That's just the trouble - you won’t assign letters to these sections of the standard Disk Management - they’re also systemic, but Google and the command line save us as usual (execute
necessarily from under the administrator account, and it is better to immediately from the file manager, for example, an unforgettable FAR ):
After that, open drive X :, and look for something similar to the BIOS. In my case, everything turned out to be quite prosaic, and in the X: \ EFI \ HP \ BIOS folder there were three sub-folders Current, New and Previous with the desired contents (01966.bin magic formed by the firmware from 01966.fd). Next - everything is as in the article, unpack, parsim, etc.
In conclusion, I note that, unlike reading, the firmware has not lost the ability to write the BIOS directly even from under Win8 x64. I really found out about this in a sad way, trying to flash a file from the original kit, but under a different platform. We must pay tribute to HP - the restoration of the correct bios occurred within a minute (it was enough for me to turn gray + 1%) in fully automatic mode, though one consequence remained - Win8 stopped loading in Secure Boot mode.
Having learned the treasured addresses of the variables that you need to change by copying the grub-shell to the USB flash drive and successfully launching it (everything is described in the article ), you may encounter one more problem - each execution of setup_var (no matter reading or writing) will cause the laptop to freeze (in my case was treated only by removing the battery). The reason was found only by analyzing the source of the patch to add the setup_var command to grub - the banal buffer oveflow. The author wrote a utilityfor myself (my laptop), and did not expect that the Setup variable could have a size greater than 0x2bc (and it is read entirely into memory, and in my case it was 0x4ae bytes for example). We can say that everyone who successfully used the utility for 4 years was quite lucky - with this bug you could get a lot more problems (for example, writing garbage to CMOS) than just freezing the laptop.
For those who need to "go" (that is, they will cope with the problem): download the rebuilt BootX64.EFI , put it as usual in EFI \ boot \ , use the setup_var command as in the original version. For persistent bonus track: an additional setup_var2 command (changes the value not only in the Setup variable, but also in the Custom variable, why a little lower) andlsefivar (displays a list of all available variables, you can pause output with a break).
The presence of these two additional commands is simply explained: while fighting with the rebellious BIOS, I discovered the presence of an additional Custom variable with the same GUID and size as the Setup variable. Because at that moment I couldn’t manage to change the value of one option (more in the third part) - there was a hope to achieve something by changing it in the Custom variable. These efforts were not crowned with success, and let the teams be, as a keepsake.
Do not be alarmed at the size of the .EFI image (2.5mb) - I was lazy to choose the necessary grub modules, so they are all there - hence the size.
For the incredulous and just curious, instructions on how to repeat my path, well, or collect your grub:
I ’ll also mention the UEFI shell from the Tianocore project (download EFI 1.0 Shell Full or EDKII UEFI Shell 2.0 , but the first version worked more stable for me) - it’s a very convenient thing, it has access to both EFI and the file system (we find the necessary disk using ls by checking queue fs0 :, fs1 :, etc.), can execute other EFI applications, and also save the values of EFI variables (most important for us) using the dmpstore command . You can read about her commands for breakfast here or here , an example of use for our purposes (it saves the entire value of the Setup variable in fs1: \ setup_dumps \ dump1.bin):
Just keep in mind that a variable-length header is added to the variable dump, for Setup, the offset relative to the indices from the menu and the setup_var command is 0x28).
I would like to add that the BIOS on my laptop allows you to download not only the BootX64.EFI file from the EFI \ boot folder, but also any .EFI file from any folder in almost any medium ( Boot from EFI file option , thanks HP). In principle, the same functionality can be obtained using the UEFI shell and loading the rest of the EFI applications from it, but nonetheless.
In the process of your attempts to change hidden BIOS settings, you may encounter the fact that the settings you need will not change, returning to its original state after a reboot (BIOS reinitialization). Unfortunately, vendors can add their own code to the BIOS, which will check the availability of equipment, serial number, or some other parameters and, depending on this, automatically restore the settings to their original values. Moreover, this will not be done in spite of us (the menus hidden from the BIOS are enough to protect against a fool), but simply to use the same platform and the same BIOS for different laptop configurations. And if you are trying to change these settings just to find out, only your laptop can work with the new hardware (say the mSATA module) - then maybe it's worth the risk, buy and install it. Perhaps you are lucky and the magical settings themselves will appear or change, as if by command.
In order not to be unfounded I will give my story: in my case, the unfortunate option was 0x39 - HDC Configure As IDE / AHCI / RAID, which could not be changed to 0x2 (RAID) by any effort. I needed this for only one reason - to add the mSATA SSD module to the laptop to connect it as a cache in the form of Intel SRT . At the same time, the presence of the mSATA connector is not described at all in the specifications or in the service manual, only one very blurry picture from the manual contains something similar, but in order to get to it you need to disassemble the chassis by half (and not just remove the back cover). Now you probably understand my doubts - you need to buy a penny SSD (by the way, the Toshiba 128GB was chosen - THNSNH128GMCT, which pleases with tests, and later broken as 1/2 iSRT, 1/4 over provisioning, 1/6 volume), disassemble the laptop half (bought by the company a week ago, that is, almost certainly losing the warranty), and even if you are lucky with the connector, then not the fact that someday it will be possible to enable the RAID option in the BIOS. The only hope was that in the US HP allows you to choose the configuration of such laptops (all of them use the same BIOS), including adding 24gb or 32gb SSD Cache, though at the same time limiting the maximum memory capacity to 8gb (why?) . The result of doubts below (the connector in the green frame): The manufacturer (HP) did not fail, the first turn on and the magic option is immediately detected in the place where it was not there a few minutes ago (i.e. a few days of leisurely fuss with setup_var on smarka) :
In the end, I want to note the good news - unlike all the descriptions on the Internet, Windows 8 did not notice the change in AHCI mode to RAID at all, only in Device manager the controller changed its name from SATA AHCI Controller to SATA RAID Controller. The merit is GPT, Windows 8 itself, or Intel - I don’t know, and I don’t really ask this question - I just enjoy the system speed that has changed (without any hemorrhoids).
Disclaimer. You use all the information from the article at your own risk. Please check that you have the means to restore the BIOS and its settings before you conduct any experiments.
- Inability to get decrypted BIOS dump
- Incorrect grub shell operation (freezing after setup_var execution)
- Inability to change some settings
It is worth noting that I personally encountered all these problems (and spent a lot of effort on them) in trying to activate the RAID mode for the SATA controller instead of AHCI (for the subsequent inclusion of Intel SRT ) on the fairly fresh DTR laptop HP Envy 17-j005tx (i7-4700MQ, 16gb, GT740M 2gb, 2x1000gb).
Problem 1: Inability to get decrypted BIOS dump
And in the article on the hub and in other places on the Internet, the only mentioned way to get the dump of the decrypted (if it is not encrypted on the manufacturer’s website there is no problem) BIOS for subsequent unpacking and parsing the menu is a modification of the platform.ini file in the firmware folder.
Unfortunately on my laptop (and I’m pretty sure that on all other new HP models) this method doesn’t work anymore - I suspect that the BIOS was closed for reading even for my own firmware to avoid future problems. All attempts to change the .ini file and launch the firmware lead to the same result (that on the original x64 Win 8, that from the PE x32 / x64 distributions, i.e. the problem is not in the system) - the error "IHSI: flash read error in SMI! "
necessarily from under the administrator account, and it is better to immediately from the file manager, for example, an unforgettable FAR ):
mountvol X: /S
After that, open drive X :, and look for something similar to the BIOS. In my case, everything turned out to be quite prosaic, and in the X: \ EFI \ HP \ BIOS folder there were three sub-folders Current, New and Previous with the desired contents (01966.bin magic formed by the firmware from 01966.fd). Next - everything is as in the article, unpack, parsim, etc.
In conclusion, I note that, unlike reading, the firmware has not lost the ability to write the BIOS directly even from under Win8 x64. I really found out about this in a sad way, trying to flash a file from the original kit, but under a different platform. We must pay tribute to HP - the restoration of the correct bios occurred within a minute (it was enough for me to turn gray + 1%) in fully automatic mode, though one consequence remained - Win8 stopped loading in Secure Boot mode.
Problem 2: Incorrect grub shell operation (freezing after setup_var execution)
Having learned the treasured addresses of the variables that you need to change by copying the grub-shell to the USB flash drive and successfully launching it (everything is described in the article ), you may encounter one more problem - each execution of setup_var (no matter reading or writing) will cause the laptop to freeze (in my case was treated only by removing the battery). The reason was found only by analyzing the source of the patch to add the setup_var command to grub - the banal buffer oveflow. The author wrote a utilityfor myself (my laptop), and did not expect that the Setup variable could have a size greater than 0x2bc (and it is read entirely into memory, and in my case it was 0x4ae bytes for example). We can say that everyone who successfully used the utility for 4 years was quite lucky - with this bug you could get a lot more problems (for example, writing garbage to CMOS) than just freezing the laptop.
For those who need to "go" (that is, they will cope with the problem): download the rebuilt BootX64.EFI , put it as usual in EFI \ boot \ , use the setup_var command as in the original version. For persistent bonus track: an additional setup_var2 command (changes the value not only in the Setup variable, but also in the Custom variable, why a little lower) andlsefivar (displays a list of all available variables, you can pause output with a break).
The presence of these two additional commands is simply explained: while fighting with the rebellious BIOS, I discovered the presence of an additional Custom variable with the same GUID and size as the Setup variable. Because at that moment I couldn’t manage to change the value of one option (more in the third part) - there was a hope to achieve something by changing it in the Custom variable. These efforts were not crowned with success, and let the teams be, as a keepsake.
Do not be alarmed at the size of the .EFI image (2.5mb) - I was lazy to choose the necessary grub modules, so they are all there - hence the size.
For the incredulous and just curious, instructions on how to repeat my path, well, or collect your grub:
- Download the source of fresh grub2 ( trunk at that time was not going to, I used grub-2.00 + 20130519 ).
- We apply my patch or fix and adapt the author’s one (funny, but I personally killed about an hour with a problem with grub: incompatible license, and even Google didn’t help - it is solved by adding GRUB_MOD_LICENSE ("GPLv3 +"; to the source).
- Build the EFI grub image. Described in detail here . The only note on grub-mkimage is the correct line (if you include all modules):
../grub-mkimage -d . -o bootx64.efi -O x86_64-efi -p /efi/boot `find *.mod | xargs | sed -e 's/\.mod//g'`
I ’ll also mention the UEFI shell from the Tianocore project (download EFI 1.0 Shell Full or EDKII UEFI Shell 2.0 , but the first version worked more stable for me) - it’s a very convenient thing, it has access to both EFI and the file system (we find the necessary disk using ls by checking queue fs0 :, fs1 :, etc.), can execute other EFI applications, and also save the values of EFI variables (most important for us) using the dmpstore command . You can read about her commands for breakfast here or here , an example of use for our purposes (it saves the entire value of the Setup variable in fs1: \ setup_dumps \ dump1.bin):
fs1:
cd setup_dumps
dmpstore Setup -s dump1.bin
Just keep in mind that a variable-length header is added to the variable dump, for Setup, the offset relative to the indices from the menu and the setup_var command is 0x28).
I would like to add that the BIOS on my laptop allows you to download not only the BootX64.EFI file from the EFI \ boot folder, but also any .EFI file from any folder in almost any medium ( Boot from EFI file option , thanks HP). In principle, the same functionality can be obtained using the UEFI shell and loading the rest of the EFI applications from it, but nonetheless.
Problem 3: Inability to change some settings
In the process of your attempts to change hidden BIOS settings, you may encounter the fact that the settings you need will not change, returning to its original state after a reboot (BIOS reinitialization). Unfortunately, vendors can add their own code to the BIOS, which will check the availability of equipment, serial number, or some other parameters and, depending on this, automatically restore the settings to their original values. Moreover, this will not be done in spite of us (the menus hidden from the BIOS are enough to protect against a fool), but simply to use the same platform and the same BIOS for different laptop configurations. And if you are trying to change these settings just to find out, only your laptop can work with the new hardware (say the mSATA module) - then maybe it's worth the risk, buy and install it. Perhaps you are lucky and the magical settings themselves will appear or change, as if by command.
In order not to be unfounded I will give my story: in my case, the unfortunate option was 0x39 - HDC Configure As IDE / AHCI / RAID, which could not be changed to 0x2 (RAID) by any effort. I needed this for only one reason - to add the mSATA SSD module to the laptop to connect it as a cache in the form of Intel SRT . At the same time, the presence of the mSATA connector is not described at all in the specifications or in the service manual, only one very blurry picture from the manual contains something similar, but in order to get to it you need to disassemble the chassis by half (and not just remove the back cover). Now you probably understand my doubts - you need to buy a penny SSD (by the way, the Toshiba 128GB was chosen - THNSNH128GMCT, which pleases with tests, and later broken as 1/2 iSRT, 1/4 over provisioning, 1/6 volume), disassemble the laptop half (bought by the company a week ago, that is, almost certainly losing the warranty), and even if you are lucky with the connector, then not the fact that someday it will be possible to enable the RAID option in the BIOS. The only hope was that in the US HP allows you to choose the configuration of such laptops (all of them use the same BIOS), including adding 24gb or 32gb SSD Cache, though at the same time limiting the maximum memory capacity to 8gb (why?) . The result of doubts below (the connector in the green frame): The manufacturer (HP) did not fail, the first turn on and the magic option is immediately detected in the place where it was not there a few minutes ago (i.e. a few days of leisurely fuss with setup_var on smarka) :
In the end, I want to note the good news - unlike all the descriptions on the Internet, Windows 8 did not notice the change in AHCI mode to RAID at all, only in Device manager the controller changed its name from SATA AHCI Controller to SATA RAID Controller. The merit is GPT, Windows 8 itself, or Intel - I don’t know, and I don’t really ask this question - I just enjoy the system speed that has changed (without any hemorrhoids).
Disclaimer. You use all the information from the article at your own risk. Please check that you have the means to restore the BIOS and its settings before you conduct any experiments.
