3.19 设备翻译层依赖性许多文章有这样一种观点：Windows CE病毒将永远不会出现，而且很多年来我们确实没发现此类病毒。然而，在2004年7月，病毒作者Ratter设计了针对Windows CE的概念型病毒WinCE/Duts.1520，证明了Windows CE病毒是可能的，如图3-13所示。
 |
| 图3-13 在HP iPAQ H2200 Pocket PC上WinCE/Duts病毒的信息 |
目前许多设备都能成功运行WinCE/Duts，这是因为 ARM处理器可以用在许多设备上，例如HP iPAQ H2200 （也像许多其他的iPAQ设备一样），Sprint PCS Toshiba 2032SP、T-Mobile Pocket PC 2003、Toshiba e405和 Viewsonic V36等等。另外几种GSM设备则建立在Pocket PC之上。
有趣的是，WinCE/Duts.1520能够感染多种系统上的PE 文件，尽管实际上病毒代码是为某一种Windows CE版本而 “硬编码”的。例如，该病毒会使用一种基于序数函数的引 入（importing）机制，这种机制看起来在攻击多种版本的 Windows CE上有着很大的局限性。事实上，病毒的编写者似乎认为WinCE/Duts只适合于 Windows CE 4，但我们在测试中发现，该病毒也能正确地运行在Windows CE 3上。
这么久以来，Windows CE未被病毒攻击，这并不奇怪。微软针对各种处理器平台发布了多 种不同的Windows CE版本，这造成了兼容性问题（使用在不同的环境上），而这一点似乎从某 种程度上限制了病毒的编写。
另外，Windows CE平台上的Office产品（例如Pocket Word或Pocket Excel）不支持宏，这一 点也限制了宏病毒的发作，但是也给人带来了一些麻烦。
在Windows CE 3.0之前，由于二进制兼容性问题， 在Windows CE上开发并发布一个应用程 序是一件痛苦的事情。编译生成的可执行二进制文件是PE格式，但只能在编译该程序的处理器 上运行。因此，开发者必须针对不同的设备编译生成不同的二进制版本。这对开发者和用户 （没有耐心总是安装新的程序）来说，都是一个很费时的过程。
对CPU的依赖性被“硬编码（hard-Coded）”在PE文件的头里了，例如在SH3处理器中，PE 文件头包含机器类型号0X01A2，而它的代码段则包含只与这种结构兼容的代码。
或许可以很容易地编写一个能够在SH3平台上编译运行的程序，但是Windows CE可以支持几种处理器，例如SH3、SH4、MIPS、ARM等等。因此，一个本地Windows CE病毒想在不同处理 器的设备间传播就不是那么容易了，例如，WinCE/Duts.1520就无法感染基于SH3处理器的系统。
病毒程序编写者或许能够编制出通过微软的Active Sync来投放Windows CE病毒的Win32病 毒，这样的病毒可以简单地发送电子邮件来传播它的Intel版本（带有一个嵌入的便携式版本）， 但它只能感染某些使用特定处理器的手持设备。将来，随着更多的兼容处理器的发布，对于病 毒开发者来说，这个问题将越来越不成问题。比如，新一代的XScale处理器与ARM系列兼容， XScale不仅用于便携式PC系统中，也用于Palm设备。这就为攻击者编写“跨平台”病毒打开了 方便之门，他们使用相同的病毒程序却能够威胁Palm和便携式PC系统。
微软针对便携式PC开发了出了一种新技术，这使得Windows CE开发人员的工作更加轻松了。 微软在便携式PC中开始支持一种新的可执行文件格式：通用可执行文件（Common executable file，CEF）格式。
可以使用Windows CE开发工具对CEF进行编译，例如嵌入式Visual C++ 3.0。CEF可以说是 一种特殊的PE文件。CEF是一种与CPU无关的代码格式，它允许在Windows CE的支持下创建跨 CPU的可移植的应用程序。实际上，CEF包含了MSIL代码。
在嵌入式Visual C++中，开发者在使用CEF工具（编译器、链接器、SDK）时同样要选定一 个明确的CPU对象（比如MIPS或ARM）。当开发者编译一个CEF程序时，编译器和链接器能完 成除产生机器特有代码以外的所有工作。虽然你仍然能得到一个DLL或EXE文件，但文件中包 含中间语言指令，而不是本地机器代码指令。
CEF让Windows CE程序开发者开发出的产品可以运行在Windows CE或以上版本的操作系统 的所有CPU体系结构上。因为CEF是一种中间语言，所以处理器生产商可以很容易地开发出一种 可以运行CEF程序的新的CPU系列。例如，HP Jornada 540就有这样一种内置的设备翻译层。 CEF文件在发布时可能还会有一个EXE的扩展版本，所以使用者不会感到有什么不同。
设备翻译器对应于某一种特定的处理器和Windows CE设备，当用户在机器上安装CEF可 执行文件时，通常将一个CEF可执行文件转换为处理器本机代码。在可执行文件被点击后，除了 有一个短暂的暂停外，这一切都神不知鬼不觉地发生了。操作系统的钩子能自动捕捉到任何试 图装载与执行CEF EXE、DLL或OCX文件的企图，并在运行文件前运行转换器。
例如，如果一个便携式PC是基于SH3处理器的，那么翻译层就要把一个CEF文件转换成一个 SH3格式的可执行文件。实际的CEF可执行文件将被已编译的SH3本地版本所取代。将文件内容 完全转换为本地可执行版本。确实，对MSIL、JIT(Just-in-Time)在便携式PC上的重新编译导致 了对文件系统的重新写入。
很明显，病毒程序编写者将来可以利用CEF格式。一个32位的Windows病毒能够轻易地将它 的CEF版本安装到便携式设备上，并运行在所有便携式PC设备上，因为操作系统能将CEF可执 行文件转换为它的本地格式。我们只能寄希望于除了Windows CE系统以外其他系统都不支持 CEF格式。例如，万一操作系统将CEF对象改写为本地可执行文件，那么一个桌面应用也会是很 痛苦的。
由于可执行文件在运行中被转换为新格式，其内容发生了变化，与OFFICE产品的宏病毒的 向上转换（up-conversion）相比，这甚至是个更严重的问题[50]。很明显，这将成为反病毒软件、 72 第一部分 攻击者的策略 完整性检查程序和行为阻截系统的挑战。
显然，如果必须检测和识别原始的MSIL格式代码和所有可能的转换代码，这将是反病毒软 件厂商面临的大问题。如果在设备上执行了一个MSIL病毒，那么在反病毒程序发现该病毒前， 病毒就会运行，并根据实际的系统类型，将其代码转换为一系列本地格式。结果，关于病毒的 MSIL信号在寻找病毒时就失去了作用。所有本地转换格式的病毒都必须能够检测出来，这个任 务并不轻松。
其次，这对于完整性检验程序来说也是个大问题，因为不仅是在内存里，磁盘里程序的内 容也已经改变了。结果，完整性检验程序就无法知道这种改变是病毒感染的结果还是一个本地 代码翻译造成的。最后，这对于行为阻截系统来说也是个大问题，因为磁盘上可执行文件的内 容改变了，这容易使人怀疑是病毒造成的。
【责任编辑：
雪花 TEL：（010）68476606-8007】
