Title: Hack Manufacturer Information of Your Computer - An Approach to Remove OEM Limitation When Installing Some Applications
Author: Colin.Xu@gmail.com
Date: 2011/02/17

Recently I was debugging an application related SW issue, which requires specific HW and SW environment. In order to compare with the expected behavior, I tried to install this application on another system comes from a different OEM. But the install program (install shield) denied to continue the installation, it popped up a message box to notify that the OEM didn’t match. I suppose the install program has a mechanism to limit the packed application can only be installed on specific OEM platforms.


In order to install the application without limitation, I have the following options, from user mode view:

1. Disassemble the install program and remove this OEM detection limitation.
This is not easy and done within short time. Not to mention to detect the pack style, I also need to analyze the install program. Potential workload is too heavy.
If it is a *.MSI package, it will be much easier.

2. Unpack the application and run without installation.
The version of install shield is up-to-date, so utility such as Universal Extractor doesn't support to extract the application from the encrypted package.
Also, I’m not sure if the extracted application can work normally. Obviously such kind of application needs many registry entries and registered COM components.

 
I think I should come back to the original problem.
I guess the install program only limit the manufacturer information, but ignore the others, such as sub-system ID. Otherwise, OEM has to build different application installation program for all its platforms, unnecessarily.

In user mode level, application will call EnumSystemFirmwareTables() and GetSystemFirmwareTable() to retrieve information from system firmware, such as BIOS. Then user mode API will pass this call to kernel, kernel will retrieve this information from a global variable, which is initialized at system boot up. Where does OS get the motherboard information? Of course it comes from BIOS.

The data path is: Applicaton-(via API)->OS-(DMI)->BIOS. So what happens if we can cheat the OS with the modified BIOS?


Obviously it is much safer to modify the manufacture information stored in the physical memory then flashing a customized BIOS. OK, Let’s do it.

First, you should know what SMBIOS and DMI stand for. SMBIOS is abbreviation of System Management BIOS, which defines some data structures stored in BIOS to store and retrieve computer information. DMI refers to Desktop Management Interface, which provides an interface for upper level OS to retrieve the hardware information from SMBIOS.

According to x86 design, BIOS is always mapped to a fixed physical memory address, 0xF0000. We search the area ranged from 0xF0000 to 0xFFFFF, to find string begin with "_SM_" and "_DMI_". It should locate within this region, if your system supports SMBIOS. The "_SM_" is the so-called "anchor string". The start address of string "_SM_" is the first four bytes of SMBIOS Entry Point Structure, let’s call it Addr_EPS. Go to offset 0x18h (Addr_EPS+0x18h), these stores the 32 bytes big-endian physical address of the SMBIOS Structure Table, Addr_ST. "_DMI_" will only appear after SMBIOS V2.0. So if you cannot find this string, it means your motherboard doesn't support SMBIOS v2.0.

Then we go to SMBIOS Structure Table, you should have got the address Addr_ST from the previous step. SMBIOS data stores different types of information in table, one after another. According to the specification, the first table is BIOS Information Table (Type 0), followed by System Information Table (Type 1). The system manufacture information we want to modify is stored in System Information Table, so it’s enough for us to check this table only.

In order to find the start address of System Information Table, we should know the length of BIOS Information Table. At offset 0x0 of BIOS Information Table (Addr_ST), the one byte value is "type", it should be 0. The length of BIOS Information Table is located at offset 0x1 (Addr_ST+0x1). We directly go to Addr_ST+length, from this address, there are several strings, ends by 0x00. Until we meet another 0x00 after a string end, we can find several strings defined in BIOS Information Table. After 0x00 0x00, the System Information Table comes out (Addr_SIT).

Offset 0x0 of System Information Table, the value 1 stands for the type of this table, just like BIOS Information Table. Offset 0x1 is the length of this table. Go to Addr_SIT+length, we will find several strings defined in System Information Table. These strings are "Manufacturer", "Product Name", "Version", "Serial Number", "SKU Number" and "Family". Now we've already found the manufacturer string, so just change it from OEM1 to OEM2, our jobs done.

After this hack, I tried to install the application again, and the install shield will no longer detect the platform as OEM1, so the installation finished successfully. Actually, if you check the system information, you can find that the manufacturer is already OEM2.


You may ask how I hack this before OS loading. Well, since I was using windbg to debug the target machine in kernel mode, I can break in the system at a very early point during windows loading. Before windows bootloader (NTLDR or bootmgr) started, BIOS is already mapped into memory and the BIOS POST is finished. After OS taking control of the system, it will read the BIOS information from the mapped address. So if I modify the memory where BIOS mapped before OS reading, OS will get the data which I've already changed. In this way, I cheat the OS. This is also the mechanism how the simulation activation of windows vista/windows 7 works: before OS loading, it will change the OEM ID and SLIC table in ACPI table to mislead OS. Then together with an OEM certification and an OEM S/N, windows vista/windows 7 can be "activated".

If you just want to take a look at the BIOS mapped memory, or you don't have a kernel mode windbg connection, you can use the following methods.

1. In 32bit windows, or pure dos, there is a very powerful tool "debug.exe". It can read/write real mode address. For example, if you want to dump the raw data at 0xf0000, you can do in this way:
Run debug.exe
-d f000:0000
Then data located at physical address 0xf0000 shows up.
Be noticed that debug will access the address in [section]:[offset] mode, so you may need to calculate the address yourself. This is the basis of computer architecture.

2. Another powerful utility running on windows platform: R/W Everything. Besides access the physical memory, it has many other functions such as check the PCI bus configuration.

3. Loading GRUB first, then load your customized image, then OS boot loader. This is a very challenging way, also very flexible and powerful. If you can do it yourself, you've already started to implement your own OS.


All tools and utilities I mentioned in this article can be found over the Internet.
For the latest SMBIOS specification, you may find it here:
http://www.dmtf.org/standards/smbios