【问题标题】:Key generation example for in-app purchases on androidAndroid 应用内购买的密钥生成示例
【发布时间】:2015-04-28 10:00:23
【问题描述】:

在sdk\extras\google\play_billing的应用内购买示例应用中,有如下注释。

/* base64EncodedPublicKey should be YOUR APPLICATION'S PUBLIC KEY
         * (that you got from the Google Play developer console). This is not your
         * developer public key, it's the *app-specific* public key.
         *
         * Instead of just storing the entire literal string here embedded in the
         * program,  construct the key at runtime from pieces or
         * use bit manipulation (for example, XOR with some other string) to hide
         * the actual key.  The key itself is not secret information, but we don't
         * want to make it easy for an attacker to replace the public key with one
         * of their own and then fake messages from the server.
         */

有人可以帮我举个例子,在运行时从片段或使用位操作生成密钥吗?那部分我不清楚。

谢谢

【问题讨论】:

    标签: android in-app-purchase in-app-billing


    【解决方案1】:

    这只是意味着你不应该把你的密钥放在一个普通的字符串常量中,因为可能即使是通过混淆它也可以隐藏在好奇的眼睛之外......

    因此,从不同的条带构建密钥,例如,假设密钥是“123456”。您可以通过连接 1L + "23" 来获得相同的字符串,然后将其解析为 Long,乘以 1000 并添加 456:

        Long longVal = 1L;
    String code = longVal.toString() + "23";
    longVal = Long.parseLong(code) * 1000L + 456;
    

    在编译后的字节码中,它会有点扭曲,即使通过反编译,所有内容都会看起来更丑陋且难以阅读。顺便提一句。也许你也可以bitwise一点。

    更多信息:Protect string constant against reverse-engineering

    【讨论】:

    • 谢谢,钥匙很长,这是一项非常艰巨的工作
    • 也许只是构建一个列表或部分代码的映射,然后将每个部分连接起来......只是不要将代码留在纯字符串常量中。
    猜你喜欢
    • 1970-01-01
    • 2020-04-06
    • 1970-01-01
    • 2014-05-31
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多