离奇死亡事件薄之CoCreate篇

“周节棍的双杰伦，砌里侉叉 …”

一阵吵杂的手机铃声将正在发呆的瓶瓶吵醒，他呆滞的眼神中蓦地闪出亮光，心想：大买卖又来了？

果不其然，又是一桩离奇案件：CoCreate在密镇莫名死亡，临终前嘴里还含糊地说了句“The file xxx failed to load. could not unpack the file xxx. Either this file is invalid, you do not have sufficient memory, or no space is left. (Error 398)” ，然后便咽气了。

密镇是凶杀案频发的地方，因其本身治案环境不好，很多案件都成了无头案。这也是为什么作为私家侦探的瓶瓶会被委托查找真凶的原因。

瓶瓶深思了一会，便开始着手重构死亡现场。这里还要多说一句，随着科技的进步，新时代的侦探们也有了更高效的破案方式方法，虽然原始的从验尸（Postmortem，Crash dump analysis）开始的福氏方式依然盛行，但越来越多的人都开始采用这种重建虚拟现场的方式，毕竟新的方法可以让你一遍一遍地推演，并在推演中不断地发现新的线索，直到真相大白。

重构虚拟现场需要相关的工具和设备才行。每位侦探都有自己偏爱的工具组合，当然也逃不脱其时代的限制与烙印。比如两位同姓宋的侦探前辈：宋慈因处宋朝，手中也只有手术刀之类的工具，纵使锋利，但作用毕竟有限；再看19世纪英国的宋戴克，他的方形绿皮箱里可谓是包罗万象，从放大镜，显微镜，到酒精灯，试剂等一应俱全，俨然福尔摩斯的化学实验室了。

但对于21世纪像瓶瓶一样的侦探们来说，一切又化繁为简，一般一台电脑足矣，有时也需要多台并加上若干互联设备。瓶瓶的书房便是充斥着各色各样的电子设备，相互间连接着的五颜六色的电缆全绞缠在一起。

瓶瓶最得心应手的工具包还是windbg，外加一根1394线，便足以对付大多数棘手的凶案。从业之初，瓶瓶用得可是debug工具包，后来经过softice，最后才用上windbg，前几年还是windbg第五代，当时用得还是串口线，现在已升级至第六代了。

不到一个小时，瓶瓶便已连接好所有设备，并设定妥了虚拟现场环境。随着“滴”的一声响，模拟系统开始启动，windbg上开始显现一串串的字符。此时，瓶瓶圆睁的双眼透过厚厚的近似镜片直盯盯地注视着快速翻滚的屏幕，生怕错过每一个细节。同时又暗自庆幸，CoCreate并没有进行反模拟手术，否则，如果像3ds max那样完全依赖log来分析地话苦头可就大了。

忽然“铛”地一声响，屏幕跳出了CoCreate的临终遗言。此次模拟相当成功，但在细致分析windbg记录之前还没找到任何明显线索，在浏览了所有记录后，也未能找到什么重要的线索。不得不又架设好procmon工具，重新又模拟了一次。procmon工具可以协助记录CoCreate死亡前的所有活动记录，及所有与他接触的相关人员等等。在procmon记录中，发现最后一个与死者接触的人是unzip。

“CoCreate死前找unzip干什么呢？”，瓶瓶陷入深思，忽然间，他想到了死者的遗言中有说 "unpack”，“难道真和unzip有关”，瓶瓶一边思考着一边努力寻找着证据。

瓶瓶打开了死者临死前正翻阅的文件，题为xxx。这是一个加密的文件，密镇定了法律为了保护所有信息，必须对各种重要文件进行加密，否则不能随便交换或传阅。瓶瓶当然知道怎么将此加密文件解密成明文，毕竟如果没有点关系，还真干不成侦探这个行当。

刚打开明文文件，瓶瓶就发现文件头竟赫然是 “504B0304”， ”504B”正是zip压缩法发明者Phil Katz的名字缩写: PK。基本可以肯定xxx文件为zip文件格式，所以CoCreate死前才会去见unzip。若如此地话，那unzip倒底做了些什么呢？

让瓶瓶大感意外的是：等找到unzip时，发现unzip也离奇死亡了。难道是…连环谋杀？看来此案件内情确实不简单，搞不好会惹火上身！想到此，瓶瓶不禁觉得背后发寒。

但事已至此，由不得自己了。瓶瓶先勘察了unzip的死亡现场，但另他失望的是，unzip临死留下的遗言更让人摸不着头脑:  ”End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive…”。这倒底什么意思？进行了一番搜索后，瓶瓶发现如此死亡的案件竟有很多，只是，众多老案件至今还未结案。

多次探索均无功而返，瓶瓶决定先从模拟unzip死亡现场开始。好在unzip也是位名人，有关他的材料可谓是汗牛充栋，特别是有关他的生平传记（unzip60.zip），更是给现场模拟提供了最好的背景材料。

模拟中果然有新的发现，unzip在通过公开渠道获取的加密文件信息竟是错的。此公开渠道是_stat64调用：

int _stat64( const char path, struct __stat64 buffer );

_stat64会返回文件大小、时间戳等信息。关键的地方是：_stat64获取这些信息的方法不是通过GetFileInformationByHandle (IRP_MJ_QUERY_INFORMATION/FileStandardInformation)，而是通过FindFirstFileEx (即IRP_MJ_DIRECTORY_CONTROL/IRP_MN_QUERY_DIRECTORY)得来的。这样操作如果在平时是没有问题的，但在密镇却会出错。

密镇会对所有文件进行过滤并加密，即便是授权的用户在用第二种办法查询文件时，所返回的文件大小与实际大小也是不相符的，因为密镇的所有文件都要附载加密信息而被增厚了。故unzip用错误的文件页码信息来校验文件时，必然会发生了意外。

这个问题当然是出在密镇身上，但令人可气的是，unzip在调用_stat64后又调用了GetFileTime (IRP_MJ_QUERY_INFORMATION/FileBasicInformation)，既然都动用私人关系了，为什么不一次性到位，直接将文件大小也一并取了呢？！

案件侦测至此，案情已基本大白。只是善后工作该怎样去做，真是个让瓶瓶头痛的事情：

最彻底的办法，当然是改良密镇，虽然此方案涉及面太广。瓶瓶经过好一番努力，透过多个渠道才将此事办妥，本以为可以长舒一口气的当口，黑老大M$的代表Office Word发飙了，无论如何都反对。此事竟然黑老大也参与其中？这让瓶瓶不得其解，在没有搞清楚其中奥妙之前，也只能放弃此番所有努力而另辟奇径了，毕竟太岁头上的土动不得。

既然unzip已经死亡，那就不妨再推出个新个unzip吧。让新的unzip用新的私人渠道来获取加密文件的信息不就完了呗。

说到便做到，等将新的unzip装上设备，又进行新的一轮模拟，一切正常了。

连日的探查已让瓶瓶厚厚的镜片蒙上了一层灰尘，正好遮挡住了他更加疲惫的眼神。但无论如何，最后还是以最小的代价将善后工作完成了，瓶瓶终于能够安坐在弹簧椅上，惬意地随着电视哼起了 《游击队歌》。

密镇的电视共有200个频道，只是所有频道上都是相同的节目，而且都是红歌大比拼。红歌声中，瓶瓶淡定地等待着下一件凶杀案的发生。他知道，用不着等太久 ……

（本故事部分纯属虚构，请勿胡乱对号入座）