P-Code简介

　　术语P-Code既不是一个新名词也不是Microsoft的发明，P-Code只是简单地被解释执行的伪指令。因此，我们并不需要通过什么复杂的专业词汇来描述它。P-Code可以被认为是一种普通的机器级代码(我们的微处理器不能解释它)。在运行P-Code之前，需要一个解释器处理它，转换P-Code为CPU可以理解的机器语言。这个过程看起来有点象JAVA, 为了执行JAVA语言写成的应用程序，我们需要一个进行解释和翻译的处理程序- 虚拟机“Virtual Machine”。这个负有想象力的术语实际意味着它是一个翻译的机制，将JAVA编写的程序转换成我们的CPU可以理解的操作码(指令)。

　　P-Code的优势是明显的。假如我们定义了一组特殊的专属性指令集，并且不公布它的详细定义规范说明，那么一般人很难理解我们生成的程序代码;另一个优势是减小了执行文件的尺寸：通过定义独特的单字节操作码，我们能够使得某些伪指令执行一系列的操作(相当于大量的机器码完成的工作)。Microsoft的 Visual Basic 包含的P-Code的确是如此：一个VB虚拟机翻译P-Code到我们本地的机器码。 虚拟机(以dll形式出现)，在P-Code程序执行前被调用，用来解释相关VB的伪指令。有如你猜测的那样，那些DLL的名称是 :

　　MSVBVM50.DLL　MSVBVM60.DLL

　　文件名称清晰的表明是Microsoft Visual Basic 虚拟机(Virtual Machine), 后跟不同的版本信息。两个版本的差异不大：版本6引入了一些新的指令，并采用了更直观的命名来标注某些版本5中的指令。换句话说，版本6只是改变了版本5中部分指令名称，而非其内在的功能。

　　虚拟机不仅解释Visual Basic 的P-Code文件，同时它也被用于执行编译过的机器码。这是因为VB 虚拟机(DLL文件)同时也包含所有VB程序要调用的API。 一个例子是rtcMsgBox, 这是个等价于标准Windows API MessageBox 的VB函数。P-Code代码被VB虚拟机解释执行，VB中所有的函数都是以这种间接的方式被提供的。

　　由于这个原因，当我们跟踪一个Windows API MessageBox被 P-Code程序时，产生了一个严重的问题：我们必须要跟踪P-Code伪指令。

　　SoftICE 无法跟踪P-Code伪指令, 它只能跟踪VB虚拟机的执行过程。更明确地说， SoftICE 只能理解CPU处理器的机器码，它不能理解任何伪指令。我们将尝试去跟踪P-Code(P-Code伪指令将被转换成可被我们的CPU理解和执行的机器码)。

　　起始表(Beginning of the Tale)

　　几乎所有的事情都是如此：好奇心引发了人们迎接一项新的挑战，我们的故事由此开始。

　　我记得曾在EFNet网站(论坛)与Green先生讨论有关VB P-Code的问题。他那时的工作正好涉及有关VB5编译的应用程序。他告诉我处理P-Code是非常的困难，所以我们有了制作一个VB P-Code的Debugger程序的想法。 实际上Black先生也认为这是个有意义的思路。考虑到这个项目，我说如果我们没有任何可用的有关资源，这可不容易实现。而后，我们查找了许多有关信息，但没有任何有意义的发现，空手而归。好奇心使得我更加努力去细心地发掘有用的信息资料。的确是不易呀…我曾和Snow先生探讨有关问题，他提供给我一个被Lazarus修改过的 MSVBVM50, 在其中，他描述了VB程序表现的所有可能的串比较。这促使我下决心制作一个VB Debugger。

　　我认为当MSVBVM50运行时注入代码是可能的。被注入的代码能够调用我的Debugger, 它在一个DLL中实现。 我决定告诉已加入这个项目的Snow先生, 由他负责制作代码注入器 (好像一个调用装入器Loader) ，我负责Debugger (DLL)编码，就是那个被装入的Debugger(DLL) 。 就在我们两个完成了一些工作后，我们进行了测试，令人振奋的是它真的可以工作!这个 Debugger项目已经迈出了它的第一步。

　　我们可以控制VB虚拟机(截获有关操作)，并且在虚拟机与VB应用程序之间安置我们的Debugger。最大的问题已经得到解决，虽然在初始阶段，我们采用的解决方案(技术上如你所见)并不是最终我们采用的方法。在我们的大目标和指导思想始终如一的情况下，我们不断对它进行改进，一直到我们完全避免了对虚拟机本身的修改。

　　* 第一步

　　跟踪分析，控制虚拟机

　　为使我们的Debugger能够工作，有一个关键性必须解决的问题：发现P-Code代码的翻译转换是什么时候以及如何发生的。一旦我们认识到这一点，我们注入的代码将接管对被调试的VB应用程序的控制，并且发送有关数据到我们的Debugger。Debugger 依次处理操作码并返回到VB 虚拟机。 我本人以前在有关调试器Debugger编码方面的经验几乎为零。不过不久前我差不多完成了一个x86的反汇编器 , 因此我将那些知识用于我的VB Debugger 开发工作。我的构思是这样的:

　　对于反汇编/解释这部分代码包含以下基本原理:

　　- 一个指针(pointer)指向一个缓存区(buffer)，它包含将被转换的数据。

　　- 一个控制程序，它从缓存区中读取操作指令(opcodes)并且重定向程序流，使其依据我们的意图，指向我们想要它执行的程序位置。

　　这个任务通常表现为两种形式: 1、一系列控制描述语句(对于每一个操作码);2、使用一个地址跳转表。 我放弃了第一种选择。因为P-Code中各不相同的操作码实在太多，这将需要一个巨大的条件控制结构(处理这样的工作将变成世界上最慢的事情)。 我猜VB虚拟机对P-Code的翻译转换过程采用的是地址跳转表方法去解释那些可能的操作代码。 这种做法同样出现在我设计的反汇编器中。 现在，我必须完成以下的工作:

　　- 定位缓存区中待解释的操作码，定位跳转地址表

　　我设计并且编译了一个小VB应用程序:

　　Private Sub Form_Load()

　　MsgBox "Hello this is P-Code!!!", VBInformation, "Example"

　　End Sub

　　我通过SoftICE的符号载入器(symbol loader)调入MSVBVM60.DLL (VB6虚拟机) ，设置BPX on _rtcMsgBox。 当SoftICE 中断时，我按 F12返回调用 _rtcMsgBox 的代码:

　　call eax　 // 调用 rtcMsgBox

　　cmp edi,esp　 // 我们在此

　　jnz 66105595　 // 检查堆栈指针

　　xor eax,eax 　// 准备寄存器 eax 去调用缓存区中的下一个操作码

　　mov al,[ESI] 　// 在al中装入待执行的操作码, 上面的演示中，它是36h

　　inc ESI　 // 增加指针偏移量(在 ESI 寄存器中)

　　jmp [eax*4+660FDA58] 　// 跳转到解释伪指令操作码 36h 的处理程序

　　我们看到，就如推测的一般，解释器从缓存区中读入操作码(P-Code伪指令)并且放入8位寄存器AL， 将此操作码作为一个地址偏移量，跳转到相应的处理子程序。我上面提供的小例子中的 36h 既是作为了一个地址偏移量 (这是一个聪明，灵活的办法去处理不同的指令避免了成千的分支判断检查。利用如此聪明的设计方法还真不太象Microsoft一贯的作风)。 如果我们继续跟踪下去，我们会看到利用寄存器ESI作为伪指令操作码缓存区指针来解释VB应用程序的步骤被不断地重复执行着。 其实，在VB 的虚拟机运行时, ESI寄存器始终指向包含被执行的VB应用程序的全部P-Code操作码的一个缓存区。 因此，在SoftICE中，我们总可以利用“ d *ESI”发现将要被执行的操作码。

[1] [2] [3] 下一页