ios馬甲包代碼混淆

1. 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數值。

實際測試如下

小結

目前第三次打回後的工程已經提審，未可知能否過審，會持續更新。腳本也寫的很匆忙，後期會進行優化。腳本傳送門

www.it9188.com

2. 馬甲包需要源碼嗎

不需要的。現在蘋果App store審核越來越嚴格，越來越多的馬甲APP 馬甲包要上架。很多APP因為需要做引流操作，需要做榜單，刷詞什麼，需要把APP重復以另外一個名字上架容易被拒4.3條款。
要解決上架被拒審4.3問題參如下方式：第一種 改源碼改UI等等修改浮度較大的操作， 這種選擇很多軟體公司可能不願意選，因為修改大，還可能影響原有的產品計劃功能，修改時間周期長，還不確定修改後能否解決問題，影響上架時間。不管從成本 還是從時間上都是一種無奈。
第二種 使用混淆加密工具，進行代碼混淆
這種方式相比第一種方式，大家相對樂意點。只需要使用合適的工具，即可處理掉煩人的4.3問題。目前市面上的混淆工具效果基本上都差強人意吧。價格不菲，單價一般在1.2W+ ，貴的一般到4W+ 按次數計算，而且不保證能過審，讓你自己准備多賬號多提審。他們這種方其實就是提供混淆工具給你，自己混淆後打包提審。好處是 ：不需要提源碼。保密性較高，時效性相對掌控，費用便宜。 缺點就是：過審率相對低點，人審這關不好過。

3. (1) 親愛的開發者，您提交審核的apk文件中，由於出現代碼混淆、加殼的原因

相反，這是對用戶負責，如果代碼混淆、加殼，那麼裡麵包含一些後台強制安裝的代碼，彈廣告代碼等都無法檢查，可能會對用戶造成不必要的隱私泄露或安全風險。
直接就能通過的，是對用戶的不負責。

4. 應用在蘋果App Store 怎麼上架以及審批

iOS APP上架App Store流程：

1、注冊開發者賬號

開發者賬號分為三種，分別是個人開發者賬號，公司開發者賬號，和企業開發者賬號。

2、創建APP ID、配置文件Profiles

創建APP ID，APP ID非常重要，上架流程就是用APP ID關聯在一起的。

3、創建iOS發布證書

創建iOS發布證書，下載P12證書文件。

4、打包ipa

利用iOS證書打包ipa，可以使用HBuilder工具打包。

5、iTunes connect創建APP

進入iTunes connect，選擇創建APP，輸入應用名稱、語言、套裝ID等，創建APP。

6、上傳ipa

APP uploader程序中，提交ipa文件。

7、填寫APP信息提交審核

iTunes connect中在我的APP中填寫APP的各項信息，提交審核，等待通過即可。

App Store審核比較嚴格，其實可以藉助蘋果簽名，這樣就可以不經過App Store，直接在蘋果手機上安裝了。

搜索微導流，點擊企業簽名，上傳自己的ipa文件，就可以完成在線簽名了。

5. 跪求：馬甲包上架技術，ios 代碼混淆 馬甲包過審技術！！！

從收集今年每月審核被拒原因得來的大量數據中可以看出，被拒原因 TOP3：條款 2.3、2.1、4.3（元數據、App 的完成度、重復 App/馬甲包）一直是穩定的居高不下，因此開發者們一定要遵守這三條條款，以增加過審幾率、節省與蘋果糾纏的時間，勿要存在僥幸心理，挑戰蘋果。

若想通過審核，除遵守上面幾項條款以外，在4.3問題上主要是改變二進制代碼，如果是同一個包（馬甲包）想要改變二進制代碼而對功能又沒有任何改變，可以使用幾維安全提供的安全編譯器，利用混淆的技術來改變二進制文件。

幫助過審的同時，還能利用IOS開發子團隊開發的包過審馬甲包加密混淆編譯器可安全編譯C、C++、Objective-C、Swift代碼，支持安卓 NDK和iOS馬甲包項目

支持iOS項目［APP、動態庫、靜態庫］和安卓NDK項目［SO動態庫、靜態庫］!

6. ios馬甲包怎麼上架

審核速度變慢

最近，蘋果審核團隊一度讓人以為進入樹懶狀態，應用相當長時間內處於「正在審核狀態」（in Review），很多小夥伴依舊寄託蘋果工作忙後面會處理的美好願景，事實並非如此。很多產品處於正在審核狀態長達一個月也並未進展，後面只能悲慘刪除應用重新提交。不排除有包等了兩個月才審的。對於蘋果為何沒有審核產品，個人分析認為是蘋果對於馬甲包過多的一種「冷藏」方式。簡單說，就是讓你的馬甲包一直處於正在審核狀態不予以後續任何干預。即使給蘋果寫郵件，或者在「Connect US」進行觸發，都是無濟於事。

團隊上家的五個App近期也中招了

7. 如何解決馬甲包審核問題

iOS審核大體分為三部分，預審、機審和人工審核。
從最新的數據反饋得出，審核被拒原因TOP5條款有：2.1 App 完成度、2.3 准確的元數據、3.2.1 可接受的商業模式、4.3 馬甲包、5.1.1 數據收集和存儲。
開發者一定要遵守上述條款，增加過審幾率。尤其是在4.3馬甲包條款上可以利用第三方的代碼混淆工具來完成，改變同一個馬甲包的代碼而對功能又沒有改變，大大降低開發時間。可以使用頂象的iOS代碼編譯器，利用iOS代碼混淆技術來改變二進制文件。

8. iOS馬甲包審核被拒如何過審

4.3一般存在3種情況，可以根據被拒回復進行判斷，如果你真的看不懂被拒回復，下面一一列舉，逐一排除，黑色字體是解決方案
第一種：簡稱代碼重復，代碼重復使用也有三種情況
1.可能你之前用這套源碼上過一個包，現在用這套代碼直接改一個logo跟名字再上一個馬甲，這種基本會直接4.3
這種情況基本要改源碼，第一步：工程中的文件夾的名字全部進行修改。第二步：每一個工程都有一個類前綴, 我們需要取一個長一點的類前綴, 並且這個類前綴在你的整個工程一定是一個唯一的字元串, 我們假設這個類前綴是PayDayLoan, 現在我們需要生成一個控制器, 控制器的結尾Controller也需要用一個特定的字元去代替, 比如:Director,剩下的View以及object做法類似, 就不一一介紹了,做馬甲的時候就是把這些名字用另一個唯一的字元去代替, 盡量長一點。第三步：把另一個其他的工程中的類全部導入進來, 主要是混淆代碼, 在現有的工程中調用, 可以沒有任何效果, 只是單純調用方法。
註：單一的加入垃圾代碼混淆沒用的！
2.如果你的這套源碼在一個賬號上提交過，但是被拒了，後來因為其他原因你不得不在別的賬號上重新提交此源碼，這種情況第二個賬號基本也會報4.3
這種情況需要在第一個賬號做一下處理, xcode新建一個應用, 直接用之前提交過的bundle Id打包，logo用一個純白或者純黑的圖片, 將這個新建的應用提交到應用市場, 構建版本中將之前被拒的包移除, 用這個新的應用頂替之前被拒的包, app名字改成 「作廢-此應用不再提交」 後面再隨便加一個數次, 因為這個名字別人已經用過了, app描述跟app名字一樣, 剩下的信息全部刪除.最後點擊保存即可．不需要提交審核。
3.你的源碼只要提交到itunes connect裡面，就算沒提交審核，當你再次使用此源碼提交審核的時候，基本都會報4.3
這種情況的解決方案參照2
第二種，界面功能相似
這種情況簡單的改源碼已經沒用了，需要在原有的app上加一些不同的功能，我用借貸類舉例說明該如何解決，其他類型的app可以參考
以下舉兩個應用說明, 分別用A應用與B應用代替, 你需要如何處理並且如何回復審核人員
1.A應用 是給沒有信用卡的用戶使用的一款借款App，B應用 是給有信用卡的用戶使用的一款借款App.2.A應用的最高借款額度是1000元, B應用 的最高借款額度是25000元.3.A應用的還款時間是7天與14天, B應用 的還款時間是28天. 4.A應用 內部有貸款計算器功能, B應用只是一個普通的貸款app, 並無其他功能5.兩款app是我們公司內不同的部門開發的app, 分別針對不同的用戶人群.
第三種，app名字被用過
這一種，可能是最容易被忽略的，取名字之前一定要先搜索app store有沒有同名應用，盡量避免同名應用