13. Insecure Input Validation — Part 3

Galilei
Mobile Penetration Testing
4 min readMay 24, 2019

We cannot conclude Android penetration testing course without discussing native development issues. As you may already know, Stack Buffer Overflow (Read Here Before Start) is the start of this journey. The final step in DIVA application tries to show such an issue. In addition we’ll talk about much more:

  • Using GDB for debugging native libraries
  • using GEF for analyzing registers and exploitation
  • radare2 memory and debugging

In the last Part we discussed about library extraction and analyzing them by rabin2 and radare2. We’ll not repeat them her. Please check here first then if you have any question add to the comments section.

Task number 13 in the DIVA asks for a crash in application. Later in the future steps we’ll exploit this but today we’re going to ficus on fundemental steps of exploitation.

open the adb logcat to see the android device logs. Put 50+, ‘A’ characters in the EditBox of application. then see what happens in the logcat.

Program Counter Register Changed to 0x41414141

Instruction pointer (PC or EIP) changed to 0x41414141 (‘AAAA’) and application crashed. So, the EIP is in the control of us. if we inject shell code and make EIP point to our shell code, it is done.

We didn’t promise you exploiting, It is an other story we’ll reach there soon. Here we are just an starter, we need to analyze this crash deeply.

Configure GDB Server

Connect to the device as root and start the gdb server and attach DIVA process into it.

# Run as root
adb root
# Run ADB Shell
adb shell
# search for DIVA PID
ps | grep jakh
# Attach process to GDB and Listen on port 8081
gdbserver :8081 --attach <PID>

Now we need to connect to gdb server. but, first we need to port forward using adb forward.

GDB Debugger

Start gdb (gef) and connect to port 8081 using gef-remote command.

After loading all libraries, it’ll stop and wait for your command.

You don’t need to do make any breakpoints because when the crash happens, gdb will stop. but if you want to see and set breakpoints on a method you can do it this way:

i function <part-of-name>
b <address-or-name>

For disassembleing the function use this:

disassemble <function-name>

Let’s crash the application again (50+ ‘A’ characters).

remember: c command resumes the application execution in GDB.

Finally, this is what we were seeking. Look deeply into the result shown above. We could override the stack and EIP register.

Radare2

Also we can use radare2 for debugging. r2 is able to attach to gdb session and manipulate the application.

r2 -D gdb gdb://127.0.0.1:8081
  • dc: Continue Execution
  • SIGSEV: crash or stop report
  • dr: print register values in debug time

What is Next?

We’ll start android exploitation in the next parts, then we’ll exploit this issue using that skills.

Final words

We prepared a Step by Step list of Android penetration testing guide based on our own experience here. check for new posts from time to time.

Feel free to add comments to help us improve our posts. by the way, security belongs to everyone.

--

--