How to experiment and learn about BIOS malware

While trying to make VMWare Workstation work with new kernel in Fedora 20, on the link where I found solution there is a section about extracting BIOS. This section has a subsection in which it is shown how to use custom BIOS for some virtual machine. Because lately I'm all in malware analysis stuff, it occurred to me that this is actually a great opportunity to experiment with BIOS malware for educational and research purposes. Using real hardware for that purpose would be very problematic because it's not easy to modify BIOS just like that. So, in essence, what we would like to do is:

1. Extract BIOS used by VMWare.
2. Decompile it.
3. Modify.
4. Compile.
5. Install and use.

So, while searching how to do that I stumbled on PHRACK magazine's article that describes just that, how to infect BIOS. It also describes how to instruct VMWare to stop in BIOS and allow gdb to be attached for BIOS debugging! In the end, it turned out that this topic is well studied already. Here are some interesting resources I found:

1. http://www.exfiltrated.com/research.php
2. http://www.endeer.cz/bios.tools/bios.html
3. https://www.blackhat.com/presentations/bh-usa-07/Heasman/Presentation/bh-usa-07-heasman.pdf
4. https://sites.google.com/site/pinczakko/pinczakko-s-guide-to-ami-bios-reverse-engineering-1
5. http://stackoverflow.com/questions/1737095/how-do-i-disassemble-raw-x86-code
6. http://duartes.org/gustavo/blog/post/how-computers-boot-up/
7. http://duartes.org/gustavo/blog/post/motherboard-chipsets-memory-map/
8. PHRACK: Persistent BIOS infection
9. https://www.bios-mods.com/downloads/
10. https://www.kraxel.org/repos/
11. https://www.kraxel.org/blog/
12. https://www.wimsbios.com/forum/depth-high-tech-bios-section-f37/

So, I stopped there with old BIOS stuff. It is clear that everything needed is there. So, I started to think about UEFI.

Lately, UEFI is much more interesting to experiment with because gradually all the manufacturers are switching from old BIOS to a new boot method that has additional protections. It turns out that VMWare Workstation, starting with version 8 supports UEFI boot, too. All that is necessary is to add the following line to vmx configuration file of a virtual machine:

firmware="efi"

So, this is a great research and learning opportunity. Yet, it is very hard to find information on how to manipulate UEFI BIOS. One reason might be that it is relatively new and not many people know what it does and how it works.

While searching for information on how to infect and manipulate UEFI, I found the following URLs to be interesting:

1. http://www.projectosx.com/forum/index.php?showtopic=3018
2. http://wiki.osdev.org/UEFI
3. http://uefi.org/learning_center/presentationsandvideos
4. http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-1/
5. http://tianocore.sourceforge.net/wiki/Welcome
6. http://vzimmer.blogspot.com/2012/12/accessing-uefi-form-operating-system.html

Fedora 20 update to kernel 3.17.2-200 and VMWare Workstation

Since I updated to VMWare Workstation 10.0.5 at the end of January 2015, things were again broken. Returning to this post I found that the link in the post now points to something that has changed and there is no patch nor instructions of what to do. So, I had to google again and now I placed the complete instructions in this post so that the next time I don't have to google again.

It turns out that there is a single line that has to be changed in the vmnet module in order for VMWare to be runnable again. So, here are the steps you have to do in order to patch the file:

1. Create temporary directory, e.g. /tmp/vmware and position yourself in that directory.
2. Create a file named vmnet.patch and put into it the following content:
   
   

   diff -ur vmnet-only.a/netif.c vmnet-only/netif.c
   --- vmnet-only.a/netif.c    2014-10-10 03:23:08.585920012 +0300
   +++ vmnet-only/netif.c  2014-10-10 03:23:09.245920008 +0300
   @@ -149,7 +149,7 @@
       memcpy(deviceName, devName, sizeof deviceName);
       NULL_TERMINATE_STRING(deviceName);
   
   -   dev = alloc_netdev(sizeof *netIf, deviceName, VNetNetIfSetup);
   +   dev = alloc_netdev(sizeof *netIf, deviceName, NET_NAME_UNKNOWN, VNetNetIfSetup);
       if (!dev) {
          retval = -ENOMEM;
          goto out;
   

   
   
3. Unpack /usr/lib/vmware/modules/source/vmnet.tar in the current directory (/tmp/vmware):
   
   

   tar xf /usr/lib/vmware/modules/source/vmnet.tar
   

   
   
4. Patch the module:
   
   

   cd vmnet-only; patch -p1 < ../vmnet.patch; cd ..
   

   
   
5. Make a copy of old, unpatched, archive:
   
   

   mv /usr/lib/vmware/modules/source/vmnet.tar /usr/lib/vmware/modules/source/vmnet.tar.SAVED
   

   
   
6. Create a new archive:
   
   

   tar cf /usr/lib/vmware/modules/source/vmnet.tar vmnet-only
   

   
   
7. Start vmware configuration process:
   
   

   vmware-modconfig --console --install-all
   

Hopefully, that should be it.

Old instructions (not valid any more!)

Well, here we go again. After recent update which brought kernel 3.17 to Fedora 20, VMWare Workstation 10.0.4 had problems with kernel modules. Luckily, after some short googling I found a solution. That solution works. There are two things that might confuse you though:

1. After cd command and before for loop you have to switch to root account (that is indicated by prompt sign change from $ to #).
2. The substring kernel-version in patch command should be replaced with a string "3.17". That is actually the name you gave to a file while executing curl command at the beginning of the process.

Anyway, that's it.