-1

I have a CTF challenge in which i've got a simple code vulnerable to buffer over flow (via strcpy) which looks like:

#include <stdio.h>
#include <string.h>
int display(char *text)
{
        char buffer[20];
        strcpy(buffer, texte);
        printf("%s\n",buffer);
}

int main(int argc, char ** argv)
{
        char forbidden[]={0x00, 0x80, 0x89, 0xe1, 0x89};
        int i,j;
        if (argc!=2)
        {
                printf("Usage: %s <text>\n", argv[0]);
                return 1;
        }
        for(i=0;argv[1][i];i++)
        {
                for(j=0;forbidden[j];j++)
                {
                        if(argv[1][i] == forbidden[j])
                        {
                                printf("Shellcode detected!\n");
                                return 1;
                        }
                }
        }
        display(argv[1]);
        return 0;
}

I managed to debug via GDB and see the addresses and instructions, I took full control of the memory, so I managed to corrupt the memory and inject my own shellcode, and change the return address to that block which runs my code.

But what bothers me, is the code check forbidden characters that I need to use to execute a \bin\cat, which really relies on 0x80 (OpCode of system call), i used shellcode generator such as masterccc.github. But it nevers provide me a shellcode without those forbidden characters, i tried as well an encoder (change shellcode instructions but have the same semantic) but no way.

I just want to know if i am in right path, and i have to execute shellcode and bypass this verification, or it's wrong path ? give me some Hint please.

I'm working on x86 32-bit.

E Epsylon
  • 56
  • 1
  • 6

1 Answers1

1

There are other ways to get a shell ;) You should probably check what is a ROP chain

If you still want to use a shellcode (and this is probably the easiest way), you could also inject it in an env variable instead of the argv[1] and use jmp ADDRESS_OF_THE_SHELLCODE_IN_ENV in argv[1]. It won't trigger the forbidden characters.

Have fun with the CTF!

atxr
  • 49
  • 6
  • 1
    That could be a great idea also! I was thinking about the env variable like this: `SHELLCODE=$(cat my_shellcode) ./my_ctf_binary` – atxr Feb 15 '23 at 09:50
  • Thanks for answering, what do you mean by env variable instead of argv[1] please ?! i thought you were meaning argv[2] but it's forbidden by the code (argc == 2 forced) – E Epsylon Feb 15 '23 at 09:51
  • I am working now, i'll try once i'm and give you a feedback, i have never known a such concept before (env variable) wish it will be injected to the memory. – E Epsylon Feb 15 '23 at 09:53
  • 1
    You should probably open gdb and type `show env`! You'll see all the env variables that the shell forwards to your binary. You can inject some shellcode here and trigger it later. All of this work of course if you have NX disabled for this section. – atxr Feb 15 '23 at 09:54
  • 1
    Oh my god, it works, the shellcode has been injected into env, but how can i determine its adress where its stored, is there anyway ? i found online that i can reach it just by shifting over the ebp register, it comes on the top ! – E Epsylon Feb 15 '23 at 16:57
  • Congrats! For the address you can use a trick called a NOP sled. The idea is to put a lot (like a huuuuge number) of NOP operation before your shellcode when injecting. Then, you can put an approximate address (go in gdb, search for your shellcode and use this address) when exploiting The problem with the env is when you go out of gdb, or when you go from your local binary to the one you want to pwn in the server, the `env` might change and therefore the address of the shellcode. But thanks to the NOP sled, you don't care if the address change as soon as you land on the sled! – atxr Feb 16 '23 at 08:30
  • 1
    \x90 :D yes i used it a lot and cached the flag :) thanks a lot boys – E Epsylon Feb 16 '23 at 08:33
  • 1
    Nice well done! – atxr Feb 16 '23 at 08:35
  • 1
    You can use the `search-pattern` command in GDB For example, you inject this: ``` NOP SLED + AAAABBBBCCCCDDDD ``` Then debug, and `search-pattern AAAABBBBCCCCDDDD` – atxr Feb 16 '23 at 08:41
  • 1
    BTW `search-pattern` is from the [gdb-gef extension](https://hugsy.github.io/gef/commands/search-pattern/) which a hugely recommend – atxr Feb 16 '23 at 08:42
  • 1
    You've just teach me a lot of things in your answer, you are a hero :) – E Epsylon Feb 16 '23 at 08:47
  • 1
    Aha no problem :) I'm glad if it helped you! – atxr Feb 16 '23 at 08:51