如何混淆 Google Play Billing Library 版本 4 中的 Purchase 和 SkuDetails？

Question

和其他發布了帶有應用內付費功能的 Android 應用程序的人一樣，我按照從AIDL 到 Google Play 庫遷移指南和其他集成文檔的說明，將最新版本的 Billing 庫應用到我的應用程序中。 到目前為止一切正常。

我的應用程序是典型的免費增值應用程序，您可以付費解鎖一些額外的功能。 然而，它不是一個很大的。 沒有后端服務器來驗證購買，老實說，沒有必要。 盡管如此，我確實重視我的應用程序和在其中進行的購買，因此我已采取某些措施來防止欺詐。

一種這樣的行為是隱藏和混淆應用程序的代碼，這樣反編譯和破解它就變得很煩人，以至於有人考慮為它的高級功能支付非常低的價格，而不是破解它。 我想到目前為止我已經成功地防止了這種情況。

在使用新的 Billing 庫發布我的應用程序之前，我對其進行了反編譯並查看了反編譯后的代碼。 從安全的角度來看，我無法描述我對新庫的實現是多么令人失望。

該庫的先前版本使用Intent和Bundle以及String和int ，而新版本使用Purchase和SkuDetails 。 盡管 ProGuard 混淆了方法名稱，但這兩個類不是. 因此，在所有文件中搜索“Purchase”非常容易，您很快就會發現onPurchasesUpdated 、 onQueryPurchasesResponse和onSkuDetailsResponse類似於：

public void M(com.android.billingclient.api.g paramg, List<Purchase> paramList)
{
   ...
}

public void N(com.android.billingclient.api.g paramg, List<Purchase> paramList)
{
   ...
}

public void O(com.android.billingclient.api.g paramg, List<SkuDetails> paramList)
{
  ...
}

我認為現在破解者遵循Purchase和SkuDetails對象的邏輯是很明顯的，特別是因為我們需要以某種方式將它們保存在內存中，以便我們launchBillingFlow SkuDetails在launchBillingFlow包含一個BillingFlowParams 。

所以，問題是：

我怎樣才能更好地混淆反編譯代碼中的Purchase和SkuDetails類？ 我應該用我自己的課程替換它們嗎？ 我應該繼承他們嗎？ 我應該重新創建SkuDetails類嗎？ 我不應該擔心嗎？ 你是怎么處理這件事的？

Answer 1

有人可能想知道反編譯應用程序是否是黑客的首選。 有根設備可能安裝了模擬 Play 商店應用程序，該應用程序會立即返回用戶已向任何具有 IAP 的應用程序付款。 無需了解您的應用即可獲得高級功能。

在我看來，花一些時間設置后端來檢查它是否是合法的應用程序購買，值得更多。 如果您使用 fi，托管后端可能很便宜 - 甚至免費。 Firebase 功能。 Play 商店將實際購買發送到您的后端，后端向應用程序報告它已成功購買。