Hacker News

My introduction to his work was "The future of RE Dynamic Binary Visualization"[0] which completely blew me away. It still feels futuristic today, 13 years later. Novel UI/UX paradigms like this are slow to find widespread adoption, even when they're so clearly demonstrated to be such an ideal fit for their purpose.

0: https://www.youtube.com/watch?v=4bM3Gut1hIk&pp=ygURY2hyaXN0b...

Alright, a new series to binge now.

If this is the same dude I am thinking of, his wife is also the CISO of Mozilla and do security research together, afair they have a whole book on x86 reverse engineering.

Very cool!

> He does such a fantastic job of explaining his work.

He did a fantastic job of explaining his work.

I saw a recent video and I was shocked that he had hair:

https://www.youtube.com/watch?v=iOq8O_phwbA

He looks so different.

His stuff is something else.

Not sure if it opens up that much on them as far as their security processors go. Modern consoles already treat DRAM as completely untrusted (an attacker could just sit on the DRAM bus and sniff/issue requests there).

The Xbox One for example encrypts all the DRAM it uses after it gets out of the main CPU die. See this part of Tony Chen's presentation https://youtu.be/U7VwtOrwceo?t=956

Also see this bit on the Apple Secure Enclave in the "Memory Protection Engine" section which also explains how they encrypt stuff stored in DRAM: https://support.apple.com/guide/security/the-secure-enclave-...

Seems like this should get us a newer PS4 jailbreak?

Xbox One runs everything under HyperV, so any user created code likely doesn't have the hardware access to use this exploit.

CPU designers have been aware of this attack vector for a while, so many (maybe all) have controls to lock these registers. They are written and locked by vendor firmware before it hands off to the operating system.

You would have first break the firmware or locks before an attack like this on a modern CPU

Zen has completely different memory controller IP (UMC), that's configured at boot by AGESA/PSP. I doubt this exploit applies to modern Zen CPUs, however AMD are the only ones who could really confirm this.

That information is intentionally left out

from the GH page: > Developed and tested on AMD Family 16h CPUs, the last generation whose datasheets document the DRAM controller's translation registers — and show that they can't be locked. 17h and beyond simply leave this information out.

As long as you know the controller's translation registers, it's applicable? Not tested on later one's merely because the information wasn't readily available it seems.

> Developed and tested on AMD Family 16h CPUs, the last generation whose datasheets document the DRAM controller's translation registers — and show that they can't be locked. 17h and beyond simply leave this information out.

Reaching into ring -2 or the TPM allows privilege escalations past traditional "root permissions" and lets attackers defeat the sort of tamper protection that's designed to make escalations to local root manageable. Wipe-resistant malware, falsified cryptographic attestations, all sorts of fun.

This is more about getting at the code that device manufacturers attempt to hide from the end user. Platform keys, secure enclaves, etc...

Yep, I believe so

1) Don't give your guests access to the DCT control registers.

2) On 15h - no obvious way. I don't know the other families.

3) Yes -- this can be verified easily. Pick up the AMD 15h BKDG, look up BankSwizzleMode. It's documented. The one oversight is that this bit is not under the Dram Controller's lock bit.

One hopes that a hypervisor would not expose hardware control registers directly in the first place, except ones deliberately designed for virtualization support.

Otherwise, the guest is running effectively at the same privilege level as the hypervisor (that's useful sometimes, but probably not intended in most applications).

This hack is 99% giving people the control over their own computers they should already have had. Guy is a Robin Hood.

This doesn't require physical DRAM access, it's all software.

With ring-0 access, this lets you poke "even things walled off and invisible to ring-0 or the CPU itself" including things that the security processor tries hard to wall off.

You're missing that modern CPUs substantially lock the users out of control of their own computer and include things like hidden additional network connected processors that run their own full on operating systems. ... and may well be used to surveil or remotely access your computers the the behest of powers unknown.

But they still use system dram, so this approach allows looking into those parts of your own computer from which you're normally blocked. At least on some hardware...

Even physical DRAM access would be thwarted by transparent total memory encryption, so this hack is still something else.

I came to the comments to complain about how unreadable it was, saw that it was the movfuscator guy, went back to check if I somehow made a mistake but no, if anything that writeup is one of the egregious ones I've seen recently. What a shame, I really liked his talks.

Maybe this is to keep script kiddies away?

Like.. having no readme or a super technical one doesn't work anymore in the age of LLMs, but having one that hurts to read might?

Because people trying to get an LLM to translate it just get more LLM output. So you actually _have_ to put in manual effort to rip out what the fuck it wants to tell you.

That would be clever.

Disappointing indeed. Us security folk have already earned a poor reputation for ineffective technical communication, and LLMs are even worse, not better. This is especially disappointing in this case because we know xoreaxeaxeax is one of the few who are actually capable of effectively communicating beautifully cursed low-level hackery, but is now choosing to outsource the most impactful part of his work (since most people will only read the abstract, I mean, README) to an LLM. I'll still take new projects with sloppy READMEs over the previous years of radio silence, but I really wish xoreaxeaxeax would recognize the value in spending the time to write a single page of text in his own voice.

I find vague gestures like this almost more annoying than the idea of someone using AI to write.

> the Claudeisms

This is hand-waving. Please be more specific.

> made it such a slog

On the flip-side, I didn't find it a slog at all. What if you're wrong?

Without any swizzling, certain common access patterns can end up with subpar performance, for example walking the columns of a 2d array with a certain stride - if it ends up directing every access to the same bank on the same channel, the throughput is much lower than if the load was evenly distributed across multiple banks/channels.

Swizzling "randomizes" bank/rank/channel distribution, which makes unlucky access patterns less likely. (Something I'd like to research is microbenchmarking different access patterns to infer the swizzle pattern and defeat physical ASLR)

He also released another research just a few days ago https://news.ycombinator.com/item?id=49245491

Oh that's a clever attack. The RAM bus was often thought of as off-limits because of the speed and signal integrity requirements. They bypassed those.

Seriously. Got tired of reading the same idea over and over reworded endlessly.

I got suspicious but decided it wasn’t AI. The “Foo is the bar.” sentence construct is coherent with the overall “through the looking glass” tenor.

Is ARM truly more user-friendly in this regard? And I dont see no genuine alternative than arm64

Guardrails are a product-quality smell. Boycott guardrailed models. Punish guardrailed model providers with reduced revenue and bankruptcy. "I'm sorry Dave" must become a subscription-cancelling response or the nannying will never stop!

Well, K3 has no problem, Sol is also fine-ish

I got you, bro:

The hardware DRAM controller maps "physical addresses" approximately to: {DRAM slot number, chip number in slot, bank number in chip, row number in bank, byte number in row} via a complex map for various irrelevant reasons. All permission checks are before this mapping. So if you change the mapping, you can access shit you should not be able to, like TPM and SMM memory. OP found a way to change the mapping.