Portaloo

Technical Walkthrough

Writeup

Challenge

• Name: Portaloo
• Category: Pwn
• Difficulty: Medium
• Mode: hybrid

Summary

Portaloo is a hybrid pwn challenge built around a portal-management menu. The

binary is a PIE ELF with stack canaries, NX stack, full RELRO, and a provided

glibc, but its own create_portal path marks the heap page as executable.

The working exploit chain is:

1. Create a portal so the heap page is marked RWX.
2. Free that portal without clearing the global slot.
3. Use the dangling slot and peek_into_the_void to leak tcache heap metadata,

recovering the heap page.

1. Reallocate the same chunk through the second portal slot and write a compact

first-stage heap shellcode.

1. Use the first step_into_the_portal read to leak the stack canary suffix.
2. Use the second step_into_the_portal read to restore the canary and return

into the executable heap chunk.

1. Stage /bin/sh shellcode and read the flag.

Artifact Inventory

Reference analysis/artifact-inventory.json and summarize the relevant files or remote surface.

• files/a12c735b-04fc-46d4-9823-1e7a5b565d55.zip: original HTB archive.
• files/extracted/portaloo: challenge ELF, not stripped.
• files/extracted/glibc/: supplied loader and libc.
• analysis/objdump-portaloo.txt: function-level disassembly used for source

audit.

• analysis/leak-probe.txt: bounded live validation of heap and canary leaks.
• solve/probe_leaks.py: leak-validation helper.
• solve/solve.py: final reproducible exploit.

Analysis

Static disassembly showed five menu actions: create, destroy, upgrade, peek, and

step. The important properties are all visible in analysis/objdump-portaloo.txt:

• create_portal allocates 0x20 bytes and calls mprotect on the aligned

heap page with permission 7, making that heap page executable.

• destroy_portal calls free(slots[index]) but leaves the global slot value

unchanged.

• peek_into_the_void prints up to 0x15 bytes from each non-null slot, so it

can read metadata from a freed tcache chunk.

• upgrade_portal writes 0x15 bytes into an existing slot, including a chunk

reallocated from the freed portal.

• step_into_the_portal uses a 0x48 stack buffer, reads 0x50 bytes, prints

it as a string, clears the buffer, and then reads 0x68 bytes before the

canary check.

The first step_into_the_portal read can be made to write one byte past the

buffer into the canary's leading null byte. The following %s print then leaks

the remaining seven canary bytes. The final read restores the full canary and

overwrites the saved return address.

The freed portal leak gives the heap page via glibc safe-linking metadata. The

first portal allocation was reused at page offset 0x2a0, which let the final

payload return directly into the first-stage shellcode stored in the executable

heap chunk.

Solve

Run:

cd <local workspace>
python3 scripts/challenge_exec.py Pwn/Portaloo --phase exploit --output analysis/flag-candidate.txt -- python3 Pwn/Portaloo/solve/solve.py --host <TARGET> --port 30555 --output Pwn/Portaloo/analysis/flag-candidate.txt --debug-output Pwn/Portaloo/analysis/exploit-debug.txt
python3 scripts/challenge_harness.py capture-flag Pwn/Portaloo --from analysis/flag-candidate.txt

The solver derives the per-connection heap page and canary dynamically, writes

the final candidate to analysis/flag-candidate.txt, and stores the raw flag

only through the harness capture step.

Flag

Raw flag is stored in loot/flag.txt and intentionally not reproduced here.

Lessons

• The challenge intentionally pairs strict normal mitigations with one unsafe

design choice: making the heap executable.

• The dangling slot is useful twice: first as a tcache metadata leak, then as a

way to reclaim the same executable chunk.

• For %s-based canary leaks, overwriting only the canary's leading null byte

is enough; the final payload must restore the full canary.

Source-Backed Dossier

The sections below are merged from companion Markdown notes for the same case. They are rendered after sanitization so the article stays precise without publishing raw flags, credentials, or target-specific secrets.

Notes

Scope

• Challenge: Portaloo
• Category: Pwn
• Difficulty: Medium
• Mode: hybrid
• Remote instance: none
• Start time: 2026-06-11T22:39:51Z
• Operator: harness
• State file: challenge-state.json

Harness Status

• Current phase: see challenge-state.json
• Next allowed actions: see next-action.json
• Raw flags and sensitive material stay in loot/ only. Do not paste them here.

Artifact Inventory

Evidence Ledger

Key Findings

• create_portal marks the aligned heap page RWX after the first allocation.
• destroy_portal frees portal chunks but leaves slots[index] dangling.
• peek_into_the_void can print freed tcache metadata, revealing the heap page.
• step_into_the_portal leaks the canary suffix with a one-byte canary overwrite during the first read.
• The final exploit restores the canary and returns to first-stage shellcode in the reused portal chunk at heap page offset 0x2a0.

RAG / Advisory Memory

RAG output is advisory only. Record evaluated retrievals with:

scripts/challenge_harness.py rag-record <workspace> --query "..." --tag MATCHED|PARTIAL|MISSING|<secret redacted>|GENERIC --validation "..."

Secrets/Flags

Raw flags and sensitive material stay in loot/ only. Use scripts/challenge_harness.py capture-flag to validate and record flag capture without printing the value.

Memory Summary

Metadata

• Platform: HackTheBox Challenges
• Category: Pwn
• Challenge: Portaloo
• Difficulty: Medium
• Source workspace: <local workspace>

Validated Solve Chain

Concepts only. Do not include raw flags, reusable credentials, tokens, cookies, private keys, or live secrets.

1.

Reusable Lessons

-

Dead Ends

-

Tool Quirks

-

Evidence Paths

-

Ingestion Decision

• Proposed for LightRAG: yes/no
• Requires user approval before ingestion: yes

Hypothesis Board

Keep no more than 3 active hypotheses on Easy/Medium and 5 on Hard unless the user explicitly asks for breadth.

Closed Branches