星期天闲着没事玩游戏,玩游戏不能无外挂。于是百度了半天,找到了一个,看介绍貌似不错,就下载了下来。一看,竟然是用.net写的,下意识地Reflector了一下。发现竟是一个叫actmp的程序集。
随便点开看了看,没发现什么和外挂有关的东西。奇怪,于是又百度了一下"actmp.dll",发现了这篇文章http://blog.csdn.net/yizhiduxiu11/archive/2008/12/23/3589396.aspx,其中说"经Sixxpack加壳后,用Reflector打开exe文件,哈哈,看到的永远都只是一个actmp.dll的信息,其中包含4个7zip命名空间和1个Sixxpack命名空间,反编出来这些东西对也没啥处......"。 基本明白咋回事了。我又用“Sixxpack”做关键字搜了一下,果然找到了一堆这个软件的信息,其中说"Sixxpack 是一个 .net EXE 文件压缩工具。经 Sixxpack 压缩过的文件,运行时与压缩前相比没有任何区别,压缩比最大可达80%。压缩后的文件更难被反编译,保护您的程序不被破解......"
感慨搜索引擎强大的同时,我们可以确定,这个程序100%是用Sixxpack处理过了。目的可能是为了减少体积,更可能是为了防止俺这样随便 Reflector的人。如果用其他工具压缩也还罢了,但是Sixxpack貌似也是.net写的,而且没有混淆过,不看一看他的代码多对不起自己.net程序员的光荣称号啊。为了查看方便,我用File Disassembler插件把源码导了出来,找到了Main方法所在的类。核心的东西在Main方法里,很简单,我加上了注释。代码如下:
从以上代码,我们可以猜测,Sixxpack把压缩过的程序集和Sixxpack的解压程序(也就是壳)放在了一个文件里。运行程序时,Sixxpack的解压程序先运行,然后执行以下步骤:
1.构造一个内存流。
2.取出压缩后的程序集二进制数据,放进内存流。所谓压缩后的程序集二进制数据,也就是这个文件的第0x8000(即程序里定义的orig字段)到最后一个字节的数据。至于为啥是从0x8000开始,我想 0x8000应该是壳的长度吧,壳的数据占据了从0到0x8000字节的空间,剩下的应该就是压缩后的程序集的数据了。
3.用Compressor类的Decompress方法解压内存流数据,得到原始程序集。
4.用反射加载原始程序集,找到程序集的入口方法,并执行这个入口方法(这时Sixxpack已完成任务,控制权已转交给解压出来的程序集),如果入口方法需要参数的话,会把Main方法的参数传给入口方法。
既然明白了解压的方法,那么想拿到原始的程序集也不是什么难事了。只要知道压缩后的程序集在文件中的偏移量(我猜测应该都是0x8000,不过没看过其他例子,不敢确定),就可以把它取出来,然后用Compressor类的Decompress方法解压即可得到原始程序集,最后输出到一个文件就行了。
代码很好写,大部分照抄Main方法就行了,至于Decompress方法,不用管它具体怎么实现的,反射过来直接使用即可。下面是主要代码,我直接写在界面里了,懒得再独立写一个方法: