> For the complete documentation index, see [llms.txt](https://hacking-notes.jord4n.pro/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hacking-notes.jord4n.pro/useful-resources/exploit-development/linux-buffer-overflow-custom.md).
# Linux Buffer Overflow - Custom
Custom Linux buffer overflow notes for building exploits, controlling execution flow, crafting payloads, and documenting memory corruption methodology.
## First example of custom binary (Pdmenu/exim):
Download the machine pluck
> The first example focuses on exploiting the legitimate exim-4.84-7 binary, which has a vulnerability identified as CVE-2016-1531. This vulnerability allows an attacker to execute commands with privileges by abusing certain environment variables.
* In this case, when we access the user Paul, a **Pdmenu** is assigned to him with certain functionalities (directory listing, file editing, ping launch, etc.):
* To escape this menu, we **edit a file**, for example (etc/host):
* In this case, **vi** is used as a text editor:
* Looking at **gtfobins**, if we filter by vi, we get the commands to exit Pdmenu and **execute a shell**:
* We filter **SUID** files and find one called exim:
* With the **searchsploit** tool, we search for possible vulnerabilities for this binary:
* Now download the script and serve it with **python3** so it can be loaded after the machine is compromised:
* We execute the script and indeed the vulnerability of this binary is exploited, we thus obtain **root access**:
## Second example (buffer overflow):
Download the vulnerableUbuntumachineInstall the toolPeda
> The second example concerns a **Buffer Overflow** in a custom [binary](https://hack4u.io/wp-content/uploads/2023/04/custom) on a 32-bit Linux machine with active protections and ASLR enabled. In this case, we focus on exploiting ret2libc in a binary that has SUID permissions and is owned by root. Through buffer overflow, we demonstrate how to inject privileged commands and elevate user privileges.
\***Buffer Overflow** involves overwriting certain system registers, and since the binary is created by the user and belongs to the root group, **it will run as a privileged user**:
* The binary called "custom" expects a **string input** and when it is executed, nothing happens:
* But if we enter a **very long string**, it returns an error (core dumped):
We send a **short string** of AAAAAAAA and no **errors appear**:
* To analyze the binary in depth, we will use the **gdb-peda** tool.
* But if we send **many characters**, we get the following error:
1. The first thing to do is to **determine the total number of strings** needed to overwrite the register (EIP).
* The first method consists of using a **motif (pattern)** that creates a chain **spatially designed** (in these cases, 300 characters) that our executions in the binary:
* In the response of **EIP**, we know that the **lower visible chain** is "AA8A":
* The **automatic** mode of the faire is with the `pattern offset $eip` command:
* To check this, we use **python3** by sending 112 A characters plus then final 4B:
```bash
r $(python3 -c 'print("A"*112 + "B"*4)')
```
* In effect, we now confirm the tail thanks to **EIP** which detects the 4 derniers B:
2. Once we know the maximum number of strings, we **check the ASLR** which will determine if there is **randomness in the memory addresses** or not:
/- With the following command we filter the strings we are interested in specifically to run the binary 10 times to see if it changes each time and to see if the **C library** is random or not:
It is indeed "random"
3. The problem with these **32-bit** binaries is often that if we run for example now **1000 times** A and filter by a fixed string, we see that each time, **it will repeat at least once**:
4. The objective now is to first find **EIP** strings (**system + exit + bin/\_sh**), which will always be fixed and necessary to execute a **Bash as root** as in the following example but in Python:
* We create a **breakpoint** so that the program flow stops at hand:
* We inject the **EIP** of (system/exit/bin/\_sh):
5. Once we see that there is **random**, we will need to use **brute force** until the **base/\_libc/\_addr** is equal to the desired value:
/- With the following we will see the **libraries that are running** (in this case **libc.so**):
* With **readelf**, our filters for the library and search for the variables injected ahead, which are (**exit and system**) with the codes:
* And to find the string **/bin/sh**, we do the following, adding a **0x00** at the beginning:
The following Python3 script will **automate all the brute force** until **base/\_libc/\_addr** is the same:
```python
#!/usr/bin/python3
import subprocess
from struct import pack
import sys
offset = 112
before_eip = b"A" * 112
# Custom Linux Buffer Overflow
base_libc_addr = 0xb7595000
system_addr_off = 0xb7d86db0
exit_addr_off = 0xb7d7a9e0
bin_sh_addr_off = 0xb7ea7b2b
system_addr = pack("
---
# 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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://hacking-notes.jord4n.pro/useful-resources/exploit-development/linux-buffer-overflow-custom.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.
