Live data from Hacker News

A Reverse Engineer's Anatomy of the macOS Boot Chain and Security Architecture

stack.int.mov

11–20 of 52 posts

Re: A Reverse Engineer's Anatomy of the macOS Boot Chain and Security Architecture

#11
post #5

This is a really interesting deep dive but why does the article hedge so much? For example, in the first few sections it says things like "... typically reveals the following sequence" or "The Boot ROM sets a specific control bit in the AES configuration register (e.g., AES_CMD_USE_GID)", which makes it sound like the author wasn't actually sure if any of this was accurate and was guessing.

> e.g., AES_CMD_USE_GID

Sometimes people mix up “i.e.” (“id est”; “that is”) and “e.g.” (“exempli gratia”; “for example”).

Of course, only the author knows if this case was a mix up, or if they really wrote what they meant.

Re: A Reverse Engineer's Anatomy of the macOS Boot Chain and Security Architecture

#12
post #5

This is a really interesting deep dive but why does the article hedge so much? For example, in the first few sections it says things like "... typically reveals the following sequence" or "The Boot ROM sets a specific control bit in the AES configuration register (e.g., AES_CMD_USE_GID)", which makes it sound like the author wasn't actually sure if any of this was accurate and was guessing.

It's AI assitance. If you search for "e.g." the page lights up like a christmas tree. There's 90 appearances if "e.g."

I have never seen this frequency before.

Re: A Reverse Engineer's Anatomy of the macOS Boot Chain and Security Architecture

#13
post #5

This is a really interesting deep dive but why does the article hedge so much? For example, in the first few sections it says things like "... typically reveals the following sequence" or "The Boot ROM sets a specific control bit in the AES configuration register (e.g., AES_CMD_USE_GID)", which makes it sound like the author wasn't actually sure if any of this was accurate and was guessing.

> e.g., AES_CMD_USE_GID Sometimes people mix up “i.e.” (“id est”; “that is”) and “e.g.” (“exempli gratia”; “for example”). Of course, only the author knows if this case was a mix up, or if they really wrote what they meant.

For anyone looking for a more memorable mnemonic, learned them as "I explain" and "example given".

Re: A Reverse Engineer's Anatomy of the macOS Boot Chain and Security Architecture

#14
post #12
post #5

This is a really interesting deep dive but why does the article hedge so much? For example, in the first few sections it says things like "... typically reveals the following sequence" or "The Boot ROM sets a specific control bit in the AES configuration register (e.g., AES_CMD_USE_GID)", which makes it sound like the author wasn't actually sure if any of this was accurate and was guessing.

It's AI assitance. If you search for "e.g." the page lights up like a christmas tree. There's 90 appearances if "e.g." I have never seen this frequency before.

Or maybe fully AI-generated. There's many factual errors in the article too.

Re: A Reverse Engineer's Anatomy of the macOS Boot Chain and Security Architecture

#15
post #5

This is a really interesting deep dive but why does the article hedge so much? For example, in the first few sections it says things like "... typically reveals the following sequence" or "The Boot ROM sets a specific control bit in the AES configuration register (e.g., AES_CMD_USE_GID)", which makes it sound like the author wasn't actually sure if any of this was accurate and was guessing.

I smell AI writing assistance. Which is a shame because this is otherwise very good and well-collated information about Apple's security. But AI loves to use bullet point lists just for the hell of it and it makes the information here smell way less reliable than it actually is. I'm also not sure if it's 100% accurate. My (possibly wrong) understanding of the guarded execution feature is that each GL is paired with a…

Perhaps using AI assistance is good OPSEC. It could help to shield the author from stylometry or author profiling.

Re: A Reverse Engineer's Anatomy of the macOS Boot Chain and Security Architecture

#16
post #5

This is a really interesting deep dive but why does the article hedge so much? For example, in the first few sections it says things like "... typically reveals the following sequence" or "The Boot ROM sets a specific control bit in the AES configuration register (e.g., AES_CMD_USE_GID)", which makes it sound like the author wasn't actually sure if any of this was accurate and was guessing.

I smell AI writing assistance. Which is a shame because this is otherwise very good and well-collated information about Apple's security. But AI loves to use bullet point lists just for the hell of it and it makes the information here smell way less reliable than it actually is. I'm also not sure if it's 100% accurate. My (possibly wrong) understanding of the guarded execution feature is that each GL is paired with a…

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...

Re: A Reverse Engineer's Anatomy of the macOS Boot Chain and Security Architecture

#17
post #5

This is a really interesting deep dive but why does the article hedge so much? For example, in the first few sections it says things like "... typically reveals the following sequence" or "The Boot ROM sets a specific control bit in the AES configuration register (e.g., AES_CMD_USE_GID)", which makes it sound like the author wasn't actually sure if any of this was accurate and was guessing.

I smell AI writing assistance. Which is a shame because this is otherwise very good and well-collated information about Apple's security. But AI loves to use bullet point lists just for the hell of it and it makes the information here smell way less reliable than it actually is. I'm also not sure if it's 100% accurate. My (possibly wrong) understanding of the guarded execution feature is that each GL is paired with a…

I think the article is being stealth edited which is a bit annoying; its explanation of guarded execution is now closer to yours, which I think is accurate.

Re: A Reverse Engineer's Anatomy of the macOS Boot Chain and Security Architecture

#18

Earlier quoted context omitted.

I smell AI writing assistance. Which is a shame because this is otherwise very good and well-collated information about Apple's security. But AI loves to use bullet point lists just for the hell of it and it makes the information here smell way less reliable than it actually is. I'm also not sure if it's 100% accurate. My (possibly wrong) understanding of the guarded execution feature is that each GL is paired with a…

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"…

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!

Re: A Reverse Engineer's Anatomy of the macOS Boot Chain and Security Architecture

#19

Earlier quoted context omitted.

I smell AI writing assistance. Which is a shame because this is otherwise very good and well-collated information about Apple's security. But AI loves to use bullet point lists just for the hell of it and it makes the information here smell way less reliable than it actually is. I'm also not sure if it's 100% accurate. My (possibly wrong) understanding of the guarded execution feature is that each GL is paired with a…

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"…

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

Re: A Reverse Engineer's Anatomy of the macOS Boot Chain and Security Architecture

#20

Earlier quoted context omitted.

I smell AI writing assistance. Which is a shame because this is otherwise very good and well-collated information about Apple's security. But AI loves to use bullet point lists just for the hell of it and it makes the information here smell way less reliable than it actually is. I'm also not sure if it's 100% accurate. My (possibly wrong) understanding of the guarded execution feature is that each GL is paired with a…

Perhaps using AI assistance is good OPSEC. It could help to shield the author from stylometry or author profiling.

And then the author posts it himself to Hacker News. Nah, that's not opsec.
Post reply on HN