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.
The data "destruction" is erasing the AES key. No data is actually destroyed. The AES key is not initialized (your word was salt) by the passcode that would be impossible, too short. Nor is it initialized by the passcode hash even though that is possible. I assume that's what you mean by salt. Salt is used with a hash, not encryption and decryption. Those use an IV.
What actually happens is this: the passcode is salted and hashed and expanded using UID (expansion being a complex hashing process to create a KEK) If it successfully decrypts the AES key you are in. It is certainly plausible to bypass key erasure unless there is a match, that should all be programmed in the firmware and modifiable. But the FBI wants an entirely new channel to do their passcode testing. They suggest bluetooth, wifi and I forgot their other suggestion. IOW, they have no robot finger to type passcodes.
No one knows what UID was burned into that ROM at manufacture was. The UID, a Device Group ID (GID), and the user's input passcode all make up only HALF of the AES key. The other HALF is made up of initially read random inputs from the camera, microphone, and accelerometer, as well as other sensors at the first startup which are combined by an algorithm and then stored for use thereafter. Those stored random inputs are combined with the UID, GID, and user's Passcode, all entangled to actually create the large alphanumeric and symbol KEY for the encryption, from which a comparison HASH is made and stored. The final size of that KEY is indeterminate, but it is at least 132 characters in length and at most 256.
Since no one knows what the possible starting points are, Ray76, there is no way to "spin through possible salts and trying each key." Your proposal is suggesting trying every possible key there could be. I don't think you have a clue about the magnitude of that number.
Apple's protocol allows those characters used for the KEY to be any of the characters reachable from the Apple Keyboard. There are 233 of those. Any one of those characters could be in any one or more of the positions of the AES KEY. Using the smallest possible of 132 characters, each of which could be one of those 233 characters, means that there are 132233 possible KEYS to the data on just one iPhone.
1,240,869,102,926,930,271,860,985,237,597,132,425,094,84,408,742,359,858,346,588,174,075,897,786,265,565,693,187,489,738,175,307,484,703,338,748,755,651,745, 687,911,932,171,965,871,748,608,452,386,133,161,972,124,255,648,175,113,747,563,518,247,967,495,956,480,892,924,951,094,785,485,948,340,401,946,603,425,451, 838,237,819,250,367,507,277,540,845,077,389,087,275,271,651,691,442,328,996,896,558,444,716,702,538,449,350,221,955,756,192,906,748,429,543,759,883,093,149, 245,360,855,972,935,011,836,288,581,968,306,133,483,294,124,983,089,110,520,815,210,577,460,928,656,664,335,527,277,252,472,574,518,381,991,908,297,444,937, 577,812,607,343,116,630,498,476,032 Possible KEYS
I've done the math to calculate how many years using a supercomputer capable of comparing 300,000 potential KEYs every second--which is a very complex task involving loading a possible KEY, applying the KEY to a set of the encrypted data, testing to see if that data resolves into anything intelligible in any known language, image compression format, sound format, video format, and other types of possible stored data, etc., deciding if it is a pass or no pass, then moving on to the next KEY. When you start with such a large number of KEYS to test, no matter how fast you can process them, it is going to take a LONG TIME to try ever single KEY to find the right one.
If your supercomputer can process 300,000 KEYS per second, you can figure out how many it can process in any particular time period. For example 18,000,000 per minute, 1,080,000,000 per hour, 25,920,000,000 per day, 9,460,800,000,000 and so on. However, using one of the online very large number calculators provides the answer to how many years it would take to try every KEY. First you let it calculate exactly what 132233 actually equals to give you the ridiculously HUGE number of possible KEYS you want to try. We already know that our Supercomputer can try about 9,460,800,000,000 possible KEYS every year. So we will divide that into that HUGE number of total possible KEYS to find out how many YEARS it would take to try ALL of them to find the right one. Simple arithmetic, right? With me, so far, Ray? Now comes the mind blowing point. Here is the answer to how many years it would take, which that on-line large number calculator totaled for us:
13,115,900,377,631,175,713,057,936,301,339,552,945,785,177,653,302,031,365,908,609,639,343,161,917,128,117,409,467,459,218,597,527,133,364,910,869,657,084,568, 737,520,312,443,543,014,185,740,358,757,521,771,110,715,335,719,507,203,150,211,213,424,604,257,196,103,175,730,497,926,759,465,197,488,790,229,518,164,620,141, 829,364,363,215,296,543,721,997,863,720,538,989,477,812,811,002,134,797,961,952,976,143,934,809,883,965,621,908,949,867,532,177,991,687,794,171,016,113,368, 938,776,100,859,529,457,189,874,884,379,067,657,505,177,478,554,722,731,186,641,453,252,225,674,819,838,415,065,583,520,898,695,881,099,727,025,720,613,247, 569,692,110 YEARS TO TRY ALL OF THOSE KEYS !