Bootrom - Revision history

760ceb3b9c0ba4872cadf3ce35a7a494: update display title to BootROM

2025-06-23T04:51:02Z

update display title to BootROM

← Older revision		Revision as of 04:51, 23 June 2025
Line 1:		Line 1:
			{{DISPLAYTITLE:BootROM}}
	== Introduction ==		== Introduction ==

Q3k at 16:24, 9 January 2023

2023-01-09T16:24:43Z

← Older revision		Revision as of 16:24, 9 January 2023
Line 1:		Line 1:
	== Introduction ==		== Introduction ==

	The iPod ~~Nano 4G~~ bootrom is different from the iBoot/SecureROM bootrom present on iOS-based ~~S5L8720~~ devices, ~~like~~ the iPod ~~Touch~~ 2G.		The iPod bootrom is different from the iBoot/SecureROM bootrom present on iOS-based devices. This is true even for iOS/non-iOS devices that share the same SoC, eg. the iPod touch 2G and Nano 4G (both of which are based around an S5L8720).

	The reverse engineering efforts below have been based on a ROM extract from a Nano 4g with the following SHA256 sum: 9cc05fb83024c9d51fd31c97a137447ce5ea87fe7cefba7b9aa6d54609bfbafb .		The reverse engineering efforts below have been based on a ROM extract from a Nano 4G with the following SHA256 sum: 9cc05fb83024c9d51fd31c97a137447ce5ea87fe7cefba7b9aa6d54609bfbafb .

	== BootROM functionality ==		== BootROM functionality ==
Line 31:		Line 31:

	The difference between the Nano and SecureROM bootrom codebases seem to be the main cause of none of the SecureROM USB exploits working (steaks4uce, usb_control_msg(0xa1, 1), checkm8, etc. However, a full pass over the USB codepaths is still yet to be performed, other vulnerabilities are likely to exist.		The difference between the Nano and SecureROM bootrom codebases seem to be the main cause of none of the SecureROM USB exploits working (steaks4uce, usb_control_msg(0xa1, 1), checkm8, etc. However, a full pass over the USB codepaths is still yet to be performed, other vulnerabilities are likely to exist.

			The USB codebase of the DFU is where the [[WInd3x\|wInd3x]] bug lives.

Q3k: Q3k moved page S5L8720 Bootrom to Bootrom

2023-01-09T16:23:16Z

Q3k moved page BootROM to BootROM

← Older revision	Revision as of 16:23, 9 January 2023
(No difference)

Q3k: /* DFU mode */

2021-12-09T22:27:50Z

DFU mode

← Older revision		Revision as of 22:27, 9 December 2021
Line 28:		Line 28:
	== DFU mode ==		== DFU mode ==

	The DFU mode codebase seems to be different from the iBoot/SecureROM codebase, with very little code shared (perhaps apart from low-level ~~DWC2~~ OTG register access code). There are no iBoot-like tasks present, the heap is very minimalistic (bitmap based), and the entire data transfer is effectively performed in poll/synchronous mode.		The DFU mode codebase seems to be different from the iBoot/SecureROM codebase, with very little code shared (perhaps apart from low-level DesignWare HS OTG register access code). There are no iBoot-like tasks present, the heap is very minimalistic (bitmap based, so no unlink/house of $x heap attacks), and the entire data transfer is effectively performed in poll/synchronous mode (with all transfers initiated via USB DMA directly into temporary receive buffers).

	The difference between the Nano and SecureROM bootrom codebases seem to be the main cause of none of the SecureROM USB exploits working (steaks4uce, usb_control_msg(0xa1, 1), checkm8, etc. However, a full pass over the USB codepaths is still yet to be performed.		The difference between the Nano and SecureROM bootrom codebases seem to be the main cause of none of the SecureROM USB exploits working (steaks4uce, usb_control_msg(0xa1, 1), checkm8, etc. However, a full pass over the USB codepaths is still yet to be performed, other vulnerabilities are likely to exist.

Q3k at 22:24, 9 December 2021

2021-12-09T22:24:26Z

← Older revision		Revision as of 22:24, 9 December 2021
Line 15:		Line 15:
	The mode is selected based on straps, pressed buttons and mode priorities (first NAND or 'NOR' is performed, then DFU).		The mode is selected based on straps, pressed buttons and mode priorities (first NAND or 'NOR' is performed, then DFU).

	All three boot paths end up performing the same [[IMG1 image]] verification steps:		All three boot paths end up performing the same [[IMG1\|image]] verification steps:

	# Load image into memory at beginning of SRAM.		# Load image into memory at beginning of SRAM.

Q3k at 22:24, 9 December 2021

2021-12-09T22:24:10Z

← Older revision		Revision as of 22:24, 9 December 2021
Line 15:		Line 15:
	The mode is selected based on straps, pressed buttons and mode priorities (first NAND or 'NOR' is performed, then DFU).		The mode is selected based on straps, pressed buttons and mode priorities (first NAND or 'NOR' is performed, then DFU).

	All three boot paths end up performing the same image verification steps:		All three boot paths end up performing the same [[IMG1 image]] verification steps:

	# Load image into memory at beginning of SRAM.		# Load image into memory at beginning of SRAM.
	# Verify image header (IMG1~~/DFU v2~~.0~~, '87202.0' header~~): perform SHA1 then AES of first 0x40 bytes, compare against stored sum.		# Verify image header ([[IMG1]] 2.0): perform SHA1 then AES of first 0x40 bytes, compare against stored sum.
	# Parse footer certificates and verify footer signature against body (undocumented).		# Parse footer certificates and verify footer signature against body (undocumented).
	# Decrypt and jump into body.		# Decrypt and jump into body.

Q3k at 21:36, 9 December 2021

2021-12-09T21:36:07Z

← Older revision		Revision as of 21:36, 9 December 2021
Line 17:		Line 17:
	All three boot paths end up performing the same image verification steps:		All three boot paths end up performing the same image verification steps:

			# Load image into memory at beginning of SRAM.
	# Verify image header (IMG1/DFU v2.0, '87202.0' header): perform SHA1 then AES of first 0x40 bytes, compare against stored sum.		# Verify image header (IMG1/DFU v2.0, '87202.0' header): perform SHA1 then AES of first 0x40 bytes, compare against stored sum.
	# Parse footer certificates and verify footer signature against body (undocumented).		# Parse footer certificates and verify footer signature against body (undocumented).

Q3k at 21:35, 9 December 2021

2021-12-09T21:35:41Z

← Older revision		Revision as of 21:35, 9 December 2021
Line 17:		Line 17:
	All three boot paths end up performing the same image verification steps:		All three boot paths end up performing the same image verification steps:

	# Verify image header (IMG1/DFU v2.0, '87202.0' header): perform SHA1 then AES of first 0x40 bytes, compare against stored sum~~, decrypt rest of image with AES~~.		# Verify image header (IMG1/DFU v2.0, '87202.0' header): perform SHA1 then AES of first 0x40 bytes, compare against stored sum.
	# Parse footer certificates and verify footer signature against body.		# Parse footer certificates and verify footer signature against body (undocumented).
			# Decrypt and jump into body.

	== Certificate parsing ==		== Certificate parsing ==

Q3k at 20:47, 9 December 2021

2021-12-09T20:47:53Z

← Older revision		Revision as of 20:47, 9 December 2021
Line 1:		Line 1:
			== Introduction ==

	The iPod Nano 4G bootrom is different from the iBoot/SecureROM bootrom present on iOS-based S5L8720 devices, like the iPod Touch 2G.		The iPod Nano 4G bootrom is different from the iBoot/SecureROM bootrom present on iOS-based S5L8720 devices, like the iPod Touch 2G.

			The reverse engineering efforts below have been based on a ROM extract from a Nano 4g with the following SHA256 sum: 9cc05fb83024c9d51fd31c97a137447ce5ea87fe7cefba7b9aa6d54609bfbafb .

			== BootROM functionality ==

			The BootROM can perform the following actions:

			# Boot from NAND flash (via built-in flash translation layer implementation)
			# Boot from some other unknown storage (NOR? Although NOR is not present on the N4G...)
			# Boot from USB DFU mode.

			The mode is selected based on straps, pressed buttons and mode priorities (first NAND or 'NOR' is performed, then DFU).

			All three boot paths end up performing the same image verification steps:

			# Verify image header (IMG1/DFU v2.0, '87202.0' header): perform SHA1 then AES of first 0x40 bytes, compare against stored sum, decrypt rest of image with AES.
			# Parse footer certificates and verify footer signature against body.

			== Certificate parsing ==

			The certificate parsing code is subject to [[Pwnage 2.0]]. This is one of the few codebases shared with iBoot/SecureROM, and is why the bug was portable to the Nano bootroms.

			== DFU mode ==

			The DFU mode codebase seems to be different from the iBoot/SecureROM codebase, with very little code shared (perhaps apart from low-level DWC2 OTG register access code). There are no iBoot-like tasks present, the heap is very minimalistic (bitmap based), and the entire data transfer is effectively performed in poll/synchronous mode.

			The difference between the Nano and SecureROM bootrom codebases seem to be the main cause of none of the SecureROM USB exploits working (steaks4uce, usb_control_msg(0xa1, 1), checkm8, etc. However, a full pass over the USB codepaths is still yet to be performed.

Q3k: Stub.

2021-12-09T20:38:46Z

Stub.

New page

The iPod Nano 4G bootrom is different from the iBoot/SecureROM bootrom present on iOS-based S5L8720 devices, like the iPod Touch 2G.