Spaghettifying DRAM
github.com
github.com
- Psychological Warfare in Reverse Engineering https://www.youtube.com/watch?v=HlUe0TUHOIc
- The MoVfuscator https://www.youtube.com/watch?v=R7EEoWg6Ekk
- Hardware Backdoors in redacted x86 https://www.youtube.com/watch?v=jmTwlEh8L7g
0: https://www.youtube.com/watch?v=4bM3Gut1hIk&pp=ygURY2hyaXN0b...
Very cool!
https://onlinelibrary.wiley.com/doi/book/10.1002/97813942771...
He did a fantastic job of explaining his work.
I had to look at the comments here to understand what was going on
So maybe he USED to explain things well, but that's not on display
https://www.youtube.com/watch?v=iOq8O_phwbA
He looks so different.
Ok, the necessary refresh was always a little pain, but still something manageable.
Nowadays, I feel you need three PhD's to even bring up a micro with DRAM and don't get me started on the proprietary binary blobs necessary just for DRAM access. No wonder PSRAM is a thing.
The corollary is that it shouldn't be too surprising that this gigantic attack surface provides many opportunities. (Of course that doesn't mean it is easy to find them, hat tip to Christopher Domas, just that I expect there to be many more).
Then there's the electrical bus: DDR5 runs so fast it need channel characterisation (sorta like the old model dial up sounds) on the lines between the controller and the DRAM. No more 5V and 0V for TTL signals there.
You can draw an analogy for comprehension purposes between DFE and 1/2.5/5/10G auto-detection logic in Ethernet, which does various circuit-level characterization; and between MBIST and f3probe, which writes data and then reads it back in various algorithmic test patterns to ensure that the electrical training produced a usable result that can carry data as specified rather than just claiming to and then crashing later on.
I’m sure Xbox and PlayStation security groups are a little nervous right now though. Getting ring-0 on those machines is near impossible, but once you do then everything else becomes wide open
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-...
See the slide on Tony Chen's presentation about Xbox One security https://youtu.be/U7VwtOrwceo?t=843 and this video from the person who hacked the Xbox One https://youtu.be/FTFn4UZsA5U?t=299
You would have first break the firmware or locks before an attack like this on a modern CPU
> Developed and tested on AMD Family 16h CPUs, the last generation whose datasheets document the DRAM controller's translation registers
> 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.
But why on earth do they have to use AI to write their writeups?!
But I have a new favorite way of demonstrating this:
https://github.com/search?q=owner%3Axoreaxeaxeax+load-bearin...
Guess how many of these are from before 2025.
Ring -1 needs DRAM, so it tells the memory controller to give it some blocks. The memory controller hands back a “physical” address, and promises not to let anything but ring -1 access that address.
The exploit takes advantage of that control register to remap the same DRAM blocks to a different physical address. Since the memory controller only promised to protect the physical address it handed back, that protection is bypassed when using the new address.
There are several theoretical ways to mitigate this exploit, but it remains to be seen if the system is sufficiently field-upgradeable to defend.
Assuming this is a genuine question, here is why people care, and why this sort of writing is a waste of everyone's time.
LLMs can of course generate a lot of text about a subject, but they are still quite bad at generating a piece of writing with a coherent point. Remember how in grade school they teach you that your writing should have stuff like "introductions" a "thesis" and "topic sentences" and "conclusions"? How these things give structure to your writing, communicating to your reader both what they are reading about and why you are telling them about it? LLMs still don't seem have a model for the why part of writing. They can generate large homogeneous blobs of text on the topic at hand, but fail to differentiate the important parts from the details.
For example: all those LinkedIn cliches that LLMs are so fond of - "it's not X, it's Y", rule of 3, etc. - these are tools for bringing focus to the most important points. Even terrible LinkedIn posters implicitly know to use these cliches to drive home their (usually anodyne) messages. LLMs don't understand this, so they just use linkedin cliches everywhere, turning the whole thing into a breathless monotone.
Besides all of that - unless you've somehow missed the constant parade of people begging others to stop sending them LLM-generated prose, and all the reasons they've given for why it's actively bad for everyone involved - it seems like "who cares?" is a bit of a disingenuous question, and one you could have easily answered yourself.
The article would be better with just the instructions and audited output. All the LLM added bloat is tiring and distracting; it's like an article from New-Yorker or Wired.
This was a relatively complicated post of the sort that we are lucky to get in any form, AI-assisted or otherwise. Does it meet my personal stylistic standards? No, it's too LLM-ish. Assuming I cared about the presentation at all -- which I don't always, but would here -- I wouldn't be able to stop myself from fixing that in the process of reviewing it. Is it the usual bucket of slop? Emphatically no.
You are literally asking this to people who clearly care...
> In today's present, I wouldn't bother writing the article myself neither besides giving the instructions and auditing the output.
Then why exactly are you even bothering to reply to me instead of having Claude do it and auditing the output? If HN didn't have a rule against it, would you even bother replying yourself?
But really, there's a fair bit more to unpack here than just that. Why wouldn't you bother? Is writing a README.md about some project you worked on really that hard? Even with heavy LLM assistance, I'd wager to guess this project, which clearly involved working on real hardware, was more than just prompting. So clearly there was human effort other than prompting. And I do respect that, but I want people who write things to respect my time. I'm not asking them to disclose every tool they use, I'm asking them to not waste our time with crappy irritating Claude writeups. Whether it's explictly specified or not, we know.
Frankly I struggle to believe that people don't really mind if someone else speaks for them in their own voice, just because they're too fucking lazy to speak for themselves anymore. We've had competent GenAI for like a year or two, at this rate people are going to forget their potty training in another few months.
> Substance is what matters
Substance matters, which is not great for LLMs, because they put out text that has far more fluff than substance. What, however, is far worse for LLMs, is the fact that kick and scream and cry all you want, but: style and presentation matters, too.
It is absolutely true that if you just dropped a very brief blurb that all AMD CPUs from a certain generation can be pwned it would have a decent chance to hit the HN frontpage just out of sheer interestingness. That is not because the style and presentation doesn't matter, it's just that the substance is significant in spite of the bad presentation and style.
And absolutely, we can easily forgive someone for simply not being very good at the presentation and style part, certainly I'm not really an expert at it. But this author has released plenty of great hits before, so I damn well know they can. It's a serious disappointment to see them downgrade to irritating, grating Claude garbage output.
This is just one random idea. But altering PSP code is also interesting, to use it for your own purposes, or extract encryption keys / make it lie to clients (breaking DRM, for instance).
The bulk of microcode is still ROM inside the CPU. Also it's mostly used for the more complex instructions, the basic load/store/add/etc. would be decoded and executed more directly.
CPUs have a limited amount of SRAM for holding patches, basically a list of addresses in the microcode ROM, and what their contents should be replaced with. Not enough to totally change the instruction set, but still exciting to potentially get write access to, as indeed the normal update mechanism requires those patches to be cryptographically signed by Intel/AMD.
Its not to say that its not impressive, but its fairly isolated to a specific family of processors from 2013.
“Poke the DRAM controller and an address can be made to land wherever you want in memory.”
I’d love to know why this specific sentence structure feels like Claude.
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.
Then don't be that guy.
> But...
Oh, ok.
Hackernews, dang and the other mod are constantly telling people, wE'rE dOIng sOMetHinG dIffeReNt hERe
Yeah, complaining about fucking ai instead of discussing the topic.
I don't give a fuck about how whatever it is you perceive as "claudisms" makes you feel.
The author is deeply technical, and the writeup as presented is easy to follow.
If you couldn't follow it and you are technical, then you have a form ai psychosis: the kind that makes you so hyper-viliglent to seeing something that might have been produced in a way that you don't like that it blanks out your brain.
> 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?
My gut feeling agrees. The rule of three is one of the stronger signals, can't stamp that out of the AI even if you wanted :-)
I'll push it to GH later, it's nothing fancy but it has been quite good in my experience. Here is highlights which it used
``` tricolon coordinated VERB run: “…break / on them collapse / unlock everything .” (3 members) tricolon coordinated VERB run: “…guard physical addresses / not DRAM coordinates / you rearrange the” (3 members) tricolon coordinated NOUN run: “…handful of data / it to z3 / the translation matrix” (3 members) tricolon coordinated NOUN run: “…view / the elaborate fences / locks / security checks the” (4 members) tricolon coordinated VERB run: “…Read it / the alias map / pipe” (3 members) ```
Anyway, I've no doubt your blog posts from 2009 or whatever were not generated by an LLM. But this fuckin shit right here from 2026 though? LLM. 100%.
(By which I don't mean it generated 100% of it, as there's the odd sentence that sounds vaguely human, just that I am 100% certain that the LLM was allowed to far more than merely breathe on this writing. And that's enough to get me complaining, because it makes it a real headache to read.)
Then at some point it "clicked" and I was suddenly unable to not see it. Articles that I had thought sophisticated now came across to me as if they were written in crayon.
Enjoy it while you still can!
(And yes, the article here is very clearly AI written. Great content, written in crayon.)
I'd just like to address this real quick because some people seem to think this is just a "hunch" that has some probability of being false; there is absolutely nothing more certain on planet Earth than the LLM involvement in this writing. It is difficult to come up with things that are certain enough to compare this to to convey the lack of doubt that exists.
I am not going to make fun of you for not being able to tell, although I do find it surprising that people seem to struggle in both directions with telling AI and human writing apart (are our brains really that different?) - I just want it to be clear that some of us can pick up Claudisms within just a couple of sentences with no effort. A Claude-generated sentence, in isolation, may not ring any alarm bells. A few of them in a row, however, that's a load-bearing smoking gun right there.
We can certainly argue to what extent undisclosed LLM involvement is an issue or not, though frankly I don't like reading LLM writeups so I would greatly prefer if people would stop using LLMs for public facing documents. But, it is at least worth making this much clear: we can tell.
Go ahead and throw the comment into your favorite unreliable AI detector. Even though I suspect they're mostly garbage, my writing is just so far away from what AI models do that it doesn't even matter.
edit: I caved into temptation and checked. Big fat zero on GPTZero.
I still pretty much stand by what I said; if my comments are ringing alarm bells then you're not really picking up on the right signals.
The em dashes are the most obvious stereotypical tell, but that doesn't really matter that much (I actually like them and occasionally used them pre-AI). It's hard to put a finger on, but the most annoying LLMism to me is the overdramatic, staccato, almost "epic" way they talk. It feels like a 2009 lens flare effect over everything, it sounds like a stereotypical hacker in a CSI show.
> the last generation whose datasheets document the DRAM controller's translation registers — and show that they can't be locked
> When your code dereferences *p, it appears to access the DRAM at p. It does not — p is a virtual address
> Physical addresses are really more of a suggestion.
> That's the exploit. All of it.
The worst part is that this stuff is genuinely cool and deserves to be dramatic. And I like stereotypical, campy hacker speak! But LLMs are, IDK... bad at it? Or maybe it just becomes a bore to read the same. Exact. Dramatic. Voice. From literally everyone. After you've heard it enough times.
None of this is against Mr. Domas. He seems like a cool person, with a cool voice, and I want to read his voice, not Claude's.
> What if you're wrong?
I definitely could be! Apologies if I am. But with all the em dashes and such, and having read his previous work, I felt confident enough to mention it. And as the sibling comment says, it really is something you just learn to spot over time.
Likewise, I don't mind the diagrams. Though they do often have the same flaw as other text, being that the LLM throws in EVERYTHING, vs. a handmade one that'd generally have more taste and discretion to it. That can kind of work in its favor here, since the point is just to show the complexity of the stack, but on the other hand the reader lacks confidence that every item in there is "really" a part of the stack (which I would be fully confident in for this author, had he written it by hand) and not just some process related to memory/DRAM that the LLM decided to toss in.
Damn. Now my artist-mode in Emacs skills are useless.
I hate these especially much: It's at the same both both overly dramatic, it's presented as some great reveal that will change everything, while at the same time being completely trivial and only detracts from the explanation. If you have no idea that memory addresses are translated you will understand absolutely nothing from the text or even what this is all about. If you want to explain what an MMU is, just do that instead and don't present it as some great revelation.
But some equally dramatic phrasings could just as well be something that leaves you astonished. You never know. You have to skim the text to find what is useful information and what is just filler. The signal-to-noise is low.
It's called slop for a reason.
In an ideal world would he have used up all of his free time to write white papers by hand, sure. But instead he used AI to help him go faster (who among us can honestly say were not using in our daily lives??)
As someone whos been a HUGE fan of his work for a long time let me add some positivty to this thread. I'm SOOO thankful that hes still spending his free time doing incredible research, releasing functional documented open source, and bothering to release white papers. When so many researchers I see today slap a cheeky logo on a shitty blog post and call it awesome.
And whether it's really real in the first place.
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.
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).
So far seems this is about right:
1. You need platform register access, so seems can't KVM-escape with just this
2. Big question is what about breaking Confidential SEV-SNP guests from the host?
Zen changed DTC (DRAM Controller) to UMC (Unified Memory Controller), UMC is programmed at boot, and one would hope they figured that locking access to it makes sense when they were adding confidential compute support; Not clear though because there is no public documentation on it, so best we can hope for is some statement from AMD/3rd party researcher saying "this won't work on Zen because X/Y/Z"
It's definitely a good research topic because there are a lot of moving pieces and having this kind of primitive might weaken one of them in a useful way, but at least at the top level, you couldn't just swap one guest's DRAM bank with another and get their confidential memory contents back this way.
https://news.ycombinator.com/from?site=github.com/xoreaxeaxe...
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 should also be able to fuse away this access forever, to be fair. But out of the box, when I get a new laptop, I should be able to read and write every byte of DRAM.
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.
The only modern silicon that gives me full control over what code is running is some (or most?) microcontrollers.
And this isn't just a question of FOSS principle. Especially SMM is problematic by unpredictably taking CPU cycles away from your workload. This can mess up hard realtime workloads, such as found in CNC controllers. If you are running something like LinuxCNC this something you need to measure to figure out if a given computer is suitable for that job.
And as I pointed out in the comment you are responding to, there are plenty of other reasons to want complete control of my computers. Härd realtime behaviour is especially important to me, as is the principle of FOSS.
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...
Generally, I don’t see why a modern security platform wouldn’t have its own private SRAM to be used as a root of trust for encrypted blobs stored in shared DRAM.
Absolutely brilliant!
The vendor locked regions (on hardware that you already own!) that this could unlock (or help future security researchers to unlock, in the case of later model CPU's) has the potential to solve many auditability/transparency/defensive security/repair (cf. "Right to Repair") problems in the future.
Christopher Domas has earned the right to be called a 'Legend' -- again!
(For probably like what, the 3rd or 4th time now? :-))
Anyway, upvoted and favorited!
https://jxself.org/titanic.shtml
He did it well. On "security", the author loves more to own his code/adata than anything. as did the PDP10/ITS hackers.
Instead, it's the blueprint for all the subsequent unsinkable ships in terms of surveillance capabilities.
It's during the move to 64-bit aarch64 where things started to imitate the x86, with more and more always-on firmware and secure monitors and whatever being introduced. Nothing really to do with device tree, in fact ACPI is being pushed to the ARM too, yet again hiding more details of the hardware towards proprietary bytecode.
> Run `platform_check` first and do not use `SKITTER_FORCE=1` casually. Start with the read-only `dram_state` and `dram_carveouts`, then `dram_dump --dry-run`. Avoid `dram_poke` until maps have been freshly collected and calibrated. Do not bypass fingerprint checks, calibration, fencing, or verification.
Claude's (apparently externally-mandated?) lobotomization continues to be concerning. :-/
You mean, completely self inflicted? "Ohhh government, guess who had the most dangerous model now... tee hehe We've been so baaaaad. Look at all these companies we accidentally hacked. Whoopsee."
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.
You have 10 food jars in your house. Your parents only allow you to grab food from, say, the jar on the far left, and the one next to it. Sadly, those jars only contain broccoli (ordinary OS memory) and lettuce (more ordinary OS memory).
But, you find out that you can just shuffle the jars around! You do a little bit of random shuffling, until you find that you have the jars with cookies (CPU microcode) and candy (SME firmware) as the leftmost ones on the shelf.
Your parents take their promise very literally, and still allow you access to the two left-most jars. Which is now cookies and candy.