和其他发布了应用内计费的 Android 应用程序的人一样,我已按照AIDL 到 Google Play 库迁移指南和集成文档的其余部分的说明在我的应用程序中实施最新版本的计费库。到目前为止一切正常。
我的应用程序是典型的免费增值应用程序,您需要付费解锁一些额外功能。然而,它不是一个很大的。没有后端服务器来验证购买,老实说,没有必要。尽管如此,我确实重视我的应用程序和在其中进行的购买,因此我采取了某些措施来防止欺诈。
一种这样的行为是隐藏和混淆应用程序的代码,因此反编译和破解它变得非常烦人,以至于有人考虑为其高级功能支付非常低的价格,而不是破解它。我认为到目前为止我已经成功地防止了这种情况。
在使用新的 Billing 库发布我的应用程序之前,我对其进行了反编译并查看了反编译的代码。从安全的角度来看,我无法描述我对新库的实现有多么令人失望。
以前版本的库使用Intent
andBundle
和String
and int
,新版本使用Purchase
and 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
andSkuDetails
对象的逻辑,特别是因为我们需要以某种方式将它们保存在内存中,以便我们launchBillingFlow
将 a 包含SkuDetails
在BillingFlowParams
.
所以,问题是:
我怎样才能更好地混淆反编译代码中的Purchase
和SkuDetails
类?我应该用自己的课程替换它们吗?我应该从他们那里继承吗?我应该重新创建SkuDetails
课程吗?我不应该担心吗?你是怎么处理的?