Re: Dmiedit V2 11l
Itaete Roberson
From your car to airport kiosks and power grids, nearly all technology is powered by firmware and for that reason, firmware attacks are on the rise. Firmware attacks are much more dangerous than OS-based attacks because firmware is invisible to OS-based security solutions.
As an Arm license partner, one of your main objectives is to bring your designs to the market as quickly and efficiently as possible. However, this process can be fraught with challenges, and one of the biggest hurdles you may encounter is in the development of firmware. Firmware is a critical component of your device, ensuring that it powers on, runs securely, and stays on during its lifecycle. Developing firmware that meets these requirements can be a complex and time-consuming task, but it is essential for the success of your device.
The AMI BIOS Configuration Program (AMIBCP) for Aptio enables customers to modify parameters in a BIOS ROM without rebuilding from source. Developers can modify default values for BIOS setup parameters, modify default boot order in BIOS setup, view and edit sign-on and setup strings, and edit SMBIOS string data.
AMISCE is a command-line tool that provides an easy way to update NVRAM variables, extract variables directly from the BIOS, change settings using either a text editor or a setup program and update the BIOS. AMISCE produces a script file that lists all setup questions on the system being modified by AMISCE. The user can then modify the script file and use it as input to change the current NVRAM setup variables.
AMIUCP is a utility that is used to pre-configure the Aptio Flash Utility (AFU). Users can insert and exchange the default command string and ROM image used in AFU to create a customized version of the utility. AMIUCP supports AFU v2.35 or AFUWINGUI v1.12 or later.
DMIEdit is a scriptable command-line utility for DOS, Microsoft Windows, Linux and the UEFI shell. The Desktop Management Interface Editor for Aptio enables developers to modify strings associated with platform SMBIOS tables (System, Base Board, Chassis, OEM string, etc). In manufacturing, use DMIEdit to embed platform serial numbers, UUID and license keys into the SMBIOS table, which identifies platforms to management software.
Copyright 2023 AMI. All Rights Reserved. Contents of this website are subject to change without notice. Products mentioned herein may be trademarks or registered trademarks of their respective companies. No warranties are made, either expressed or implied, with regard to the contents within, its merchantability or fitness for a particular use.
So i recently installed this program on my PC called "DMI Edit" and i was trying to change the serial numbers on some of the key parts on my pc (I don't even know if that works) and It said that I had to restart my pc for the changes to take effect after I supposedly changed them. I restarted my pc and got no display for either of my monitors it was just a black screen. The pc lights and the GPU lights come on and the fans run I just don't get any display. I have tried taking out the CMOS battery and even moved the graphics card to a different slot on the motherboard. I also tried plugging in the HDMI cord to the motherboard itself and I still got no display. Does anyone know what I could do?
We (3 admins) manage a network that's the result of the merging of about 40 laboratories a few years ago, and before that each lab was managing it's own pool of computers, so we have to work with a very heterogeneous range of computers (HP / Lenovo / customs ...).
It seems that fusionInventory cannot add or update a computer into glpi if it doesn't have a serial number. Most of our machines are branded (HP / Lenovo / Dell) so there's no problem there, but some custom computers give me a "To be filled by OEM" when I try "wmic bios get serialnumber".
Edit: I've tried changing the files with sudoedit, but they're locked for editing (like most of the /sys/ directory, from what I understand). There are a couple ways to accomplish this in Windows, but I haven't found any information online about how to edit these values in Linux.
BIOS writers provide tools to update the DMI information, without needing to modify BIOS images, to companies which manufacture devices using those BIOSs. For example, AMI has a AMIDEDOS tool under DOS, or AMIDEWIN or DMIEdit for Windows (there used to be an AMIDELNX for Linux but that is no longer provided). These tools are usually provided under NDA, but some manufacturers provide them in their BIOS update images. This article provides a good description of the possibilities, and a list of tools (relevant when it was written, in 2012).
As far as I know, and according to this SE link posted in the comments, the DMI information comes from tables hardcoded into system BIOS (or UEFI firmware). To persistently change them would require unpacking a BIOS update, modifying the DMI tables within it using BIOS-vendor-specific tools, and then packaging it back up into a custom BIOS update and flashing it to your system. Any mistakes in the process would have the risk of bricking your computer.
Systems with Secure Boot often require firmware updates being cryptographically signed, so without the vendor's private keys you would not be able to create an custom firmware update package that would install in the normal way anyway.
Windows may have registry entries that may override the DMI information reported by the BIOS, but that's basically just setting up your OS to tell little white lies to your applications, nothing more.
I have the 690 Hero and after upgrading to BIOS 2305 I started getting all sorts of problems with iCue and my RGB fans and control hubs. I spent a couple of days trying to find the problem and in the end I thought that 2305 was causing the problem. So, despite the BIOS being locked, I found a way to go back to 2204 using an unlocked 2305 BIOS on overclock.net. Then I directly flashed 2204 using a tool called FTPW64.exe. That all worked fine, but then I discovered that my iCue problems were related to HWInfo, not the BIOS, so I went back to 2305. Since then, I used the WMIC command in Windows and discovered that my BIOS no longer contains the serial number etc.
Everything is still working perfectly, but it seems that when I flashed the official 2204 directly to my motherboard, the serial number and UUID were not retained within the BIOS. Although 2305 installed fine, obviously the information had already been lost.
So yes, my fault, but is there any way to get that information restored? My motherboard is registered with Asus and I could supply the serial number etc from the box and motherboard sticker. Is there any way that a BIOS could be programmed with the correct information so that I could re-flash it and get everything back correctly?
Going by -uefi-utilities/, it sounds like the DMIEDIT tool can probably setup those values for you. I didn't see any public way to get that tool from AMI, but Intel distribute a version of it which might be worth a look.
Those tools might be beyond my expertise and I'd be nervous of making things worse. Getting the serial number back in might not be too bad (I have that on the motherboard box ) but I don't know how to get the original UUID. I wonder if it's just a randomly generated value, or whether it's calculated from some other unique values (maybe including the serial number).
Just a thought, currently Windows does give me a UUID value, but it's a very simple string of digits which is mostly 0's. So it maybe looks like a 'default' value that Windows has generated. I do have an OS backup from before I ruined the BIOS. If I restored that temporarily and queried the UUID again, I wonder if I could see the original value?
I doubt restoring Windows from an older point will change the reported info, as I suspect Windows is just reading that from the BIOS either on boot or on demand. It's possible that Windows might write the data to a log file somewhere, but I really don't know where that would be. I had a look at my most recent reboot in Event Viewer, and it doesn't seem to log any of that stuff on boot in there. I.e. if the backup contained a logfile or something, maybe, but I don't think the reported value would be restored from backup. Another possible source is if you've saved a report file from one of the tools like AIDA64, CPU-Z, or HWiNFO64.
For general system operation, I suspect the board serial and UUID don't matter much. Where it could creep in is things like authentication, cryptography, DRM, licensing, the LSA, the SAM db, etc. It may well also have done something to your Ethernet MAC addresses. I don't know if the Ethernet MAC chips on the boards have an address programmed into them, or if it's assigned to them from main BIOS storage.
There's some licensing and enablement for the advanced audio features that ASUS supply which could possibly be impacted. I don't know if they use those DTS keys shown in your screenshot above for that, or if they just base it on detecting the board type.
On my Crosshair VIII board, I'm seeing the UUID that HWiNFO64 reports being derived from my two Ethernet MAC addresses. AIDA64 reports two different UUIDs, a "Universal Unique ID" and a "Universal Unique ID (GUID)", both of which contain my two MAC addresses prefixed by a 32 bit number. The HWiNFO64 UUID matches the AIDA64 GUID. They look like this in AIDA64:
xxxxxxxx and yyyyyyyy are 32 bit numbers. I don't know if they are random, a standard prefix, or what. My MAC addresses are 04-42-1A-aa-bb-c0 and 04-42-1A-aa-bb-c1 (04-42-1A is a vendor block allocated to ASUS).
My Intel AX210 WiFi M.2 card uses an Intel MAC address that I'm pretty sure is stored in the WiFi card's BIOS/NVRAM, not the motherboard. It's probably printed on the card's label, but I'd have to disassemble the motherboard to see it.
Curiously, the DMI serial number for my board is a decimal number that does not obviously relate to the product serial number on the barcode label stuck to the board (which is alphanumeric). There's a barcode label between my CPU socket and RAM which has my second Ethernet MAC address on it.
aa06259810