Adding a new driver to an existing UEFI firmware

Following up on efifs and VMWare firmware extraction, you might be interested to find out how, for instance, you should proceed to add an NTFS EFI driver to an existing UEFI firmware, so that you can access/boot NTFS volumes from UEFI.

Reading NTFS volumes natively from UEFI

If that's the case, then look no further than this guide.

It provides a step by step breakdown, using VMWare, of how you can generate an UEFI firmware module from an EFI driver executable (through FFS, which is a convenient repackaging of the EDK2's GenSec and GenFfs), and insert it into an existing UEFI firmware to make the driver natively available:

A VMWare UEFI firmware with a native NTFS driver

How to get a vmdk mapped in Windows Explorer when using VMWare Player 4.x and Windows 7

VMWare... Yet another textbook story of a technological company that has become a bit too complacent with its users, possibly without even realizing it (Disclaimer: I have been a virtualization evangelist, as well as direct contributor to sales of VMWare products in the previous company I worked for, so I do feel somewhat entitled to exert criticism).

So, you have VMWare Player 4.x, installed on a Windows7 platform, and let's say you fancy recompiling FreeDOS in a virtualized environment. For this you have set up your VM, with a small virtual disk and everything, but since it's DOS, no shared folders or VMWare Tools will be available there. Yet you need a solution to exchange data in a convenient manner, between the Windows 7 host and the VM disk image. How are you going to do it then? Why, by mounting the vmdk as a virtual drive of course. And since VMWare is a Virtual hardware company, they made sure that such a staple of virtualization was as easy and as straightforward as possible, right?

Wrong. Below is what you actually need to go through:

1. The VMWare Player does not natively offer any tools to map/mount a virtual drive. You have to install extra software.
2. That software is the Virtual Disk Development Kit (presently in its version 5.5.1) which can be obtained here (after registration of course! It's not like you were about to sort this virtual disk mapping issue in 30 seconds anyway).
3. Once installed (by running bin\vstor2install.bat), and of course without any obvious mention of it (since officially it's an SDK, not an application plugin!), you will find out that the following becomes available when editing your disk properties:
   
   Brilliant: a GUI with the ability to map drives is exactly what we've been looking for.
4. Except, at least in Windows 7 x64, and if you run VMWare Player 4.x under your regular credentials, you will be greeted with the following error message "Error reading volume information. Please select another disk file":
   
   Same occurs if you try the vmware-mount.exe from from the VDK's bin directory (and this even if you open a command prompt as admin, as I have also found)
5. To avoid the "Error reading volume information..." message then, and be able to mount the disk, you must run VMWare Player as admin
6. HOWEVER, "Open drive in Windows Explorer after mapping" still will not work, because Explorer is running under your user credentials, and the drive was mounted under the Administrator's credentials. Thus, you must run your File Explorer as administrative.
7. Luckily, if you happen to run a proper File Manager (such as the most excellent Directory Opus, which I can't recommend enough as it's well worth its license), this isn't a major problem and you will actually get the friggin' vmdk mapped at long last, with the ability to transfer files. If you're stuck with the default Windows Explorer, running it as admin may or may not work —can't test, as on my machine, Directory Opus is the explorer that will be launched by default by VMWare)

Yay, at last VMWare may actually prove useful in getting some work done. Now let's see if the FreeDOS guys also see it this way...

Update (2012.01.06): The FreeDOS people kindly indicated that vmsmount might also be able to help you out if you want to acces VMWare shares from DOS.

Using an older version of VMWare Tools

Lost enough time with this already so I'll be short. First of all, yes, sometimes the latest version of the VMWare Tools can fail and you want to downgrade. I'm looking at you VMWare Tools 8.8.0 from VMWare Player 4.0.0 using a Windows 2000 image! And as you may have already found out, when that occurs, the VMWare Software as well as the VMWare community are less than helpful.

In case you're running the VMWare Player on Windows, to emulate another Windows virtual platform, here's what you should know:

1. After they are downloaded by the Player, the VMWare tools are installed, as a windows.iso file, in your VMWare installation directory (typically C:\Program Files (x86)\VMWare\VMWare Player\). It is that ISO image that is mounted in the virtual machine during installation.
2. You can obtain older versions of the VMWare Tools by navigating the not-intended-for-users VMWare Software Update directory, starting at http://softwareupdate.vmware.com/cds/vmw-desktop/player/.
3. The VMWare Tools download is then found in <version>/<build>/windows/packages/ (eg. http://softwareupdate.vmware.com/cds/vmw-desktop/player/3.1.5/491717/windows/packages/ )
4. Of course the download is not provided as an ISO, because that would be too easy. Instead, it's a tar of an exe that silently extracts and copies (overwrites) a new windows.iso in the VMWare directory. Thus, before you run that exe, you may want to rename your old windows.iso to something else, so that you can both tell whether the downgrade process completed successfully and have the ability to switch back between ISOs if needed.

Extracting and using a modified VMWare Player BIOS or UEFI firmware

(updated 2016.05.17 for VMWare UEFI firmware extraction)

One day or another, you may want to play with BIOS/UEFI firmware modification. But before jumping into physical motherboard flash alteration, where the consequences of a mishap can be difficult to salvage, experimenting with the BIOS/UEFI in a virtual environment sounds like a sound first step. You have of course the opportunity to do so using bochs, however the ubiquitous nature and ease of use of the (freely available) VMware Player can turn the latter in a much better candidate for the job if you don't really care about the extra features that bochs brings in. This post details how one can extract the BIOS/UEFI firmwares used by the VMWare Player, and how to setup the player to use a modified one.

1. Download and install VMware Player. The current version of VMware Player is 12, and the download can be obtained from this page (freely, but after e-mail registration). Binaries are available for Windows and Linux, in both 32 and 64 bit versions.
2. Extract the BIOS from the VMware executables by following the instructions below:
   
   
   • Windows: Download and install 7-zip (which any reasonable Windows user should have installed anyway). Then navigate to your VMware Player installation directory and locate the vmware-vmx.exe application (notice the -vmx here). It should reside in the same directory for 32 bit, or in the x64\ directory for 64 bit. Open it in 7-Zip and go to the .rsrc\BINRES\ directory.
     For the BIOS (internally called bios440, as it emulates an intel 440BX chipset), you need to look for a file exactly 524 288 bytes (512 KB) in size. On current versions, there should be only one, called '6006'. This is the BIOS file we are after, so just extract it to a directory of your choice.
     For the UEFI firmware, you should look for a file that is 2 097 152 bytes (2 MB) in size. Because VMWare can emulate both 32 and 64-bit platforms, you will find that there exists 2 of these. At the time of writing this article, just know that '6020' is the IA32 UEFI firmware and '6021' is the X64 UEFI firmware.
   • Linux: From a terminal, navigate to the directory vmware-vmx binary resides (default is /usr/lib/vmware/bin. Issue the following set of commands (copied from the Arch Linux VMware page):

     $ objcopy /usr/lib/vmware/bin/vmware-vmx -O binary -j bios440 --set-section-flags bios440=a bios440.rom.Z
     $ perl -e 'use Compress::Zlib; my $v; read STDIN, $v, '$(stat -c%s "./bios440.rom.Z")'; $v = uncompress($v); print $v;' < bios440.rom.Z > bios440.rom

     Remember that you can always use objdump -h to find the various sections before using objcopy, in case the BIOS is no longer called bios440.rom
3. Edit the BIOS or UEFI firmware as you see fit. Note that the BIOS VMware uses is of type Phoenix.
   If you are on Windows, you can download a full version of Phoenix Bios Editor Pro v2.1.0.0 from Intel under the name BIOS Logo Change Utility (or simply search for "Phoenix" on the Intel Download Center). If you install this tool on Vista or later, you will have to run Phoenix Bios Editor Pro as Administrator, and possibly in a 32 bit environment, for it to work.
4. Once your BIOS/UEFI file is modified according to your needs, locate the Virtual Machine you plan to test your firmware with and copy your modified file into its directory. Then, edit the .vmx file to add one of these lines, according to the type of platform you want to run.
   • For BIOS, you only need to add:

     bios440.filename = "bios440.rom"

   • For 32-bit UEFI, you will need to have something like:

     firmware = "efi"
     efi32.filename = "efi32.rom"

   • For 64-bit UEFI, you will need:

     firmware = "efi"
     efi32.filename = "efi64.rom"

5. Run the image, and it should use your modified firmware. If you have simply modded the original BIOS using Phoenix Bios Editor, a good way to confirm that the VM is using your custom BIOS is to change the 'Quiet Boot Logo' section, which contains the VMware logos you see during BIOS execution.
   

Also note that, as pointed out on this page, if you are usingVMWare Fusion, you may actually be able to extract the various embedded binaries using the -e switch (the page linked also provides a list of all the binaries you can extract). Sadly however, this switch doesn't apply for VMWare Player on Windows...