Cracking Damn Insecure and Vulnerable App (DIVA) 2023
In this article we will learn about Cracking Damn Insecure and Vulnerable App (DIVA).
In the first four articles, we discussed the solutions for the first eleven challenges in DIVA. In this final article of this series, we will discuss the remaining two challenges that are related to native code.
In case you missed the previous articles in this series, here are the links.
https://resources.infosecinstitute.com/cracking-damn-insecure-and-vulnerable-apps-diva-part-1/
https://resources.infosecinstitute.com/cracking-damn-insecure-and-vulnerable-app-diva-part-2/
https://resources.infosecinstitute.com/cracking-damn-insecure-and-vulnerable-app-diva-part-3/
https://resources.infosecinstitute.com/cracking-damn-insecure-and-vulnerable-app-diva-part-4/

Challenge 12: “12. HARDCODING ISSUES – PART 2.”
Steps to solve[Cracking Damn Insecure and Vulnerable App]:
Click on “12. FIXED CODING PROBLEMS – PART 2” in your application. The goal of this challenge is to find out the vendor key and send it to the application.
The following is the decompiled code that is associated with the activity.

Hardcode2Activity.class
Looking at the above code on Hardcode2Activity.class, it appears that this activity creates an object of class DivaJni on load. Examining the other files, you will find that there is a file called DivaJni.class as shown below.

DivaJni.class
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
AndroidManifest.xml
META-INF
classes.dex
diva-beta.apk
lib
res
resources.arsc
$
Lets navigate
to “lib” folder and run “ls *” to list out all the files within each directory. This is shown below.
$ ls *
arm64-v8a:
libdivajni.so
armeabi:
libdivajni.so
armeabi-v7a:
libdivajni.so
mips:
libdivajni.so
mips64:
libdivajni.so
x86:
libdivajni.so
x86_64:
libdivajni.so
$
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
/system/bin/linker
__cxa_finalize
__cxa_atexit
Java_jakhar_aseem_diva_DivaJni_access
strncmp
__aeabi_unwind_cpp_pr1
Java_jakhar_aseem_diva_DivaJni_initiateLaunchSequence
strcpy
__aeabi_unwind_cpp_pr0
JNI_OnLoad
__aeabi_unwind_cpp_pr2
__gnu_Unwind_Find_exidx
__gnu_Unwind_Restore_VFP_D
__gnu_Unwind_Restore_VFP
__gnu_Unwind_Restore_VFP_D_16_to_31
__gnu_Unwind_Restore_WMMXD
__gnu_Unwind_Restore_WMMXC
abort
restore_core_regs
memcpy
_Unwind_GetCFA
__gnu_Unwind_RaiseException
__gnu_Unwind_ForcedUnwind
__gnu_Unwind_Resume
__gnu_Unwind_Resume_or_Rethrow
_Unwind_Complete
_Unwind_DeleteException
_Unwind_VRS_Get
_Unwind_VRS_Set
__gnu_Unwind_Backtrace
__cxa_begin_cleanup
__cxa_type_match
__gnu_unwind_execute
__cxa_call_unexpected
_Unwind_VRS_Pop
__gnu_Unwind_Save_VFP_D
__gnu_Unwind_Save_VFP
__gnu_Unwind_Save_VFP_D_16_to_31
__gnu_Unwind_Save_WMMXD
__gnu_Unwind_Save_WMMXC
__restore_core_regs
___Unwind_RaiseException
_Unwind_RaiseException
___Unwind_Resume
_Unwind_Resume
___Unwind_Resume_or_Rethrow
_Unwind_Resume_or_Rethrow
___Unwind_ForcedUnwind
_Unwind_ForcedUnwind
___Unwind_Backtrace
_Unwind_Backtrace
__gnu_unwind_frame
_Unwind_GetRegionStart
_Unwind_GetLanguageSpecificData
_Unwind_GetDataRelBase
_Unwind_GetTextRelBase
_edata
__bss_start
_end
libstdc++.so
libm.so
libc.so
libdl.so
libdivajni.so
olsdfgad;lh
.dotdot
GCC: (GNU) 4.8
gold 1.11
aeabi
.shstrtab
.interp
.dynsym
.dynstr
.hash
.rel.dyn
.rel.plt
.text
.ARM.extab
.ARM.exidx
.rodata
.fini_array
.init_array
.dynamic
.got
.data
.bss
.comment
.note.gnu.gold-version
.ARM.attributes
$
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
olsdfgad;lh

We can also find this hardcoded key in the source, which is available at the following link.
https://github.com/payatu/diva-android/blob/master/app/src/main/jni/divajni.c
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@[email protected]@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@[email protected]
.
.
.
.
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:
https://github.com/payatu/diva-android/blob/master/app/src/main/jni/divajni.c
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.

So it is clear that we are writing larger data than the buffer size. Due to insufficient bounds checking in the strcpy() function, a buffer overflow occurs when copying user-supplied input and the application crashes. Any input that is greater than 20 bytes in length will cause a buffer overflow condition in this application.
Also Read:Everything you need to know about Ethical Hacking as a Career by Blackhat Pakistan 2023