正文
ios开发代码混淆,app代码混淆
小程序:扫一扫查出行
【扫一扫了解最新限行尾号】
复制小程序
【扫一扫了解最新限行尾号】
复制小程序
iOS代码加密的几种方式
对ios应用加固有两种实现方式。
一种使用安全编译器
基于LLVM编译器中间层实现。基于 LLVM 的保护方案,在使用时需要更换已有的编译环境,替换编译器,调整编译选项等,对开发环境造成了很多影响,易用性差。从保护效果上看,基于 LLVM 的保护方案,受限于编译器框架,生成的代码只能做逻辑上的混淆变换,仍然可以被反编译,对控制流的混淆效果有限,且边界清晰,更容易被分析。
反编译效果
OLLVM 保护后反编译效果:
一种使用VirboxProtector 虚拟化保护。
ARM 虚拟化是 Virbox Protector 针对 ARM 架构的指令推出的虚拟机保护方式,通过将原始的 ARM 指令进行翻译,转换为自定义的虚拟机指令,运行时在自定义虚拟机执行。Virbox Protector 实现了针对 ARM 指令的虚拟机保护工具,支持对armv7(包括 thumb, thumb2),及 armv8 以上指令集进行翻译,安全强度高,适用于需要高安全性的代码保护需求。通过虚拟化保护后的代码无法被反编译。
Virbox Protector 保护后反编译效果:
iOS代码需要混淆吗,具体怎么弄,请指教
app发布前,最好做一下扫描和加固,应用扫描可以通过静态代码分析、动态数据跟踪,定位出风险代码(目前好多都是只告诉APK包里面有风险),同时监控敏感数据的异常行为。
加固可以在一定程度上保护自己核心代码算法,提高破解/盗版/二次打包的难度,缓解代码注入/动态调试/内存注入攻击等
但也对应用的兼容性有一定影响,加壳技术不行的话,还会影响程序运行效率.
目前市面上有很多第三方加固的平台, 如果新应用发布前需要扫描或者加固的话,可以先试试免费的,例如腾讯御安全,建议自己先去扫描测试下。
iOS审核被拒4.3,怎么解决
最近,苹果对于中国区的iOS开发者们要求很是严格,想必各位也吃到了苹果的2.1大礼包,满世界的寻找马甲包的混淆方案。
作者:棋牌视角
来源:棋牌视角
本文为作者授权鸟哥笔记发布,转载请联系作者并注明出处
来源: 棋牌视角(ID:qipai49)
本文为作者授权鸟哥笔记发布,转载请联系作者并注明出处。
马甲包对于一家公司的产品引流起到至关重要的作用。但是最近这段时间,苹果对于中国区的iOS开发者们要求很是严格,想必各位也吃到了苹果的2.1大礼包,满世界的寻找马甲包的混淆方案。
第一次被打回
第一次被打回时,我们并没有意识到马甲包的问题有多严重,而且苹果给出的拒绝原因是我们的APP中包含敏感词汇,我们当时并没有往马甲包的方面去想,第一次被打回时,我们采用的方案是对敏感词汇进行base64+MD5的混合加密方案,然后就重新提包了。
第二次被打回
这次苹果说的很明显了,而且他们机扫了我们的二进制文件,告诉我们API名称与我们之前的一个产品非常相像,而且那个产品并不是使用这个马甲包的开发者账号。我们猜测苹果可能针对APP做了数据库,会去比对方法名。
这一次我们代价比较大,由于之前没有考虑到这层,我们的API名称就是和系统方法命名方式保持一致,导致无法引入脚本来自动替换。我们花了三个开发,和6个小时,人工对我们自定义的API名称加上了特定前缀,如ab_xxx.这个思路主要是根据念茜大佬之前在微博上发布的API混淆加密方案。念茜的脚本是将需要混淆的API添加进文件,然后全局对所有需要加密的API字段进行混淆加密。我们在此基础上更新了脚本,可以自动抓取拥有我们前缀的API进行加密。但是这个方案在后面我们完全摒弃,所以在这里不详细往下说了。
第三次打回
第三次被打回已经惊动了老板,再想不出好的固化混淆方案我觉得差不多可以收拾东西了。这次苹果的拒绝原因更令人窒息,他说我们的API加密性质太明显,认为我们的APP一定藏有什么隐藏功能,还给我们吃了一张延迟审核的黄牌。经过我们一波分析之后,认为这几次被打回的经验中,苹果没有涉及到说我们的UI有什么相似的地方,所以,只要我们能把这个马甲包做到变成我们开发人员都认为是另一个APP即可。
分析
首先感谢将混淆脚本开源的大佬!已经找不到源码是谁写的了,我们只是站在了巨人的肩膀上!
改头换面
首先,由于是从主APP上拉的分之进行开发,所以这个马甲包的scheme和工程名都没有变化,于是我们首先从这里进行开刀。我们把project名称完全换成了另一个。
API
首先base64加密API肯定不能再使用了,苹果都说了,加密特征太过明显。
幸好之前已经把所有自定义的API名称都加上了ab_前缀,使得我们写脚本很好识别。我们将所有扫描出的API放到一个plist文件中保存在本地,然后我们建立了6个数组,每个数组中有6个单词,每次从每个数组中随机抽取一个单词。将6个单词拼接成一段方法名保存在另一个plist文件中,当然,在保存前,先去重,如果这个方法名已经用过了,那我们随机再换,这样一共可以生成46656种方法名,对于我们的工程已经够用了。
图片
我们利用脚本遍历本地所有png文件,当然你可以自行添加.jpg格式遍历。根据自己的命名规则将所有图片重新命名了一波。另外我们也发现网上有个轮子可以利用shell命令对所有图片资源进行超轻量级的压缩,在不影响图片质量的情况下,改变图片的hash值。当然我们的马甲包中图片没有和主界面相似的,所以的这一步我们没有实践。
类前缀替换
这一步主要是更改文件名。程序扫描绝对地址下的所有文件,只要是带”XX”开头的文件都替换成”AB”这种,另外每次替换一个文件都要遍历所有文件,将所有用到这个头文件的文件内容进行更换。
注意
类前缀替换有时会有个别没有替换到,我没能定位到问题,但很少,可以手动查找替换
生成垃圾代码
我用plist专门搞了一个垃圾方法名,每四个方法生成一个带参数名的方法。暂时每个文件里只生成一个垃圾方法。当然可以多运行几次,就会生成几个垃圾方法
实现
混淆工程我们使用C+OC的混合编程方式。
目前已经实现的功能有:
1、图片资源修改名字
2、修改工程名
3、类前缀修改,如“GD”修改为“IE”,即修改了文件名
4、混淆随机添加垃圾代码、参数
5、修改方法名前缀
6、人工修改部分方法名,人工对重要类中的方法进行打乱排序
7、(可选)本地图片超轻量级压缩,打乱hash值,新上的马甲包建议修改
使用方法
启动参数配置
先配置启动参数再运行,如图
除第一项必选外其他都非必选。另外第一项启动参数必须放在第一行
参数解释
1.工程代码的绝对路径
2.-modifyProjectName [原工程名][新工程名]
3.-modifyClassNamePrefix [xcodeproj文件的绝对路径,不是pod安装后的那个打开文件] [旧类前缀][新类前缀]
4.-spamCodeOut
5.-ignoreDirNames [需要忽略的文件夹],[需要忽略的文件夹] 注意,Pods文件夹不在混淆范围内,不需要写
6.-handleXcassets (混淆图片文件)
7.-deleteComments (删除多余的空格和注释)
8.-chageAPIPrefix [旧方法名前缀][新方法名前缀] 注意,前缀要有“”才能被识别,如果之前工程中没有xx下划线开头来命名方法的,此项不要勾选
此工程可以选择混淆概率,修改工程中kPercent数值。
实际测试如下
小结
目前第三次打回后的工程已经提审,未可知能否过审,会持续更新。脚本也写的很匆忙,后期会进行优化。脚本传送门
跪求:马甲包上架技术,ios 代码混淆 马甲包过审技术!!!
从收集今年每月审核被拒原因得来的大量数据中可以看出,被拒原因 TOP3:条款 2.3、2.1、4.3(元数据、App 的完成度、重复 App/马甲包)一直是稳定的居高不下,因此开发者们一定要遵守这三条条款,以增加过审几率、节省与苹果纠缠的时间,勿要存在侥幸心理,挑战苹果。
若想通过审核,除遵守上面几项条款以外,在4.3问题上主要是改变二进制代码,如果是同一个包(马甲包)想要改变二进制代码而对功能又没有任何改变,可以使用几维安全提供的安全编译器,利用混淆的技术来改变二进制文件。
帮助过审的同时,还能利用IOS开发子团队开发的包过审马甲包加密混淆编译器可安全编译C、C++、Objective-C、Swift代码,支持安卓 NDK和iOS马甲包项目
支持iOS项目[APP、动态库、静态库]和安卓NDK项目[SO动态库、静态库]!