Difference between revisions of "Talk:OTA Updates"

From The iPhone Wiki
Jump to: navigation, search
(Splitting by individual firmware)
(Splitting by individual firmware)
Line 117: Line 117:
 
::::I actually like [[User:Spydar007|Spydar007's]] idea. Another idea that I had was we could have used something like [[OTA Updates/iPhone/11.0.x]], [[OTA Updates/iPhone/11.1.x]], etc and include both beta and public released but I do think Spydar007's idea is better. --[[User:IAdam1n|iAdam1n]] ([[User talk:IAdam1n|talk]]) 22:41, 13 December 2017 (UTC)
 
::::I actually like [[User:Spydar007|Spydar007's]] idea. Another idea that I had was we could have used something like [[OTA Updates/iPhone/11.0.x]], [[OTA Updates/iPhone/11.1.x]], etc and include both beta and public released but I do think Spydar007's idea is better. --[[User:IAdam1n|iAdam1n]] ([[User talk:IAdam1n|talk]]) 22:41, 13 December 2017 (UTC)
 
::::I think the beta and public release OTA updates were never split up because they were initially delivered on the same XML. Apple only started using a different XML for betas around iOS 10 (...maybe a 9.x firmware?). Splitting off the beta updates would be good for consistency, but I don't think it'll address the page size issue by much; Apple typically pushes two OTA packages at most per beta release (one "universal" release, and one delta for the previous beta). This also brings up a rather minor question: should we go with this, how would we treat carrier and internal builds? Would those be clumped together with the beta OTA updates, or would they have their own page (e.g. "Carrier OTA Updates")? --[[User:Dialexio|Dialexio]] ([[User talk:Dialexio|talk]]) 22:52, 13 December 2017 (UTC)
 
::::I think the beta and public release OTA updates were never split up because they were initially delivered on the same XML. Apple only started using a different XML for betas around iOS 10 (...maybe a 9.x firmware?). Splitting off the beta updates would be good for consistency, but I don't think it'll address the page size issue by much; Apple typically pushes two OTA packages at most per beta release (one "universal" release, and one delta for the previous beta). This also brings up a rather minor question: should we go with this, how would we treat carrier and internal builds? Would those be clumped together with the beta OTA updates, or would they have their own page (e.g. "Carrier OTA Updates")? --[[User:Dialexio|Dialexio]] ([[User talk:Dialexio|talk]]) 22:52, 13 December 2017 (UTC)
  +
:::::I still think it'd be worth a shot. If we really needed to, we could break it down to use my idea but keep beta's on the beta one and public on public if we get to a point where it's still too big with public only. As for carrier OTA's, I think they should have their own page. --[[User:IAdam1n|iAdam1n]] ([[User talk:IAdam1n|talk]]) 00:35, 14 December 2017 (UTC)

Revision as of 00:35, 14 December 2017

Archives
 • 2012 • 2013 •

Encryption

Are the updates encrypted in any way (VFDecrypt?) --5urd 18:31, 30 August 2011 (MDT)

No. Just regular Zips. --M2m 22:36, 30 August 2011 (MDT)
Only NOR payloads and RAM disks are encrypted, rest of the "asset" is unencrypted --pjakuszew 04:19, 31 August 2011 (MDT)
The Kernel and bootloaders ARE encrypted, They are the exact same files as bundled with the .ipsw file --Itsme (talk) 16:04, 7 February 2013 (UTC)
Exactly as in same code, but different key/IV pair, or same code, and same key/IV pair? --5urd (talk) 16:15, 7 February 2013 (UTC)
the same key/IV pair, the encrypted binaries are identical. --Itsme (talk) 21:49, 7 February 2013 (UTC)
Most of the update consists of binary patchfiles, which can be processed using bspatch --Itsme (talk) 00:14, 9 February 2013 (UTC)

Tracker

Anyone into making a watchguard that tracks mesu.apple.com for changes (and records them)? --M2m 00:55, 12 November 2011 (MST)

Should do the trick to make a backup of OTA.xml's whenever there is a change
#!/bin/bash
SHA_OLD=1
while true; do
SHA_CUR=$(curl --user-agent 'softwareupdateservicesd (unknown version) CFNetwork/539 Darwin/11.0.0' http://mesu.apple.com/assets/com_apple_MobileAsset_SoftwareUpdate/com_apple_MobileAsset_SoftwareUpdate.xml | shasum)

if [ "$SHA_OLD" = "$SHA_CUR" ]; then
	echo nothing to do
else
	NOW=$(date +"%F")
	NOWT=$(date +"%T")
echo download
	curl --user-agent 'softwareupdateservicesd (unknown version) CFNetwork/539 Darwin/11.0.0' http://mesu.apple.com/assets/com_apple_MobileAsset_SoftwareUpdate/com_apple_MobileAsset_SoftwareUpdate.xml -o OTA_$NOW-$NOWT.xml

	SHA_OLD=$(curl --user-agent 'softwareupdateservicesd (unknown version) CFNetwork/539 Darwin/11.0.0' http://mesu.apple.com/assets/com_apple_MobileAsset_SoftwareUpdate/com_apple_MobileAsset_SoftwareUpdate.xml | shasum)
fi
sleep 600
done
--M2m 08:33, 24 March 2012 (MDT)

Applying .patch files from OTA updates

Hey guys, has anyone successfully "patched" a file with a .patch file from the "patches" folder of an OTA update? I am trying to do this and can't get it to work. I have tried on OS X, iOS, and Linux, with multiple different patches, and always get the same error:

patch: **** Only garbage was found in the patch input.

With --verbose option:

Hmm... I can't seem to find a patch in there anywhere.

I understand from some research that common .patch files have a certain syntax to them, bu I have looked inside these .patch files (using a text editor) and they never contain any readable text (even a .txt.patch file). This leads me to believe that iOS uses a specific and exclusively designed version of Patch. If so, how would I make use of that?
Ideally I would patch the files on-device via SSH, as I am developing something yet-to-be-announced which would need to do so automatically. If needed, it could alternatively be done using Mac OS X or Linux.
I would greatly appreciate any help, --ValleyForge 23:12, 28 June 2012 (MDT)

I'd like to help, but I need to learn :P --Haifisch 21:49, 5 July 2012 (MDT)
I actually figured it out, you have to use the bspatch command which is available on iOS, Mac OS X, Linux, and Windows :) --ValleyForge 22:59, 5 July 2012 (MDT)
Fancy wanna iMessage me and we can brain storm what good can come out of this. Maybe a jailbreak technique ;) --Haifisch 10:21, 6 July 2012 (MDT)
Quick note: all OTA updates are signed with a private key owned by Apple. Unless you get into that department of Apple, you can't sign them without brute force. --5urd 12:09, 6 July 2012 (MDT)

Do BOM files contain any hash sums?

File Names

Does anyone have the slightest on how Apple names their files? It looks like a hash that is 20 bytes long (40 hex chars/160 bits). From this list, there are a few like that, but none that I have heard of. --5urd 14:32, 21 July 2012 (MDT)

Should be the SHA-1 of the file.--M2m 21:14, 21 July 2012 (MDT)

Resequence? and deleting files?

  1. In most updates there are "added", "patches", and "replace" folders in the payload folder. In the iOS 6.0 updates, there is a folder among those named "resequence". What does this do? Currently the only file contained in the resequence folder is the dyld cache.
  2. How do OTA updates control which/whether files are deleted? Where is it specified which files are deleted, or do they delete files at all?

--ValleyForge 23:55, 29 September 2012 (MDT)

Documentation

Someone should make a page with the documentation links, here's the XML: http://mesu.apple.com/assets/com_apple_MobileAsset_SoftwareUpdateDocumentation/com_apple_MobileAsset_SoftwareUpdateDocumentation.xml --Srb21103 20:16, 20 November 2012 (MST)

I was wondering where the documentation was retrieved from… I don't think it needs a new page, but I think it can be easily added onto this page as a new column. --Dialexio 20:04, 24 November 2012 (MST)

Exploits

I'm interested in this stuff also. I have a sense there's an exploit here somewhere, but I haven't had time to look into it --posixninja 17:18, 22 November 2012 (MST)

Their would definitely be an exploit, but it'd be fairly easily patched by Apple. You're best looking for a bootrom exploit. --Srb21103 19:48, 22 November 2012 (MST)
Removing the signing checks would be a big achievement because we could have jail broken OTA Updates by patching out the kernel and some files in the package. --5urd 20:32, 22 November 2012 (MST)
I've been examining the Settings app, kernel, and appropriate frameworks, but I haven't found anything. It is however obvious that the package contents are signed. --5urd 20:32, 22 November 2012 (MST)
I set up a fake mesu.apple.com server for testing, but it seems that even the plist is somehow signed. After changing a single letter in the plist, iOS says something about having a connection problem when trying to fetch it. --Tobi 11:00, 26 November 2012 (CEST)
The Plist contains a certificate and a signature section at the bottom - so obviously this takes care that a plist can not be modified by just anyone.--M2m 05:27, 26 November 2012 (MST)
LOL, stupid me for not actually looking at the file. Although I found the source of the thing that signs the files. Look for the function called SecPolicyCreateMobileAsset --Tobi 16:04, 26 November 2012 (CEST)
A header file isn't going to do us much good. Maybe something along the lines of the actual source itself (search for SecPolicyCreate)? --5urd 18:19, 26 November 2012 (MST)

Anyone noticed that Apple's iOS Updater seems can modify files under "/" IPA File ? --khaost 15:59, 13 December 2012 (CST)

Yes, please look here: Trampoline --Srb21103 15:24, 13 December 2012 (MST)

Apple TV

I don't really know how to add these to the wiki. 2G 3G They're mentioned in the mesu.apple.com XML, but are a bit different from the other OTA updates. (Notably, considering the file size, it looks like it contains an image to restore an Apple TV.) Any ideas?

Speaking of the Apple TV, it seems like Apple wants to keep the version numbers confusing. I think that we should add a new column for the "marketing version" for this page as well. --Dialexio 18:57, 2 December 2012 (MST)

I agree that we should list the internal version too. --iAdam1n (talk) 22:43, 27 June 2013 (UTC)

ios8

I just noticed that around 19:30 ( CET ) the appldnld.apple.com domain was removed, but the webserver at ipaddress 17.253.2.226 is still serving the OTA updates. So if you add the appldnld domain in your /etc/hosts file, you can still download. I guess apple did this because of the ios8 update. So they can test if everything is allright before opening everything up to the public. Itsme (talk) 17:44, 17 September 2014 (UTC)

There are inferno logs in one of the OTA updates.

Download 5.0b5 for the iPod touch 4G here. Then, unzip it, go to AssetData -> payload -> added -> private -> var -> logs -> Inferno -> Plists -> N81. Weird, right? I wonder if most OTA beta updates are like that. --Awesomebing1 (talk) 13:52, 11 December 2014 (UTC)

Ok, looked at another OTA. They even went as far to patch those files. Weird. Don't they want to keep this type of stuff secret? --Awesomebing1 (talk) 13:57, 11 December 2014 (UTC)
There's been a few cases in which Apple did not strip all internal data off of both OTA packages and IPSWs, this is a little interesting cause it's all of Inferno's test plists. --Haifisch (talk) 18:50, 13 December 2014 (UTC)

Page Partitioning

This page has a pretty big problem— about 1 MB, to be more precise. The wiki markup makes this page a monster to edit— to the point where my computer chokes whenever I try to make edits. (This computer's admittedly a six year old relic, but the specs should be more than capable of editing a web page, of all things— heck, I have less trouble with editing 4+ MB images.) As such, I would like to propose partitioning the page in a fashion similar to (but not exactly like) how Firmware used to be. Keeping in mind the editing limit, dividing the page based on device type (Apple TV, iPad, iPad mini, etc.) should be more than suitable for this. --Dialexio (talk) 23:29, 12 April 2015 (UTC)

This is a great idea. My MacBook Pro also lags badly when editing that page and maxes out my RAM due to the page being huge. --iAdam1n (talk) 08:25, 13 April 2015 (UTC)
This has now been completed. --iAdam1n (talk) 11:34, 17 April 2015 (UTC)

This is sort of becoming an issue again because it takes ages to edit. I've been thinking we should break it down even further. The ideas I have are: 1) Break the pages down from OTA Updates/iPhone to OTA Updates/iPhone/8.x, OTA Updates/iPhone/9.x etc. 2) Keep OTA Updates/iPhone etc and have a table for each major iOS (we could have either a major iOS heading then the devices, followed by next major iOS heading etc or device headings then each major iOS as a table).

Personally I think idea 1 is the best because then the pages could be linked on OTA Updates/iPhone etc that the user would click for the iOS they want without the page taking ages to load. Idea 2 would fix editing being annoyingly slow but not loading each page since it would still have as much content on it. I'd like to think what other people think and if anyone has any other ideas. --iAdam1n (talk) 17:03, 16 January 2016 (UTC)

This has now been completed. --iAdam1n (talk) 09:24, 21 January 2016 (UTC)

Format 1.0

Is anyone able to provide more information about this? (e.g. What updates does it appear in?) All of the updates that I've seen are either in the IPSW format, format 2.0, or format 3.0, and the OTA IPSWs don't quite match the description of format 1.0. --Dialexio (talk) 02:02, 18 February 2016 (UTC)

Splitting by individual firmware

I threw an idea out on Twitter a few days ago on a whim, asking how people would feel about listings being split by individual firmware. To my surprise, the majority of votes were in favor of it. (The idea actually came about after noticing how homebrew wikis for video game systems listed their firmware updates, but I digress.) A few days later, Apple pushed iOS 11.2.1, and while adding the iPhone updates I noticed we have a big problem with the way OTA updates are currently listed. For the iOS 11 updates specifically, it's about 788 KB big. (Literally.) 788 KB for just the page text is a lot for the server to parse into HTML. That bloat is only going to get larger, since Apple's just getting started with iOS 11, and iOS 12 will probably get worse.

I would like to propose cutting up the OTA updates pages based on firmware version. For instance, you would be able to find all of the OTA updates for 10.1.1 at OTA Updates/iPhone/10.1.1. (Builds 14B100 and 14B150 would be listed under different headings.) Updates for a beta could be listed at OTA Updates/iPhone/10.2 beta 2. In addition to addressing the size problem, it also has the benefit of making it easier for users to focus on the firmware version they're looking into. Of course, this rollout will take an excruciating amount of time and effort, and I don't anticipate this being finished until we're well into 2018; if anyone wants to lend a hand, it might be easier to just run older XMLs (I can supply them) through the parser I wrote. --Dialexio (talk) 21:36, 13 December 2017 (UTC)

I think this is an utterly stupid idea, it increases workload and it increases the hideousness or page names. 778 KB is nothing for the wiki to deal with. I'd be far more concerned about fixing the idiotic session error we keep getting on every single page edit. — Spydar007 (Talk) 21:40, 13 December 2017 (UTC)
The workload will be increased until the change is made, but after that it will be trivial. 778 KB isn't that big, but keep in mind that a significant amount it is tags and markup that need to be converted into HTML, and it will continue to blow up— Apple just got started with 11.x releases. Compare OTA Updates/iPhone/11.x with a smaller page like Keynote, and you'll see a pretty noticeable difference in load times. If you really don't think this is an issue still, I invite you to try adding iPhone OTA updates for the 11.2.5 beta— thanks to both the time it takes to process the markup and the stupid session error problem, you'll likely go through a few session errors before it succeeds. (That happened to me when I added 11.2.1 earlier.) --Dialexio (talk) 21:59, 13 December 2017 (UTC)
Whilst I take your point, I still don't think it is necessary to change this. However, I value consistency on this wiki, and, having considered this, I think there is something we could do.
We split Firmware and Beta Firmware up, why do we not do the same with OTA Updates? Is there any reason we can't? If we were going to split OTA Updates by each individual firmware, it would probably be confusing if we didn't do the same with the Firmware pages too. Separating OTA Updates and OTA Beta Updates would decrease page size, and would keep consistency with the Firmware pages. Any thoughts of this? — Spydar007 (Talk) 22:38, 13 December 2017 (UTC)
I actually like Spydar007's idea. Another idea that I had was we could have used something like OTA Updates/iPhone/11.0.x, OTA Updates/iPhone/11.1.x, etc and include both beta and public released but I do think Spydar007's idea is better. --iAdam1n (talk) 22:41, 13 December 2017 (UTC)
I think the beta and public release OTA updates were never split up because they were initially delivered on the same XML. Apple only started using a different XML for betas around iOS 10 (...maybe a 9.x firmware?). Splitting off the beta updates would be good for consistency, but I don't think it'll address the page size issue by much; Apple typically pushes two OTA packages at most per beta release (one "universal" release, and one delta for the previous beta). This also brings up a rather minor question: should we go with this, how would we treat carrier and internal builds? Would those be clumped together with the beta OTA updates, or would they have their own page (e.g. "Carrier OTA Updates")? --Dialexio (talk) 22:52, 13 December 2017 (UTC)
I still think it'd be worth a shot. If we really needed to, we could break it down to use my idea but keep beta's on the beta one and public on public if we get to a point where it's still too big with public only. As for carrier OTA's, I think they should have their own page. --iAdam1n (talk) 00:35, 14 December 2017 (UTC)