Once you have your platform.ini file, bundle this together with the other files and we can create a Configuration Manager package from this. If you take a look through the rest of the file you will find you can also control several other parameters such as restart behaviour and AC power checks etc. You will find an explanation of the values in the comments below the parameters. This can be done by looking for the section of the file and amending the parameters to the desired settings. So, all we need to do is keep this bunch of files together and configure the parameters to make the UI silent.
If you do some searching around automating this then it’s quite bare but I did come across this PDF from 2014 (pre Windows 10!) which can be used for some guidance and understanding of the parameters within the platform.ini file. This configuration includes parameters for a silent install. In here we have the ROM file which is the actual firmware update, an exe and 2 dll files which carry out the actual firmware flash, then finally a file named platform.ini which contains a variety of parameters which can be pre-configured to your desire.
Whilst this is obviously fine for piecemeal upgrades, it’s no use for an automated upgrade through something like a Configuration Manager task sequence.įear not, after a little tinkering I saw that the original executable extracted a number of files and when checking the %temp% folder you will see that there are a number of files extracted. From there, the user can hit upgrade, interact with any prompts such as AC power missing etc and then the upgrade kicks in, restarts and completes after a few minutes. This tool simply instigates a comparison between the existing firmware and the version included within the supplied executable.
I understand this is used with a variety of other manufacturers too including Lenovo for some devices. Regardless, the customer was given a single executable which when launched ran an interactive utility called the Insyde Flash Firmware utility. These particular devices are well integrated with the firmware in that some of the software that runs on them can be part configured through the BIOS/UEFI setup utility. In the absence of online updates being available my customer had contacted Getac and obtained a firmware update. The devices I was working with were Getac RX10’s and they look something like this. That’s all good and fine when you’re using the major vendors such as Dell, Hp and Lenovo but sometimes things can get a little more ‘exotic’ when using low volume or specialised devices.
The project I was working on was a Windows 10 upgrade and as part of that upgrade, as any good desktop admin knows, we should be updating the BIOS/UEFI firmware as part of any operating system upgrade. Here<- is the modded one with hex editor.I did some work recently with an organisation who use specialised ‘tough’ tablets from a company named Getac. I looked but didn't recognize any modules that look to hold a password, but as I mentioned I'm not familiar with removing these passwords.Ĭan anuone help me remove password from original BIOS? So, password still remains there, somewhere between 600000, or something there is invoked to read the password from another location. RTC Alarm = 98 00 06 09 00 00 00 00 00 00 00 00 FF 07 00 00ĬapsuleLongModuffer = AA (you only FF'd one byte of this modules GUID Header name entry, rest of GUID and module remains) GUID names is mainly what you FF'd and it's contents after = sign below (which is not much)
What you FF'd out, is the following, none of which is the actual password entry.
This is why your driver installs fail, product name, family, SKU etc is all stored in NVRAM (windows keys, serial, UUID is too) You may or may not have removed the password, it's simply not loaded due to it's all broken now. Since you broke the entire section, no NVRAM can be loaded. Quote: Luckily for you this BIOS is booting, you broke the VSS Store/NVRAM, so before I even look into BIOS or what you edited, we know password is stored in VSS/NVRAM or something there pulls password from another location but it can't load now due to this region is broken
Tryed (comparing another bios from Surface Pro 4) with Hex editor to FF some adresses, I managed to boot the bios without password, but brobably broke VSS/NVRAM region.Īn user from another forum had a look to the bios and said this: With RPi and a cable I managed to recover the Bios. I buyed a dead Surface Pro 5, restored it and found that the bios had a password.