和其他发布了应用内计费的Android应用程序的人一样,我遵循了
AIDL to Google Play Library migration guide
剩下的人呢
integration documentation
以便在我的应用程序中实现最新版本的计费库。到目前为止,一切进展顺利。
我的应用程序是一个典型的免费应用程序,你可以付费解锁一些额外的功能。然而,它不是一个很大的。没有后端服务器来验证购买情况,老实说也不需要。尽管如此,我还是很重视我的应用程序和在其中进行的购买,因此我采取了一些措施来防止欺诈。
一个这样的行动是隐藏和混淆应用程序的代码,因此,反编译和破解它变得烦人,足以让人考虑付出非常低的价格为其溢价特征,而不是破解它。我想到目前为止,我已经成功地防止了这种情况。
在发布带有新计费库的应用程序之前,我对其进行了反编译,并查看了反编译代码。
从安全角度看,我无法描述我对新库的实现是多么令人失望
.
使用的库的早期版本
Intent
和
Bundle
具有
String
和
int
,新的
Purchase
和
SkuDetails
.
尽管ProGuard对方法名进行了模糊处理,但这两个类没有
.因此,在所有文件中搜索“购买”非常容易,您很快就会找到
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)
{
...
}
我认为现在对于一个破解者来说,很明显的一点就是要遵循
购买
和
SKU详细信息
对象,特别是因为我们需要以某种方式将它们保存在内存中,以便
launchBillingFlow
包括
SKU详细信息
在
BillingFlowParams
.
因此,问题是:
我怎样才能更好地混淆这个问题呢
购买
和
SKU详细信息
反编译代码中的类?我应该用我自己的课程来代替它们吗?我应该继承他们的遗产吗?我应该重新创建
SKU详细信息
班我应该不担心吗?你是怎么处理的?
