There is one AES key encrypting most of the data on the phone. That key is stored in flash but it is encrypted. Some data from ROM forms part of the KEK (key encryption key, also used to decrypt that AES key). Other data needed for the KEK is the hash of the passcode.
To get the needed AES key someone has to enter the correct passcode, then the SW creates the KEK and uses it to decrypt the AES key. If 10 incorrect passcodes are entered the SW deletes the AES key. The user's data stays intact but cannot be decrypted. The FBI wants that numerical restriction eliminated. Second they want an internet or bluetooth interface for guessing the passcode instead of typing it on the screen. That doesn't exist at all. Third they want the AES key deletion turned in addition to turning off the numerical restriction. These are demanded in the court order, not optional.
They also requested the SW to load on the phone although they did not demand it. They said Apple can tailor the SW to work on that one phone only while giving some hand wave about how that would be done. They even suggested using a unique ID assigned by the carrier (Verizon) which can obviously be assigned to any phone they want to compromise in the future (either they are stupid or think we are).
The hardware has a UID in ROM. I think the UID, the AES key, and the passcode as a salt for the AES, are combined. The passcode length is 6. Having the AES from ROM and the hardware UID from ROM it shouldn’t be too difficult to spin through possible salts and trying each key.
The boot program is in ROM as well. On powering on the boot program begins to execute, checking the integrity of programs prior to executing them. The programs are signed with Apple’s public key. The public key is stored in ROM. If any signature checks fail the boot program halts and goes to “device firmware upgrade” mode, aka “reset mode”. This is when data will be destroyed. (What that destruction method is, I don’t know. Is it set to x00?) Not starting the boot program seems to be a solution.