落格輸入法是如何在 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

通過 落格博客

如非聲明,本人所著文章均為原創手打,轉載請註明本頁面鏈接和我的名字。

18 評論

      1. 謝謝回复。我是在xcode下安裝的應用,刷新票據後獲取到的In-App Purchase Receipt Fields字段是空數組。請問是要在商店版才能獲取到嗎?

  1. 我有點沒明白。我是用中國賬號下載的落格,iCloud也是中區,當然由於眾所周知的原因,有可能要搬家。 但是由於Appstore中區很多app下架,我現在用了日區賬號,並且掛了Suica,支付很方便,匯率也更優惠。日常使用中 我的Appstore實際上是日區賬號,那麼,我會被檢測出來嗎?

  2. 活著就是一切,活著就是樂,活著也有苦,苦裡卻也有樂;就如一片樹葉,我該生的時候,我生氣勃勃地來,長我的綠,現我的形,到該落的時候了,我痛痛快快地去,讓別的葉子又從我的落疤里新生。

發表評論

您的電子郵件地址不會被公開. 必填字段標 *