背景
公司需要做一系列的壳版本，壳版本如果内容雷同提交到App Store会有被拒绝的风险，其中有一种解决方案是在壳版本中注入混淆的代码，防止被苹果检测到内容太过雷同而导致审核被拒绝，本文是针对这个场景，使用shell脚本进行半自动批量添加和删除混淆代码。
shell实战的系列文章
iOS使用shell脚本注入混淆内容
iOS使用Shell脚本批量修改类名称
iOS使用shell脚本批量修改属性
结果
使用方法
- 打开测试工程
测试工程位于项目目录下面的DevPods/InjectedContentKit/Example/目录下，打开InjectedContentKit.xcworkspace即可
- 执行命令
在命令行中进入到项目目录下面的DevPods/InjectedContentKit/Example/injectContentShell子目录，在我的电脑对应的目录为/Users/aron/git-repo/YTTInjectedContentKit/DevPods/InjectedContentKit/Example/injectContentShell，然后执行./injectedContentShell.sh脚本文件批量添加混淆内容，脚本开头的to_process_file_dir变量配置的是需要修改的类所在目录，脚本会自动检测该配置是否正确，正确会显示菜单项页面，否则会提示用户输入需要修改的类所在目录，输入正确之后才会显示菜单项页面。菜单项有三个选项，第一个为删除注入内容，第二个为添加注入内容，第三为退出脚本执行，输入对应的编号即可执行相应的功能
处理结果
添加注入内容到源码中的结果
把注入内容从源码中删除的结果
本文的Demo代码YTTInjectedContentKit
分析
在开始做之前，对步骤流程做了一些构思如下：
初始步骤流程
-
步骤一：手动处理
混淆注入类列表
混淆注入类对应的方法列表 -
步骤二：配置化
步骤一的形成配置化 -
步骤三：自动化
扫描对应的类和类对应的方法列表，形成对应的配置文件
从配置文件中读取配置注入到对应的目标类中 -
步骤四：自动目标文件的处理
目标文件的查找规则：哪些是需要注入的目标文件
目标文件的注入规则：目标文件中需要在什么位置进行注入 -
步骤五：注入内容自身配置
注入内容需要在不同环境下变换不同的形态，包括类名，方法名等
后面在实现的过程中发现步骤三和步骤五不好实现，所有简化了这部分的流程，最终只保留了以下几个步骤：
优化的步骤流程
-
步骤一：手动处理
混淆注入类列表
混淆注入类对应的方法列表 -
步骤二：配置化
步骤一的形成配置化 -
步骤三：自动目标文件的处理
目标文件的查找规则：哪些是需要注入的目标文件
目标文件的注入规则：目标文件中需要在什么位置进行注入
以及在实现过程中遇到了一些细节需要处理，这些细节部分作为自步骤如下：
- 子步骤：
步骤三-1：检查时候安装gun-sed，mac下的sed和gun sed 会有差别，所有统一使用gun sed
步骤三-2：用户指定目标位置，需要用户输入
步骤三-3：删除所有的注入内容
实现
步骤一：手动处理
整理一份注入的内容这部分工作是需要手动处理的，这部分的内容应该是具备自完备性的，可以被多个项目做为依赖导入，所以把这些内容作为一个pod库比较合适，也很方便在pod库的测试项目中测试该库的自完备性。库里面的内容可以是任意的，在我实践的过程中，我是把一个旧的项目的网络接口模块作为了这部分内容，因为这部分内容相对的比较独立和容易抽取。
下图是我从旧的项目中提取的一些类作为混淆类
以及我在测试工程中测试混淆的接口调用，在测试工程中测试混淆代码的调用以确保编译链接无误以及确保库的自完备性。
步骤二：配置化
配置文件其实就是把测试工程总的接口调用代码拷贝一份到单独的配置文件中，配置文件如下
步骤三：自动目标文件的处理
这个是最核心的部分，主要包含了以下内容：
- 配置文件路径配置和需要注入的源码文件夹的配置
- 读取配置文件的注入内容
- 读取源码文件夹下的源码实现文件（XXX.m）
- 把注入内容添加到源码中指定的位置
- 从源码从把注入的内容删除
完整的脚本如下，里面有比较完整的注释，阅读起来应该不会有太大难度：
文本的插入和删除部分使用的是shell中的sed(stream editor)工具，特别滴在mac中sed命令和标准的sed命令有差别，脚本中也会有做这部分的检测，如果机器上安装的不是标准的gun sed程序会自动通过brew安装gun sed
总结
以上就是基于shell脚本，从混淆内容注入和把混淆内容删除两方面做了一个半自动化的实现步骤，如果不妥之处，还请不吝赐教。