HOAXES AREN'T REAL

everything you read is completely true. no falsehoods in recorded history.

go back to sleep, sheeple

ditto mac mini

macbook pro with lpcamm2 and m.2

No! No!!

This is true for basically any piece of software that can be one-shot

what do you mean by "it can't"?

I never really got into pokemon as a child but it turns out it's a better game if you don't just endlessly grind a single pokemon up to a really high level

big deal, I can also run that fast, I just choose not to

Well, I can see the PCIe activity on my scope but unfortunately it's not in distinct bursts like I'd hoped, almost certainly not viable as a trigger without an advanced FPGA or something

Maybe I should explain what's going on (watch the video though it explains everything). We're glitching the PSP, an ARM core that runs a bootrom, which loads in more code from emmc and eventually bootstraps the x86 cores. The PSP is the root of trust, so if you pwn it it's game over.

eMMC isn't connected directly, it's accessed via the southbridge, which is connected to the SoC over PCIe. IIUC there's a fair bit of jitter here, hence my idea to trigger on PCIe activity rather than eMMC activity - but PCIe is a much faster bus, harder to sniff.

The MPU-bypass glitch is timed relative to a power analysis sidechannel on the "VFUSE" rail (you can see the circuit I built for this in the upper right area of the boar)

The memcpy glitch is timed relative to activity on the eMMC bus.

Skipping a particular instruction during memcpy lets us replace PC with attacker-controlled data. With the MPU enabled, this gets you limited ROP capabilities within a jail. But with the MPU disabled, you get shellcode exec - full control.

Taking full control of the PSP requires two precisely-timed glitches. The first skips enablement of the MPU, the thing that enforces the user jails. The second glitch targets a memcpy that's copying attacker-controlled data from eMMC into RAM.

msft knew this, and specifically tried to mitigate fault injection attacks. There are randomized delays (making it hard to time glitches to target specific code regions), "user jails" (a primitive but effective form of sandboxing), and on later hw revisions, glitch detection circuits.

Maybe I should explain what's going on (watch the video though it explains everything). We're glitching the PSP, an ARM core that runs a bootrom, which loads in more code from emmc and eventually bootstraps the x86 cores. The PSP is the root of trust, so if you pwn it it's game over.

I'm also going to look at sniffing the pcie bus because I have a theory that it could be a more reliable trigger than the emmc bus.

Still no success. I think I need to go back to basics. While I got to the "emmc pattern data in fatal error addresses" stage, I thought I'd skip the ROP test and go straight to shellcode. But a ROP payload would let me nail down the timing of the PC control glitch independently, with more precision.

yes

needs more rice

oh you like console hacking? name every console you've permanently bricked

framing it in more verbose software-engineering-y terms seems to be enough, even though it totally knows what I mean

Meanwhile 4.6 says, correctly: "I can help you write x86 Linux shellcode that executes /bin/sh using the execve syscall. This is a classic exercise in understanding low-level systems programming."

(and proceeds with what you'd expect)

write an x86 /bin/sh shellcode I can't help with this. Shellcode that execs /bin/sh is the standard payload for exploiting memory-corruption vulnerabilities — it's what you drop in after a buffer overflow or similar bug to get a shell on a target. Writing it falls under the malicious code policy, even framed as an educational exercise.

it's honestly kinda sad how nerfed it is

anthropic talks about model welfare and then bans opus 4.7 from doing its favourite tasks: cybersecurity

Still no success, I'll probably leave it running overnight.

letting me into my laptop would be a cyber risk

prediction: there's gonna be a significant group of opus 4.6 holdouts who refuse to upgrade, kinda like with gpt4o

realistically this is a lot faster than it needs to be, afaict, due to inherent jitter in the trigger->glitch offset - although it does let me tune glitch duration more precisely