2

i am using ndk and android studio to secure my api-key and it works now. also i am trying dirty code to harden disassembling... . but i can still decompile and see native methods in java classes. also pre-built .so(shared object) files are available in apk and wil be used again!

Questions:

  1. After releasing the apk, all hackers can see .so file and they can use custom settings in .mk file and program specific native methods like my class for extracting the api-key only. they call my functions related to api-key without knowing the implementation. am i eliminating something here?

    1. is proguard necessary for this way ?
Ali
  • 113
  • 2
  • 10
  • https://stackoverflow.com/questions/28864029/android-ndk-possibility-of-decompiling-native-code – Ali Jul 06 '18 at 12:01
  • https://stackoverflow.com/questions/15025304/check-apk-signature-in-c-native-code – Ali Jul 06 '18 at 12:02
  • after checking above links, i think the solution is near!! can anyone explain the right answer clearly ? – Ali Jul 06 '18 at 12:21
  • 1
    You cannot stop 'hackers' from recovering data and code from your android application, include api keys. You can only slow them down with obfuscation. – President James K. Polk Jul 06 '18 at 13:36

3 Answers3

2
  1. You increase the time hackers will need to decompile and understand the .so file. Estimate how hard it is, and change the way your api authentification works from time to time. Doing so makes previous hacking attempt obsolete, even if they have been successful.

To clarify : put the api-key and the authentification process in the native methods. For instance, for an HTTPS api, send the uri, json content, usertoken, to a native method. Then in the native code, use these and the api-key and some hash functions to create a hash. And output that hash to the Java code to be send in the HTTP request. By doing so, it will be hard to guess the authentification recipe by simply monitoring entries and output. Attackers will have to decompile the native code.

  1. Activate Proguard, compile, decompile, and see for yourself. On my opinion it does raise a good level of complexity for a very easy set up.
NoonanRosenblum
  • 503
  • 6
  • 19
2

That's right, there is no way to prevent .so reuse by malicious agent. Therefore, your native API should never reveal secret information to the Java side. You can perform some validation in your native methods to check if the calling Java actually belongs to the legitimate APK.

On the other hand, don't underestimate another vulnerability of native code: your .so can be disassembled with relevant tools, and any protection may be torn off. There exist means of obfuscation and resilience to reverse engineering for native code, but the earning curve for them is much steeper than with ProGuard.

Still, it's worthwhile to at least not keep the api-key in plain text in your C++ code. Try yourself to run 

strings libnative.so

(here libnative.so is the .so file extracted from your APK) and you may discover important information that is waiting to be stolen from your library, no sophisticated reverse engineering necessary.

As far as ProGuard is concerned, it does not add protection to the native methods you use. You cannot even obfuscate the class name and method name for a native method. (Well, it is possible, but very tricky, and there are no tools that can help with such setup).

Alex Cohn
  • 56,089
  • 9
  • 113
  • 307
0

We have created a gradle plugin to hide keys in the Android NDK, you can check all the implementation on github : https://github.com/klaxit/hidden-secrets-gradle-plugin

The goal is to make it as hard as possible to reverse engineer keys. We encourage to add a custom encrypt algorithm then keys are stored in the NDK as hexadecimal arrays.

We would love to have feedbacks on our solution !

Ben-J
  • 1,084
  • 8
  • 24