Yes but like where would you nop? You can't statically analyse the code because the image is encrypted at rest (and potentially partially in ram also?)
The code which decrypts the system (and is responsible for wiping the drive on repeated failures) is definitely not encrypted. How would it be able to take the input in order to decrypt the drive.
Yes but that code is all running in ram, precluding static analysis. You can still dynamically analyse it, but that is much harder.
The way I understand it (and, correct me if I'm wrong) is that the code flows from disk through the aes engine where it is decrypted and then placed in a presumably interesting/hard to reverse place in ram at which point it is executed. I imagine even more interesting things are done to higher value data in ram, but that's not code - because as you said, code has to be decrypted (at the latest) by the time it reaches the registers.
Their security PDF says that the system has a chain of trust established, anchored at an immutable loader residing inside the chip, and each step verifies the digital signature of the next step against the hardcoded Apple CA certificate.
