New arguments in the battle with the settings Insyde UEFI BIOS
Not so long ago on Habré was published a detailed article on changing the hidden settings Insyde BIOS . Without pretending to the laurels of its author and all the other people who worked on the topic ( modifying the grub UEFI shell and the pioneers of parsing the menu ), I want to describe several problems (and ways to solve them) that may arise for those who want to put this information into practice:
It is worth noting with all these problems I personally ran into (and spent a lot of effort on them) trying to activate the RAID mode instead of AHCI for the SATA controller (to later turn on the Intel SRT ) on the pretty fresh DTR HP Envy 17-j005tx laptop (i7-4700MQ, 16gb, GT740M 2gb, 2x1000gb).
And in an article on Habré and in other places on the Internet, the only mentioned way to get a decrypted dump (if there is no encryption on the manufacturer’s website, then there is no problem) the BIOS for subsequent unpacking and parsing the menu is modifying the file platform.ini in the flash folder.
Unfortunately on my laptop (and almost certain that on all other new HP models) this method does not work anymore - I suspect that the BIOS has been closed for reading even for its own firmware in order to avoid problems in the future. All attempts to change the .ini file and launch the firmware lead to the same result (which is on the original x64 Win 8, which is from under 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, do not be alarmed to see such a reboot of the laptop, you can only turn off the power and take out the battery:
')
But what is important, the BIOS firmware itself happens (usually) not directly, but using UEFI — that is, The firmware transfers the BIOS image to the UEFI utility (as it turned out already 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 Recovery Partition (400mb) and EFI System Partition ( 260mb, we need it then). The only trouble is that you will not assign letters to these sections with the standard Disk Management - they are systemic, however, Google and the command line are saved as usual (they must be done from the administrator’s account, and better from the file manager, for example, the unforgettable FAR ):
After that, open the X: drive, and look for something similar to the BIOS. In my case, everything turned out to be rather prosaic and in the X: \ EFI \ HP \ BIOS folder there were three sub-folders Current, New and Previous with the desired content (01966.bin is a magic formed by the firmware from 01966.fd). Next - just like in the article, unpack, parsim, etc.
Finally, I note that, in contrast to reading, firmware has not lost the ability to write BIOS and directly even from under Win8 x64. I found out about it in a really sad way, trying to flash a file from the original kit, but under a different platform. We must pay tribute to HP - the recovery of the correct BIOS occurred within a minute (I had enough to get another + 1% gray) in a fully automatic mode, although one consequence remained - Win8 stopped loading in Secure Boot mode.
Finding out the treasured addresses of variables that you need to change, copying the grub-shell to a USB flash drive and successfully launching it (everything is described in the article ), you may encounter another problem - each execution of setup_var (no matter reading or writing) will cause the laptop to hang ( My case was treated only by removing the battery). The reason was found only by analyzing the patch source to add the setup_var command to grub — the banal buffer oveflow. The author wrote the utility for himself (his laptop), and did not expect that the Setup variable may have a size larger than 0x2bc (and it is read entirely into memory, and in my case was, for example, 0x4ae bytes). We can say that everyone who successfully used the utility for 4 years was pretty lucky - with such a bug, you could get a lot more problems (for example, writing trash to CMOS) than just hanging the laptop.
For those who "go" (ie, cope with the problem): download the reassembled BootX64.EFI , put it as usual in the EFI \ boot \ , use the setup_var command as in the original version. For stubborn bonus track: additional setup_var2 command (changes the value not only in the Setup variable, but also in the Custom variable, why just below) and lsefivar (displays a list of all available variables, you can pause the output with a break).
The presence of these two additional commands is explained simply: while fighting the recalcitrant bios, I discovered the presence of an additional Custom variable with the same GUID and size as the Setup variable. Since at that moment I could not change the value of one option (more details in the third part) - it was the hope of achieving 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 intimidated by 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 incredulous and just curious instructions on how to repeat my path, well, or put together your grub:
I will 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) - a very handy thing, it has access to both EFI and the file system (we find the necessary disk by checking ls by queue fs0 :, fs1 :, etc.), can run other EFI applications, as well as save the values ​​of EFI variables (the most important for us) using the dmpstore command . You can read about her commands here or here , for example, for use in our purposes (retains the entire value of the Setup variable in fs1: \ setup_dumps \ dump1.bin):
Only take into account 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 of almost any media (option Boot from EFI file , thanks to HP). In principle, the same functionality can be obtained using the UEFI shell and loading the remaining EFI applications from it, but nonetheless.
In the process of your attempts to change the hidden BIOS settings, you may be faced with the fact that the most necessary settings for you will not change, returning to its original state after a reboot (reinitialization of the BIOS). Unfortunately, vendors can add their own code to the BIOS, which will check the availability of equipment, the serial number, or some other parameters and, depending on this, automatically restore the settings to their original values. And this will be done not to spite us (there are enough menus hidden from the BIOS to protect against a fool), but simply to use the same platform and the same BIOS for different configurations of laptops. And if you are trying to change these settings only to find out, only your laptop will be able to work with the new hardware (say, the mSATA module) - then it may be worth the risk to buy and install it. Perhaps you are lucky and the magic settings themselves will appear or change, as if by magic.
In order not to be unsubstantiated, I will give my story: in my case, such an ill-fated option was 0x39 - HDC Configure As IDE / AHCI / RAID, which could not be changed by any efforts to the value 0x2 (RAID). I only needed this for one reason - in order to add a module to the mSATA SSD laptop as a cache in the form of an Intel SRT . At the same time, the presence of the mSATA connector is not described in the specifications or in the service manual at all, only one very blurred picture of the manul has something similar, but to get to it you need to half disassemble the chassis (and not just remove the back cover). Now you probably understand my doubts - you need to buy not a penny SSD (by the way Toshiba 128GB was chosen - THNSNH128GMCT, pleasing with tests , and subsequently broken as 1/2 iSRT, 1/4 over provisioning, 1/6 volume), disassemble the laptop by half bought by the company a week ago, that is, almost certainly losing the warranty), and even if you are lucky with the connector, it’s not a fact that you can ever turn on the RAID option in the BIOS. Hope was given only by the fact that in the US, HP allows you to choose the configuration of such laptops (they all use the same BIOS), including adding 24gb or 32gb SSD Cache, but at the same time limiting the maximum memory capacity to 8gb (why?) . The result of doubt below (the connector in the green frame):
The manufacturer (HP) did not fail, the first switch-on and the magic option immediately show up at the place where it was not a few minutes ago (that is, for a few days leisurely fuss with setup_var on the smark):
Finally, I also want to note the joyful - in contrast to all the descriptions on the Internet, Windows 8 did not even notice the change of AHCI mode to RAID, only in the Device manager the controller changed its name from SATA AHCI Controller to SATA RAID Controller. The credit is GPT, Windows 8 itself, or Intel — I don’t know, and I’m not really asking this question — I just enjoy the speed of the system that has changed (without any hemorrhoids).
Disclaimer. All information from the article you use at your own risk. Please check that you have the means to restore the BIOS and its settings before you perform any experiments.
- Inability to get decoded BIOS dump
- Incorrect grub shell operation (hang after executing setup_var)
- Inability to change some settings
It is worth noting with all these problems I personally ran into (and spent a lot of effort on them) trying to activate the RAID mode instead of AHCI for the SATA controller (to later turn on the Intel SRT ) on the pretty fresh DTR HP Envy 17-j005tx laptop (i7-4700MQ, 16gb, GT740M 2gb, 2x1000gb).
Problem 1: Failure to get decoded BIOS dump
And in an article on Habré and in other places on the Internet, the only mentioned way to get a decrypted dump (if there is no encryption on the manufacturer’s website, then there is no problem) the BIOS for subsequent unpacking and parsing the menu is modifying the file platform.ini in the flash folder.
Unfortunately on my laptop (and almost certain that on all other new HP models) this method does not work anymore - I suspect that the BIOS has been closed for reading even for its own firmware in order to avoid problems in the future. All attempts to change the .ini file and launch the firmware lead to the same result (which is on the original x64 Win 8, which is from under PE x32 / x64 distributions, i.e. the problem is not in the system) - the error "IHSI: flash read error in SMI! "
')
But what is important, the BIOS firmware itself happens (usually) not directly, but using UEFI — that is, The firmware transfers the BIOS image to the UEFI utility (as it turned out already 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 Recovery Partition (400mb) and EFI System Partition ( 260mb, we need it then). The only trouble is that you will not assign letters to these sections with the standard Disk Management - they are systemic, however, Google and the command line are saved as usual (they must be done from the administrator’s account, and better from the file manager, for example, the unforgettable FAR ):
mountvol X: /S After that, open the X: drive, and look for something similar to the BIOS. In my case, everything turned out to be rather prosaic and in the X: \ EFI \ HP \ BIOS folder there were three sub-folders Current, New and Previous with the desired content (01966.bin is a magic formed by the firmware from 01966.fd). Next - just like in the article, unpack, parsim, etc.
Finally, I note that, in contrast to reading, firmware has not lost the ability to write BIOS and directly even from under Win8 x64. I found out about it in a really sad way, trying to flash a file from the original kit, but under a different platform. We must pay tribute to HP - the recovery of the correct BIOS occurred within a minute (I had enough to get another + 1% gray) in a fully automatic mode, although one consequence remained - Win8 stopped loading in Secure Boot mode.
Problem 2: Incorrect grub-shell operation (hang after executing setup_var)
Finding out the treasured addresses of variables that you need to change, copying the grub-shell to a USB flash drive and successfully launching it (everything is described in the article ), you may encounter another problem - each execution of setup_var (no matter reading or writing) will cause the laptop to hang ( My case was treated only by removing the battery). The reason was found only by analyzing the patch source to add the setup_var command to grub — the banal buffer oveflow. The author wrote the utility for himself (his laptop), and did not expect that the Setup variable may have a size larger than 0x2bc (and it is read entirely into memory, and in my case was, for example, 0x4ae bytes). We can say that everyone who successfully used the utility for 4 years was pretty lucky - with such a bug, you could get a lot more problems (for example, writing trash to CMOS) than just hanging the laptop.
For those who "go" (ie, cope with the problem): download the reassembled BootX64.EFI , put it as usual in the EFI \ boot \ , use the setup_var command as in the original version. For stubborn bonus track: additional setup_var2 command (changes the value not only in the Setup variable, but also in the Custom variable, why just below) and lsefivar (displays a list of all available variables, you can pause the output with a break).
The presence of these two additional commands is explained simply: while fighting the recalcitrant bios, I discovered the presence of an additional Custom variable with the same GUID and size as the Setup variable. Since at that moment I could not change the value of one option (more details in the third part) - it was the hope of achieving 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 intimidated by 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 incredulous and just curious instructions on how to repeat my path, well, or put together your grub:
- Downloading the source of the fresh grub2 ( trunk wasn’t collected at that time, I used grub-2.00 + 20130519 ).
- We apply my patch or fix and adapt the author (funny, but personally I killed about an hour with the grub problem: incompatible license, and even Google did not help - it is solved by adding GRUB_MOD_LICENSE ("GPLv3 +"); to the source).
- We collect EFI image grub. Described in detail here . The only remark on grub-mkimage, 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 will 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) - a very handy thing, it has access to both EFI and the file system (we find the necessary disk by checking ls by queue fs0 :, fs1 :, etc.), can run other EFI applications, as well as save the values ​​of EFI variables (the most important for us) using the dmpstore command . You can read about her commands here or here , for example, for use in our purposes (retains the entire value of the Setup variable in fs1: \ setup_dumps \ dump1.bin):
fs1: cd setup_dumps dmpstore Setup -s dump1.bin Only take into account 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 of almost any media (option Boot from EFI file , thanks to HP). In principle, the same functionality can be obtained using the UEFI shell and loading the remaining EFI applications from it, but nonetheless.
Problem 3: Failure to change some settings
In the process of your attempts to change the hidden BIOS settings, you may be faced with the fact that the most necessary settings for you will not change, returning to its original state after a reboot (reinitialization of the BIOS). Unfortunately, vendors can add their own code to the BIOS, which will check the availability of equipment, the serial number, or some other parameters and, depending on this, automatically restore the settings to their original values. And this will be done not to spite us (there are enough menus hidden from the BIOS to protect against a fool), but simply to use the same platform and the same BIOS for different configurations of laptops. And if you are trying to change these settings only to find out, only your laptop will be able to work with the new hardware (say, the mSATA module) - then it may be worth the risk to buy and install it. Perhaps you are lucky and the magic settings themselves will appear or change, as if by magic.
In order not to be unsubstantiated, I will give my story: in my case, such an ill-fated option was 0x39 - HDC Configure As IDE / AHCI / RAID, which could not be changed by any efforts to the value 0x2 (RAID). I only needed this for one reason - in order to add a module to the mSATA SSD laptop as a cache in the form of an Intel SRT . At the same time, the presence of the mSATA connector is not described in the specifications or in the service manual at all, only one very blurred picture of the manul has something similar, but to get to it you need to half disassemble the chassis (and not just remove the back cover). Now you probably understand my doubts - you need to buy not a penny SSD (by the way Toshiba 128GB was chosen - THNSNH128GMCT, pleasing with tests , and subsequently broken as 1/2 iSRT, 1/4 over provisioning, 1/6 volume), disassemble the laptop by half bought by the company a week ago, that is, almost certainly losing the warranty), and even if you are lucky with the connector, it’s not a fact that you can ever turn on the RAID option in the BIOS. Hope was given only by the fact that in the US, HP allows you to choose the configuration of such laptops (they all use the same BIOS), including adding 24gb or 32gb SSD Cache, but at the same time limiting the maximum memory capacity to 8gb (why?) . The result of doubt below (the connector in the green frame):
The manufacturer (HP) did not fail, the first switch-on and the magic option immediately show up at the place where it was not a few minutes ago (that is, for a few days leisurely fuss with setup_var on the smark):
Finally, I also want to note the joyful - in contrast to all the descriptions on the Internet, Windows 8 did not even notice the change of AHCI mode to RAID, only in the Device manager the controller changed its name from SATA AHCI Controller to SATA RAID Controller. The credit is GPT, Windows 8 itself, or Intel — I don’t know, and I’m not really asking this question — I just enjoy the speed of the system that has changed (without any hemorrhoids).
Disclaimer. All information from the article you use at your own risk. Please check that you have the means to restore the BIOS and its settings before you perform any experiments.
Source: https://habr.com/ru/post/190354/
All Articles