談一談第三方軟件授權管理平臺

文中提及的逆向工程思路僅供學習參考，請支持正版軟件。

付費授權模式在商業軟件中十分常見，它也爲公司提供了收回軟件開發成本的可能，或是讓個人開發者過上小資生活（想多了）。

在之前嘗試繞開 iStat Menus 6（下稱「ISM6」）的授權驗證時，曾被授權驗證函數間傳遞的 NSDictionary 中的 Keys ——「CPU」和「Memory」所迷惑，這樣做也是在一定程度上降低了敏感字符串暴露的風險。正如上一篇文章所分析的一樣，ISM6 並未使用第三方的授權管理 SDK，而是選擇了自己在最終用戶端使用 Security Framework 進行驗證。

可以說，大部分工具軟件都在使用這類相對簡單但也能保留部分強壯性（Robustness）的驗證模式。畢竟，實現一套完整的授權管理體系所需要操心的事情並不少，支付訂單管理、授權發放和管理以及最終用戶端的驗證及反破解等，綜合算下來可能要比開發一個工具類軟件還複雜。

因此一些着手解決此類問題的第三方平臺便開始提供軟件授權管理服務，開發者只需要接入 SDK 便可以輕鬆地管理自己的軟件授權，從此高枕無憂。

可是，事實真的如此嗎？我們先分析，再來討論這個問題。

本來今天上午要去看牙醫，但年後醫院的人實在是太多沒有掛到號。下午外面還下起了大雪，那就趁着機會總結一下對 Gifox 的授權模式分析吧。

在上次分析 ISM6 時，靜態和動態的方式都用上了，因此這次我決定先靜態分析看看。

Gifox 的字符串像一鍋漿糊一樣，以往靠直接查找敏感關鍵詞的方法並不是很好用。但在粗略分析後，我發現真正的驗證工作可能不在它本身。如果嘗試點擊「Lost license」來恢復購買，你會發現跳轉到的網站並不是 Gifox 的官方支持頁面，而是一個第三方授權管理平臺的網站。

從這裏開始，我開始懷疑它使用了我們開頭所說的第三方 SDK。這也是繞開驗證的突破口。

在有了思路之後，我找到了它的實現者。這回靜態分析的目標變成了這個在最終用戶端實現授權驗證的 Framework。

很快便找到了控制授權驗證的函數，看流程圖（太長所以我把它們 (ﾉ*･ω･)ﾉ 推倒了）也能看出來是一棵充滿條件分支的老樹。

當然，這裏爲了繞開驗證流程，我們只需要對 rax（絨布球寄存器） 下手就好了。mov rax, 1 總歸是好用的。

實測去除了 10 秒的錄製以及水印顯示/隱藏開關的限制。

靜態分析的時候還看到了用 sysctl 檢查是否有 Debugger 附加的函數，也一起改掉了。

不過動態調試的時候發現這個函數並沒有顯式的影響程序的正常啓動，不像有一些軟件在遇到 Debugger 的時候便華麗麗的 SIGKILL 自殺。反調試的手段和近期研究的一些帶殼 Android 軟件所用的也並沒有太大差異。

現在回到開始時的問題——真的高枕無憂嗎？並不是。

既然是第三方授權管理平臺，除了 Gifox 必然還會有其他的軟件或開發者在使用，而第三方 SDK 的天然特性又限制了它對出現的安全性問題的快速響應和修補能力。

現在可以肯定的說，第三方平臺並不能讓開發者高枕無憂的管理收入。

破解和反破解，正如反破解和反反破解一樣，是宿敵無疑。即便使用了高級的殼子，也總歸要在最終用戶的設備上運行，也總歸要在運行效率和安全性之間做出權衡。

破解和未被破解，只是時間的問題。作惡與不作惡，也只是底線的問題。

交給最終用戶，總歸是不安全的。

就說到這裏，雪還在下。

咱繼續寫個人的項目去了。