Obfuscating resource strings that may give away too much information about programming logic

这一生的挚爱 提交于 2019-11-30 10:56:19

If you define a resource string, you will probably define or use it in:

  • the string resource file res/values/strings.xml,
  • layout files res/layout/*.xml,
  • the generated resource file R.java,
  • your java code src/**.java.

After compilation, the resource string, its name, and its integer code end up in:

  • the resource file resources.arsc (string, name, and code),
  • the resource class R$string.class (name, code),
  • your compiled code **.class (inlined code).

ProGuard will remove R$string.class entirely, but Android decompilers can reconstruct all information from resources.arsc. It still takes a bit of work, but the strings may indeed hint at the purpose of the code (along with certain API calls).

You can improve on this by encrypting/obfuscating the strings in your code and by using reflection to access certain APIs, as suggested in Google's presentation Evading Pirates and Stopping Vampires.

ProGuard's closed-source sibling for Android DexGuard can encrypt strings for you (along with API calls and entire classes), probably more effectively than you could achieve manually, and without burdening the source code.

(I am the developer of ProGuard and DexGuard)

When i want to conceal important strings in android i put them in a c/c++ library. then i use a JNI call to retrieve them. In the c library i go even further, i convert the string to hexadecimal and when im retrieve the same string i convert it to integer again from hexadecimal. When a hacker tries to view the c/c++ library it will be very difficult to find your secret string (especially if there converted to hexadecimal).

here is a nice article and how to get started doing that.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!