剖析DotNet的名称混淆保护技术,兼谈某壳3.15的新保护技术

简介: 混淆在目前的DotNet保护中占主流地位。名称混淆是最基础的混淆保护技术。DotNet加密保护工具MaxToCode也在最近的更新中加入了混淆保护--名称混淆。我们先谈谈名称混淆技术,名称混淆的意义何在?在我看来它就只有一个意义,将表意的名称替换为无意义的名称。

混淆在目前的DotNet保护中占主流地位。名称混淆是最基础的混淆保护技术。
DotNet加密保护工具MaxToCode也在最近的更新中加入了混淆保护--名称混淆。

我们先谈谈名称混淆技术,
名称混淆的意义何在?
在我看来它就只有一个意义,将表意的名称替换为无意义的名称。
如果说再在名称混淆上搞其它的花样都是徒劳的。

名称混淆从本质上可以分为两类。

第一类,最简单的名称混淆——名称替换。
.Net的元数据中有一个NameTable,这个表里面保存了所有类型,方法,属性,字段等的名称。
这一类混淆的本质就是从NameTable里面进行一对一的名称替换。
当然实现的方式可能是多样的。可以IL级替换,也可以直接元数据级替换,或者其它达到相同效果的方式。
抗反混淆的强度很低。

第二类,名称擦除、索引破坏
这类混淆只能在元数据级进行操作,要求对元数据的全部结构十分清楚,有一定难度。
它的本质,让名称索引数组越界。
元数据中类型,方法,属性,字段等的定义处是通过一个整形的index值指向 NameTable 的,index所对应的字符串就是它的名称。
这类混淆就是直接修改这个index值,如将它改为-1。

如果还要进一步做,可以再删除NameTable中无用的字符串,以及删除NameTable有用但重复的字符串。
再修改索引,让名称相同的指向同一个字符串。

这类混淆有一定的抗反混淆的强度,能让一部分反混淆工具失效,还能让一部分反混淆工具发生数组越界的异常。


名称混淆的反混淆技术(实质也是一个“名称混淆”过程,只是这次我们是有意义的“混淆”):
Jason早前就分析过了,我这里就直接搬来用。
Jason说过,名称都存在元数据中的NameTable中的,反混淆只要直接修改这个NameTable,将特许字符的名称改为字母的名称即可。
这实际上就是使用的第一类名称混淆技术来反混淆。
这种方法能对付目前绝大部分保护工具的名称混淆。对付不了第二类名称混淆。

这种只是最初级的反名称混淆技术。我们可以使用第二类混淆技术来实现更好的反名称混淆工具。
能达到什么效果呢?不仅能把特许字符替换为字母的字符,还能让替换后的名称表达一定的意义。
即在进行名称替换时采用匈牙利命名法,只要看到名称就能知道它是“类型、方法、属性、字段等”。
甚至看得出字段的类型,访问权限。类型的基类等。
这类工具能反上面两类名称混淆。

目前DST(Dotnet Security Team)[http://bbs.dotnetreverse.com]组员已经开发出了这样的工具。

下面谈谈某加密保护工具的新版3.15.
今天朋友给了我一个3.15加密的程序,让我看看。
首先直接拿3.14的脱机试了一下,脱壳正常。
然后再看,有名称混淆。
去看了一下该工具的更新说明,增加了名称混淆,还提到有增加新保护技术。

我问那朋友新版都有什么新功能,他告诉我,新版有名称混淆界面,提供了三种名称混淆方式。
"encrypt objects name","none objects name", "md5 objects name"。
看到这三种方式,很明显,第一个和第三个都是第一类名称混淆。
我想新保护技术不会就是"none objects name"吧。如果是,那怎么说也应该是第二类名称混淆才能勉强称得上新技术。
实际分析了一下被加密程序的NameTable,发现不是,它还是第一类名称混淆。用第一类名称混淆技术就能反它。它只不过是把所有名称都替换成了不可见字符("\r\n")。

这就让我有一点困惑了,它提供的三种方式本质是一样的,而且用Jason自己介绍的方法就能实现反混淆。
从技术上讲,他自己应该清楚提供一种方式就足够了。也许这只是商业化运作的产物,这样能满足一批不懂技术的用户。

名称混淆,简简单单就行了,没有必要深入,毕竟它只有一个浅显的意义。
目前反名称混淆工具很完善,再怎么深入也是徒劳的。

说了这么多还没有提到它的新保护技术是什么,
我朋友是遇到了问题才把程序抛给我的,他说用PEdumper dump后程序没法用Reflector和ildasm看结构 了。
它的新保护技术大概就是anti一般的pedumper吧,说新保护技术有些夸张了,其实在win32保护中就有用过。通过破坏PE文件结构来anti pedumper。
难怪用3.14的脱机没有问题,而用pedumper就有问题了。


再就没有发现什么新东西了。
该工具从3.11起在加密核心就基本没有变了,强度也一直停留在那个水平。
现在看来,他似乎是在转型了,开始向混淆保护发展了。
加密保护是他的特色,加密壳在jit层还是有一定发展空间的,至少能让强度再上一个台阶。

DNGuard 2.0已经实现了jit层的内核,可行性是没有问题的了。
开发中的 DNG H-VM接近尾声了,兼容性比预期的要好。








目录
相关文章
|
3月前
|
前端开发 JavaScript 安全
顶级加密混淆混淆工具测评:ipagurd
顶级加密混淆混淆工具测评:ipagurd
52 0
|
7月前
|
监控 API C++
一个更好的文件监控类,基于 DotNet 官方提供的 FileSystemWatcher
一个更好的文件监控类,基于 DotNet 官方提供的 FileSystemWatcher
|
3月前
|
Java
血泪教训!Java项目的路径中一定不要包含中文~
血泪教训!Java项目的路径中一定不要包含中文~
|
3月前
|
移动开发 安全 前端开发
iOS代码混淆工具
iOS代码混淆工具
60 1
|
3月前
|
安全 Java Android开发
iOS代码安全加固利器:深入探讨字符串和代码混淆器的作用
iOS代码安全加固利器:深入探讨字符串和代码混淆器的作用
35 0
|
11月前
|
安全 Go API
自写go加载器加壳免杀——过国内主流杀软
自写go加载器加壳免杀——过国内主流杀软
306 0
|
11月前
|
Go 微服务 Python
go加壳分离免杀过国内主流杀软
go加壳分离免杀过国内主流杀软
542 0
一起谈.NET技术,Visual Studio对程序集签名时一个很不好用的地方
  由于我们的项目底层使用到一个通过LogicalCallContext实现的上下文数据管理框架,导致所有的Unit Test不能正常运行。具体的现象在《只在UnitTest和WebHost中的出现的关于LogicalCallContext的严重问题》有过详细的介绍。
848 0
|
C++
VS Code英汉词典进化效果演示: 翻译文件所有命名
实现VS code插件, 基于本地词典数据, 提供英汉翻译功能, 演示批量命名翻译功能. Demonstrate a new feature in vscode extension to translate English word or phrase to Chinese, by supporting translating all identifiers in a file.
929 0