ES version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
56% Positive
Analyzed from 1453 words in the discussion.
Trending Topics
#llm#https#run#access#com#amd#same#stuff#read#more
Discussion (28 Comments)Read Original on HackerNews
- 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
Very cool!
> 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) ```
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.
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.
> 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.
And whether it's really real in the first place.
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"
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)
[^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.
> 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. :-/