建站
咨詢
售后
建站咨詢
新聞中心
本文轉(zhuǎn)載自微信公眾號(hào)「鹵蛋實(shí)驗(yàn)室」，作者鹵代烴 。轉(zhuǎn)載本文請(qǐng)聯(lián)系鹵蛋實(shí)驗(yàn)室公眾號(hào)。
前段時(shí)間我們公司的一個(gè)大佬從一些渠道得知了一些小道消息，某國(guó)民級(jí) APP 因?yàn)?apple App Store 審核人員檢測(cè)出 React Native 熱更新的內(nèi)容，被拒審了三個(gè)月。我們的熱更新平臺(tái)和出事的 APP 原理相似，所以也存在著拒審危險(xiǎn)。那么我們就要想一些辦法，隱藏?zé)岣?Bundle，不被審核人員發(fā)現(xiàn)。
其實(shí)這個(gè)問(wèn)題蠻復(fù)雜的，因?yàn)樗粏渭兪且粋€(gè)技術(shù)問(wèn)題，還涉及到各種復(fù)雜的商業(yè)利益，在諸多的限制條件下，你很難去找到一個(gè)最優(yōu)解。而且這個(gè)問(wèn)題也比較敏感，我也只能大致講一下我的思路，具體的代碼實(shí)現(xiàn)本文也不會(huì)提供。
鄭重聲明：若有人按本文思路隱藏?zé)岣聰?shù)據(jù)導(dǎo)致應(yīng)用拒審或下架，本人概不負(fù)責(zé)
一、商業(yè)利益
Apple 公司對(duì) iPhone 生態(tài)有著非常嚴(yán)格的管控：App 上架必須走 App Store，動(dòng)態(tài)鏈接庫(kù)要參與簽名，帶 JIT 功能的虛擬機(jī)不能用......
對(duì)于熱更新技術(shù)，Apple 在 2017 年封殺過(guò)一次 JSPatch[1] 這個(gè)熱更新框架，導(dǎo)致很多的 APP 被拒審，根據(jù) Apple 官方給出的理由，主要有三點(diǎn)：
- 熱更新代碼沒(méi)有做好加密和校驗(yàn)，有可能被第三方破解劫持
- JSPatch 權(quán)限過(guò)高，可能會(huì)調(diào)用私有 API，改變?cè)械?APP 功能
- 對(duì)于 Apple 官方來(lái)說(shuō)，JSPatch 自由度太大，會(huì)繞過(guò) App Store 這個(gè) iOS 上的唯一流量分發(fā)平臺(tái)更新應(yīng)用，影響商業(yè)利益
俗話說(shuō)得好，斷人財(cái)路如殺人父母，這種涉及商業(yè)利益的事情無(wú)論放在誰(shuí)都頭上都忍不了，而且很多應(yīng)用又不是微信，有龐大的用戶基數(shù)可以和 Apple 官方談判(微信小程序生態(tài)就是談出來(lái)的，但是小程序支付權(quán)限就沒(méi)談妥)，所以說(shuō)這個(gè)問(wèn)題還是很復(fù)雜的。
其實(shí)對(duì)于 Apple 官方來(lái)說(shuō)，對(duì)與動(dòng)態(tài)化熱更新的態(tài)度向來(lái)是不贊成也不反對(duì)，和 JSPatch 比起來(lái)，React Native 和游戲熱更新這兩種應(yīng)用場(chǎng)景還是被允許的，主要還是體現(xiàn)在三點(diǎn)：
- 網(wǎng)游這種重運(yùn)營(yíng)的場(chǎng)景還是需要熱更新維持活動(dòng)熱度的，每周都有新活動(dòng)，讓用戶主動(dòng)去 App Store 下載更新包很不合理，App 活動(dòng)運(yùn)營(yíng)同理
- React Native/Lua 等熱更新技術(shù)是在一個(gè)容器里進(jìn)行動(dòng)態(tài)化的，不像 JSPatch 有那么大的修改權(quán)限
- 蘋(píng)果官方在商業(yè)利益上和游戲廠商/互聯(lián)網(wǎng)巨頭達(dá)到一些微妙的平衡
說(shuō)實(shí)話蘋(píng)果審核一直很迷，拒審有時(shí)候和打太極一樣，給出的規(guī)范各路解讀都不一樣，不過(guò)為了保險(xiǎn)起見(jiàn)，我們還是要研究一下相關(guān)的平臺(tái)規(guī)范。
二、解讀規(guī)范
2015 年蘋(píng)果發(fā)過(guò)一篇協(xié)議——《Apple Developer Program License Agreement》[2]，文中第 3.3.2 節(jié)有一段關(guān)于熱更新的內(nèi)容：
Except as set forth in the next paragraph, an Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exceptions to the foregoing are scripts and code downloaded and run by Apple's built-in WebKit framework or JavascriptCore, provided that such scripts and code do not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store.
這一段話大概就是說(shuō)除了 Webkit 和 JavascriptCore 可以動(dòng)態(tài)執(zhí)行下發(fā)的腳本和文件，其它所有腳本/代碼/解釋器都必須打包在 APP 內(nèi)部。這句話其實(shí)就給 React Native 留了一個(gè)口子：React Native 就是用 JavascriptCore 執(zhí)行 JS 腳本文件的，那么動(dòng)態(tài)下發(fā)也是合理的。
Interpreted code may be downloaded to an Application but only so long as such code: (a) does not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store, (b) does not create a store or storefront for other code or applications, and (c) does not bypass signing, sandbox, or other security features of the OS.
這一段話大概就是說(shuō)，我允許你熱更新，但是必須遵循我這三條規(guī)定：
- 不能大的修改 APP 功能，導(dǎo)致應(yīng)用實(shí)際功能和 APP Store 的宣傳不符(這個(gè)地方就很打太極，評(píng)判標(biāo)準(zhǔn)全靠審核人員心情)
- 不能動(dòng)態(tài)創(chuàng)建應(yīng)用商店(應(yīng)該是不能繞過(guò) IAP 支付的意思，要不然怎么收蘋(píng)果稅)
- 不能繞過(guò)簽名/沙箱/OS 的安全功能(這個(gè)可以理解，維護(hù)系統(tǒng)和生態(tài)安全)
這樣解讀下來(lái)，貌似只要按照規(guī)范當(dāng)個(gè)良民就可以解決問(wèn)題了。但是說(shuō)實(shí)話，動(dòng)態(tài)化規(guī)范更多的是君子協(xié)議，如果雙方都講武德，那大家其樂(lè)融融都挺好;萬(wàn)一哪個(gè)人跳出來(lái)要壞規(guī)矩，說(shuō)實(shí)話大家都很難堪。在未來(lái)，熱更新技術(shù)肯定還是要以微妙的平衡狀態(tài)存在下去。
三、技術(shù)實(shí)現(xiàn)
每次設(shè)計(jì)一些工程方案時(shí)，我個(gè)人的習(xí)慣都是先從理論上找答案。就拿隱藏?zé)岣?bundle 這個(gè)例子來(lái)說(shuō)，我們主要是想在信息傳輸這里找到突破口，實(shí)際上香農(nóng)老爺子 1949 年就提出了一個(gè)「香農(nóng)一韋弗通信模型[3]」。這個(gè)模型里把通信分為五個(gè)部分：信息源、發(fā)射器、信道、接收器、信息接受者 和 噪音。
香農(nóng)一韋弗通信模型
那么結(jié)合這個(gè)通信模型，我們隱藏/加密通訊信息的答案就呼之欲出了：
- 對(duì)信源加密：在信息的收發(fā)終端發(fā)送消息時(shí)加密，接受消息時(shí)解密
- 對(duì)信道加密：信息在信道傳輸時(shí)，經(jīng)過(guò)信道時(shí)進(jìn)行加密
那么我們下面就對(duì)這兩個(gè)大方向進(jìn)行擴(kuò)展和探討。
1.對(duì)消息本身加密/混淆
1.1 隱寫(xiě)術(shù)——當(dāng)代特洛伊木馬
隱寫(xiě)術(shù)是一個(gè)非常非常古老的技術(shù)，這個(gè)技術(shù)的關(guān)鍵就是把想要傳遞的數(shù)據(jù)隱藏/偽裝一下，不讓第三方看出來(lái)真實(shí)想要傳遞的數(shù)據(jù)。
隱寫(xiě)術(shù)的例子非常多，比如說(shuō)特洛伊木馬，你從外面看是個(gè)木馬，但運(yùn)到城里，士兵就跑出來(lái)了;我們看的一些影視劇里，也有類(lèi)似原理的橋段：主角收到一份無(wú)字信紙，在蠟燭上一烤，文字就顯現(xiàn)出來(lái)。如今的數(shù)字時(shí)代肯定不會(huì)用無(wú)字信紙秘密傳遞消息，我們肯定有些更加賽博的方法，比如說(shuō)圖種技術(shù)——把消息隱寫(xiě)到圖片文件里。
如果大家玩過(guò)一段時(shí)間貼吧，對(duì)圖種技術(shù)肯定不會(huì)陌生，有些大神會(huì)發(fā)個(gè)貼，把種子文件隱藏在圖片里，大家把圖片下載下來(lái)，把 .jpg 的后綴改為 .zip or .rar，然后解壓文件就能得到隱藏的種子文件，然后在貼吧留下「樓主好人」的美譽(yù)。
那么圖種技術(shù)的原理是啥?其實(shí)很簡(jiǎn)單，它只是單純的把一個(gè) jpg 文件和一個(gè) rar 文件合并在一起，但是圖片查看器會(huì)忽略附加的 rar 文件數(shù)據(jù)，這樣在感官上這是一張圖片，但是從二進(jìn)制的角度看這個(gè)圖片文件里隱藏了一些數(shù)據(jù)。
下面我們看看圖種文件的原理。
首先我用圖片編輯器生成一個(gè) 2x2 4 個(gè)像素大小的圖片——RGBY.jpg。顏色我參考 Google logo 配了一下：
RGBY-image
然后我們用二進(jìn)制查看工具(我這里用的是 Hex Fiend 軟件)查看這個(gè)圖片的編碼，因?yàn)閳D片只有 4 個(gè)像素，所以二進(jìn)制數(shù)據(jù)也會(huì)比較小，注意觀察這個(gè)文件的二進(jìn)制數(shù)據(jù)，它是 FF D8 開(kāi)頭，F(xiàn)F D9 結(jié)尾的。
圖片查看器加載一張圖片文件時(shí)就會(huì)做檢測(cè)，如果是 FF D8 開(kāi)頭，就會(huì)認(rèn)為這是一張 jpg 圖片，然后就會(huì)進(jìn)入 jpg 圖片解碼的分支，加載二進(jìn)制數(shù)據(jù)遇到 FF D9 后，就會(huì)認(rèn)為這個(gè)圖片已經(jīng)加載完畢，后面的數(shù)據(jù)就不會(huì)再管了。
RGBY-Binary-Code
基于圖片預(yù)覽器不會(huì)加載 FF D9 之后數(shù)據(jù)的這個(gè)特性，我們可以把一些要隱藏的數(shù)據(jù)附加到 jpg 文件之后。
這里為了測(cè)試方便，我新建了一個(gè)內(nèi)容為 hello word 的 text.txt 文件，然后用 cat 命令把 RGBY.jpg 和 text.txt 合并一下，生成 RGBY_text.jpg 文件：
- cat RGBY.jpg text.txt > RGBY_text.jpg
這時(shí)候用圖片瀏覽器查看文件，可以看出文件還是正常預(yù)覽的：
RGBY_text-image
但是用二進(jìn)制查看工具查看這張圖片，就會(huì)發(fā)現(xiàn)他在末尾多了 11 個(gè)字節(jié)，正是 text.txt 里的內(nèi)容—— hello word ：
RGBY_text-Binary-Code
這樣我們就達(dá)到了隱寫(xiě)的目的。
大家不要覺(jué)得這個(gè)方案 low，實(shí)際上阿里的一些密鑰就是通過(guò)類(lèi)似的原理寫(xiě)到一張圖片里的(當(dāng)然不會(huì)像以上案例那么簡(jiǎn)單)。我們?cè)趥鬏敓岣?bundle 文件時(shí)，可以把 bundle 文件隱寫(xiě)在一張圖片里，這樣審核人員在做流量監(jiān)控的時(shí)候，抓包看到的是一張圖片，如果不檢查圖片的二進(jìn)制編碼，是不會(huì)發(fā)現(xiàn)里面隱藏了數(shù)據(jù)的。
針對(duì)這種方案，服務(wù)端和客戶端的改動(dòng)都比較小，服務(wù)端只需要每次下發(fā) bundle 時(shí)前合并一個(gè)圖片文件，客戶端讀取隱寫(xiě)圖片后去掉多余的圖片數(shù)據(jù)就可以了。
當(dāng)然隱寫(xiě)術(shù)還有很多種，比如說(shuō)基于 LSB 的圖片隱寫(xiě)技術(shù)，把數(shù)據(jù)寫(xiě)在 jpg png mp4 的擴(kuò)充數(shù)據(jù)字段里，因?yàn)樵泶笸‘?，這里就不多介紹了，感興趣的同學(xué)可以自行搜索學(xué)習(xí)。
1.2 對(duì)稱(chēng)加密
對(duì)稱(chēng)加密也是一個(gè)歷史悠久的加密技術(shù)，在信息技術(shù)的加持了下也飛速發(fā)展，我舉個(gè)最簡(jiǎn)單的對(duì)稱(chēng)加密算法——異或算法加密。
異或運(yùn)算我想每一個(gè)程序員都不陌生，我們先約定 0 為 false， 1 為 true，那么 XOR 運(yùn)算的真值表如下：
| A | B | A ⊕ B |
|---|---|---|
| 0 | 0 | 0 |
| 0 | 1 | 1 |
| 1 | 0 | 1 |
| 1 | 1 | 0 |
從真值表可以很容易推出下面的運(yùn)算法則：
- // 加密：
- // 原文 密鑰 秘文
- 01010111 ^ 11110011 = 10100100
- // 解密：
- // 秘文 密鑰 原文
- 10100100 ^ 11110011 = 01010111
眾所周知，位運(yùn)算都是非?？斓?，如果要簡(jiǎn)單地對(duì) bundle 做個(gè)混淆，直接用異或加密，基本上不會(huì)影響性能。
雖然異或運(yùn)算很簡(jiǎn)單，但是密碼學(xué)有個(gè)第一準(zhǔn)則：永遠(yuǎn)不要自己實(shí)現(xiàn)加密算法。我們可以用已經(jīng)非常成熟的對(duì)稱(chēng)加密算法(例如 AES 和 DES)對(duì) bundle 進(jìn)行加密：性能高，安全性好，最重要的是開(kāi)源社區(qū)都有現(xiàn)成的庫(kù)，直接調(diào)包就可以了。
所以如果用對(duì)稱(chēng)加密的方案，只要服務(wù)端和客戶端商量好一個(gè)密鑰，然后服務(wù)端用密鑰加密 bundle，客戶端用同一個(gè)密鑰解密，就能在一定程度上繞過(guò) App Store 的異常流量檢測(cè)。
1.3 非對(duì)稱(chēng)加密
非對(duì)稱(chēng)加密是屬于近代密碼學(xué)的內(nèi)容了，非常的新，但是也非常的可靠，具體原理太復(fù)雜了，一句兩句根本說(shuō)不清楚，我就不做介紹了。
在加密熱更新 bundle 這個(gè)場(chǎng)景下，其實(shí)和對(duì)稱(chēng)加密的效果差不多，只不過(guò)換成私鑰加密公鑰解密了。
1.4 總結(jié)
一般來(lái)說(shuō)，對(duì) bundle 加密不會(huì)單純使用一種技術(shù)，比如說(shuō)我們會(huì)用混合加密的方式對(duì) bundle 本身加密，用消息認(rèn)證碼(例如 HMAC)防篡改，加入時(shí)間戳隨機(jī)數(shù)防重放，最后再把加密后的數(shù)據(jù)進(jìn)行隱寫(xiě)......這里面的組合實(shí)在是太多了，個(gè)人認(rèn)為參考一些經(jīng)典的加密組合進(jìn)行業(yè)務(wù)實(shí)踐即可。
2.對(duì)信道加密
信道加密在本文的場(chǎng)景下也比較直觀，就是使用 HTTPS 協(xié)議，目的就是防止審核人員通過(guò)抓包的方式捕獲到我們的熱更新流量。當(dāng)然 HTTPS 也有很多的有意思的知識(shí)點(diǎn)，下面我就簡(jiǎn)單介紹一下。
2.1 使用 HTTPS
2021 年了，我想互聯(lián)網(wǎng)上基本沒(méi)有裸露的 HTTP 明文流量了吧......前幾年可能還會(huì)有企業(yè)考慮 HTTPS 加密帶來(lái)的服務(wù)器成本，但在各大平臺(tái)(iOS/Android/Chrome)的要求下，除了個(gè)別無(wú)人維護(hù)的網(wǎng)站，基本都全站上 HTTPS 了，畢竟現(xiàn)在數(shù)據(jù)的價(jià)值遠(yuǎn)遠(yuǎn)高于服務(wù)端的電費(fèi)，上了 HTTPS 后，起碼被中間人攻擊被劫持的概率會(huì)降低不少。
上 HTTPS 就高枕無(wú)憂了嗎?那肯定不是。我去年寫(xiě)過(guò)一篇 Charles 抓包的文章，里面花了大量的篇幅去介紹 HTTPS 抓包。既然一個(gè) APP 開(kāi)發(fā)者可以借助市場(chǎng)上的工具進(jìn)行抓包，那么審核人員更可以了。在抓包工具下，大部分 HTTPS 數(shù)據(jù)都可以被捕獲和劫持。下面我們就說(shuō)說(shuō) HTTPS 協(xié)議中一些比較高階的內(nèi)容。
2.2 HTTPS 證書(shū)固定
HTTPS 證書(shū)固定，又叫 HTTPS 證書(shū)鎖定，英文名為 Certificate Pinning，指的是我們?cè)?APP 內(nèi)置僅接受指定域名的證書(shū)，而不接受操作系統(tǒng)或?yàn)g覽器內(nèi)置的CA根證書(shū)對(duì)應(yīng)的任何證書(shū)。
通過(guò)這種授權(quán)方式，我們可以保障 APP 與服務(wù)端通信的唯一性和安全性。如果開(kāi)啟了抓包軟件，不主動(dòng)導(dǎo)入固定的證書(shū)，就無(wú)法有效的抓包(具體原理可看我的博文：Charles 抓包原理)。我想審核人員還沒(méi)那個(gè)精力去砸殼你的 APP 獲取你的證書(shū)，所以可以通過(guò)這種方式隱藏你的熱更新 bundle。
當(dāng)然，證書(shū)固定也是有一定代價(jià)的。CA 簽發(fā)證書(shū)都存在有效期問(wèn)題，所以缺點(diǎn)是在證書(shū)續(xù)期后需要將證書(shū)重新內(nèi)置到 APP 中。
2.3 HTTPS 雙向認(rèn)證
我們平常使用 HTTPS 時(shí)，一般只做了單向認(rèn)證，即客戶端認(rèn)證服務(wù)端的真實(shí)性。其實(shí) HTTPS 支持雙向認(rèn)證的，即支持服務(wù)端認(rèn)證客戶端的真實(shí)性(具體流程可見(jiàn)下圖 * 部分)。
TLS 1.2 握手流程圖
一般來(lái)說(shuō)開(kāi)啟 HTTPS 雙向認(rèn)證的 APP 都是那種安全性要求極高的 APP，比如說(shuō)金融類(lèi) APP 和匿名社交類(lèi) APP。而且想要實(shí)現(xiàn)雙向認(rèn)證，就必須要在客戶端內(nèi)置一份公鑰證書(shū)和私鑰，但 APP 又有砸殼風(fēng)險(xiǎn)，所以還得想辦法把這兩個(gè)東西加密和隱寫(xiě)(都成俄羅斯套娃了)。
綜合來(lái)看，實(shí)現(xiàn) HTTPS 雙向認(rèn)證的成本還是很高的，但是一旦實(shí)現(xiàn)，安全系數(shù)還是非常高的，不僅僅是繞過(guò)審核人員的流量檢測(cè)，綜合來(lái)看整個(gè) APP 的網(wǎng)絡(luò)安全都得到了極大的防護(hù)。
四、總結(jié)
對(duì)于熱更新這件事，根據(jù) Apple 的應(yīng)用規(guī)范，基于 JavaScriptCore 的熱更新是完全可行的，但前提是你必須守規(guī)矩，不能脫離 Apple 的掌控范圍;但是 App Store 的審核規(guī)則又極其不透明，雖然我們是良民，但是一定程度上還是要隱藏一下熱更新 bundle，規(guī)避不必要的麻煩;隱藏?zé)岣?bundle 我們可以從信源加密和信道加密兩個(gè)角度去思考，綜合來(lái)看就是靈活利用密碼學(xué)知識(shí)，對(duì)網(wǎng)絡(luò)數(shù)據(jù)進(jìn)行加密，防止被檢測(cè)出異常流量，隱藏 bundle 的同時(shí)，也保護(hù)了用戶的數(shù)據(jù)安全，降低被攻擊的可能性。
五、參考閱讀 為什么你的 Charles 會(huì)抓包失敗?
分享文章：如何隱藏你的熱更新 Bundle 文件？
文章網(wǎng)址：http://m.5511xx.com/article/cogiiep.html
