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 !
You are making the problem larger than it is.
The key is stored. It can be retrieved.
Now that I think about it the solution is extremely simple.
The boot ROM contains Apple’s public key and the bootstrap loader. The public key is used to verify programs run by the bootstrap program prior to running them.
The boot ROM will run the Low-Level Bootloader (which is signed by Apple), then iBoot runs (it too is signed by Apple) and in turn launches the iOS kernel. Each of these programs are updated by Apple from time to time. The updates are provided by services at apple.com. Those services use the device UID to ensure that only the latest versions are downloaded, and downloaded only once.
It would be very easy to place the subject device and a server on their own network and provide updates to either the Low-Level Bootloader or iBoot, which ever counts the sign-on attempts. Rather than incrementing the counter every sign-on attempt, set it to 1.