author:[email protected]

0x00 “Hotpatch”簡介

---

IOS App的開發者們經常會出現這類問題：當一個新版本上線後發現存在一個嚴重的bug，有可能因為一個邏輯問題導致支付介面存在被薅羊毛的風險，這個時候能做的只能是趕快修復完安全問題並提交到appstore稽核，在急忙推送使用者儘快更新，避免為此導致的嚴重安全後果買單。為了解決此類問題遍有了實現給App應用”實時打補丁”這類方案，目前大致有兩種主流的“熱修復”的專案。

根據基本原理可以分為下面兩種，

原理同為構建JS指令碼與Object-C語言之間轉換的橋樑。

1. WaxPatch(Lua呼叫OC)

2. JSPatch(Javascript呼叫OC)

”熱修復” 技術雖然極大的減少了開發者更新補丁的時間與商業成本，但卻將Apple努力構建的安全生態系統——Apple Store對上架App的嚴格審查規則置於高風險下。透過這種技術可以在上線以後直接更新App原生程式碼，從而從某種意義上繞過了Apple Store的審查規則。

0x01 原理分析

---

這種手段是透過IOS內建的JavaScriptCore.framework 微型框架來實現的，它是Apple官方在IOS7以後推出的主要是用來提供一個在Objective-C中執行Javascript環境的一個框架。

JSPatch並沒有使用JSExport協議與OC程式碼進行互調，而是使用了JSBinding(Javascript與OC程式碼互動的介面)與Objective-C中的runtime(執行時)，採用了JavaScriptCore.framework框架作為解析javascript的引擎，與客戶端的程式碼實時互動動態修改OC方法的一種方案。

對客戶端整個物件的轉換流程如下：

使用JavaScriptCore.framework作為Javascript引擎解析JavaScript指令碼，執行JavaSript程式碼並與Objective-C端的程式碼進行橋接。另一方面則是使用Objective-C runtime中的method swizzling的方式和ForwardInvocation訊息轉發機制使得在JavaScript指令碼中可以呼叫任意Objective-C方法。

總的執行過程：

Javascript-> JavaScriptCore Framework-> Objective-C->runtime->動態修改IMP

(更像與Android的Webview程式碼執行？)

下圖展示了在客戶端程式碼中如何嵌入JSPatch。

在此之後客戶端每次啟動時都會下載請求這段js指令碼來更新客戶端程式碼。

0x02 存在的安全隱患

---

JSPatch的確給IOS開發者們帶來了很多好處，但是這麼高的許可權如果使用不當往往會有惡意使用者會用它來做一些壞事。

可以預見的風險主要來自以下方面：

一 傳輸過程安全問題

服務端在下發JS的更新補丁時如果傳輸過程中如果沒有使用Https或者對Https的證照未做嚴格校驗，又或者沒有做資料防篡改的方案，更新的補丁在傳輸過程中被惡意攻擊者劫持篡改了傳輸補丁資料，就可以導致非常大的危害，比如命令執行什麼的。。

實踐出真知，由於沒有找到合適的App做演示，我們使用虛擬機器做跳板機來簡單搭建一箇中間人的場景：

虛擬機器ip: 10.180.145.17 這臺機器充當中間人的角色。

本機搭建一個簡單的伺服器，用於App的更新指令碼伺服器，用於下發jspatch指令碼。

在測試App中的Object-C加入要更新補丁的url(嵌入到JPEngine中)：

url:http://10.180.144.1:8081/static/js/test.js

這段js補丁本來是要在螢幕列印222 這幾個數字,但是App在更新補丁時並沒有使用Https安全傳輸，也沒有對傳輸資料進行防篡改，如以下幾種場景：

1. 傳輸過程沒有使用Https

2. 傳輸過程使用了Https，但是對Https的證照沒有做正確校驗。

3. 傳輸過程沒有使用Https，也沒有對資料做防篡改。

整個傳輸過程是明文可見的:

載入補丁後正常顯示：

之後我們新建一個下發的更新補丁：

Apple預設是不允許呼叫私有api的(在App上線時會經過App Store的審查)，但是在使用了JSPatch引擎後，可以直接呼叫私有的Api來獲取裝置私密資訊。

這裡載入了一個Accounts.framework, 用來獲取裝置中的帳號資訊。

替換遠端載入的Js：

之後成功利用JSPatch更新了客戶端的程式碼，讀取出裝置的帳號資訊:46個

46個帳號被顯示在App中。

此外還有很多private frameworks 可以拿來呼叫，當然這隻適合越獄手機了，這種許可權是很可怕的。

二 惡意的第三方SDK

同傳輸過程安全一樣，第三方的SDK極大的擴充套件了App的功能，但是不能保證這些SDK的開發者不存在惡意的開發者，惡意的SDK可以利用JSPatch下發惡意指令碼，利用App的許可權竊取敏感資料或者對系統做一些敏感操作。

三 本地篡改下載更新的javascript指令碼

如果下載到了本地更新指令碼沒有做加密，透過篡改本地的更新補丁，可以修改為執行任意OC程式碼的js指令碼，同樣可以執行任意程式碼。

0x03 其他面臨的風險

---

補丁傳輸安全

在使用JSPatch時一定要注意傳輸過程的安全，使用Https傳輸，或使用作者推薦的RSA檢查下發的JS補丁，或者使用作者提供的Loader。

第三方SDK

在使用第三方的SDK時需要注意檢查是否嵌入了JSPatch，防止利用App的許可權來對系統做一些壞事，或者竊取App的使用者資訊。

本地儲存

更新補丁在本地儲存時需要對儲存的補丁做加密，防止資料被篡改造成程式碼執行。

參考文獻

• https://www.fireeye.com/blog/threat-research/2016/01/hot_or_not_the_bene.html
• https://github.com/bang590/JSPatch/