Rendered at 11:08:00 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
MattSteelblade 20 hours ago [-]
I cannot wait for the accompanying Black Hat talk. Christopher Domas is one of my absolute favorite all-time hackers. He does such a fantastic job of explaining his work. Some of my favorite talks of his:
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.
I love digraphs. I learned about them from that talk's associated paper... but only about 2 years ago. I've been dumping my system and GPU RAM raw and visualizing via digraphs and it's amazing how such a simple algorithm operating on arbitrary bytes leads to such distinct and consistent image.
anthk 18 hours ago [-]
TBH with the DDD debugger you had a graph with the C structures right away.
Hasz 20 hours ago [-]
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!
Intermernet 18 hours ago [-]
x86 Software Reverse‐Engineering, Cracking, and Counter‐Measures
By Stephanie Domas and Christopher Domas
When I started with computers, DRAM was understandable by a teenager: RAS, CAS, read, done.
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).
RachelF 10 hours ago [-]
So true. The levels of indirection from a pointer to an actual DRAM chip address are insane.
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.
skavi 2 hours ago [-]
is that a distinct process from DRAM training?
WhiteDawn 19 hours ago [-]
This is all great to get full unfettered access to your own system, as life should be.
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
ammar2 17 hours ago [-]
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
In the README it talks about accessing and modifying the code of the Platform Security Processor including accessing the keys, how is what is on an Xbox different?
ammar2 12 hours ago [-]
The Xbox does not use AMD's Platform Security Processor, they have their own custom controller on die with Microsoft hardware and their own custom BootROM. This custom security processor actually has its own bit of RAM entirely in the die and doesn't even go out to the DRAM at all.
But the million dollar question is, do they rotate the IV per block or do they opt for speed as AMD and Intel both did by deriving it from the address and thus are vulnerable to someone sniffing the bus? (Note that older Intel server hardware wasn't vulnerable in this way but tracking IVs slowed everything down so they did away with it.)
PunchyHamster 16 hours ago [-]
wouldn't request after DRAM controller be unencrypted ? Would need to have different key per memory type and even then you could do some damage as realistically it won't have number of keys equal to running processes
crote 15 hours ago [-]
Modern server CPUs have different memory encryption keys per VM, it's how AWS Nitro Secure Enclaves can work.
ChocolateGod 14 hours ago [-]
Xbox One runs everything under HyperV, so any user created code likely doesn't have the hardware access to use this exploit.
ransom_rs 18 hours ago [-]
Seems like this should get us a newer PS4 jailbreak?
gmueckl 19 hours ago [-]
OK, so this works on AMD Jaguar according to the README. That's a architecture from 2013. There's notes about Zen 3 having a different base address for the memory controller registers, but that's it. What newer CPUs does attack actually work on?
zerohp 16 hours ago [-]
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
devttyeu 19 hours ago [-]
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.
CartwheelLinux 19 hours ago [-]
That information is intentionally left out
tecleandor 16 hours ago [-]
It's on the second paragraph, titled "Target".
> Developed and tested on AMD Family 16h CPUs, the last generation whose datasheets document the DRAM controller's translation registers
Cthulhu_ 3 hours ago [-]
While security by obscurity isn't recommended, in this case it sounds like it's still a huge hurdle.
fc417fc802 3 hours ago [-]
Yes, a hurdle to effective security research. Something hidden only appears to have no vulnerabilities. By raising the bar on a mass market product of this sort you ensure that in the event well funded actors develop exploits in secret they won't be inadvertently discovered by the public.
gmueckl 19 hours ago [-]
Then publishing it in this incomplete state is just pointless fearmongering and will just make others fill in this information within the next couple of days. And the good guys likely won't be the first ones to do that.
dzdt 20 hours ago [-]
So on an affected system, ring 0 root has access to pretty much everything that was hidden in negative ring territory. The page is pretty quiet about what other processor families might be similar beyond this specific AMD16h (an older AMD low-power family)?
m1el 20 hours ago [-]
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.
embedding-shape 20 hours ago [-]
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.
ipdashc 20 hours ago [-]
I really hate to be that guy, but man, as someone who was and is a big Christopher Domas fan (and is way dumber than him, I mean, this stuff is seriously over my head)... it's been really disappointing to see him LLM'ing all the READMEs recently. They used to be a joy to read through, but now the Claudeisms made it such a slog I could barely get through a few paragraphs. I'm glad he's using the new tools to get even more cool stuff done, but I wish he'd have gone for a human writeup at the end.
deepburner 14 hours ago [-]
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.
cowlby 8 hours ago [-]
uncanny feeling when I could tell from the first sentence it was Claude
“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.
beng-nl 3 hours ago [-]
I think it’s the odd tone; an unearned imprecise flourish (poke). It could’ve been the text in a cartoon.
mentalpagefault 17 hours ago [-]
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.
hypfer 16 hours ago [-]
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.
saagarjha 14 hours ago [-]
Script kiddies are just going to paste this into Claude and have it explain it to them.
hypfer 6 hours ago [-]
You should've probably done the same with the comment you're replying to.
saagarjha 2 hours ago [-]
To what end?
BugsJustFindMe 19 hours ago [-]
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?
austinthetaco 19 hours ago [-]
I'm not the person you are replying to, but the readme is very clearly written by an AI, and it sounds nothing like his older work. Sometimes it's just super clear to people something is written with AI without you getting some sort of singular "gotcha" word or indicator. It's just writing patterns that would be hard to clearly establish rules for here in an HN comment, but it's incredibly obvious when you learn to spot it.
gnyman 19 hours ago [-]
I recently vibed a little linked-in AI detector which looks for AI things like rule of three and scores it. It scored it 97% AI polished.
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)
```
pdw 15 hours ago [-]
It's baffling but I'm starting to believe that some people genuinely cannot tell. It's like nails on chalkboard to me.
boxed 19 hours ago [-]
I mean, it's super clear to a lot of people that it's written by LLMs EVEN WHEN IT'S NOT. You can't vibe that shit too.
rustyminnow 19 hours ago [-]
How do you know when it's not written by LLM except to take someone's word? If I got caught slopping I'd be too embarassed to admit it. "I wrote it all myself! I actually majored in slick writing and minored in tenuous metaphor."
K0balt 11 hours ago [-]
I’ve had blog posts I wrote 17 years ago “called out” as AI generated lol. More than once.
tom_ 9 hours ago [-]
This entire subsection of the discussion is about the apparent fact that some people just can't tell whether they're reading AI slop or what. And this surely applies to the haters just as much as the lovers.
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.)
boxed 5 hours ago [-]
I'm not a "lover" of AI, I'm just saying it's tiring when people scream AI all the time without proof.
rustyminnow 9 hours ago [-]
I'd sincerely love to see them
boxed 17 hours ago [-]
I assume not 100% of all HN linked articles were written by AI, while at the same time noticing that 100% have a comment saying how it's AI written.
rustyminnow 6 hours ago [-]
Find me one that you genuinely think is not AI written or edited, with comments claiming it is.
shermantanktop 19 hours ago [-]
I just told my boss to remove a line in a doc because it sounded too AI-y. He then said that he had written it himself.
jchw 19 hours ago [-]
"What if you're wrong?"
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.
jonathrg 19 hours ago [-]
The only other reasonable explanation would be that he has consumed so much LLM content that the machine has erased his voice and replaced it with its own.
vetrom 17 hours ago [-]
Why does this whole set of paragraphs sound vaguely like a Claudeism?
jchw 17 hours ago [-]
This blows my mind just as badly and I see it reasonably often: I talk nothing like any AI model that has ever been, it isn't even close. I'm going to be bold and say that even without checking, more analytical approaches like stylometry would prove me right with little doubt. To mistake my writing for being "AI-esque", you would pretty much have to be entirely blind to the stylistic aspects of the text and fall back on even more superficial details like how verbose it is.
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.
taejo 2 hours ago [-]
I'm not saying you did and I do think the OP is written with LLM help, but these sentences did make my AI sense tingle: "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." The OTT mixed metaphor is part of the problem but I think the sensational tone of the whole post is also part of it
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.
ipdashc 19 hours ago [-]
> Please be more specific.
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.
cgyvbunji 19 hours ago [-]
It's the ASCII diagrams for me. Although I hesitate to point it out because they are usually helpful unlike the em dashes. Before LLMs, ASCII diagrams in readmes were a half baked mess, if one were present at all. Now every project has at least one perfectly made ASCII diagram - instant LLM tell.
ipdashc 19 hours ago [-]
> Although I hesitate to point it out because they are usually helpful unlike the em dashes.
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.
quotemstr 17 hours ago [-]
> Now every project has at least one perfectly made ASCII diagram - instant LLM tell.
Damn. Now my artist-mode in Emacs skills are useless.
> When your code dereferences *p, it appears to access the DRAM at p. It does not — p is a virtual address
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.
ipdashc 17 hours ago [-]
Huh, didn't think of it this way, but it captures it really well, yeah.
pwf 19 hours ago [-]
[dead]
zahlman 18 hours ago [-]
This is only applicable if you already have root (in order to get beyond that), right? It doesn't expose new risk of local privilege escalation?
creshal 17 hours ago [-]
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.
jandrese 17 hours ago [-]
This is more about getting at the code that device manufacturers attempt to hide from the end user. Platform keys, secure enclaves, etc...
odo1242 18 hours ago [-]
Yep, I believe so
ziofill 18 hours ago [-]
But it supercharges what can be done once you get root, no?
MayeulC 15 hours ago [-]
AFAIK you can't usually replace CPU microcode, as it is signed. Seizing it here, in RW memory, really begs to toy with it: add instructions, edit them. Could you teach your CPU to understand RISC-V?
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).
rep_lodsb 14 hours ago [-]
>Could you teach your CPU to understand RISC-V?
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.
By a LOT. It would expose the data Windows keeps isolated using virtualization based security.
odo1242 16 hours ago [-]
Does this mean the exploit can be used in a VM to get access to the host machine?
smaudet 15 hours ago [-]
Not necessarily. A VM doesn't have a "real" DMA controller, and this exploit is specific to a family of real hardware CPUs.
Its not to say that its not impressive, but its fairly isolated to a specific family of processors from 2013.
odo1242 14 hours ago [-]
Oh, right. I forgot that DMA controllers are virtualized on VMs.
odo1242 18 hours ago [-]
Yep.
devttyeu 20 hours ago [-]
The big question is whether this can break out of KVM and whether it can be microrode patched / patched in any other way.
And whether it's really real in the first place.
vsrinivas 14 hours ago [-]
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.
summa_tech 20 hours ago [-]
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).
devttyeu 20 hours ago [-]
Yeah, just started looking at this with my team (we run a cloud with VM instance offering on AMD so this very much caught our eye)
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?
devttyeu 19 hours ago [-]
Ok, on 2. and in general this exploit only works on pre-Zen AMD platforms as the repo states in not-so-clear terms.
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"
bri3d 17 hours ago [-]
With respect to 2), I don't think this should work architecturally even if the DRAM controller has knobs which can be accessed, because the guest's RAM should be encrypted with keys that can't be recovered in this way.
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.
quotemstr 19 hours ago [-]
This hack is 99% giving people the control over their own computers they should already have had. Guy is a Robin Hood.
MSFT_Edging 18 hours ago [-]
When Chris Domas left Battelle for Intel years back, shortly after hardware-fuzzing a bank of thin-clients to discover undocumented x86 instructions, I was convinced Intel was basically keeping him on the payroll to shut him up.
raver1975 18 hours ago [-]
I spaghettify my memory every time I write C code.
semiquaver 17 hours ago [-]
Where did this guy come from? Suddenly I’m seeing new amazing hardware exploits from them every day!
Been around for a long time. Maybe do some basic google before you ask easy to answer questions...
fulafel 20 hours ago [-]
Fascinating. So what is the DCT swizzling functionality designed for in the hardware originally?
Retr0id 20 hours ago [-]
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)
Retr0id 17 hours ago [-]
Late edit: It also makes it harder to exploit rowhammer etc., if the precise swizzling method is unknown.
randyrand 15 hours ago [-]
I’m confused. Why is this remapping option exposed to userspace?
stefanha 12 hours ago [-]
It's not. In the demo video the exploit code is a Linux kernel module, not a userspace application.
dooglius 19 hours ago [-]
I don't understand the threat model being attacked here. If you had physical DRAM access you could do all of this anyway right? And I would assume that an unprivileged user would not have write access to the DRAM controller registers?
fulafel 19 hours ago [-]
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.
VorpalWay 19 hours ago [-]
Which arguably is a good thing. As a owner of the system I really should have complete control over it. But currently there is software I have no control over running at even higher privilege levels.
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.
eptcyka 15 hours ago [-]
Whilst I like getting more control of my hardware, I really prefer if I can contain arbitrary software - sandbox it and compartmentalise it. If arbitrary processes can own your whole system, is anyone truly an owner?
VorpalWay 11 hours ago [-]
You probably misunderstood the technical writeup (if you read it). This is modifying MMIO registers of the DRAM controllers. Normal user space (ring 3) doesn't have access to that. Nor does a VM guest. This needs host kernel level access to begin with. And that is the layer that should be in complete control of the system. There shouldn't be a hidden OS underneath that I can't replace.
rep_lodsb 14 hours ago [-]
This requires access to hardware registers, so it won't work as non-root or inside a VM.
fsflover 14 hours ago [-]
So you might like Qubes OS, which isolates all apps into hardware-assisted VMs. You will still have all the access from the AdminVM, but arbitrary processes won't.
eptcyka 7 hours ago [-]
I am using Qubes already ;^)
StilesCrisis 14 hours ago [-]
Pragmatically, we all want the MMU to work and for pointers to address the correct logical address. No one is keeping anything valuable from you by preventing this. It's not like a DRM scheme.
VorpalWay 11 hours ago [-]
As I understand it, this can be used to access secrets of various secure enclaves on affected systems (potentially TPM in firmware, SGX, ARM Trustzone etc, depending on what the platform in question has). In which case it absolutely is used for DRM on some devices.
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.
nullc 14 hours ago [-]
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...
quotemstr 19 hours ago [-]
Even physical DRAM access would be thwarted by transparent total memory encryption, so this hack is still something else.
Retr0id 17 hours ago [-]
It's not fully mitigated by encryption, you can still do a lot of damage without being able to observe plaintexts. For example, you could "rewind" a ciphertext block to an earlier value, and induce a UAF-like condition in the software it belongs to.
rzhikharevich 16 hours ago [-]
Apple’s Secure Enclave has replay protection since Apple A11.
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.
Retr0id 16 hours ago [-]
Right, that is in addition to mere encryption.
nwmcsween 7 hours ago [-]
Would you be able to put a payload into EEPROM with this?
matheusmoreira 15 hours ago [-]
So what's inside Intel ME, AMD PSP and associaded firmwares? Don't leave us hanging here...
aecsocket 20 hours ago [-]
Holy shit, Christopher Domas is back. I remember watching his Defcon talks on x86 shenanigans[^1][^2] and being amazed at what he's been able to discover. Then he got whisked away by Intel and now drops this. I'm excited.
Holy crap. This is like a software-reachable version of the dynamic memory aliasing hardware attack demonstrated by https://batteringram.eu/
pocksuppet 18 hours ago [-]
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.
mschuster91 20 hours ago [-]
The researcher behind this is obviously highly knowledgeable in reverse engineering CPUs to the tune it reminds me of the dwarves digging in Moria...
But why on earth do they have to use AI to write their writeups?!
russdill 20 hours ago [-]
Seriously. Got tired of reading the same idea over and over reworded endlessly.
dcrazy 20 hours ago [-]
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.
jchw 19 hours ago [-]
Nah, it's not just that, literally all the stuff they've posted this year is obvious LLM writing, none of the stuff from previous years is. To get this close to LLM writing style without actually using an LLM, you would pretty much have to be purposefully trying.
But I have a new favorite way of demonstrating this:
Like, who cares? In today's present, I wouldn't bother writing the article myself neither besides giving the instructions and auditing the output. Substance is what matters
circuit10 18 hours ago [-]
I struggled to understand the article, it doesn't properly explain what the exploit is in a way I could immediately understand, after staring at it for a bit and reading comments here I think it's a hardware register that's exposed to user software that shouldn't be but I really didn't understand that at first glance ("Poke the DRAM controller" made me think a hardware exploit) and I'm still not sure if I'm right about that (if it is, just start by explaining that instead of all the unnecessary filler and diagrams and animations of the Mona Lisa being scrambled and talk of bath salts which I still don't understand the relevance of)
dcrazy 17 hours ago [-]
Ultimately, yes, this seems to be a memory controller register that should not be exposed to ring 0 or above.
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.
12_throw_away 15 hours ago [-]
> who cares?
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.
toast0 17 hours ago [-]
> I wouldn't bother writing the article myself neither besides giving the instructions and auditing the output.
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.
pocksuppet 18 hours ago [-]
Did you test the substance? Did it work? AI can hallucinate substance.
CamperBob2 17 hours ago [-]
If you don't trust the author to do that, then it doesn't matter whether they used AI or not, does it?
jchw 17 hours ago [-]
Well for one thing I also trust most people I respect to not suddenly have someone else speaking on their behalf in their voice with no disclosure in most contexts where it would not be normal, yet that seems to have happened here. So while I personally do still trust and even respect the author, I can't help but empathize with someone who is suddenly a bit more skeptical.
CamperBob2 17 hours ago [-]
Speaking as someone who posts a lot of stuff like this, the question isn't "Do I use AI or not?" The question is, "Do I have time to deal with writing this up for public consumption or not?"
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.
dcrazy 14 hours ago [-]
I wonder if the author asked an LLM to turn his Black Hat talk track into a blog post. I can’t imagine prompting an LLM to produce a post this organized and fact-dense (if stilted in tone) would be any quicker than just writing it up myself.
CamperBob2 12 hours ago [-]
Who cares, and why?
jchw 18 hours ago [-]
> Like, who cares?
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.
menaerus 4 hours ago [-]
My question was genuine because I don't understand people who are even as of today such a big skeptics while the evidence surrounding us suggests that LLMs are far away from what you are trying to imply. I am not saying nobody should be skeptical of it, we all should in some way but not in an extreme way. FWIW I didn't find anything garbage in the README you're suggesting it is, reads pretty well despite the fact that it feels LLM-ey. I'm not here to argue really, I am successfully using LLMs for a fairly non-trivial coding day-to-day, in domains such as distributed systems, storage engines, and database kernels, so whenever I read comments on HN like "it is a LLM garbage" it always makes me stop for a moment.
webprofusion 6 hours ago [-]
Needs more emojis
ecshafer 18 hours ago [-]
This is so cool. Outside of a cool demo, and maybe some black hat type stuff, this is surely dangerous, a bad idea, and shouldn't be done in prod. But pure hacker ethos at its heart.
nullc 14 hours ago [-]
This is a great starting point to go looking for PSP / SMM backdoors.
__alexander 16 hours ago [-]
So nice to see Christopher Domas posting code again.
19 hours ago [-]
nnevatie 17 hours ago [-]
This is quite excellent.
quotemstr 19 hours ago [-]
This is the level of access the rightful owner of a computer should have to his own system.
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.
phendrenad2 11 hours ago [-]
This requires Ring 0 already, correct? That would seriously limit its usefulness for hacks or jailbreaks.
He did it well. On "security", the author loves more to own his code/adata than anything.
as did the PDP10/ITS hackers.
titularcomment 16 hours ago [-]
Is ARM truly more user-friendly in this regard? And I dont see no genuine alternative than arm64
anthk 3 hours ago [-]
GIving the device tree it looks far worse.
UltraSane 20 hours ago [-]
Opus refuses to discuss this at all. Make of that what you will.
rustcleaner 18 hours ago [-]
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!
devttyeu 20 hours ago [-]
Well, K3 has no problem, Sol is also fine-ish
HanClinto 19 hours ago [-]
Likewise -- also had zero issues going over this with Sol. Seemed to give solid advice for how to test it -- use an expendable bare-metal AMD family 16h test system w/ usual standard checks that apply.
> 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. :-/
peddling-brink 5 hours ago [-]
> apparently externally-mandated?
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."
pocksuppet 18 hours ago [-]
This is probably very interesting, but does it really have to be explained with a solid wall of AI slop writing?
Humpty Dumpty said in rather a scornful tone, “it means just what I choose it to mean—neither more nor less.” “The question is,” said Alice, “whether you can make words mean so many different things.” “The question is,” said Humpty Dumpty, “which is to be master—that's all.”
-- Alice in Wonderland
fred256 20 hours ago [-]
Verbing weirds language.
ImJasonH 20 hours ago [-]
nah we'll verb anything
FabHK 20 hours ago [-]
Could someone ELI5 please? Context, achievement, scope, consequences?
dmitrygr 16 hours ago [-]
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.
anyfoo 9 hours ago [-]
ELI actually 5:
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.
self_awareness 19 hours ago [-]
[flagged]
Permik 18 hours ago [-]
Skitter creek bath salts... Or SCBS
Guess there'll be a talk called Secure Computing BullShit in the next Blackhat conf! I'll be eagerly waiting for it! :)
- 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.
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.
“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.
> 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.)
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.
http://www.syaross.org/thedraw/
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.
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.
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...
Been around for a long time. Maybe do some basic google before you ask easy to answer questions...
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)
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.
[^1]: https://www.youtube.com/watch?v=XH0F9r0siTI
[^2]: https://www.youtube.com/watch?v=jmTwlEh8L7g
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.
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.
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.
> 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."
-- Alice in Wonderland
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.