今天晚上朋友找我，说他用的OA系统(ASP.Net的)今天更新了，注册算法好像变了，好像加密壳也换了，找我帮他看看。
是DLL的程序而且是net2.0的，感觉应该很好弄。资源管理器中用大图标视图模式看了一下所有的dll文件的版本信息没有发现可疑文件。先拿ildasm看看结构，分析一下有什么保护方式。结果出来一个 红叉的对话框，说什么是受保护的模块。
用reflector不能看是预料之中的，这个工具太脆弱了。用9ray的能看到部分。
不过这些工具都太弱，还是Dis＃比较强悍，就用它了，打开一幕了然，看得清清楚楚。
有名称混淆，名字都被混淆成了类似这样 "o10l1o0l" 的名称。还没有见过什么混淆器有这样的名称混淆特征。
除了部分方法能看到代码，大部分方法都看不到代码，应该是有加密壳。
发现有pinvoke调用。汗，调用的是一个数据库访问层的dll（从dll的文件名来看），实际分析一下这个文件，发现原来是一个native的dll。隐藏得这么深，看来这个文件有猫腻。
看了一下导出表，你面有几个函数是在maxtocode的运行库中看到过的。但这个库导出的函数比以前看到的maxtocode运行库导出函数多了很多，而且运行库的大小明显要大很多。
先不管它是什么壳，姑且用反射方式脱试试，结果显然不行，这个壳 anti 反射了。
我怀疑这个是不是最新版的maxtocode，上它网站下了一份说明文档，看看更新记录。
* 增加了对ILdasm以及使用API 访问源数据的反编译工具的反制功能
（后来发现它实际上只是anti了 ildasm 2.0，严格的说只对ms官方的有效）
* 经测试,目前没有一种反编译工具可以完整的读取加密后的结构,更不用说加密后的代码了
(看说明文档介绍了ildasm,reflector,spices 无法读取，似乎没有介绍其它工具，尤其是Dis＃。这三个不能 就算 没有一种 :P)
先就按maxtocode来治，试试用maxtocode 3.16的方式反射，似乎有一点效果，能得到一些方法属性，但还是没有IL代码。
看说明文档，里面提到 maxtocode 3.2企业版用了多核分段保护，会不会是在jit层中也有挂接服务呢？先扫了一面jit领域，没有发现异常。
那就应该是在mscorwks.dll领域了。
我在想它会不会是用的我在前一篇文章 "mscorwks.dll在.Net中的地位以及在.Net代码保护方面的应用" 中提到的 第三种方式或者类似方式？虽然那个方案已经被我否定掉了，这个壳也许就是这样的。
扫了一下A区，和B区，果然在这两个区都发现了异常。看起来反射的路是不太好走了。
直接拿jit层脱壳的方式试试，OK，可以正确获取到方法体代码。
因为是脱dll，所以可以先把jithook安装好后再载入加密的程序集，不会有方法从jit中漏掉，如果是exe可能需要hook全局的loadlibrary之类的函数，在mscorjit.dll加载时完成jithook。另外hook的位置也需要注意可灵活多变，防止壳有反hook机制。
进到Jit层里面方法的内容已经被转换成了几个类结构，好在在sscli中可以找到它们的定义，这就使方法体的重建简单很多了。
一直在做hvm，都是jit层的东西，所以对这部分非常熟悉。重建就只是sehtable稍麻烦一点。
朋友只需要几个关键函数的代码，这工作量就少很多了。上看雪下了一个修改版的 ildasm，因为ms官方版的被anti了。
打开程序集，查到所需方法的token值，记下来。通过反射找到方法并invoke，让它经过jit，jithook(根据token过虑)把获取的方法体dump出来。为了省事，首先拿反射脱壳dump一个空壳程序集下来。再手动把jithook取到的方法体填充回去（现在还没做自动回填的工具）。
如果要做成自动脱机，得在jithook里面把所有方法体按模块合计存起来，然后做个自动回填的工具填到程序集中。
看这个壳的特征很像maxtocode新版所描叙的，从运行库的导出表来看原始模块名称是 attick.dll，好像就是maxtocode运行库原始名称。而且导出函数包含了以往maxtocode运行库的导出函数，多出了Getcpuid,getdiskid,getmacid等函数。
另外在里面也看到了一些和DNGuard v1.0相似的结构混乱以及静态构造函数的处理方式。
元数据头也是和DNGuard v1.0处理后的相似，估计也用了framework api来处理。
这种方式能使加密速度提升很多。冒似maxtocode 3.16的更新记录也有说大幅提供加密速度。
虽然很像，暂且还是称之为未知壳吧。
