You're believing that there's some magic cryptography that guarantees that you can only try 10 pins. There isn't. There's explicit code that Apple wrote that can be bypassed by Apple. In fact, this code has been changed by Apple during regular iOS updates, e.g. when they added the feature to require a PIN once a week.
No it doesn't work that way. What you know is old information that no longer works for years.
Apple can't magically bypass the passcode because everything is locked inside an isolated Secure Enclave, including the decryption key of flash storage. Without that key every single bit of data on iOS devices is inaccessible because they're all encrypted before writing onto the flash memory.
Before SE, Apple is capable to make a modified version of firmware, signing with their master certificate, and upload to the target phone via DFU. In the modified version of firmware they can lift the error limiting that auto wipe data after certain errors, thus make the brute force applicable. And that's exactly what FBI asked for in San Bernardino case. Due to very obvious reason, Apple was unwilling to do that.
But things changed after SE. Now everything regarding to security must first go though SE, including passcode verification. DFU firmware update is no longer valid since all your data is inaccessible until SE says yes, and SE can easily wipe out everything, simply by erasing the decryption key stored in it. And SE is booting separately from the main system: it has its own memory storage and running its own kernel. Every encryption and decryption of the main flash storage is solely done in SE that even the main processor doesn't know what the decryption key is.
It's just plain impossible to have a "explicit code" now.
P.S. It also worth noting that the "2017 Secure Enclave Hacking" incident is a fake news. The hackers just extracted the firmware and tried to decrypt a partial of it. They didn't even figure out how it really works, let along finding a way to access decryption key.
No you are completely misunderstanding. Cellebrite is going through a backdoor. The anti-hammer provisions are a front door. Cellebrite can't modify core OS code due to OS signing. Apple holds the signing keys and can.
No Cellebrite did not find any "backdoor" but exploit the hardware structure of old iPhone 5C. They made a device that cut off signals when the passcode is incorrect and force shutdown the machine, before the error input counts accumulate. Without the auto wipe limitation, you just need to try 10,000 times to get it unlocked and it takes just few hours to do so.
Any iPhone after 5C is not applicable for this method, not to mention the iOS devices with SE.
Also note the caveat "End-to-end encryption requires that you have two-factor authentication turned on for your Apple ID.". If you didn't turn it on, they have access to everything on iCloud.
Something needs to be clarified.
End-to-end encryption means that data is encrypted and decrypted on the device end before they're sending to the cloud or after they're downloaded from the cloud, and the key will not be submitted to the server side. In Apple systems this key is generated from the hardware unique ID combined with your local user account info (such as passcode), and that's why you need to set up two factor authentication, because the original device that encrypted these message must pass the key onto the device you're logging in via another PK-based end-to-end channel that just constructed when Apple pushes verification code to these devices.
It also means that only Apple device is capable to decrypt these data, not any arbitrary web browser. As a result, data that can be accessed outside of Apple device, i.e. everything on iCloud.com web interface, are **NOT** encrypted using end-to-end. So far as we know, only a part of highly sensitive data are encrypted by end-to-end, including Health, Keychain, payment, and Siri. Anything else, including device backup, are **NOT** encrypted using end-to-end but a standard AES symmetry master key.
With or without two factor authentication, Apple CAN recover the backup onto a new device, and will submit to the law, as they did in both San Bernardino and this case.
Again, your first article explicitly discusses iMessage, something you apparently posted but didn't read. iMessage is end-to-end encrypted, but your article specifically notes that if iCloud messages and backup is turned on, then that protection is lost.
He is right. iMessage is end-to-end encrypted ONLY during transmission that Apple can't intercept. All the iMessage conversation **DATA** stored on your device is not. It's handled in the same way as other data on your iOS device. And you CAN recovery your iMessage from backups.
However, the newly received messages that is not yet included in the last backup, like the ones in San Bernardino case that FBI accidentally bricked the phone before they reaching Apple, can not be recovered, of course.