JSPatch 嘗試

JSPatch 原理

JSPatch 能做到通過 JS 調用和改寫 OC 方法最根本的原因是 Objective-C 是動態語言，OC 上所有方法的調用/類的生成都通過 Objective-C Runtime 在運行時進行，我們可以通過類名/方法名反射得到相應的類和方法

JSPatch 安全

JSPatch 存在兩個安全方面的問題

1. 傳輸安全：JS 腳本可以調用任意 OC 方法，權限非常大，若被中間人攻擊替換代碼，會造成較大的危害。
2. 執行安全：下發的 JS 腳本靈活度大，相當於一次小型更新，若未進行充分測試，可能會出現 crash 等情況對 APP 穩定性造成影響。

傳輸安全
1. 對稱加密
2. HTTPS
3. RSA 校驗

RSA校驗

服務端計算出腳本文件的 MD5 值，作爲這個文件的數字簽名。
服務端通過私鑰加密第 1 步算出的 MD5 值，得到一個加密後的 MD5 值。
把腳本文件和加密後的 MD5 值一起下發給客戶端。
客戶端拿到加密後的 MD5 值，通過保存在客戶端的公鑰解密。
客戶端計算腳本文件的 MD5 值。
對比第 4/5 步的兩個 MD5 值（分別是客戶端和服務端計算出來的 MD5 值），若相等則通過校驗。

執行安全

• 回退
  
  • 後臺可以提供一個指令讓APP不執行JSPatch 的方法
• 測試充分

JSPatch 熱更新方案

假設後臺版本對應補丁是這樣子的

appVersion	patchVersion
1.0.0	0.1
	0.2
	0.3
	0.4
	0.5

請求體

Request:
{
    appVersion:1.0.0,
    bundleVersion:0.3,
    ...
}

簡單一點方法就是將所有的patch下發

Response:
[
    ...
    {
        patchVersion:0.1,
        patchUrl:<Url>.0.1,
        fileMD5:<>, //js文件通過計算出腳本的MD5值,通過RSA加密
        ...
    },
    {
        patchVersion:0.2,
        patchUrl:<Url>.0.2,
        fileMD5:<>,
        ...
    },
    {
        patchVersion:0.3,
        patchUrl:<Url>.0.3,
        fileMD5:<>,
        ...
    },,
    {
        patchVersion:0.4,
        patchUrl:<Url>.0.4,
        fileMD5:<>,
        ...
    },,
    {
        patchVersion:0.5,
        patchUrl:<Url>.0.5,
        fileMD5:<>,
        ...
    },
]

發送到前端.然後前端根據本來保存的最後patchVersion的版本.進行選擇性的添加.

其實覺得還是後臺直接下發缺失的部分比較好.

Response:
[
    ...
    {
        patchVersion:0.4,
        patchUrl:<Url>.0.4,
        fileMD5:<>,
        ...
    },,
    {
        patchVersion:0.5,
        patchUrl:<Url>.0.5,
        fileMD5:<>,
        ...
    },
]

最後下載下來的文件,我們通過計算出它的MD5值,我們在通過RSA公鑰解密,然後跟下發的MD5進行比對.如果正確,說明沒有問題.
不正確,就可能被篡改了,選擇重新請求,或者其他方案