# Pwn1
We're given a file and an address to connect to once we've found the solution for the file.
First off, let's see what the program does.
```$ ./pwn1```
![](https://raw.githubusercontent.com/shawnduong/ctf-writeups/master/2019-TAMU/images/pwn1-0.png)
Looks like we're going have to find out what the correct inputs are. Let's run `ltrace` on it to see how the `strmp` behaves.
By running `ltrace`, we can discover what the first two answers are by looking at the strings that `strcmp` compares them to.
```$ ltrace ./pwn1```
![](https://raw.githubusercontent.com/shawnduong/ctf-writeups/master/2019-TAMU/images/pwn1-1.png)
The last one, however, is a little bit problematic because it does not use `strcmp`. Let's disassemble it then to see how it handles comparisons.
```$ objdump -d -M intel pwn1 > disassembly.asm$ vim disassembly.asm```
![](https://raw.githubusercontent.com/shawnduong/ctf-writeups/master/2019-TAMU/images/pwn1-2.png)
These few lines are of particular importance to us. `0x8aa` calls `gets()`, which is what prompts us for our input. `0x8b2` compares a double word (4 bytes) located in memory at `ebp` minus `0x10` with the hexadecimal sequence `0xdea110c8`.`gets()` stores data in the `eax` register, which is pointing to a memory address at `ebp` minus `0x3b`. By now, it should be thoroughly evident that this is a classic buffer overflow problem.
We need to first calculate how many bytes it will take for us to reach the target address from the buffer. The buffer that we are inputting data into starts at `ebp` - `0x3b`. The target address starts at `ebp` - `0x10`. `0x3b` - `0x10` = `0x2b`, which is 43 in decimal. Thus, we need 43 bytes of padding. The program is also in little-endian format, which means that we need to input `0xdea110c8` in reverse order, or `0xc810a1de`. 
Our final payload is the answers to the first two questions followed by 43 bytes of padding plus our hexadecimal sequence.
A big problem is that when we input data into the program, it will interpret it as characters, which is problematic for us because we want the program to interpret it as hexadecimal. In order to get around this, we can put our inputs into a file, and then feed it to the program via the pipeline.
These three commands handle the first two answers, plus the padding.
```$ echo "Sir Lancelot of Camelot" > inputs$ echo "To seek the Holy Grail." >> inputs$ python -c "print('A' * 43)" >> inputs```
![](https://raw.githubusercontent.com/shawnduong/ctf-writeups/master/2019-TAMU/images/pwn1-3.png)
We can append the hexadecimal sequence using a hex editor. I personally use [Bless](https://github.com/bwrsandman/Bless). We also have to remember to insert a line feed, `0A`, to denote an "Enter" and submit the input into the prompt.
![](https://raw.githubusercontent.com/shawnduong/ctf-writeups/master/2019-TAMU/images/pwn1-4.png)
Now that we've generated our payload, we can run it through the script by feeding it through the pipeline.
```$ cat inputs | ./pwn1```
![](https://raw.githubusercontent.com/shawnduong/ctf-writeups/master/2019-TAMU/images/pwn1-5.png)
The reason we get a segmentation fault is because this is a local copy of the file, and so it can't exactly process the win instructions correctly. However, recall that an address was given to us of a server running this program. We just need to feed our payload to that program running on that server now. We can again do this using our payload file and the pipeline.
```$ cat inputs | nc pwn.tamuctf.com 4321```
![](https://raw.githubusercontent.com/shawnduong/ctf-writeups/master/2019-TAMU/images/pwn1-6.png)
And just like that, we have our flag!