Difference between revisions of "Talk:Main Page"

From The iPhone Wiki
Jump to: navigation, search
(HTTPS links on firmwares and OTA's that are hosted on "updates.cdn-apple.com")
(HTTPS links on firmwares and OTA's that are hosted on "updates.cdn-apple.com")
Line 199: Line 199:
 
back when apple was still using appldnld.apple.com, adding https (https://secure-appldnld.apple.com) would make the links unreliable or not work at all.
 
back when apple was still using appldnld.apple.com, adding https (https://secure-appldnld.apple.com) would make the links unreliable or not work at all.
   
but now with http://updates-http.cdn-apple.com, it works just fine to sitch to (https://updates.cdn-apple.com).
+
but now with http://updates-http.cdn-apple.com, it works just fine to switch to (https://updates.cdn-apple.com).
   
 
it is easy as pie to switch the links to use https by using a good text-editing program that has a "find and replace" function. like [https://notepad-plus-plus.org Notepad++] or [https://wiki.gnome.org/Apps/Gedit Gedit].
 
it is easy as pie to switch the links to use https by using a good text-editing program that has a "find and replace" function. like [https://notepad-plus-plus.org Notepad++] or [https://wiki.gnome.org/Apps/Gedit Gedit].
Line 208: Line 208:
 
- [[User:DanTheMann15|DanTheMann15]] ([[User talk:DanTheMann15|talk]]) 22:32, 5 May 2021 (UTC)
 
- [[User:DanTheMann15|DanTheMann15]] ([[User talk:DanTheMann15|talk]]) 22:32, 5 May 2021 (UTC)
 
:(This should probably be on [[The iPhone Wiki:Community portal]] instead, but oh well.) It kinda boils down to personal preference; to my understanding, there was never any sort of formal agreement on this. A user simply started converting some links to HTTPS, and I just let them do their thing since I do see benefits of using HTTPS. (At the end of the day though, you're still going to get the same file, especially if you verify its hash.) But personally, I'd rather keep the links the same way Apple provided them— if they gave us an HTTP link, that's what I'll add, and if they gave an HTTPS link, that's what I'll add. I'm not opposed to others changing the links I post to HTTPS as it's still Apple hosting and providing the download links, but I don't feel we should have to go out of our way to add one more step to an already tedious task. You can make an argument that it's for consistency, but that logic can also be used towards converting HTTPS links back to HTTP, and we would also trim the URLs for the older IPSWs so those look more consistent with newer, pre cdn-apple.com releases. --[[User:Dialexio|Dialexio]] ([[User talk:Dialexio|talk]]) 00:21, 6 May 2021 (UTC)
 
:(This should probably be on [[The iPhone Wiki:Community portal]] instead, but oh well.) It kinda boils down to personal preference; to my understanding, there was never any sort of formal agreement on this. A user simply started converting some links to HTTPS, and I just let them do their thing since I do see benefits of using HTTPS. (At the end of the day though, you're still going to get the same file, especially if you verify its hash.) But personally, I'd rather keep the links the same way Apple provided them— if they gave us an HTTP link, that's what I'll add, and if they gave an HTTPS link, that's what I'll add. I'm not opposed to others changing the links I post to HTTPS as it's still Apple hosting and providing the download links, but I don't feel we should have to go out of our way to add one more step to an already tedious task. You can make an argument that it's for consistency, but that logic can also be used towards converting HTTPS links back to HTTP, and we would also trim the URLs for the older IPSWs so those look more consistent with newer, pre cdn-apple.com releases. --[[User:Dialexio|Dialexio]] ([[User talk:Dialexio|talk]]) 00:21, 6 May 2021 (UTC)
  +
  +
i understand where you are coming from, but i will continue to use https on the firmware links i post, since there are more advantages than the other way around, albeit the possible reason why apple gives us http links is likely because https requires valid certificates, which for some reason not everybody has. also it's important to note about HTTPS-Only on some major browsers so http links will not work for those who have that setting enabled. and like i said above, it takes me a fraction of a second to convert the links to https, thanks to Notepad++. perhaps you could add a setting that you can enable in the OTA Catalog Parser that would automatically convert links to https when parsing the links to save time.
  +
  +
- [[User:DanTheMann15|DanTheMann15]] ([[User talk:DanTheMann15|talk]]) 18:47, 16 May 2021 (UTC)

Revision as of 18:59, 16 May 2021

Archives
 • 2009 • 2010 • 2011 • 2012 • 2013 •

Baseband Chip Page Titles

For the baseband chip page titles, I think we should stick with the model number despite the marketing name. Pages:

--5urd 21:35, 8 May 2012 (MDT)

I'm leaning more towards the marketing names, since I think people are more familiar with them and they've been in use for a long time. We've always referred to the iPhone 2G's baseband as the "S-Gold 2" and the iPhone 3G/3GS's baseband as the "X-Gold 608." (By the way, it sounds like Qualcomm "markets" their chips by model number. [1]) --Dialexio 00:11, 9 May 2012 (MDT)
I created most of these newer pages and always used the model number (without space). So I agree with that in general. Changing old ones is a totally different story though, where we need more consent. I would be for it (and create a redirect on the marketing names). --http 01:52, 9 May 2012 (MDT)

Baseband downgrade possibility: Attempt for 04.11.08/04.12.01 to 04.10.01

0x1 There is no downgrade possibility; according to the most basis of fact in how baseband works as explained by dear MuscleNerd and there is signature checks as well as bootloader's chain of trust that I'm not going to repeat them again, but for this topic I start from iTunes error 1,-1,11

0x2 iTunes error 1,-1,11 : We will get this error whenever we want to do something with BB which is not allowed by apple. you can read about these error in detail from here[2]. Going deeper, this error raise by baseband's bootloader whenever you attempt to downgrade BB (in this case), this happens inside the NOR so this is why we can not exploit it easily from the outside. Another reason for this error (and in here the most important one that I wanted to discuss) is that apple no longer signing that firmware.

0x3 The situation that there is no BB installed on iPhone! : I could restore my iPhone4 in the case of there will be no BB at all. I called it reset my BB. There will be no Wifi, no BT. At the first time (a few months since I've started to work on) I thought it is dead (as apple confirmed this also). But I could restore it only to stock firmware with the latest one. So for who stays in 04.11.08 it may lead to do upgrade to 04.12.01 permanently with the latest iOS, now is 5.1.1 and before for me was 5.0.1, so be sure what you are doing and then go to reset the BB. So back to the game, if there was no BB then there is no bootloeader inside the NOR to stuck BB update process but I do not know that in this case what happened to "sectable" also known as "locktable" which is the master accountable to unlock the carrier, any way I think so only firmware signature checking by apple will be remain in "restore verify process" by iTunes. because as mentioned earlier, "currentBB"(BB to be updated) is allowed to be update by "comingBB" (BB to be updating to) only if : 1. "currentBB" < "comingBB" (= are you the most recent/lastest BB?) 2. "comingBB" is now signing by apple (=if so, does apple sign you? Are you eligible?) Huum... What happens if "currentBB"="null/zero/no matter"? Could we eliminate option (1) from the security check above in this case? So what next?

0x4 Track back to the issue lead us inside the bbfw file (ICE3_04.11.08_BOOT_02.13.Release) which contains four .fls files inside, and the most important one is psi_flash.fls who is in charge of security checks before handover the routines to stack.fls which is responsible for updating the baseband. This file does like NOR bootloader but fortunately it's outside the device so it is accessible but not such easy format to be understand by programmers. They are raw ROM based images for XMM6180 chip, ARM based and programmed in Thread-X, but the compiler is unknown; I will write about some disassembly notes using ida pro 6.1; by the way I leave my iPhone with no BB trying to find out and break the trust chains in the above files in order to bypass the bootloader security checks which may let us to downgrade to 04.10.01 which is currently unlocked by Gevey. Keep in mind that if this solution works..., it will need the SHSH for downgrading the iOS firmware to do reset the BB. I heard that iPhoneDevTeam are going to release the new version of Redsn0w which there will be no need to restore by iTunes but I do not know if the baseband approaches supposed to be addressed or it will work like iFaith that is basically bypass (preserve) BB, any way if I found this article useful I will note about disassembly and possibility approach as well as BB reset to share with any followers. --Kambiz 07:49, 13 May 2012 (MDT)K.N

Bluetooth Chip on iPhone 5

Is there any confirmation of the Bluetooth chip used in the iPhone 5? If there is, can we edit this page and add it? --5urd 10:04, 8 October 2012 (MDT)

Chipworks analyzed the iPhone 5's Murata Wi-Fi module and determined it uses the BCM4334. I'll add it to the Main Page now. --Dialexio 20:35, 8 October 2012 (MDT)

Adding vulnerability to main page

The page CVE-2013-0964 is currently orphaned. I think it would fit under the "Vulnerabilities and Exploits" subheading. Can someone with adequate permission make the change? 0x56 (talk) 03:52, 12 September 2013 (UTC)

Added. --http (talk) 00:53, 13 September 2013 (UTC)

Update for new devices

Somebody should update the main page (table) for the 5s and 5c --Phyrrus9 (talk) 21:14, 2 October 2013 (UTC)

No need. It says "iPhone 4S and newer". --iAdam1n (talk) 22:01, 2 October 2013 (UTC)

Permission

Permission to add pangu8? Or should we wait until a Cydia version comes out? --Awesomebing1 (talk) 15:52, 22 October 2014 (UTC)

It has already been added and is fine IMO. I would state that it's SSH only though. --iAdam1n (talk) 16:22, 22 October 2014 (UTC)

All of the Watch product images?

So I was looking for Apple product images and found this interesting document that has links to all of the (current) product images. Since the Apple Watch has so many models, editions, colors, etc., would it be worthwhile to upload all the images listed from the document? So far I've found this one. (Apple Watch 42mm, Stainless Steel buckle) --Citrusui (talk) 18:01, 5 September 2015 (UTC)

It's not a great idea to upload images from Apple's website in general, since they're copyrighted by Apple, unless you can make a decent argument that using a copyrighted image in a particular article is is fair use. Britta (talk) 09:01, 6 September 2015 (UTC)

Removal of Apple TV 3G from "Latest Firmware" Section?

Apparently, the Apple TV 3G has not received any updates from Apple for a long time and looks like it will not get any in the future. So, should we remove it from the "Latest Firmware" section on the Main Page? Any other thoughts? --Tp1194045441 (talk) 03:51, 28 November 2015 (UTC)

It's still been sold so it should stay as it's still "active" for this reason. --iAdam1n (talk) 22:34, 23 February 2016 (UTC)

Cleanup

This page has a lot of links... It almost looks intimidating. That's not exactly an impression you want to leave on a first-time visitor. I'd like to clean it up, but I'm not entirely sure on what to cut out. I currently have everything in "Hardware" underneath the basebands in mind, and some of the definitions (be honest, how popular of a topic do you think iBEC is?). Any thoughts on what can or should not be cut? --Dialexio (talk) 21:09, 23 February 2016 (UTC)

I think we should remove links to pages that have not been created yet. We can always add them back if/when made. --iAdam1n (talk) 22:33, 23 February 2016 (UTC)

KPP

Is there a reason why a KPP page has not been created? It would be useful to many... --Detiac 15:19, 9 October 2017 (UTC)

It would certainly be useful and something that should be on the wiki, but I don't think any active users are knowledgeable enough on the topic to provide a writeup. --Dialexio (talk) 02:23, 11 October 2017 (UTC)

Rename Bad Stuff section

I don't know what we could rename it to, but it doesn't come off very well --Nullpixel (talk) 17:26, 10 October 2017 (UTC)

Although the name is accurate, "Bad Stuff" does sound a little... off-kilter. Maybe something like "Malicious/Cautionary Topics?" --Dialexio (talk) 02:23, 11 October 2017 (UTC)
Sorry for the late response. I agree, this is a better name. --Nullpixel (talk) 16:10, 23 May 2018 (UTC)

Various Software

I feel like the Various Software section should either be segmented into smaller sections (Downgrading Utilities, Package Managers, etc.) or not exist at all -- and in the former case, would most likely not be under the section Various Software. Any thoughts? --wxblank (talk) 16:02, 21 June 2019 (UTC)

Firmware Status style.

I am proposing a change to the firmware status table, to pack-in more info into a smaller space while also being more future-proof.

i believe having the table in this style will improve not only the aesthetic of the table, but also be able to handle more devices in the future.

Exhibit A

This is what we have now:

Device Apple TV (4th generation) and newer Apple Watch Series 1 and newer HomePod iPad (5th generation) and newer
iPad Air 2
iPad mini 4
iPad Pro (12.9-inch, 9.7-inch, 12.9-inch 2nd generation, 10.5-inch)
iPhone 6s through iPhone X
iPod touch (7th generation)
iPad Air (3rd generation)
iPad mini (5th generation)
iPad Pro (11-inch, 12.9-inch 3rd generation)
iPhone XR and newer
Latest
Public Firmware
13.4.6 (17L570) 6.2.6 (17T620) 13.4.6 (17L570) 13.5.1 (17F80)
Jailbreak available? Yes
(checkra1n)[1][2]
No Yes
(checkra1n)
No
(N/A)
Latest
Beta Firmwares
13.4.8 beta 3 (17M5558b)
14.0 beta (18J5313t)
6.2.8 beta 3 (17U5559d)
7.0 beta (Series 3+) (18R5310a)
N/A 13.6 beta 3 (17G5059c)
14.0 beta (18A5301v)
  1. ^ Apple TV HD only but supports Apple TV 4K with hardware modfications
  2. ^ Check the "Allow untested iOS/iPadOS/tvOS versions" checkbox in the options view to bypass the version check.

Exhibit B

This is the style i propose we replace Exhibit A with:

Product Linup Apple TV HomePod Apple Watch iPhone iPad iPad Air iPad Pro iPad mini iPod touch
Supported Apple TV HD
and newer
Series 1
and newer
iPhone 6s
and newer
5th Generation
and newer
iPad Air 2
and newer
12.9-inch (2016)
and newer
iPad mini 4
and newer
7th Generation
Latest
Public Firmwares
13.4.6 (17L570) 6.2.6 (17T620) 13.5.1 (17F80)
Jailbreak availability Yes
(checkra1n)[1][2]
No Yes* (checkra1n)[1]
*except for devices with the A12 or newer SoC's.
Latest
Beta Firmwares
13.4.8 beta 3 (17M5558b) N/A 6.2.8 beta 3 (17U5559d) 13.6 beta 3 (17G5059c)
14.0 beta (18J5313t) N/A 7.0 beta (18R5310a)*
*Series 3 and newer only.
14.0 beta (18A5301v)
  1. ^ a b Check the "Allow untested iOS/iPadOS/tvOS versions" checkbox in the options view to bypass the version check.
  2. ^ Apple TV HD only, but can support the Apple TV 4K with some hardware modifications.

I am open to comments or suggestions - DanTheMann15 (talk) 23:11, 30 June 2020 (UTC)

I agree and prefer the new style. It sucks having devices listed twice but that would change once watchOS 7 is out of beta. Maybe though we could just add a note under the table that watchOS 7 beta’s require series 3 or newer and not have the second list. IMO that’d be better. —iAdam1n (talk) 00:16, 1 July 2020 (UTC)

That sounds like a good idea, and the note actually fits inside the table! i've changed Exhibit B to reflect this. - DanTheMann15 (talk) 01:13, 1 July 2020 (UTC)

I made the edit before seeing the talk page, oops. I'll leave it like that for now. Admanny (talk) 06:09, 1 July 2020 (UTC)

I like the "Jailbreak availability" text, but on the other hand though many people ask that question: is a "Jailbreak available?", i edited Exhibit B so everyone can see how it looks, get other opinions on it, but overall im down with either way. - DanTheMann15 (talk) 08:00, 1 July 2020 (UTC)

I think "available?" makes more sense to be honest with the yes and no answers. --iAdam1n (talk) 13:10, 1 July 2020 (UTC)
I changed it because it's unconventional for labels in a chart to be written in the form of a question. But, this is a small wiki anyway, so if the consensus sways towards keeping the question, that's fine. I'm still with keeping it as "availability". Admanny (talk) 19:55, 1 July 2020 (UTC)

Mac in the jailbreak table

Why is this in the table? Macs aren't exactly locked up in a BSD jail like iOS devices; they have security to prevent modifying system files by default, but Macs are a more open platform and SIP can be disabled to edit said files. You don't need to run some jailbreaking utility to e.g. change around some system icons in macOS. I presume the intent was to say bridgeOS on Macs with the T2 are susceptible to jailbreaking per the footnote, but the "Supported" row points to "All Macs with the M1". None of the M1 Macs have a T2 chip. The information provided is also for macOS, not bridgeOS. --Dialexio (talk) 08:24, 14 February 2021 (UTC)

That can be fixed but it was added as it's "firmware status" not just "jailbreak status" as should be there. --iAdam1n (talk) 11:40, 14 February 2021 (UTC)

HTTPS links on firmwares and OTA's that are hosted on "updates.cdn-apple.com"

I'm writing this topic because Dialexio hasn't been using https. https has been used here on the wiki regularly since 2019 when adding new firmware links that are hosted on Apple's CDN, which host's all of Apple's firmwares released since April 2018, such as iOS 11.3.1 and newer.

back when apple was still using appldnld.apple.com, adding https (https://secure-appldnld.apple.com) would make the links unreliable or not work at all.

but now with http://updates-http.cdn-apple.com, it works just fine to switch to (https://updates.cdn-apple.com).

it is easy as pie to switch the links to use https by using a good text-editing program that has a "find and replace" function. like Notepad++ or Gedit.


is there any good reason we shouldn't be using https on the newer firmwares hosted on Apple's CDN?

- DanTheMann15 (talk) 22:32, 5 May 2021 (UTC)

(This should probably be on The iPhone Wiki:Community portal instead, but oh well.) It kinda boils down to personal preference; to my understanding, there was never any sort of formal agreement on this. A user simply started converting some links to HTTPS, and I just let them do their thing since I do see benefits of using HTTPS. (At the end of the day though, you're still going to get the same file, especially if you verify its hash.) But personally, I'd rather keep the links the same way Apple provided them— if they gave us an HTTP link, that's what I'll add, and if they gave an HTTPS link, that's what I'll add. I'm not opposed to others changing the links I post to HTTPS as it's still Apple hosting and providing the download links, but I don't feel we should have to go out of our way to add one more step to an already tedious task. You can make an argument that it's for consistency, but that logic can also be used towards converting HTTPS links back to HTTP, and we would also trim the URLs for the older IPSWs so those look more consistent with newer, pre cdn-apple.com releases. --Dialexio (talk) 00:21, 6 May 2021 (UTC)

i understand where you are coming from, but i will continue to use https on the firmware links i post, since there are more advantages than the other way around, albeit the possible reason why apple gives us http links is likely because https requires valid certificates, which for some reason not everybody has. also it's important to note about HTTPS-Only on some major browsers so http links will not work for those who have that setting enabled. and like i said above, it takes me a fraction of a second to convert the links to https, thanks to Notepad++. perhaps you could add a setting that you can enable in the OTA Catalog Parser that would automatically convert links to https when parsing the links to save time.

- DanTheMann15 (talk) 18:47, 16 May 2021 (UTC)