> For the complete documentation index, see [llms.txt](https://alham-rizvi.gitbook.io/alhamrizvi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://alham-rizvi.gitbook.io/alhamrizvi/binary-exp/04.-stack-overflow/challenge/ret2win/chall1.md). # chall1 this challenge for ret2win is super cool! ## Solution image image image The binary takes user input using `gets()` into a fixed-size buffer, making it vulnerable to a classic stack buffer overflow. The goal is to redirect execution to the hidden `win()` function, which spawns a shell. During initial recon, running the program shows it accepts input and prints a number. Looking at the source (or reversing), we identify a vulnerable pattern: ```c char buff[30]; gets(buff); ``` Since `gets()` does not perform bounds checking, we can overflow beyond `buff` and overwrite adjacent stack values, including the saved base pointer and return address. To understand the stack layout, the binary is inspected in GDB. Disassembling `main` shows: ```asm sub rsp, 0x30 ``` This allocates 48 bytes on the stack. Even though the buffer is only 30 bytes, the compiler aligns it to 48 bytes. After this comes: * saved RBP (8 bytes) * return address (8 bytes) So total offset to RIP: ``` 48 (buffer region) + 8 (saved RBP) = 56 bytes ``` *** To avoid guessing, a cyclic pattern is used. A 100-byte cyclic string is generated using pwntools and sent as input. The program crashes with a segmentation fault. Inspecting the stack in GDB shows parts of the cyclic pattern where the return address should be. Using the observed value from the crash and passing it into `cyclic_find()`, the exact offset is confirmed to be 56 bytes. This matches the manual calculation from the disassembly. *** Next, the address of the target function is required. Using GDB: ```gdb info functions win ``` This reveals: ``` 0x0000000000401216 win ``` Since the binary is compiled without PIE, this address is static and can be used directly. *** Because the system is 64-bit, the return address must be written as an 8-byte value in little-endian format. This is handled using `p64()` from pwntools. The final payload is constructed as: ``` [A * 56] + [address of win()] ``` *** One important issue encountered was using `print()` to send the payload. This adds a newline character, which corrupts the exploit. The correct approach is to send raw bytes using `sys.stdout.buffer.write()`. The working exploit: ```bash python3 -c "import sys; from pwn import *; sys.stdout.buffer.write(b'A'*56 + p64(0x401216))" | ./ret2win ``` *** Upon execution, the return address is overwritten with the address of `win()`. When `main` returns, execution jumps directly into `win()`, which prints a success message and spawns a shell: ``` [+] PWNED!!! ``` *** This challenge demonstrates a full ret2win exploitation flow: * identifying unsafe input (`gets`) * analyzing stack layout via disassembly * finding offset using cyclic patterns * locating target function address * crafting a precise payload with correct endianness * handling real-world issues like newline corruption It serves as a foundational example of control flow hijacking and prepares for more advanced techniques like ret2libc and ROP chains. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://alham-rizvi.gitbook.io/alhamrizvi/binary-exp/04.-stack-overflow/challenge/ret2win/chall1.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.