Question

我正在考虑如何保护我的应用免受像Freedom这样的黑客入侵应用内购买。

我使用应用内结算版本3 API，尚未实施＆＃34;有效负载＆＃34;示例应用程序内结算代码中的功能（但未填写）。我想知道这是否是对抗自由的有用保护。

这个想法似乎是在启动应用内购买时发送有效负载：

    /* TODO: for security, generate your payload here for verification. See the comments on
     *        verifyDeveloperPayload() for more info. Since this is a SAMPLE, we just use
     *        an empty string, but on a production app you should carefully generate this. */
    String payload = "";

    mHelper.launchPurchaseFlow(this, SKU_PREMIUM, RC_REQUEST,
            mPurchaseFinishedListener, payload);

您设置了mPurchaseFinishedListener回调（上面传递）以在收到回复时验证购买，例如：

IabHelper.OnIabPurchaseFinishedListener mPurchaseFinishedListener = new IabHelper.OnIabPurchaseFinishedListener() {
    public void onIabPurchaseFinished(IabResult result, Purchase purchase) {

        if (!verifyDeveloperPayload(purchase)) {
            complain("Error purchasing. Authenticity verification failed.");
            return;
        }

        // ... it's OK... now we can act on the purchase...

    }
}

boolean verifyDeveloperPayload(Purchase p) {
    String payload = p.getDeveloperPayload();

    /*
     * TODO: verify that the developer payload of the purchase is correct. It will be
     * the same one that you sent when initiating the purchase.

    return true;
}

（我的理解是，无论您选择何种格式的有效负载，您都会坚持使用它，因为它（有效负载）是由Google针对每次用户购买而永久存储的，因此您需要能够验证有效负载比如，10年的时间。）

所以，关于我的实际问题：

这是＆＃34;有效载荷＆＃34;机制提供任何保护，以防止像Freedom这样的黑客应用？或者，Freedom有效地提供了一张伪造的信用卡，用于在上述机制中间伪造购买，而不会改变购买过程中的任何其他内容，特别是留下有效负载＆＃34;完整？

情况就是如此，即使使用Freedom，您在发起购买时发送的原始有效负载仍会返回mPurchaseFinishedListener，并且会通过verifyDeveloperPayload()中的检查，而不管假货使用付款详情？

或者（希望）自由的干预会导致一个不存在的（或至少是不同的）有效载荷＆＃34;返回mPurchaseFinishedListener，导致验证失败？

如果会导致验证失败（有效负载与启动购买时发送的有效负载不匹配），我们会继续回答有关＆＃34;有效载荷＆＃34;应该/可以采取。从某些研究中可以看出生成有效负载的复杂方法，您可以将其存储在自己的服务器上并进行查询，但这一切都非常麻烦。

因此，如果有效载荷功能对Freedom有效，那么一种有效的方法是使用一些任意的固定的有效载荷......一种像Freedom那样的通用黑客会不知道的？例如。你可以用＆＃34;我爱香蕉＆＃34;或＆＃34; com.mydomain.app＆＃34;或＆＃34; EJF323MASd8DAS＆＃34;。这不会提供针对专门分析和定位您的应用的黑客的任何保护，但对于像Freedom这样的通用黑客......也许会这样？它具有简单的好处......

Answer 1

This excellent answer解释了自由攻击是如何工作的，@savanto，测试了对根设备的攻击，并从中发现：

在购买流程中，黑客应用程序拦截了用于合法服务的purchase Intent

这告诉我developerPayload可能不安全，因为截获的购买意图将开发者有效负载作为参数接收，它可以在响应INAPP_PURCHASE_DATA中简单地返回它。

然而，自由无法生成有效INAPP_DATA_SIGNATURE，因为这是使用您在Google服务器上的证书创建的。因此，我建议验证签名，而不是developerPayload。

使用应用内结算有效负载是否可以防范Freedom hacks？

1 个答案: