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