On Phat consoles? You could turn it into a modchip, if for some reason you wanted to. It'd be repeatable on every boot but might take a while.

The hard work comes after this though. There are lots of software level mitigations MS could use to keep the old devices usable with Xbox Live if they really wanted to. Just because you can boot anything you want doesn't mean you can't be detected remotely, it just makes it harder for MS to do so reliably. You'd be in a constant game of catch-up.

Amazing talk. Here's a quick writeup if you don't want to watch the full hour or don't have enough hardware knowledge to follow what Markus is talking about, as he goes very fast, in some cases too fast to even let you read the text on his slides. It's mandatory to use the pause key to understand the full details even if you have a deep understanding of every relevant technology, of which he explains none.

The Xbox uses a very advanced variant of the same technologies that also exist on smartphones, tablets and Secure Boot enabled PCs. When fully operational the Xbox security system prevents any unsigned code from running, keeps all code encrypted, proves to remote servers (Xbox Live) that it's a genuine device running in a secure state, and on this base you can build strong anti-piracy checks and block cheating.

The Xbox has several processors and what follows applies to the Platform Security Processor. When a computer starts up (any computer), the CPU begins execution in a state in which basically nothing works, including external communication and even RAM. Executions starts at a 'reset vector' mapped to a boot ROM i.e. the bytes are hard-wired into the silicon itself and can't be changed. The boot ROM then executes instructions to progressively enable more and more hardware, including things like activating RAM. Until that point the whole CPU executes out of its cache lines and can't use more memory than exists on-die.

Getting to the state where the Xbox can achieve all its security goals thus requires it to boot through a series of chained steps which incrementally bring the hardware online, and each step must verify the integrity of the next. The boot ROM is only 19kb of code and a few more kb of data, and can't do much beyond just activating RAM, the memory mapping unit (called MPU on the Xbox), and reading some more code out of writeable flash RAM. The code it reads from flash RAM is the second stage bootloader where much more work gets done, but from this second stage on it can be patched remotely by Microsoft. So if bugs are found there or in any later stage, it hardly matters because MS can issue a software update and detect remotely on Xbox Live servers if that upgrade was applied, so kicking out cheaters and pirates. The second stage boot loader in turn loads more code from disk, signature checks and decrypts it, sets up lots of software security schemes like hypervisors and so on, all the way up to the OS and the games.

Therefore to break Xbox security permanently you have to attack the boot ROM, because that's the only part that can't be changed via a software update. It's the keys to the kingdom and this is what Markus attacked. Attacking the boot ROM is very, very hard. The Xbox team were highly competent:

• Normally the bringup code would be written by the CPU or BIOS vendors but MS wrote it all in house themselves from scratch.

• The code isn't public and has never leaked. To obtain it, someone had to decode it visually by looking at the chip under a scanning electron microscope and map the atomic pictures to bits and then to bytes.

• Having the code barely helps because there are no bugs in it whatsoever.

So, the only way to manipulate it is to actually screw with the internals of the CPU itself by "glitching", meaning tampering with the power supply to the chip at exactly the right moment to corrupt the state of the internal electronics. Glitching a processor has semi-random effects and you don't control what happens exactly, but sometimes you can get lucky and the CPU will skip instructions. By creating a device that reboots the machine over and over again, glitching each time, you can wait until one of those attempts gets lucky and makes a tiny mistake in the execution process.

Glitching attacks predate the Xbox and were mostly used on smartcards until the Xbox 360, which was successfully attacked this way. So Microsoft knew all about them and added many mitigations, beyond "just" writing bug free code:

1. The boot ROM is full of randomized loops that do nothing but which are designed to make it hard to know where in the program the CPU has got to. Glitching requires near perfect timing and this makes it harder.

2. They hardware-disabled the usual status readouts that can be used to know where the program got up to and debug the boot process.

3. They hash-chain execution to catch cases where steps were skipped, even though that's impossible according to program logic.

4. They effectively use a little 'kernel' and run parts of the boot sequence as 'user mode' programs, so that if sensitive parts of the code are glitched they are limited in how badly they can tamper with the boot process.

And apparently there are even more mitigations added post-2013. Markus managed to bypass these by chaining two glitch attacks together, one which skipped past the code that turned on the MMU, which made it possible to break out of one of the the usermode 'processes' (not really a process) and into the 'kernel', and one which then was able to corrupt the CPU state during a memcpy operation, allowing him to take control of the CPU as it was copying the next stage from flash RAM.

If you can take control of the boot ROM execution then you can proceed to decrypt the next stage, skip the signature checks and from there do whatever you want in ways that can't be detected remotely - however, the fact that you're using a 2013 Phat device still can be.

My memory of this time is getting a bit fuzzy tbh, but from what I remember Google in the first part of the 2010s put Flash inside their renderer sandbox and Safari/Firefox were still lagging on browser sandboxing at that time. I think Adobe had shared the plugin code with Google to make this possible.

There are certainly obvious issues with securing a third party codebase you don't control, and it's likely that the browser makers had more budget to spend on security than Adobe. But there was no technical reason Flash couldn't have been treated as an alternative rendering engine from a sandboxing perspective, and I think Chrome did it. Pepper was an initiative to generalize that. Blink is full of holes as other comments point out and it's only the kernel sandboxing that makes adding new features viable at all.

I'm cynical because when the browser makers talked about phasing out plugins it wasn't primarily security they talked about. This blog post talks about speed and energy usage first:

https://blog.google/products-and-platforms/products/chrome/s...

The same language can be found in the announcement of their HTML5 by default strategy here:

https://groups.google.com/a/chromium.org/g/chromium-dev/c/0w...

"While Flash historically has been critical for rich media on the web, today in many cases HTML5 provides a more integrated media experience with faster load times and lower power consumption."

Security isn't mentioned, perhaps because trying to argue that their own pile of C++ was somehow meaningfully more robust than Adobe's big pile of C++ wasn't going to be convincing.

Their writings about this were also very heavy on "open web" ideology, although the SWF format was documented by that point and openness doesn't go well with deliberately wiping out a tech that was voluntarily deployed by 80%+ of websites. If openness means anything it means open to extension, which plugins provided and forcing everyone to use HTML5 did not. When they deprecated NPAPI they even sort of admitted to this:

https://blog.chromium.org/2013/09/saying-goodbye-to-our-old-...

"The Netscape Plug-in API (NPAPI) ushered in an early era of web innovation by offering the first standard mechanism to extend the browser. In fact, many modern web platform features—including video and audio support—first saw mainstream deployment through NPAPI-based plug-ins. But the web has evolved. Today’s browsers are speedier, safer, and more capable than their ancestors."

I always found this blog post curiously worded. It has a Fukuyama-style "end of history" vibe to it. Yes plugins boosted innovation because the web platform always lagged years behind, but now the web has "evolved" and the innovation era isn't needed anymore.

Arguably, so is the web. A long series of extremely complicated and constantly changing data formats that are nightmarishly difficult to parse, which has to be done in C++ for speed reasons, combined with a full scripting language, which has to be JIT compiled for speed reasons, combined with 30 years of legacy and a security model that was completely ad hoc and more discovered than designed (e.g. the different variants of the same origin policy). Take that and add on top a browser community that doesn't philosophically recognize any limits on what the web is meant to do, so it just keeps getting more and more APIs until one day both Mozilla and the Chrome team decided to just stop pretending and build full blown operating systems on top of them.

I don't think Flash was harder to secure than HTML itself. People just gave up trying because browser vendors used security to purge the web of anything they didn't control.

> Do. the. math. and. think.

OK then, where's your math?

tptacek is right, this whole discussion is silly because it revolves around what exactly "bad" means which is subjective. But if you want to really do calculations about this, you'd need to price out total expected revenue over your time preference window for each scenario. It's not at all obvious which one would win because it depends on at least these variables and probably more:

1. Over what time period you care about. "You" here means a hypothetical pharma executive who cares about his/her incentives. If symptom management makes a billion dollars repeatedly but each billion takes 200 years, and a cure makes a billion dollars once but in five years, nobody rational will want to sell symptom management.

2. Related to (1) what expected market returns are in future.

3. What price premium you can charge for a cure vs symptom management. The former is more valuable to customers.

4. How fast competitors can catch up. Imagine you find both symptom management and a cure for disease X. You keep the cure a secret and bring the subscription to market (for a price much less than what a cure would command). Six months later a competitor releases a cure, simultaneously wiping out your market and capturing all the immediate revenue. That would have been a bad move.

I recently built my own coding agent, due to dissatisfaction with the ones that are out there (though the Claude Code UI is very nice). It works as suggested in the article. It starts a custom Docker container and asks the model, GPT-5 in this case, to send shell scripts down the wire which are then run in the container. The container is augmented with some extra CLI tools to make the agent's life easier.

My agent has a few other tricks up its sleeve and it's very new, so I'm still experimenting with lots of different ideas, but there are a few things I noticed.

One is that GPT-5 is extremely willing to speculate. This is partly because of how I prompt it, but it's willing to write scripts that try five or six things at once in a single script, including things like reading files that might not exist. This level of speculative execution speeds things up dramatically especially as GPT-5 is otherwise a very slow model that likes to think about things a lot.

Another is that you can give it very complex "missions" and it will drive things to completion using tactics that I've not seen from other agents. For example, if it needs to check something that's buried in a library dependency, it'll just clone the upstream repository into its home directory and explore that to find what it needs before going back to working on the user's project.

None of this triggers any user interaction due to running in the container. In fact, no user interaction is possible. You set it going and do something else until it finishes. The model is very much to queue up "missions" that can then run in parallel and you merge them together at the end. The agent also has a mode where it takes the mission, writes a spec, reviews the spec, updates the spec given the review, codes, reviews the code, etc.

Even though it's early days I've set this agent missions that it spent 20 minutes of continuous uninterrupted inferencing time on, and succeeded excellently. I think this UI paradigm is the way to go. You can't scale up AI assisted coding if you're constantly needing to interact with the agent. Getting the most out of models requires maximally exploiting parallelism, so sandboxing is a must.