最近苹果机审似乎有了一些变化
由于cocopods被广泛得被开发者使用, 即便是两个毫无相关的应用 cocopods部分,代码重复率也会很高, 苹果很可能基于这个因素,对cocopods部分检测侧重比较低,否则会造成大量误审
什么是检测侧重比较低?
比如 可执行文件检测结果占比0.7 , 动态库检测结果占比0.3, 综合来评定, 这样的侧重,即便是两个不相关得应用恰巧cocopods部分重复较高, 也不会被误判定4.3 .
这也是flutter应用, uniapp 应用 混淆过审概率更大得原因,因为flutter和unity编译后得ipa包中, 可执行文件几乎是空的
但是就在近一个月几乎发生了一些变化, 通过我多年摸索得flutter 混淆方案, 过审率一直为100%, 近期出现了一例 4.3
我们来用flutter 举例进行一次反推:
对flutter得编译产物稍微有点了解得应该知道你写的dart代码,最终以动态库得形式集成到这里. (这就是很多flutter手写白包导致4.3得原因, 因为你的可执行文件根本没有发生变化)
比如苹果能解析出我们所有得动态库的信息, 他用什么方式判定相似度最为准确呢?
1: 苹果很有可能对这个app.framework 做了"格外关照", 因为苹果拿到动态库里面得信息非常容易, 很多类名,方法名,提取出来易如反掌.
但是不见得苹果一定会这么做,因为这会增加工作量, 由本身得检测一个可执行文件变成检测两个, 机审时间很有可能被拉长一倍.
说到这里很多开发者对fluttter 官方发布的混淆命令有所疑惑, 这个混淆命令作用在哪里? 是否有用?
flutter build ios --obfuscate --split-debug-info=./debug_info
这个命令作用在app.framework中, 始终这种形式打包, 你得dart代码会被混淆成乱码.
(慎重使用, 会被苹果判定2.3.1 ,亲测)
2: 苹果能不能根据你得应用引用得动态库得名称进行相似度判定呢?
比如你的app中有 以下几个动态库,别人的app也有这几个, 你和会别人判定相似吗?
device_info.framework
file_picker.framework
image_gallery_saver.framework
in_app_purchase_storekit.framework
非常不会, 因为这并不准确, 苹果永远会选择最精准且最快速的方法, 这种方式虽然非常快速,但是并不精准, 很有可能app凑巧使用得动态库或者说三方库完全一样
那么什么方式最精准 ? 名字 + 顺序
名字我们知道了就是这些动态库名称, 顺序是什么顺序呢? 动态库得链接顺序
我们看上图, 这是我解析可执行文件的动态库链接, 当你的app被打包后得那一瞬间, 你的动态库链接顺序就已经确定了 .
如果得动态库名称和链接顺序完全一致或者几乎一致, 那么你跑不掉了 , 这就是我之前说的控制流
并且这些信息都可能在可执行文件中提取, 无需单独提取某一个动态库, 这从时间上是也是可行的
UI 页面 相似度 能否从可执行文件提取得信息中 判定?
你是否听信了很多人让你大改UI, 到底有没有用? 这里我们分多种情况
1: 你的布局代码大多是xib构建得, 那么你要注意了, xib是以一种资源文件集成到ipa中, 并不是编译到可执行文件中, 即使你大面积调整了xib布局 不会引起可执行文件的丝毫变化, 重复率不会降低
2:如果你的布局代码是frame编写: view.frame = CGRectMake(10, 20, 100, 200);他可能在可执行文件中这这样的
参数加载 (x0=view, x1~x4=CGRect 参数)
mov x1, #10 ; x
mov x2, #20 ; y
mov x3, #100 ; width
mov x4, #200 ; height
bl _objc_msgSend ; 调用 [view setFrame:]那么单凭这些信息几乎无法判定相似度, 准确率极低, 因为适配不同设备的动态布局（如 screen.width * 0.5）在二进制中表现为计算指令，而非固定值。
结论: UI相似度 根本无法静态判断, 必须是代码相似度过高 ,触发人工关注 , 由肉眼判定 .
关注我, 了解更多iOS审核4.3 最新案例和信息, 对抗库克!!!