In-Memory Patching -- GDB (ARM64)

We are going to write a simple C program and use GDB to modify its behavior at runtime. This technique is widely used in reverse engineering, but what we are doing here is purely temporary: the modifications exist only in memory while the program is running. Once the execution ends, the original binary remains untouched — no permanent changes are written to disk.

1. The C program

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

char *read_char() {
    char *str = NULL;
    int length = 0;
    char c;
    while ((c = getchar()) != '\n' && c != EOF) {
        char *tmp = realloc(str, length + 2);
        if (!tmp) {
            free(str);
            return NULL;
        }
        str = tmp;
        str[length++] = c;
    }
    if (str)
        str[length] = '\0';
    return str;
}

int main() {
    printf("Username : ");
    char *nom = read_char();

    printf("Password : ");
    char *mdp = read_char();

    if (!nom || !mdp) {
        printf("Allocation error\n");
        free(nom);
        free(mdp);
        return 1;
    }

    const char *pass = getenv("PASSWORD");
    if (pass == NULL) {
        printf("Error: PASSWORD not set.\n");
        return 1;
    }

    if (strcmp(mdp, pass) == 0) {
        printf("Access granted.\n");
    } else {
        printf("You are banned!\n");
    }

    free(nom);
    free(mdp);
    return 0;
}
            

Note: This code is for demonstration purposes only. In a real situation, the verification process would not be implemented this way.

This program dynamically reads a username and password, then compares the entered password to the real one to grant or deny access. We are going to bypass this verification using gdb.

2. Starting GDB

Pre condition: The program expects the real password to be stored in an environment variable before execution i.e
"export PASSWORD=gdb_learn"
Without this, the program will immediately exit with "Error: PASSWORD not set".

Compile the c program with this (In this case, my file is named main.c) : "gcc -g main.c -o main"
Now, run with gdb : " gdb ./main"

To bypass the verification, we need to make the program believe that the line "strcmp(mdp, pass)" returns 0, which means that the correct password has been entered.

In gdb, type "start"
- We need to pause the program at the very beginning of main so we could inspect it before any important instructions are executed.
- Also, because of ASLR (Address Space Layout Randomization), the real memory addresses change every time the program starts.
- By stopping at the start, we could later get the real, relocated addresses to place our breakpoints correctly. (break at strcmp)



Now, we need to disassemble the main using this command : "disassemble main" in gdb.
This is because, we need to understand where the password check happens in assembly.

- The strcmp call (bl strcmp@plt), this is where the entered password is compared with the real one (the red boxed line on the image below)
- The instruction immediately after (cmp w0, #0) | where the program decides if the password is correct.
- Without this, we wouldn’t know where to stop the program to modify its behavior.

3. Setting the breakpoint AFTER strcmp

We now have the memory adress where the verification is taking place and we're setting a breakpoint at that area : "break *0x0000aaaaaaaa0a70" is the command to type in gdb

Why after strcmp?
Inside strcmp, the comparison is still running → modifying registers there could crash the program.
Right after strcmp, the result is already stored in w0:

0 → correct password,
≠0 → wrong password.

4. RUN the program

Now, run the program by simply typing "run" in gdb. The program will run normally and your username and password will be asked. Submit any credentials to continue.
Once you submitted the credentials, you will reach the breakpoint which was set before as show in the picture below.

5. Finally bypassing the verification

On AArch64, w0 holds the return value of strcmp. Forcing it to 0 makes the program believe the entered password is correct, even if it’s wrong.
We will therefore modify this behavior by typing this command : "set $w0=0"
When this is done, the verification has been bypassed and we can now type "continue" in gdb to proceed with the end of the progam. The full access will be given to you.

6. Conclusion:

This experiment demonstrated how to bypass a password verification on an AArch64 binary using GDB by modifying the program’s flow at runtime. By carefully choosing the breakpoint after the strcmp call and altering the w0 register, we successfully gained access without knowing the real password. This highlights the importance of secure coding practices and avoiding reliance on simple client-side checks.