AdSense

Saturday, December 31, 2016

ANDROID PT - DIVA / 12 - Hardcoding Issues 2 - Shared Object Files


HARCODING ISSUES 2 - SHARED OBJECT FILES

- Layout for this exercise:




- Connecting from Santoku to Nexus 5 with ADB:




- Launching the application: 





- Clicking the tab for challenge 12:




- The application prompts the user for a key. Introducing an invalid key the access is denied:




- Let's have a look to the Java source code of this challenge, Hardcode2Activity.java:




- First, it is important to notice that in this activity the JNI (Java Native Interface) is used to validate the access.


- Java Native Interface is a programming framework that enables Java code running in a Java Virtual Machine (JVM) to call and be called by applications and libraries written in other languages such as C, C++ and Assembly.






- The access method gets a text using JNI and checks whether the text entered by the user matches or not the valid key.






- Also, it is interesting to see the source code for DivaJni.java:









- Going into the application data directory, there is a lib directory:






- Inside the lib directory there is a libdivajni.so file:




.so (shared object) files are a type of dynamic libraries used with Unix systems (similar to .DLL's for Windows). Code stored inside a .so file is not embedded in a binary. Instead it's just referenced, so the executable will depend on it and the code from the .so file is just added/loaded at runtime.

.so files are usually written according to the ELF (Executable and Linkable Format) standard.

- In order to analyze the file, we can pull it out from the mobile device to Santoku:




- Now, the file is available to be opened at Santoku:





- Either objdump or readelf can be used to disassemble the file, and look up into the .rodata segment (read only data, storings constant data) of the program with similar results:







- Both outputs indicate the presence of a "suspicious" string ... maybe the secret key?




- Running strings command over the file libdivajni.so, the string olsdfgad;lh appears again:




- Finally, checking the source code of the application, the C program divajni.c holds the original C language program where the vendor key was stored as a constant (#define VENDORKEY "olsdfgad;lh"), and later compared with the function strncmp:











- The most important conclusion from this exercise would be to remember that developers often hardcode keys into .so files.

- To test the validity of the research, using the previous string the access is actually granted: