Debugging Android Application using GNU Debugger

What is GNU Debugger?
The GNU Debugger (GDB) is a powerful and versatile tool used for debugging applications and systems at the binary or machine-code level. It allows developers and security researchers to analyze and manipulate running processes, set breakpoints, inspect memory, examine the call stack, and much more. This functionality makes GDB an essential tool for software development, reverse engineering, and security research, including Pentesting.

GDB in the Context of Android Pentesting
In Android Pentesting, GDB can be used to analyze how applications function at a low level, identify vulnerabilities, and understand the behavior of software components. Here are some common ways a pentester might use GDB during Android security assessments:

• Reverse Engineering Android Binaries
• Debugging Applications
• Bypassing Security Controls
• Analyzing Exploits
• Memory Inspection and Data Extraction

Pre-Requisite

• ADB : Ensure you have the Android Debug Bridge (ADB) installed and your device is connected for debugging.
• GDBServer : If GDB isn’t installed on the device, you might need to transfer a compatible version using ADB. You can download the gdbserver from here.
• Root ADB Shell : Some debugging tasks require root access. Ensure your device is rooted, or consider rooting it for deeper analysis.

Step-1: Attaching GDB to a Process
Before attaching GDB, ensure you have the necessary permissions and the process ID (PID) of the target application or service. You can list running processes using ADB or within GDB itself.

# Get the list of processes
adb shell ps

# Attach to a specific process (replace <PID> with the process ID)
gdb -p <PID>

Step-2: Setting Breakpoints
Breakpoints are used to pause the execution of the program at specific points. This helps you examine the state of the application, including the stack, registers, and memory.

• Function Breakpoints: Set breakpoints at specific functions or methods to analyze their behavior.

# Breakpoint at a function name
break <function_name>

• Address Breakpoints: Set breakpoints at specific memory addresses.

# Breakpoint at an address
break *0x12345678

Step 3: Stepping Through Code
Once you’ve set breakpoints, you can step through the code to understand the control flow and identify any unusual or potentially exploitable behavior.

• To execute the current line and proceed to the next one without entering functions.

next

• To execute the current line and enter into any function call.

step

Step 4: Examining Variables and Registers

Inspect the values of variables and CPU registers to identify potential vulnerabilities or unexpected behaviors.

• Inspect Variables: Look at local or global variables to understand how data is being used.

print <variable_name>

• Check Registers: Examine CPU registers to understand the state of the program.

info registers

Step 5: Analyzing Memory

Memory inspection can reveal potential vulnerabilities such as buffer overflows, use-after-free, or improper memory access.

• Memory Dump: Examine a specific memory region to look for sensitive data or anomalies.

x/10x <address>  # Dumps 10 words in hexadecimal starting from the given address

• Memory Corruption: Look for patterns that indicate buffer overflows or memory corruption.

# Example: Check for buffer overflow
x/100x <address>  # Examine a larger memory region to spot unusual patterns

Step 6: Testing for Vulnerabilities

Test known exploit scenarios or behaviors that could indicate a vulnerability.

• Manipulate Variables: Change variable values to test if the program behaves unexpectedly.

set variable <variable_name> = <new_value>

Alter Execution Flow: Modify registers or addresses to force the program to take a different code path.

set $pc = <new_address>  # Change the program counter (instruction pointer)

Step 7: Examine Logs and Output

Check the application’s output or logs to identify errors or unexpected messages that could point to vulnerabilities.

• Analyze Application Output: Look for crashes, errors, or unusual behavior that could indicate security issues.

adb logcat  # View Android system logs