Identifying Hard-coded sensitive values in Native Library Files – #12 DIVA Solution

You might be knowing that Android apk can be made using Java, Kotlin, HTML-Js(cross platform apps) as well as in Native languages using C, C++ etc (reason being they can inherit already available popular libraries in those language plus better performance). When we talk about apps using Native languages compilation using C/C++, such languages could be used via JNI (Java Native Interface) to generate Apk.

 

The video demonstrates DIVA app to understand how developers might hard-code keys inside library files using Native language support. Here aim is to view hidden key inside the C file which was hardcoded.

 


Download
diva.apk

Method-1

Examining Hardcode2Activity.java you would see that DivaJni is referenced in it. Opening DivaJni we come to know that it is loading Library named divajni and from that it is invoking native method access() & initiateLaunchSequence(). This helps us in understanding that we now have to look for some native language file in source code. For this we would check .c or .h files, currently such files are part of jni folder. you would see jni > divajni.c . You would notice #define VENDORKEY “olsdfgad;lh” hard-coded over there. This was the 1st method which could be done after extracting apk (black-box) or directly having source-code (white-box).

You might like to check this article on Reverse Engineering .apk to get source code.

Method-2

One more possibility is looking into Android app sandbox for the same library file. For that install the app inside (emulators might not work because of architecture difference)physical rooted device (or a debug=true app for non-rooted device). Move into /data/data/jakhar.aseem.diva/lib and see the content of libdivajni.so file present as shown in below steps.

 

You would find olsdfgad;lh inside that libdivajni.so file. Which you can use as key for this challenge in the DIVA app.

Remediation

  • Never hardcode any sensitive information within native code/java/xml/html files – may it be encryption key, passwords, or any other personal information which might cause confidentiality breach as apps can be reversed and code can be extracted.
  • Relying upon obfuscation you may make the task difficult for attacker, however it is still a bad practice to save anything sensitive even after obfuscation, as even strongest obfuscation technique are meant to be broken with ample of time.

Report Errors + Bugs & Become Insider for Nestedif.com

We would like to hear you, if you find any error or misspelled phrase while reading our tutorials. By reporting mistakes through email to insider@nestedif.com you could help other peers.