DRAM unlock nerd stuff

Despite having all this, we still see exploits like use after free in 2026. That raises a question - do they really matter or not?

They do, but not when you pass an unsanitised string into eval(), then nothing can save you. Typically those data pages have NX (no execute), W^X (either write or execute, not both) flags set, but copying it to eval() means you’ll run the bytes anyway (command injection)…

Broadly, security measures enable:

1. restricting access & execution of user land page files (SMAP, SMEP - supervisor mode access / execution prevention)
2. concealing the actual mem addresses even to the same process running in the same memory space (to avoid copying of data through a compromised part from same process)
3. isolation of memory resources & translation layers (the other party doesn’t even know whether a resource exists or not, let alone guess)
4. prevent impersonation (like devices copying data through DMA (direct memory access), by acting like one).
5. more hardcore restrictions (data that is only visible to ring -2, 2 level below kernel’s ring 0)
6. cryptographic trust (to prevent hw exploits, and runtime system tampering)

Cache mechanisms in place before reading a single bit from the DRAM (ordered, assume everything misses) ^[1]:

1. TLB translation buffer (virtual address -> physical address mapping + permissions)
2. walks 4 levels of pages (PML4, PDPT, PD, PT) + LA57 (5th), and finds a pointer to top-level page table addresses in (CR3) register. And the corresponding frame in CPU’s SRAM cache (dedicated SRAM cache to store these page tables, not the same as the cache from next point).
3. L1, L2, L3, LLC (last level) caches

If you do not want any of that, and wish to have a straight conversation with DRAM directly, follow https://github.com/xoreaxeaxeax/skitter-creek-bath-salts

Footnotes

1. based on my understanding, I’m not an expert in this topic so please cross check with actual resources. ↩︎