Cracking Damn Insecure and Vulnerable App (DIVA) – part 5:

February 10, 2016 by

In the first four articles, we have discussed solutions for the first eleven challenges in DIVA. In this last article of this series, we will discuss the remaining two challenges that are related to native code.

In case if you missed the previous articles in this series, here are the links.

FREE role-guided training plans

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.






Challenge 12: "12. HARDCODING ISSUES – PART 2."

Steps to solve:

Click on "12. HARDCODING ISSUES – PART 2" in your application. The goal of this challenge is to find out the vendor key and submit it to the application.

Following is the decompiled code that is associated with the activity.


Looking at the above code at Hardcode2Activity.class, it appears that this activity is creating an object of DivaJni class when it is loaded. Exploring other files reveal that there is a file called DivaJni.class as shown below.


From above code, it is clear that a native library called "divajni" is loaded. Libraries will come with the APK file, and they are usually located within the"lib" directory.

Unpacking the application using the command $ unzip diva-beta.apk will result in all the files and folders extracted as shown below.

$ ls









Lets navigate
to "lib" folder and run "ls *" to list out all the files within each directory. This is shown below.

$ ls *
















As we can see in the above excerpt, there are multiple instances of "libdivajni.so" files for various architectures. Lets pull one of them and run strings command on that to see if we can find anything interesting. This is shown below.

$ strings libdivajni.so



































































GCC: (GNU) 4.8

gold 1.11























Looking at the above output, we can notice various strings coming out among which two strings that are highlighted in the above output caught my attention. After trying both of them in the application, I ended up finding the right vendor key

We can also find this hardcoded key in the source, which is available at the following link.


Following is the hardcoded constant from the source code.

Challenge 13: "13. INPUT VALIDATION ISSUES – PART 3"

Steps to solve:

Click on "13. INPUT VALIDATION ISSUES – PART 3" in your application. The goal is to crash the application some how.

Let's first see how the application is responding when we enter some input. I have entered 4 As in the input field as shown below.

As you can see, the application has shown an error message.

After entering multiple inputs as such, the application responded with the same error message as long as the input length is not greater than 20.

The following figure shows that the app is throwing the same error when we enter 20 As.

Now let's see how the application responds of we enter some large text. This time, I am entering 40 As.

As you can see in the above figure, the application has been crashed.

Lets see if we can find any information about this crash in "logcat". Open up a new terminal and type "adb logcat"

I/DEBUG ( 54): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

I/DEBUG ( 54): Build fingerprint: 'generic/sdk/generic:4.4.2/KK/938007:eng/test-keys'

I/DEBUG ( 54): Revision: '0'

I/DEBUG ( 54): pid: 1246, tid: 1246, name: khar.aseem.diva >>> jakhar.aseem.diva <<<

I/DEBUG ( 54): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 41414140

I/DEBUG ( 54): r0 00000000 r1 bef7536c r2 00000007 r3 00000000

I/DEBUG ( 54): r4 41414141 r5 b715b398 r6 00000004 r7 b2e52d10

I/DEBUG ( 54): r8 bef75388 r9 b2e52d08 sl b715b3a8 fp bef7539c

I/DEBUG ( 54): ip aafbdfe4 sp bef75388 lr aafbad5c pc 41414140 cpsr 00000030

I/DEBUG ( 54): d0 0000000080000000 d1 0000000042180000

I/DEBUG ( 54): d2 0000000000000000 d3 33d6bf9500000000

I/DEBUG ( 54): d4 0000000000000000 d5 3f80000000000000

I/DEBUG ( 54): d6 3f80000000000000 d7 0000000080000000

I/DEBUG ( 54): d8 0000000000000000 d9 0000000000000000

I/DEBUG ( 54): d10 0000000000000000 d11 0000000000000000

I/DEBUG ( 54): d12 0000000000000000 d13 0000000000000000

I/DEBUG ( 54): d14 0000000000000000 d15 0000000000000000

I/DEBUG ( 54): scr 60000010

I/DEBUG ( 54):

I/DEBUG ( 54): backtrace:

I/DEBUG ( 54): #00 pc 41414140 <unknown>

I/DEBUG ( 54): #01 pc 00000d58 /data/app-lib/jakhar.aseem.diva-1/libdivajni.so (Java_jakhar_aseem_diva_DivaJni_initiateLaunchSequence+76)

I/DEBUG ( 54): #02 pc 000b973a /data/dalvik-cache/data@app@jakhar.aseem.diva-1.apk@classes.dex

I/DEBUG ( 54):

I/DEBUG ( 54): stack:

I/DEBUG ( 54): bef75348 fffffe01

I/DEBUG ( 54): bef7534c bef75374 [stack]

I/DEBUG ( 54): bef75350 b21d95c0 /dev/ashmem/dalvik-LinearAlloc (deleted)

I/DEBUG ( 54): bef75354 b715b398 [heap]

I/DEBUG ( 54): bef75358 00000004

I/DEBUG ( 54): bef7535c bef7536c [stack]

I/DEBUG ( 54): bef75360 b715b398 [heap]

I/DEBUG ( 54): bef75364 aafbad5c /data/app-lib/jakhar.aseem.diva-1/libdivajni.so (Java_jakhar_aseem_diva_DivaJni_initiateLaunchSequence+80)

I/DEBUG ( 54): bef75368 00000000

I/DEBUG ( 54): bef7536c 41414141

I/DEBUG ( 54): bef75370 41414141

I/DEBUG ( 54): bef75374 41414141

I/DEBUG ( 54): bef75378 41414141

I/DEBUG ( 54): bef7537c 41414141

I/DEBUG ( 54): bef75380 41414141

I/DEBUG ( 54): bef75384 41414141

I/DEBUG ( 54): #00 bef75388 41414141

I/DEBUG ( 54): ........ ........

I/DEBUG ( 54): #01 bef75388 41414141

I/DEBUG ( 54): bef7538c 41414141

I/DEBUG ( 54): bef75390 00414141

I/DEBUG ( 54): bef75394 b3e260f8 /dev/ashmem/dalvik-heap (deleted)

I/DEBUG ( 54): bef75398 b3d0ef5c /dev/ashmem/dalvik-heap (deleted)

I/DEBUG ( 54): bef7539c b5a8df03 /system/lib/libdvm.so (dvmCallJNIMethod(unsigned int const*, JValue*, Method const*, Thread*)+398)

I/DEBUG ( 54): bef753a0 b2e52d04

I/DEBUG ( 54): bef753a4 ab78e73e /data/dalvik-cache/data@app@jakhar.aseem.diva-





e1a00005 e28dd00c

I/DEBUG ( 54):

I/DEBUG ( 54): memory map around fault addr 41414140:

Looking at the above output from logcat, its clear that the crash is due to CPUs attempt to jump to 41414140. Basically A maps to 41 in hex. We have used large number of As in the input we have supplied, and CPU is trying to jump to this location thus causing an error condition since this location is something that is unknown.

Now, let's explore the source code available at the link:


After exploring the source code available at the above link, it is clear that the application is processing user supplied input using strcpy() function.

The buffer size allocated is 20. We can see it from the following figure.

FREE role-guided training plans

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

So, it is clear that we are writing larger data than the size of the buffer. Due to insufficient bounds checking in strcpy() function, the buffer is overflown when user-supplied input is copied, and the application crashed. Any input that has the length greater than 20 bytes will cause a buffer overflow condition in this application.


Srinivas is an Information Security professional with 4 years of industry experience in Web, Mobile and Infrastructure Penetration Testing. He is currently a security researcher at Infosec Institute Inc. He holds Offensive Security Certified Professional(OSCP) Certification. He blogs atwww.androidpentesting.com. Email: srini0x00@gmail.com