落格輸入法是如何在 iOS 上反賬號共享盜版的

對於 iOS 開發者來說，面對 app 盜版，最大的問題不是技術破解，反而是越來越多的 Apple ID 共享盜版，有的人可能會說這樣的盜版就相當於是“試用”了，喜歡的人自然會去入正……但實際上，由於一分錢共享賬號盜版的存在，導致無數獨立開發者最終走向了投簡歷。

總之，去年，Surge 的作者發布了這麼一篇文章 浪湧 2.0 是如何實現在 iOS 上反盜版的 他的理論是從 app 購買的 Receipt 中得到一個唯一的時間戳，在一定程度上可以作為唯一用戶的憑證。具體論證過程這裡不再詳述，這裡我沿用了他的思路，所以本文的基礎，是這個 original_purchase_date_ms 。

對於免費+內購的銷售模式，如果要反賬號共享的盜版，那麼你應該取對應內購的時間戳而不是應用購買的時間戳。

自從 iOS 7 開始，蘋果改進了 app 購買的回執，可能有些開發者不知道，即使沒有內購，你也可以通過 StoreKit 來獲取一個購買回執，這個回執就是用戶購買 app 的回執。

服務器問題

讀完 Surge 作者的這篇文章，你可能會遺憾——很可能你的 app 是一個工具類，就像落格輸入法，它不需要登錄甚至不需要聯網就可以工作，所以它自然也就沒有一個屬於自己的服務器，那麼怎麼實現數據的存儲呢？

這時候我們就可以使用蘋果為所有開發者提供的 Cloud Database，你的 app 是通過系統的 API 進行通訊的，你無需為複雜的網絡通信煩惱。

判斷共享賬號

這個時候有人會提出，如果你是按照激活來判斷的，那麼我同一個賬號，下載了你的app，我刪除了，再下載，不就和多人共享的過程是一樣的了嗎？即使按照 Surge 的規則，多達 10 次，那依舊有很大誤判的概率。——沒錯，因為蘋果對用戶的隱私保護的太好，對於開發者是根本無法獲取用戶的 Apple ID 的，對於購買回執，也沒有任何用戶信息。

——但實際上，雖然我們不能得到 Apple ID 的明文數據，但開發者確實可以得到用戶 Apple ID 的 hash 值！通過 CloudKit ，我們可以得到用戶的唯一身份證明，比如這樣：

你就可以得到如下的結果：

這就是用戶的 Apple ID 。

那麼，擁有了唯一購買標誌，擁有了當前用戶標誌，一切就變得明朗了，我們只需要把兩者保存起來，然後進行比對就可以了！

比如用戶第一次購買的時候，我們得到購買標誌，把它存入數據庫，後續下載，只要用戶的 Apple ID 與數據庫中記錄的值不同，那麼計數就 +1，這樣，就可以得到完全準確的分享次數了。

實際上，你的 Cloud Database 中完全不需要單獨創建第一個購買用戶的 id 這個字段，因為你可以直接檢查創建者這個系統字段。同時，你還可以創建一個數組，順便保存一下本次購買的 app 都有哪些用戶共享安裝了。

誤殺重置

目前來看，這個思路我還沒想到什麼漏洞，對於可能的誤殺，那就是人工重置了，開發者可以直接編輯 Cloud Database 的數據的，如果某用戶需要重置，那麼我們需要在 app 中顯示購買的唯一憑證字段（即那個時間戳），通過這個憑證在數據庫中找到對應條目，即可重置共享計數，或者查看共享的人數等等。

沒有登錄 Apple ID 的用戶？

當然，本文所有的判斷邏輯都建立在用戶登錄並啟用 iCloud Drive 的前提之下（如果用戶不啟用，那麼和斷網是沒什麼區別的。如果你 app 的功能不依賴 Cloud Database，那麼願意犧牲 iCloud Drive 的用戶就可以繼續使用盜版而不會被發現）。那麼我們假設：

1. 共享賬號在購買時沒有登錄 iCloud，並且沒有打開 app，那麼就無法記錄。——這一點沒關係，因為總會有用戶購買這個共享賬號並安裝和使用 app，這樣就會建立本次購買的記錄；
2. 用戶在購買了共享賬號後下載了app，但最終沒有登錄 iCloud。——如此一來 app 就不能訪問數據庫，檢查和記錄也就不存在了，如果用戶願意為了使用盜版而放棄 iCloud，那沒辦法了——本方案無效，用戶可以繼續正常使用盜版；
3. 用戶安裝了共享 app 後，繼續典型使用，但在第一次打開 app 前禁用了 app 的聯網權限。——這樣一來 app 無法聯網，那一切就都是空談了，用戶可以繼續使用盜版——對於一些對網絡功能有依賴的 app 來說，或許用戶就無法這麼做了。對於落格輸入法來說，用戶就無法使用【對數雲】中共享的內容以及共享內容到對數雲。

額外疑惑：分享賬號的 Apple ID 不是一樣的麼？

對於不這樣使用盜版 app 的用戶來說，這可能是個謎。實際上，使用共享賬號的用戶，並不會使用共享賬號來登錄 iCloud，也更不會綁定自己的設備到這個賬號——這是使用共享賬號盜版的常識。

總之，iOS 是允許在不退出 iCloud 的情況下更換 App Store 的賬號的，這樣一來，用戶只需要使用共享賬號登錄 App Store 即可下載 app，這也是本文成立的前提，即用戶最終還是會使用自己的 Apple ID 來日常使用，畢竟誰也不想被陌生人啟用自己 iPhone 上的 “Find my iPhone”。

雙賬號問題

有些用戶和我一樣，是中區、美區兩個賬號，那麼如果是這樣，就有可能出現類似上文中共享賬號的行為，比如中區購買，實際上 iCloud 使用的是美區，這裡我們假設幾種情況：

• 使用主賬號購買——這是典型使用情況，一切正常；
• 使用小號購買，即 iCloud 登錄的是另一個 Apple ID，那麼在用戶第一次打開 app 時，app 在數據庫中添加的記錄，實際上是用戶當前登錄的 Apple ID。——一切正常；

綜上，那麼實際上對於正常的雙賬號用戶來說，影響是不存在的。當然，這建立在用戶不會換著賬號登錄 iCloud，如果用戶這麼做，那麼在另一個賬號登錄的時候，用戶刪除了 app，又重新下載了 app，還打開了一次，那麼這時候共享計數 +1，但由於具有容錯數量（比如 10 次），那麼我們可以認為這樣是足夠一個用戶在整個 app 生命週期來重裝或者重置手機，更換 iPhone 的。

特別地，如果有用戶很 2，他就要不停的刪除重裝，還用了非常用 Apple ID 登錄了 iCloud，或者說他是用非常用 Apple ID 購買並已經配置好 app 然後才換回常用 Apple ID，再不停的刪除重裝，那我們還有最後一條補救措施——人工重置。通過人工重置，可以看到本次購買究竟共享給了多少個不同的 Apple ID，如果都是同一個，那麼顯然，這是一個誤判。

隱私考慮

這樣記錄唯一信息，可能有些朋友會為隱私問題而擔憂，這裡我們分析一下：

數據安全

數據使用蘋果公司提供的數據庫服務，通信是通過 iOS 自身，開發者無法干預整個通信過程，完全依賴蘋果公司自身的業界標準安全加密。

唯一憑證之 Apple ID

開發者能夠獲取的 Apple ID 的 hash，是僅供 Cloud Database 使用的唯一哈希，此數據僅對 Cloud Database 有意義，即使洩露，也無需擔心，對於數據庫的安全性，參考上一條。

唯一憑證之時間戳

這個時間戳是你在購買 app 時的付款時間，這個時間精確到毫秒，它可以用來粗略分辨單次購買的唯一性，但不足以與具體的 Apple ID 進行關聯，所以即使與上一條結合，也無法定位具體的“某用戶”，僅僅能得知是“確定的一位用戶”。

總結

落格輸入法的所有網絡數據都保存在 Cloud Databse，結合一年來我對 Cloud Database 的使用，我在 Surge 作者的基礎上總結出了這麼一套精確判斷共享用戶的策略，可能優點就是不需要額外的服務器就能實現，且精準無誤；缺點則是需要用戶登錄並開啟 iCloud Drive，否則則無法判斷。

本文由 落格博客 原創撰寫：落格博客 » 落格輸入法是如何在 iOS 上反賬號共享盜版的

轉載請保留出處和原文鏈接：https://www.logcg.com/archives/2950.html