混淆密钥缓存中的漏洞?安卓许可

发布于 2024-10-07 06:19:55 字数 2003 浏览 2 评论 0原文

每当 Android Market Licensing ping 服务器返回 GRANT_ACCESS pong 时,我就会缓存用户的身份验证。

有人发现这个策略有什么漏洞吗?我相信它非常强大,因为我正在混淆密钥,而消除混淆的唯一方法就是知道盐。现在,可以想象有人可以打开 apk 并寻找盐,但这并不是我认为值得担心的破解程度。

正如您所看到的,设备特定信息被添加到混淆技术中。

// Try to use more data here. ANDROID_ID is a single point of attack. 
String deviceId = Secure.getString(getContentResolver(), Secure.ANDROID_ID); 
obfuscator = new AESObfuscator(SALT, getPackageName(), deviceId); 
mChecker = new LicenseChecker(this, new ServerManagedPolicy(this, obfuscator), BASE64_PUBLIC_KEY ); 

接下来创建持久数据:

 public void allow() {
   SharedPreferences settings = getSharedPreferences(PREFERENCES_EULA, 0);
   SharedPreferences.Editor editor = settings.edit();
   String uid = UUID.randomUUID().toString();
   if(!settings.contains(ACCESS_KEY)) {
     editor.putString(ACCESS_KEY,uid);       
     editor.commit();
   } 
   if(!settings.contains(OBFU_ACCESS_KEY)) {
     String obfu = obfuscator.obfuscate(uid);
     editor.putString(OBFU_ACCESS_KEY,obfu); 
     editor.commit();
   }

然后,我使用另一种方法来检查缓存内容的状态:

boolean isCachedLicense() {
  SharedPreferences settings = getSharedPreferences(PREFERENCES_EULA, 0);
  if(settings.contains(ACCESS_KEY) && settings.contains(OBFU_ACCESS_KEY)) {
    String accessKey = settings.getString(ACCESS_KEY, "");
    String obAccessKey = settings.getString(OBFU_ACCESS_KEY, "");
    try {
      if(accessKey.equals(obfuscator.unobfuscate(obAccessKey))) {
              return true;
      } else {
              return false;
      }
    } catch (ValidationException e) {
       e.printStackTrace();
       return false;
    }
  } else {
       return false;
  }
} 

最后,我检查了 LicenseCheckerCallbackisCachedLicense >: @Override dontAllow@override applicationError。如果 isCachedLicense 为 true,则我让用户转发。

此外,完整的源代码位于此处

I'm caching a user's authentication to whenever the Android Market Licensing ping server returns a GRANT_ACCESS pong.

Does anyone see any vulnerabilities with this strategy? I believe it is very strong, since I am obfuscating a key, and the only way to unobfuscate is to know the salt. Now, someone could conceivably open the apk and look for the salt, but this is not really the level of cracking I think is too important to worry about.

As you can see, device specific information is being added to the obfuscation technique.

// Try to use more data here. ANDROID_ID is a single point of attack. 
String deviceId = Secure.getString(getContentResolver(), Secure.ANDROID_ID); 
obfuscator = new AESObfuscator(SALT, getPackageName(), deviceId); 
mChecker = new LicenseChecker(this, new ServerManagedPolicy(this, obfuscator), BASE64_PUBLIC_KEY ); 

Next the creation of the persisted data:

 public void allow() {
   SharedPreferences settings = getSharedPreferences(PREFERENCES_EULA, 0);
   SharedPreferences.Editor editor = settings.edit();
   String uid = UUID.randomUUID().toString();
   if(!settings.contains(ACCESS_KEY)) {
     editor.putString(ACCESS_KEY,uid);       
     editor.commit();
   } 
   if(!settings.contains(OBFU_ACCESS_KEY)) {
     String obfu = obfuscator.obfuscate(uid);
     editor.putString(OBFU_ACCESS_KEY,obfu); 
     editor.commit();
   }

Then, I used another method to check the state of the cached content:

boolean isCachedLicense() {
  SharedPreferences settings = getSharedPreferences(PREFERENCES_EULA, 0);
  if(settings.contains(ACCESS_KEY) && settings.contains(OBFU_ACCESS_KEY)) {
    String accessKey = settings.getString(ACCESS_KEY, "");
    String obAccessKey = settings.getString(OBFU_ACCESS_KEY, "");
    try {
      if(accessKey.equals(obfuscator.unobfuscate(obAccessKey))) {
              return true;
      } else {
              return false;
      }
    } catch (ValidationException e) {
       e.printStackTrace();
       return false;
    }
  } else {
       return false;
  }
} 

Finally, I checked if isCachedLicense in the following locations of the LicenseCheckerCallback:
@Override dontAllow, and @override applicationError. If isCachedLicense is true, then I let the user forward.

Also, full source code is located at here.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

难以启齿的温柔 2024-10-14 06:19:55

一般来说,用盐进行混​​淆是一种较弱的策略。攻击者只需要找出盐,一旦你知道你在寻找什么,这就相当简单,并且可以在不直接访问你的应用程序的情况下完成。一旦(任何人)发现盐,我们所有的安装基础都将受到损害。

最好的选择是,不要使用具有固定密钥的混淆算法,而是使用经过验证的加密库+算法,其密钥对于用户或您所运行的设备来说是唯一的。

Obfuscation with salt is generally speaking a weak strategy. The attacker just has to figure out the salt, which is fairly straight forward to do once you know what you're looking for, and can be done without direct access to your application. Once the salt is discovered (by anyone), all of our install base has been compromised.

Your best bet is, instead of using an obfuscation algorithm with a fixed key, to use a proven encryption library+algorithm with a key that is unique to either the user or the device that you're running on.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文