oc-obfuscator混淆方案(1)

1.背景

进行逆向分析的过程，最主要的是源码级别的分析，代码审计等。而对于android，是由 Java语言开发，而系统的操作机制实际靠的是"虚拟机"，Dalvik字节码，该虚拟机又叫Dalvik VM.该虚拟机比JVM快得多，他的字节码很难看出代码逻辑。但是可以用apktool反汇编成smail，smail虽然也不好读，但是易懂啊，至少比汇编好懂。接下来扯到iOS,他的开发语言就直接是Objective-C或者Swift，我想Swift还没普及到那个境界，所以还是默认OC，基于面向对象的C语言，对C的扩充。各种对象内存管理机制和各种异同这里也不想大篇幅的写，就说一点，OC的编译结果跟C一个样，你反编译的结果都会是晦涩的汇编语言。

在Windows下，C、C++的可执行文件是PE格式，在Mac\iOS下，OC的可执行文件是Mach-o 。结构是头部(header structure)，加载命令(load command)，多个段（segment）,链接信息。再来写写class-dump ，这个程序主要是用于提取Mach-o文件中的__objc_classname和 __objc_methname，这两个结构头包括程序的类名和方法名。很厉害啦，能提取到这些东西对于一个iOS、Mac程序而言是很致命的，意味着你有很多东西要暴露出来，安全分析人员或hacker仅仅需要猜解开发者规范的命名究竟是什么含义，就能弄懂程序的运行流程和结构。

2.目的意义

对于android而言，需要的防护手段是加壳，不让你看到我的核心代码。而iOS而言，防护效果太低了。可能就只有AppStore的加固防护，苹果官方为你加的壳，帮你混淆所有的代码。而iOS应用程序蜕壳就更为简单了，有两个开源工具可以用，dumpdecrypted、Clutch，第一个需要插入设备环境变量，然后用DYLD_INSERT_LIBRARY的方法注入dylib，进行砸壳。Clutch更为直接，在越狱设备安装好后直接就能使用Clutch -i -d等参数进行砸壳操作。

对于如此粗暴的手段，市面上竟然没有一款防护class-dump分析类名方法属性名的高级加壳工具。oc-obfuscator因此而生，真正具备了混淆源码的功能，是真正的混淆了源码，让你dump也无法猜解出我的类名和方法名到底是干了什么，进行了什么操作。从而提高逆向分析的难度。关键还是自动化，给出一个源码包输出一个源码包，完全解放双手。

3.概要设计

我们真要从源码级别动手，就得明白，有一些东西能改，而有一些东西时绝对不能改动的。

这是个深坑，也是我在开发过程中遇到的诸多问题，下面我想从设计方面尽可能详细地一并阐述他们。

3.1怎么入手？

源码级别的改动，改动你的源代码类名、方法名、属性名，使用一个加密的函数对他们加密，生成一张巨大的hash表，明文键对应加密后的密文键，然后遍历你的工程进行全部替换。

3.2修改后工程是否正常？

理论上说不可能，文件名被改动了（类名），需要重新组织该项目（深坑），如打开Xcode项目，然后到Finder中修改一个文件名，发现在项目中该文件变红。

3.3编译是否正确？

不稳定性因素太多，因为我们无法得知究竟替换了什么部分，混淆了什么方法，只能得到混淆的结果与字典表，并不知道逻辑是否被改动。不过都是可控，我们可以追求更完美的混淆，只混淆我们指定的一个地方。

3.4运行是否正常？

无法保证，但是能追求到完美。完美的概念就是正则的结果！

3.5python+正则

为此，我做出了这个决定，使用python 和正则表达式来完成它，正则可以保证我筛选替换的字段一定是正确的，而python可以更为方便操作系统相关方法，例如遍历文件、修改内容和文件名。

4.详细设计图以及一些坑

 

 

深坑就是：重组项目的进行，替换函数的进行，正则不完美以及没法预料特殊情况，还有运行崩溃，编译失败等等等等。

上述，这些深坑我都还没提到解决方法，这些没法预料的深坑只能在开发过程中遇到和解决了。

github:https://github.com/ch4r04/MiaoDump

商用请联系作者，转载请注明出处，谢谢。