Hardcoded HEAP_BASE, LIBC_BASE, and PREREAD_HEAP_OFFSET do not work for all machines

[terry422]

HEAP_BASE, LIBC_BASE, and PREREAD_HEAP_OFFSET in my machine are different than what is written in poc.py.

root@a44933714e16:/app# ps axf
    PID TTY      STAT   TIME COMMAND
     31 pts/1    Ss     0:00 bash
     43 pts/1    R+     0:00  \_ ps axf
      1 pts/0    Ss     0:00 /sbin/docker-init -- /app/entrypoint.sh
      7 pts/0    S+     0:00 nginx: master process /nginx-src/build/nginx -p /app -c /app/nginx.conf
      8 pts/0    S+     0:00  \_ python3 server.py
     10 pts/0    S+     0:00  \_ nginx: worker process
root@a44933714e16:/app# cat /proc/10/maps | grep heap
555555691000-5555556f6000 rw-p 00000000 00:00 0                          [heap]
5555556f6000-555555717000 rw-p 00000000 00:00 0                          [heap]
root@a44933714e16:/app# cat /proc/10/maps | grep libc.so
7ffff77b6000-7ffff77de000 r--p 00000000 00:2f 37364884                   /usr/lib/x86_64-linux-gnu/libc.so.6
7ffff77de000-7ffff7973000 r-xp 00028000 00:2f 37364884                   /usr/lib/x86_64-linux-gnu/libc.so.6
7ffff7973000-7ffff79cb000 r--p 001bd000 00:2f 37364884                   /usr/lib/x86_64-linux-gnu/libc.so.6
7ffff79cb000-7ffff79cc000 ---p 00215000 00:2f 37364884                   /usr/lib/x86_64-linux-gnu/libc.so.6
7ffff79cc000-7ffff79d0000 r--p 00215000 00:2f 37364884                   /usr/lib/x86_64-linux-gnu/libc.so.6
7ffff79d0000-7ffff79d2000 rw-p 00219000 00:2f 37364884                   /usr/lib/x86_64-linux-gnu/libc.so.6

Also, POST sprays also landed at different offsets, so I had to manually spray and find out the correct candidates.

Could be helpful if poc.py or README.md had some comments about this.

[NadjiHamid]

this behavior is expected given how this PoC is constructed, rather than an issue in your environment.

The key point is that the values for HEAP_BASE, LIBC_BASE, and PREREAD_HEAP_OFFSETS in poc.py are not dynamically derived at runtime. They are precomputed layout assumptions taken from a specific execution snapshot where the heap state was known and reproducible.

In your case, the differences you observed are consistent with normal runtime variance inside modern Linux/container environments:

---

1. Heap base divergence

The heap base you observed:

0x555555691000

differs from the hardcoded:

HEAP_BASE = 0x555555659000

This is expected due to:

ASLR still affecting heap placement (even inside Docker)

glibc malloc behavior depending on request history

brk/mmap transition thresholds varying per run

prior allocations from nginx startup sequence shifting heap origin

As a result, the heap base is not stable across executions, even if the system appears identical.

---

2. libc base mismatch

Similarly, the libc mapping you observed:

7ffff77b6000

vs PoC assumption:

7ffff77ba000

is explained by:

standard ASLR randomization of shared libraries

loader-dependent mapping offsets

container image + libc version differences

slight differences in process initialization order

Even small shifts here invalidate absolute-address assumptions like:

SYSTEM_ADDR = LIBC_BASE + 0x50d70

---

3. PREREAD_HEAP_OFFSETS are snapshot-specific

This is the most important part.

The PREREAD_HEAP_OFFSETS list is not generic. It encodes:

observed heap object layout from a single controlled run

relative distances between allocations in that specific allocator state

deterministic ordering assumptions (request sequence + timing + pool reuse)

In your environment, nginx introduces variation due to:

request scheduling differences

body parsing timing

allocation reuse patterns in pools

spray timing and TCP segmentation effects

Therefore:

spray landing positions shift

expected adjacency patterns break

manual exploration becomes necessary

---

4. Why POST spray behaves differently

The spray phase depends heavily on:

connection reuse behavior in nginx

timing between concurrent requests

buffering strategy for request bodies

kernel-level socket scheduling

Even small timing differences can change:

which pool chunk is allocated first

where large buffers land in memory

whether reuse occurs or fresh allocation happens

So the spray is inherently probabilistic unless fully synchronized with a calibration phase.

---

5. Architectural implication (important)

This PoC assumes a pre-calibrated heap topology model, meaning:

memory layout is treated as stable

offsets are derived from a known-good run

exploitation is performed under near-identical conditions

In your setup, you are effectively running it in a non-calibrated environment, which exposes the lack of:

runtime heap base discovery

libc leak stage

adaptive offset adjustment

feedback-driven spraying loop

---

6. Why manual spraying "fixes" it

Your observation that manual spraying helps is correct and expected.

What you are effectively doing is converting:

deterministic layout assumption

into:

probabilistic heap search / convergence

This is commonly required when:

absolute addresses are unavailable

allocator state is not fully reproducible

timing introduces variability

---

7. Suggested improvement to the PoC

It would improve clarity if the repository explicitly stated that:

all offsets are snapshot-derived

ASLR is assumed disabled or controlled

heap layout is expected to be stable across runs

no runtime calibration is implemented

Additionally, a more robust design would typically include:

heap/libc base discovery phase (info leak or inference)

relative addressing instead of absolute offsets

adaptive spraying with feedback (crash/no-crash loop refinement)

---

Summary

What you're observing is not a misconfiguration — it's a direct consequence of running a static heap model exploit in a dynamic allocator environment.

The PoC is essentially based on a frozen memory snapshot, while your runtime behaves as a probabilistic system with varying heap geometry.

---