【问题标题】:Making sure that a malicious apk isn't talking to my server确保恶意 apk 没有与我的服务器通信
【发布时间】:2013-02-18 04:00:26
【问题描述】:

我正在努力确保有人无法重新编译我的混淆应用程序,然后将恶意数据发送到我的服务器。我正在对我的应用程序的 versionCode 和 packageName 进行 SSLed PHP_POST。这些 POSTED 变量都通过非对称加密以及签名验证进行加密,每次版本升级都会更改。我曾考虑过使用校验和,但这些方法不受 Google 官方支持,研究表明它们不能防错,这意味着它们可能会破坏合法用户。

最重要的是,当检测到 100% 不合法的东西时,通过 IP/Mac 地址/IMEI/Serial/Android_ID/等禁止站点。

我知道没有什么是 100% 安全的,好的安全性和坏的安全性之间的区别在于破坏安全性所需的时间/金钱/努力的价值高于受安全性保护的项目。考虑到这一点,我是否可以使用任何其他方法来保护我的应用程序或我应该实施的任何想法以增加当前的安全性?

顺便说一句,反编译/重新编译一个被混淆的 apk(jar) 有多容易,一旦完成一次会更容易吗? (也就是说,我更改密钥的次数并不重要,因为应用程序已经受到威胁,反编译器可以简单地查看我最后一个密钥所在的位置)

【问题讨论】:

  • 常见的解决方案是要求用户在授予访问权限之前在服务器上进行验证。你不能这样做有什么原因吗?
  • 是的,我觉得这给用户带来了麻烦。我要保护的特定功能需要一个用户可以购买的代币来使用它。购买后,他们将收到一个带有其标识符的 tokenID。我认为使用登录系统也无济于事。我正在尝试识别我的 apk 的反编译版本

标签: java php android security


【解决方案1】:

首先,不要自己加密。如果您正确(!)执行 SSL,这可能足以保护传输中的数据免受篡改等。您需要做的是以某种方式验证您的应用程序,这通常很棘手,因为您需要将凭据保留在应用程序中。有不同的方法,但目前的标准(和谷歌认可的方式)是使用谷歌播放服务来获取一个令牌并在你的服务器应用程序中验证它。详情在这里:http://android-developers.blogspot.jp/2013/01/verifying-back-end-calls-from-android.html

这并不完美,但可能比您能想出的大多数非标准解决方案要好。

反编译通常很容易,并且混淆不会有太大变化,因为找到调用系统 API 的位置(获取 MAC 地址、哈希、加密等)很简单

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2020-05-13
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多