The compatibility issue is likely exactly why it's limited to Win32 applications with a manifest and Metro apps.

itunes asked if she'd like to sync with the new device. she said yes. it deleted all of the music on her computer, including physical files

This did not occur. iTunes does not permit an iOS device to become the "master device" for songs. It will only copy songs to the iOS device (except for purchased songs, which it copies to the existing iTunes library). It's actually a very common complaint that iTunes won't copy all songs off an iOS device.

iTunes never accepted the iPod as a master copy. In fact, one of the main complains about iTunes is there's no way to copy songs off a device. iTunes only copy files to devices (although they eventually added the ability to copy only purchased songs off a device).

And that's exactly what Apple will be doing. Since Apple cannot reproduce the issue, and has no real idea if it ever occurs, is a user error, or is a bug, they basically have one option:

Go through all the code that uses FSDeleteObject(), FSUnlinkObject(), and unlink() (The function calls iTunes actually makes) and either replace them with calls to FSMoveObject() or fortify the code with additional error checking they can't confirm will help.

The issue is, under no circumstances is iTunes supposed to delete music files. Even when explicitly telling iTunes to delete files, the code uses FSFindFolder() and FSMoveObject() to move the files to the trash instead of outright deleting it. And for huge collections of files, like with 122GB, deleting items from the trash is not fast since Mac OS X uses assloads of error checking and notification sending to make sure none of the files are in use or lack the appropriate permissions (it doesn't simply unlink() files). This means the user will see a trash dialog counting up and then down the number of files to delete.

Even if there is a rare deletion bug, it's extremely likely most of the reports of iTunes deleting music are false. Even when songs "disappear from the iTunes library" (like if you modify a playlist on one device and have playlist syncing on through iTunes in the Cloud, iTunes Match, or Apple Music), the song files remain on disk.

iOS has an anti-replay counter to prevent reimaging like the type you suggest to assist with a brute force attack. Furthermore, the "secure enclave" is a marketing term Apple uses to group disparate security features under one umbrella. Most of the security features under the "secure enclave" umbrella still existed on previous iOS devices.

Finally, the Apple A6 SoC does have its own rewritable NVRAM that can be used to store the number of incorrect attempts without needing to store it on the NAND.

On iOS, the TouchID bad guess counter is global. So even bad guesses in apps that ask for the fingerprint via TouchID count against the limit of 5.

Not really sure that's necessary. As this is an iPhone, TouchID is disabled if the device is rebooted, 48 hours pass, or their are five incorrect attempts at fingerprint scanning.

That is, they're far more likely to burn through the 5 attempts than they are to hit the duress finger.

You haven't "wrecked" anything. All you've done is proven your unwillingness to learn.

At least you're finally acknowledging it's no where near as simple as brute forcing a 4 digit PIN, as your previous posts claimed repeatedly.

Now you've realized/learned there are other major, significant hurdles to doing a brute force attack, such as finding security holes in other parts of iOS that first allow you to run arbitrary code on the iOS device when you have physical access or getting access to the UID by physically decapping the SoC.

So I assume this means you've stopped claiming it's as simple as reading the NAND directly.

The core functionality of the encryption methods haven't changed much, as you can clearly see if you compare the iOS 7, Feb 2014 security paper to the 2015 iOS 9 security paper.

There are many excellent guides on how iOS encryption works. There's no need for you to remain this ignorant about how iOS encryption works.

As reading the iOS Security Paper has proven too difficult for you, here's an excellent iOS Encryption Primer that discusses how iOS encryption actually works.

Sigh. The encryption methods haven't changed in years. iOS devices have had these features for multiple generations. You can read the iOS Security Paper from February 2014 to confirm this. It starts on page 8.

Sigh. Could you at least have tried to read the iOS Security Paper before posting?

If you had, you would have realized the decryption key is derived from the passcode, the unique UID burned into the SoC, and the GID unique to each model family.

In order to brute force the securely generated AES 256 decryption key via the passcode, you need the other pieces of information. Had you read the paper, you would have learned how difficult that task is.

Oh, so that means your laptop doesn't support InstantGo/Connected Standby, which requires soldered RAM for security reasons (to prevent cold boot attacks).

Know how I can tell you've never read the iOS Security Paper and have no actual knowledge of how iOS encryption works?

Because you think a 4 digit numeric passcode is the only thing that makes up the securely generated AES 256 encryption key. It's not. At all.

Here's the iOS Security Paper. The relevant section begins on page 10. Read it. Understand it. Then review your original comment and learn how many fundamental mistakes you made.

Using multiple static data sources when generating an encryption key protects against extremely weak passcodes.