# ASLR

**ASLR** works by **randomizing the locations of key components** in a system's memory, such as the location of libraries. This makes it harder for attackers to predict where these components will be located, as it will be different each time the system is restarted or a new process is launched.

ASLR is like [PIE](/pwn/protections/pie.md) for external libraries and kernel components.

{% hint style="warning" %}
**ASLR depends on the environment in which a binary is run**, while PIE can be included in the binary itself and is therefore independent of the environment.

**If a binary compiled with ASLR disabled is run on another system with ASLR enable, it will had ASLR protection.**
{% endhint %}

{% hint style="warning" %}
Such as PIE, it's then impossible to hardcode values such as function address (e.g. `system` for a [ret2libc](/pwn/stack-exploitation/arbitrary-code-execution/code-reuse-attack/ret2libc.md)).
{% endhint %}

{% hint style="danger" %}
Use the followed command in order to disable ASLR to your system :

```bash
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
```

**Don't forget to enable it again using :**

```bash
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space
```

{% endhint %}

## Double-Checking

For the same reason as PIE, libc base addresses always end in the hexadecimal characters `000`.

## Bypassing ASLR

{% hint style="warning" %}
It may be tempting to think that, similar to PIE, leaking a `libc` address using format string and subtracting a static offset from it will work. However, this is not the case.

When functions finish execution, they do not get removed from memory; instead, they are ignored and overwritten. Chances are very high that one of these remnants will be grabbed with the format string. Different `libc` versions can behave differently during execution, so a value grabbed this way may not even exist in the target `libc`, and if it does, the offset is likely to be different due to the varying sizes of different `libc` versions. It is possible to be successful with this method with a high dose of luck, but it should not be relied upon.
{% endhint %}

As explain [here](/pwn/general-knowledge/plt-and-got.md), the **GOT** section is a table within the binary that points to external libraries functions ( such as `puts`, function of `libc`) .

As the GOT is part of the binary, it will always be a constant offset away from the base. Therefore, if PIE (Position Independent Executable) is disabled or the binary base is somehow leaked, the exact address containing the address of a `libc` function can be determined.

{% hint style="info" %}
[ret2plt ](/pwn/stack-exploitation/arbitrary-code-execution/code-reuse-attack/ret2plt.md)is generaly used to bypass ASLR.

There is also methods to [leaks the libc base address](/pwn/stack-exploitation/arbitrary-code-execution/code-reuse-attack/leaking-libc.md).
{% endhint %}


---

# Agent Instructions: 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:

```
GET https://www.ctfrecipes.com/pwn/protections/aslr.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.