[nicolas_17]

There's many factual errors in this AI slop.

For example, it says quite unambiguously that the bootloader is encrypted directly with the GID key (loading the LLB ciphertext into the AES engine), but that's not how it works, the GID key is used to decrypt the LLB's KBAG into an AES key:IV pair and that is used to decrypt the LLB.

More:

> The behavior of the Boot ROM changes fundamentally based on the "Security Domain" fuse. > > Production (CPFM 01):

Security Domain (SDOM) is a different thing than CPFM. And production devices have CPFM 03.

> CHIP (Chip ID): Identifies the SoC model (e.g., 0x8101 for M1).

The M1 SoC is 0x8103.

Due to Brandolini's Law I will not continue to list everything else that is wrong here...

[nicolas_17]

They just fixed the KBAG thing.

This quickly went from Brandolini's Law to Cunningham's Law. Learn how Apple's boot process works by explaining it wrong and waiting for people to correct you!

[jjtech]

All of these errors have now been stealth-corrected.

New strategy discovered: Ask LLM to write article, nerdsnipe HN into correcting it, feed corrections back into LLM until people stop complaining

[ethin]

Yeah, definitely not at all a fan of stealth editing.

I suspected LLM rewriting or generation but I don't possess enough knowledge into how the Apple pre-boot environment works to make an accurate judgement on the accuracy of the post. But I definitely had very strong suspicions of LLM influence with all the bullet lists and hem-hawing the post does; I would expect that someone who successfully reverse engineered the boot chain this thoroughly wouldn't need to hedge anything but Apple's rationale on why they did things. But maybe I'm too overly focused on details.

[matu3ba]

Can you recommend a more factual and complete overview on Apple security architecture and bootchain than this bug-ridden article? I'm interested in hardware security (models).