ios马甲包

一、什么是马甲包

马甲包是利用App store 规则漏洞，通过技术手段，多次上架同一款产品的方法。马甲包和主产品包拥有同样的内容和功能，除了icon和应用名称不能完全一致，其他基本一致。

二、为什么做马甲包，做马甲包有什么好处？

抗风险
正常情况下，任何一款产品都是要不断的更新功能的。如果我们直接在主包上更新，一旦新功能不被用户接受那就损失大了，我们前期大量投资带来的用户将会流失，这对很多产品开发者来说是不可承受之痛。

如果使用马甲包，则可以随意测试新功能，好的功能就在主包上迭代，不好的也无所谓，马甲包本身就是来背锅的。

导量
主包和马甲包属于同一个平台，用户信息可以共享

通过弹窗,广告,Push等引导用户到App Store下载主App。

有一部份App接了网盟相互导流。

3. 增加关键词覆盖数

App Store关键词长度上限是100个字符,据了解人为正常优化的极限是关键词覆盖数在4000左右,那些覆盖数在8000+的都是利用了苹果漏洞。所以,多做一个马甲,也就意味着覆盖的关键词可以更多。

4. 刷榜

①积分墙;理论上是真实用户,冲榜量级大,可靠后续补量维持;但冲榜和维榜费用高昂,非一般产品所能承受。

②真机;利用真实机器操作任务,但不能抹机,否则就成假量了,成本相对较低。

③技术流;机刷,服务器控制操作,成本最低。

上面三种方式，机刷是最便宜的，但是风险高，容易被苹果后台发现下架，所以一般用马甲包来做机刷，以此来抵抗风险。

三、制作马甲包

1、二进制代码务必不同

二进制代码是应用市场判别产品的唯一标准，把代码做一些调整或修改，就会生成一个全新的二进制代码，这是制作马甲包的唯一方式。

2、功能局部化

如果主App功能较为丰富，做马甲是可以独’立其中一部分功能，这种方式审核通过率高，但技术投入成本也比较昂贵，适合大产品大公司操作。

3、产品简单化（关闭部分功能或页面）

如果独’立部分功能操作马甲复杂，可以选择产品简单化操作。具体是指：

将主App中的部分界面/功能删除掉；
主App中的部分界面/功能设置开关按钮，在审核期间关闭，审核通过后打开，此操作对用户体验不造成任何影响，常见的第三支付接口一般都是这样搞的。
4、页面差异化

修改App启动后第一个页面，保证马甲与主App的第一个页面不同，从先入视觉迷惑苹果审核人员。

5、整套UI更改

整套UI/美术更改，适合游戏类。

总结：总而言之，马甲包的出现给ASO优化带来了新的方式，也给优化工作带来了极大的便利。我们在使用马甲包的时候一定要把握两个方向，其一：导量，不管是什么产品带来量才能带来效益，效益为先。其二：抗风险，有些优化手段风险极高，但是带来的利益也是极大，所以制作马甲包就是为了抵抗风险，把利益留下。

三、马甲包的开发招式
1、UI部分
在原有的UI的基础上，修改新的UI。
启动图修改，坚决不能和之前的一样。
logo修改，坚决不能和之前的一样。
2、代码部分
修改工程中文件夹名字（全部需要修改）。
修改项目名字。
修改类名，前缀统一的进行统一替换，后缀名也可以根据情况进行修改（view/ViewController/model）。
添加混淆代码,修改之前的方法名,往类中添加不相关的方法（此处建议使用 #pragma mark -(此处是马甲包的特殊标记)进行标记，方便后续修改）。
修改boundID。
在之前App的基础上，增加或者删除部分功能，把两个App之间的差异尽量最大化。
四、上架招式
上架马甲包，最好是准备一个新的账号，不要影响主App，防止账号被封或者处罚影响主App的正常下载。
上架的时候项目描述不要和主App的一样。
项目宣传也不要和主App的一样。
提供给苹果的测试账号也提供新的。
上传马甲包的电脑，不要和上传主App使用同一台电脑（据说会检测上传包的ip）。
五、总结
马甲包本身是不符合苹果的上架规范的，但是为了让更多的用户下载我们的App，提升我们App的排名，我们不得不想尽办法制作马甲包，顶风作案。开发马甲包我们主要从UI展现和代码实现尽量的把它们做的不像相同的App，但是它们的核心内容是相似的，用户流量最终流向同相同的服务器，实现导量和提升排名的功效。

我们在上架马甲包的时候还要尽量保证主App的安全，所以使用单独的账号上架马甲包，为了提高过审率，还要使用不同的电脑进行包的上传。项目描述&产品宣传等等都不能一样，就是尽量做成两个App，但是呢周期又要短。

最后，马甲包只是一个辅助，我们的App本身一定要有内容，这样才能够留住用户，否则就算用户下载了，很快也会卸载。导致“留住了用户的人，没有留住用户的心”，只留下了用户信息，不能为我们带来实质性的价值。

---

1. 机审原理
   我们虽然无法得知苹果实际的机审原理，但从程序员的角度还是能分析出一些东西的。

1.1 首先OC和C++代码编译出的二进制文件，有点经验和反编译过的应该都知道：
删注释神马的是没用的，因为注释是不会被编译进包里
改类名是靠谱的，因为反编译出来能看到类名，改掉它显然是会造成包不一样
增改函数也是靠谱的，同样是因为反编译能看到
改文件夹或者文件名应该是不太靠谱的，编译的时候会根据路径来引用查找，编译之后应该是根据在包里的相对内存地址来查找类和函数，跟你编译时的文件名称和路径关系应该不大。不过为了方便和代码的统一，更换时可以顺便换了。
1.2 然后是一些资源文件如图片、音效
路径和文件名相当可能或者绝对是有用的，可惜修改代价有点高
文件的md5值以程序员的角度来看才是真正区分文件是否一致的标准，我们有理由相信我们的苹果同行也用了这个来判断是否重复。所以一些修改md5值的操作如添加空行、注释、额外字节，应该也被考虑加上。
1.3 最后是相似的判定，应该是相似率高于某个值才认为你跟其他的重复了，针对像改资源文件名这种代价太高的可能暂不考虑的操作，我们只能添加垃圾文件提高总值来降低重复率了。
2. 混淆方法
2.1 修改类名文件名
先说下手动操作，无非是在xcode上修改文件名类名，然后在可能引用的地方替换类名和文件名（header），要注意的地方是替换的时候要选中匹配大小写；然后是文件夹名称跟文件名一样的时候，可能文件夹名称也要跟着改名，否则替换之后路径引用可能找不到。
如果是要脚本批量操作，那最好先对工程整理下，确保以下几点能让脚本写的更简单更可靠：

要修改的类和文件最好都放到一个文件夹下，万一搞出事不用东找西找，备份和回滚也简单一点
类名和文件名尽量带上前缀，这样修改只替换前缀即可，也不太会跟函数名、变量名什么的重复
最好过一遍把不能修改类名的列出来，比如外面太多地方调用的、第三方的类库。在写脚本的时候把他们排除在外
脚本的话就是遍历文件，判断前缀、是否排除在外，修改文件名类名，在其他文件中查找替换。用python的话应该不是什么大问题。一个小技巧是改完后可以替换一下xxx.xcodeproj/project.pbxproj里的相应字符串，这样xcode打开工程的时候就不用手动再添加进来。

2.2 添加垃圾函数
OC头文件的声明必然是在@interface @end之间，实现是在@implementation @end之间，C++的大部分应该是以}结尾，直接在相应的地方插入垃圾函数，模板可以直接写个HelloWorld输出个随机字符串。在这一步随机名称是个坑，可以去网上找下常见英文单词，格式化后把太短的、太长的、看着不爽的，最重要的是语言的关键字如break,false,if之类的删掉

2.3添加垃圾类
根据我们猜测的路径应该是不影响打包的，所以我们可以简单的把垃圾类文件都放到同一个文件夹下方便管理，写好2.2后这一步应该就是顺手的事情了 。我不太确定的是如果外部不引用这些垃圾类，编译之后它们会不会因为太独立而被检测认为是垃圾代码。所以保险起见，我实现的时候写了一个单独的头文件include了所有这些生成的垃圾类，然后在外部include了这个单独的头文件

2.4修改资源md5值
资源文件有很多类型，通常来说文本文件添加随机数量的空格或空行应该就可以了。图片的话常见的png和jpg都是有固定的结尾字节块的，png是00 00 00 00 49 45 4E 44 AE 42 60 82，jpg是ffd9，用16进制查看工具打开图片应该能注意到这个规律，也可以参考下常见图片文件格式简析。在结尾字节块添加的内容是不会影响图片本身显示的，我们可以利用这个来改变图片的md5值。音效应该也有相应的格式，期待大佬科普下！

2.5创建资源垃圾文件
跟2.3类似，不过这个最好也随机下创建文件夹显得真实点，一些文本文件是什么格式都有各自定义，png和jpg的话就随机写任意长度的任意字符，最好结尾加上相应的结尾字节块，防止2.5后又执行2.4导致出错。

3. 其他事项
   上面的基本都能脚本自动化执行，完了后工程名最好也在xcode改下；info.plist会被打包进ipa，最好也多加几个字段上去；target能改也改下方便识别；scheme关联到导出的ipa文件名，不是特别麻烦也顺手改掉；包名、启动页、图标应该都是基本的东西不会被忽略。

---

一、只改了APP图标和bundleId
Guideline 4.3 - Design
This app duplicates the content and functionality of other apps submitted by you or another developer to the App Store, which is considered a form of spam.

显然已经被标定为重复APP了，机器审核应该就已经发现相似度很高了，然后当晚我打开公司APP监控，在审核这个甲方APP期间，公司的APP被打开了，显然机器审完后，人工还做了一次校验，发现两个APP几乎一样，囧。

二、加入垃圾代码和更改类名
这里我主要做的是，找一些平时练习的工程或者测试工程，把能用的全部拉拉进去，管他是啥，编译不报错就行了。
因为本身学了一些Python的基础，然后我参考网上的一些教程写了一个用Python一键更改类名前缀和后缀的脚本，这样类名也变了，我想应该差差不多了吧。
因为之前4.3了，被警告并延迟审核了，为了快速审核，我移除了那个APPID，重建一个id，这样第二天就得到审核了。然而…

Guideline 4.3 - Design …

what?! 还是一样的结果

三、新建工程，并更改资源文件MD5
这里我想到了，我原来的Project都跟之前的一样，所有配置参数都一样，这样可能比较容易被发现。于是我新建了一个项目，工程名称也用新的，然后调一调工程基础设置，还是用第二点的方式，进行处理。
同时我查到资源文件MD5也可能被苹果的机器审核进行了记录。于是想办法在不改变图片的情况下，更改文件的MD5值，于是了解到文件的二进制原理，于是做了下尝试在图片的流数据末尾混入垃圾数据，结果真的可以在不改变图片展示的情况下，成功修改了图片的MD5，同样在Python一键更改类名前缀和后缀的脚本有脚本代码，可自行更改。该做的都做了，于是又新建了个APPID重新提交。

Guideline 4.3 - Design …

我去?! 怎么还过不了

四、更改首页(假页面)、在其他IP地址下打包上传APP
查了比较多资料，看看我的工程，该做的都做了，机器审核应该发现不了了吧，莫非是我打包APP的ip地址苹果也会记录，既然如此那就，用我的手机给电脑发热点，然后打包吧。
同时，既然过了机器，那怎么过人工呢，人工肯定是肉眼来看的，那就用假页面骗骗他吧。本来我们的APP是开放的进首页点击的时候再登录的，我在后台做了个接口配置，让他在审核的时候必须先登录才能进首页，进入的首页，根据给他的账号，跳转到假页面上…差不多就这样

Guideline 2.1 - Information Needed…
This type of app has been identified as one that may violate one or more of the following App Store Review Guidelines. Specifically, these types of apps often:
1.1.6 - Include false information, features, or misleading metadata.
2.3.1 - Have hidden or undocumented features, including hidden “switches” that redirect to a gambling or lottery website
…

等等！这不是2.1大礼包吗？然而身经百战的我根本不慌，我直接回复：“我们确认，我们的APP不存在你说的任何问题”，也可以参考网上的一些2.1大礼包的回复格式。

最终，苹果审核人员第二天就妥协了，运气还不错！
仅供参考，毕竟每个APP应用场景不同

---

规避4.3的重心：

切断当前马甲包与以往马甲包的所有相似性关联；

相似性关联包括：

1. ipa包特征；

2. 开发者帐号；

3. 打包电脑；

4. 上传IP；

5. 材料相似；

分项细述：

1. ipa包特征：

包括有代码相似性，资源相似性；

代码相似性解决办法：

a. 已有代码的混淆（改类名、改函数名）

b. 添加一些无用的代码；

资源相似性解决办法：

a. 资源改名；

b. 适当添加一些无用的资源；

2. 开发者帐号：

两个马甲包不要关联到同一个开发者帐号的信息；比如打包时关联。

3. 打包电脑：

有条件的最好用不同的MAC来打包（每台MAC上最好打包马甲包不要超过5个）

4. 上传IP：

上传马甲包时，IP不要跟其他马甲包的IP相同；

5. 材料相似：

itu后台材料如宣传图，ICON，版权人不要出现相同；

【注：即使是前边没审核过的包，也不要跟他们有关联。尤其是前边被4.3拒绝的包，更不能跟他们有相似性】