@Zhang wrote:

很多人都问我Hikari为什么不做这一块的支持。主要是懒
其实很简单，因为OC本身语言特性的问题不可能在不限制语言特性的情况下完美无缺。考虑如下代码

@interface AAA:NSObject
-(void)BBB;
@end
@interface CCC:AAA
-(void)BBB;
@end

@implementation DDD
-(void)FFF:(id)arg1{
   [arg1 BBB];
}
@end

假设AAA是系统类，也就说编译器不能修改里面的定义。很显然在混淆FFF:的时候混淆工具无法确定这里的SELBBB是应该修改成CCC里BBB混淆后的的名字还是维持不动。 这个问题实际上有很多种变种，但其他所有变种都跟这个例子某种意义上类似。 比如说常见的通过respondToSelector:来运行时判断类型对分析带来的干扰等等。在这个基础上还有分析时跨界的引用问题，比如上例的AAA CCC DDD都在多个翻译单元(aka源代码文件)，又或者是子类复写的父类的SEL等等带来的问题，或者更明确一点，都来自语言本身高度的反射机制和最重要的: 类和SEL的解耦合以及泛型/弱类型。 语言本身的设计问题，无法完美解决。 更不要说这些SEL和类型信息走入LLVM IR之后就无法直接获取到了。类名相对会好做一些，但是SEL是一个巨大的坑。

看到这里读者很可能会问: 那么为什么不做一个黑名单机制，即所有系统的SEL/Class都不混淆呢？ 这又回归到了设计哲学上的问题。首先不完全统计iOS11为例系统大约有数万个系统类和十万左右的系统SEL,这对于编译过程中的分析是一个无比巨大的内存和性能开销。除此之外还需要额外维护整张表来处理第三方框架等问题。这个过程是非常非常容易出错的。这就回到开头的另一个原因，懒。

TODO

写一下传统意义上的符号&&上述问题可行的部分绕过方案及他们的问题。 写一下DFA。
写一篇如何自己实现不依赖LLVM的效果更好的符号混淆工具的教程

Note:

不要发微博推广

Posts: 1

Participants: 1

Read full topic