隨著蘋果稽核越來越細緻，對APP管控愈發嚴格，馬甲包的上線也越來越困難。那麼，是不是曾經叱吒風雲的群狼戰術已經行不通了呢？答案是否定的！還是有很多同行，與蘋果稽核人員鬥智鬥勇，你方唱罷我登場，多點開花，馬甲齊飛，產品做得有聲有色。

這就說明這條路是可行的，而我們被拒只是我們沒有找到方法。既然確定了這一點，那麼我們要做的就是反思自己的馬甲包是否處理到位了。

一、前事不忘，後事之師

所謂失敗是成功他媽。首先，我們可以先分析下以往被蘋果拒絕的原因。目前蘋果被拒的反饋主要有4。3和2。1大禮包。

Guideline 4.3 - Design

We noticed that your app provides the same feature set as other apps submitted to the App Store； it simply varies in content or language， which is considered a form of spam。

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。0 - Undergo significant concept changes after approval

2。3。1 - Have hidden or undocumented features， including hidden “switches” that redirect to a gambling or lottery website

3。1。1 - Use payment mechanisms other than in-app purchase to unlock features or functionality in the app

4。3。0 - Are a duplicate of another app or are conspicuously similar to another app

5。2。1 - Were not submitted by the legal entity that owns and is responsible for offering any services provided by the app

5。3。4 - Do not have the necessary licensing and permissions for all the locations where the app is used

我們知道，蘋果的稽核過程主要分為：預稽核——- 掃描api，及plist檔案字元缺失等；機審——- 此處掃描支付SDK等，及馬甲情況，機器掃描主要看程式碼塊，可參考百度蜘蛛抓取網站模組原理；如遇部分無法過機審情況可嘗試加速繞過機審（不是100%成功； 人工稽核——- 此處主要檢測功能或者App體驗測試，例如用測試賬號登入App體驗功能，或其他是否明顯bug等，ipv6也在此處檢測；而通常得到這樣的反饋，是在進入稽核後，很短的時間就被拒了。這也佐證了馬甲包的稽核主要靠機器稽核。

機器稽核，主要能檢測什麼，程式碼比對？資源特徵值抓取？函式名索引？這些在以往都被大家針對性的進行了應對。網上有人總結了從時間上，複雜程度上經歷的處理過程：

1。UI不變，程式碼不變，新開發者賬戶送審

2。UI不變，程式碼混淆，新開發者賬戶送審

3。UI套殼，程式碼不變，新開發者賬戶送審，蘋果稽核看到固定頁面

4。UI套殼、程式碼混淆，新開發者賬戶送審，蘋果稽核看到固定頁面

5。UI套殼、程式碼混淆，全新類名、函式名，新開發者賬戶送審，蘋果稽核看到固定頁面

6。UI全新、程式碼重構，全新類名、函式名，新開發者賬戶送審，打包裝置、全新IP送審，等同全新產品。

但是蘋果稽核系統經過這麼長時間的學習進化，我們發現1-4都已經失效，5，6主要看程式碼處理得是否徹底以及運氣了。也就是說，簡單的程式碼混淆，函式名修改，程式碼加密，資源名字特徵值修改，改改UI已經很難逃得過蘋果稽核系統的火眼金睛了。當然，並不是說這些處理沒用了，只是它們能提升過審的機率降低了。就好像蘋果對你程式碼的重複率有一個打分機制，有一個閾值。上面的這些處理只能打50，60分，而閾值可能在70分以上。而且，按照AI的發展趨勢，稽核應該不僅僅只對程式碼層面進行檢測了，甚至還會抓取應用介面截圖進行影象對比。對比影片圖片內容網站的監黃系統，百度、谷歌圖片識別系統；這樣的技術對於蘋果來說不要太容易。

二、他山之石，可以攻玉

網上有大牛針對更嚴格的稽核機制，講解了一些處理方法，這裡整理如下：

1。換皮。換皮就不是簡單的改改UI了，而是設計全新的面板，頁面結構。重點是首頁面一定要有差異化，頁面質量要儘量精良。

2。換框架。換程式碼框架，可以是第三方類庫，也可以是蘋果的系統框架。如果實在換不了，這匯入幾個無用的框架。

3。減少

裝置、IP、開發者賬戶、聯絡人、繫結銀行卡等其他資訊的關聯。具體而言，有這些點需要注意：

開發者賬號避免處理：同一款類似的產品不放在一個送審賬號上；同一個開發者賬號儘可能不關聯幾個馬甲包產品

打包電腦裝置處理：如有條件最好不要用同樣的MAC打包，如無條件，儘可能不超過5個克隆包

上傳包IP處理：上傳克隆包IP，儘量避免與其他克隆包的IP相同

聯絡人、收款銀行卡資訊處理：過多克隆包，儘量避免同一銀行卡資訊、聯絡人關聯

技術網站、隱私協議用獨立域名處理：如果有條件，儘可能使用一個獨立的域名，技術網站儘可能複雜點，有產品資訊，有聯絡資訊，有公司資訊等等。以往，做馬甲包時候，經常使用類似上線了的工具搭建官網。

App內關於產品能直接訪問技術網站官網，在官網上能找到隱私協議等，雖然不知道會不會影響，作假作全套。

4。有很多加固混淆的工具聲稱可以提高過包率（他們也不敢打包票說一定可以過）。分析他們的處理方式，主要包括：專案程式碼的自動翻新（混淆）、支援資料夾名稱、檔名、修改資原始檔hash值、類名、方法名、屬性名、新增混淆函式方法體、新增混淆屬性、自動呼叫生成的混淆方法、字串混淆加密等。他們的功能邏輯圖可以參考下：

三、實踐是檢驗真理的唯一標準

前面對以往的失敗經歷進行了總結，也在網上搜集了很多更嚴格的處理方式。最後我們制定具體的實施條例來進行檢驗。

1。UI設計層面：設計全新的UI，特別是注意主頁的差異性以及精緻度，能用蘋果的新功能新特性就儘量用

2。程式碼層面：

修改資料夾名稱、資料夾的結構、檔名；修改資原始檔hash值、類名、方法名、屬性名；

新增混淆函式方法體、新增混淆屬性、自動呼叫生成的混淆方法、字串混淆加密（最佳化現有的指令碼處理，新增這些自動化處理功能）；

如果某個檔案程式碼量比較大，就需要多去修改裡面的方法名，變數名，以及順序；

國際化的宏，通知的宏，打包的宏，廣告宏，Key值宏，靜態字串全部進行修改；

換程式碼框架，可以是第三方類庫，也可以是蘋果的系統框架。如果實在換不了，則匯入幾個無用的框架（3個蘋果框架，3個第三方類庫）。

3。垃圾程式碼：

新增垃圾程式碼，垃圾程式碼量佔總程式碼的30% - 40%（垃圾程式碼生成指令碼，增加隨機性，降低其自身的重複率，也要注意不同馬甲包之間垃圾程式碼的重複率）

加減程式碼註釋（最佳化現有指令碼）

4。伺服器層面：

技術網站、隱私協議用獨立域名處理；

域名修改

5。賬號，證書，打包等方面：

申請證書時使用不同電腦

申請證書時新增不同測試裝置

登入賬號的IP和傳包的IP保持一致

有條件最好不要用同樣的MAC打包，如無條件，儘可能不超過5個克隆包

上傳克隆包IP，儘量避免與其他克隆包的IP相同

6。如果前面的方式還不能透過稽核，則可以逐步嘗試下面的方式：

程式碼加密混淆（稽核時可能需要勾選加密選項）

https：//

github。com/chenxiancai/

STCObfuscator

採用swift重寫工程（暫不考慮，時間成本太高）

伺服器介面名修改

收費工具：

https：//

zfj1128。blog。csdn。net/a

rticle/details/95482006

（傳說透過率挺高）

四、寫在最後

不要迷信蘋果，不要自我懷疑。上架 App 是商業行為，App Store 拒絕你上架不能說明任何問題。蘋果公司能力極強，但是 App Store 的稽核團隊並不神聖。

不服就幹，App Store 讓你上架，你就是合理的；App Store 不讓你上架，說明你能力不夠，搞贏 4。3 條款，你就是贏家，千萬不要因為被拒就覺得問題出在你自身，上有政策，下就有對策。