Pwnage 2.0 - Revision history

Q3k at 22:23, 9 December 2021

2021-12-09T22:23:39Z

← Older revision		Revision as of 22:23, 9 December 2021
Line 5:		Line 5:
	This information is based on the reverse-engineering of the iPod Nano 4G [[S5L8720 Bootrom]]. All function/structure names present are pulled out of thin air.		This information is based on the reverse-engineering of the iPod Nano 4G [[S5L8720 Bootrom]]. All function/structure names present are pulled out of thin air.

	After performing header validation (SHA1 & AES), the bootrom parses the certificates present at the footer of an uploaded ~~image~~. These certificates are plain DER-encoded ASN.1 X.509 certificates, and thus their parsing logic is quite complex. For reference, see RFC5280.		After performing header validation (SHA1 & AES), the bootrom parses the certificates present at the footer of an uploaded [[IMG1]]. These certificates are plain DER-encoded ASN.1 X.509 certificates, and thus their parsing logic is quite complex. For reference, see RFC5280.

	=== WTF ===		=== WTF ===

Q3k: /* Exploiting the bug */

2021-12-09T21:48:53Z

Exploiting the bug

← Older revision		Revision as of 21:48, 9 December 2021
Line 76:		Line 76:

	struct der::cert::certificate {		struct der::cert::certificate {
	byte unimportant[~~1036~~]; // parsed certificate fields		byte unimportant[1016]; // parsed certificate fields
	byte authorityKeyIdentifier[20];		byte authorityKeyIdentifier[20];
	byte signatureValue[256];		byte signatureValue[256];
	uint signatureValue_len;		uint signatureValue_len;
	uint der_outer_sig_alg_type;		uint der_outer_sig_alg_type;
	byte[20] ~~sha1_tbs_calculated~~;		byte sha1_tbs_calculated[20];
	byte[20] ~~sha1_all_calculated~~;		byte sha1_all_calculated[20];
	uint unknown;		uint unknown;
	}		}
Line 91:		Line 91:
	uint unknown[2];		uint unknown[2];
	der::cert::parse_ctx current_cert;		der::cert::parse_ctx current_cert;
	der::cert::certificate[3] ~~chain_certs~~;		der::cert::certificate chain_certs[3];
	}		}

Q3k: /* Exploiting the bug */

2021-12-09T21:47:36Z

Exploiting the bug

← Older revision		Revision as of 21:47, 9 December 2021
Line 102:		Line 102:
	# Present the BootROM with a valid image header with some certificates after the body. The body never gets to be checked or decrypted, so we can write anything we want there (as long as the sizes match the sizes in the header).		# Present the BootROM with a valid image header with some certificates after the body. The body never gets to be checked or decrypted, so we can write anything we want there (as long as the sizes match the sizes in the header).
	# Provide three certificates in the chain that match the bare minimum required by the certificate DER parse steps.		# Provide three certificates in the chain that match the bare minimum required by the certificate DER parse steps.
	# Make the last certificate's signatureValue overflow into the saved LR. The original buffer is 256 bytes, we need to overflow it by 308 bytes to leave the der::chain::parse_ctx structure, then by 0x20 bytes ~~more~~ to reach the saved LR, then provide 4 bytes of PC to override. Since the signatureValue is an ASN.1 BIT STRING, we need to prefix the tag value with a zero. This gives us in total 344 or 345 bytes to fill signatureValue with.		# Make the last certificate's signatureValue overflow into the saved LR. The original buffer is 256 bytes, we need to overflow it by 308 bytes (256 + 52) to leave the der::chain::parse_ctx structure, then by 0x20 more bytes to reach the saved LR, then provide 4 bytes of PC to override. Since the signatureValue is an ASN.1 BIT STRING, we need to prefix the tag value with a zero. This gives us in total 344 or 345 bytes to fill signatureValue with.

	If we can't generate arbitrary image headers to set arbitrary footer certificate sizes we need to pad all certificates involved so that the signatureValue of the last cert is exactly the size we want to overflow (or at least not too long so that the copy doesn't cause a write to unmapped memory). Afterwards, with code exec, we can use the HW AES engine to sign arbitrary headers to not have to worry about sizes.		If we can't generate arbitrary image headers to set arbitrary footer certificate sizes we need to pad all certificates involved so that the signatureValue of the last cert is exactly the size we want to overflow (or at least not too long so that the copy doesn't cause a write to unmapped memory). Afterwards, with code exec, we can use the HW AES engine to sign arbitrary headers to not have to worry about sizes.

Q3k at 21:47, 9 December 2021

2021-12-09T21:47:00Z

← Older revision		Revision as of 21:47, 9 December 2021
Line 102:		Line 102:
	# Present the BootROM with a valid image header with some certificates after the body. The body never gets to be checked or decrypted, so we can write anything we want there (as long as the sizes match the sizes in the header).		# Present the BootROM with a valid image header with some certificates after the body. The body never gets to be checked or decrypted, so we can write anything we want there (as long as the sizes match the sizes in the header).
	# Provide three certificates in the chain that match the bare minimum required by the certificate DER parse steps.		# Provide three certificates in the chain that match the bare minimum required by the certificate DER parse steps.
	# Make the last certificate's signatureValue overflow into the saved LR. The original buffer is 256 bytes, we need to overflow it by 308 bytes to leave the der::chain::parse_ctx structure, then by 0x20 bytes more to reach the saved LR, then provide 4 bytes of PC to override. Since the signatureValue is an ASN.1 BIT STRING, we need to prefix the tag value with a zero. This gives us in total ~~600~~ or ~~601~~ bytes to fill signatureValue with.		# Make the last certificate's signatureValue overflow into the saved LR. The original buffer is 256 bytes, we need to overflow it by 308 bytes to leave the der::chain::parse_ctx structure, then by 0x20 bytes more to reach the saved LR, then provide 4 bytes of PC to override. Since the signatureValue is an ASN.1 BIT STRING, we need to prefix the tag value with a zero. This gives us in total 344 or 345 bytes to fill signatureValue with.

	If we can't generate arbitrary image headers to set arbitrary footer certificate sizes we need to pad all certificates involved so that the signatureValue of the last cert is exactly the size we want to overflow (or at least not too long so that the copy doesn't cause a write to unmapped memory). Afterwards, with code exec, we can use the HW AES engine to sign arbitrary headers to not have to worry about sizes.		If we can't generate arbitrary image headers to set arbitrary footer certificate sizes we need to pad all certificates involved so that the signatureValue of the last cert is exactly the size we want to overflow (or at least not too long so that the copy doesn't cause a write to unmapped memory). Afterwards, with code exec, we can use the HW AES engine to sign arbitrary headers to not have to worry about sizes.

	Crafting the certificates is an exercise left to the reader. Maybe the exact constraints and process will be listed here at some point, but starting out with certificates from a legitimate WTF file and mangling the last certificate to overflow by exactly ~~600~~ bytes is a good start (possibly adjusting previous certs to make some space for the longer signatureValue).		Crafting the certificates is an exercise left to the reader. Maybe the exact constraints and process will be listed here at some point, but starting out with certificates from a legitimate WTF file and mangling the last certificate to overflow by exactly 344 bytes is a good start (possibly adjusting previous certs to make some space for the longer signatureValue).

	=== Payload ===		=== Payload ===

	The easiest place to stuff the payload is in the body of the image. The bootrom never gets to checking or decrypting it, so we can easily just put some executable code there. Depending on the bootrom, the image body will be placed somewhere in the beginning of SRAM (0x22000600 for Nano4g). Then, our stack smash can simply point to that address and we get code execution.		The easiest place to stuff the payload is in the body of the image. The bootrom never gets to checking or decrypting it, so we can easily just put some executable code there. Depending on the bootrom, the image body will be placed somewhere in the beginning of SRAM (0x22000600 for Nano4g). Then, our stack smash can simply point to that address and we get code execution.

Q3k at 21:33, 9 December 2021

2021-12-09T21:33:03Z

Show changes

Cmwslw at 23:02, 1 August 2010

2010-08-01T23:02:12Z

← Older revision		Revision as of 23:02, 1 August 2010
Line 1:		Line 1:
	Planetbeing has adapted the Pwnage 2.0 exploit to work on the iPod Nano and Classic line. This exploit is at the bootrom level, so it cannot be patched by Apple. Apple built in the functionality to upload a WTF recovery stage to the iPod when it is in DFU mode. There is a bug in the certificate parsing code that permits an unauthorized jump to an arbitrary location. It is also convenient that a payload can be embedded in the main body of the WTF. It is know that the entire WTF is copied to 0x22000000. If you put your exploit payload at 0x800 in the WTF, you should jump to 0x22000800. The iPod Classic and Nano lines are vulnerable to Pwnage 2.0, but this vulnerability has been patched starting with the [[5G ~~Nano~~]].		Planetbeing has adapted the Pwnage 2.0 exploit to work on the iPod Nano and Classic line. This exploit is at the bootrom level, so it cannot be patched by Apple. Apple built in the functionality to upload a WTF recovery stage to the iPod when it is in DFU mode. There is a bug in the certificate parsing code that permits an unauthorized jump to an arbitrary location. It is also convenient that a payload can be embedded in the main body of the WTF. It is know that the entire WTF is copied to 0x22000000. If you put your exploit payload at 0x800 in the WTF, you should jump to 0x22000800. The iPod Classic and Nano lines are vulnerable to Pwnage 2.0, but this vulnerability has been patched starting with the [[Nano 5G]].

	==WTF==		==WTF==

Cmwslw at 23:01, 1 August 2010

2010-08-01T23:01:56Z

← Older revision		Revision as of 23:01, 1 August 2010
Line 1:		Line 1:
	Planetbeing has adapted the Pwnage 2.0 exploit to work on the iPod Nano and Classic line. This exploit is at the bootrom level, so it cannot be patched by Apple. Apple built in the functionality to upload a WTF recovery stage to the iPod when it is in DFU mode. There is a bug in the certificate parsing code that permits an unauthorized jump to an arbitrary location. It is also convenient that a payload can be embedded in the main body of the WTF. It is know that the entire WTF is copied to 0x22000000. If you put your exploit payload at 0x800 in the WTF, you should jump to 0x22000800. The iPod Classic and Nano lines are vulnerable to Pwnage 2.0, but this vulnerability has been patched starting with the 5G Nano.		Planetbeing has adapted the Pwnage 2.0 exploit to work on the iPod Nano and Classic line. This exploit is at the bootrom level, so it cannot be patched by Apple. Apple built in the functionality to upload a WTF recovery stage to the iPod when it is in DFU mode. There is a bug in the certificate parsing code that permits an unauthorized jump to an arbitrary location. It is also convenient that a payload can be embedded in the main body of the WTF. It is know that the entire WTF is copied to 0x22000000. If you put your exploit payload at 0x800 in the WTF, you should jump to 0x22000800. The iPod Classic and Nano lines are vulnerable to Pwnage 2.0, but this vulnerability has been patched starting with the [[5G Nano]].

	==WTF==		==WTF==

Cmwslw at 03:13, 13 July 2010

2010-07-13T03:13:00Z

← Older revision		Revision as of 03:13, 13 July 2010
Line 4:		Line 4:
	The WTF file is the first recovery stage. It is believed that this stage facilitates the loading of a second stage. The iPhoneWiki has some limited information about WTF binaries [http://theiphonewiki.com/wiki/index.php?title=WTF here]. WTF files for your device can be downloaded from Phobos, which hosts binaries for many of Apple's devices. There is a nice directory of Phobos downloads [http://www.trejan.com/projects/ipod/phobos.html here]. Go to the "DFU/Recovery Files" section and find the WTF for your device and download the corresponding ipsw. Extract this and find the actual WTF binary. It normally has a name like WTF.x1225.release.dfu.		The WTF file is the first recovery stage. It is believed that this stage facilitates the loading of a second stage. The iPhoneWiki has some limited information about WTF binaries [http://theiphonewiki.com/wiki/index.php?title=WTF here]. WTF files for your device can be downloaded from Phobos, which hosts binaries for many of Apple's devices. There is a nice directory of Phobos downloads [http://www.trejan.com/projects/ipod/phobos.html here]. Go to the "DFU/Recovery Files" section and find the WTF for your device and download the corresponding ipsw. Extract this and find the actual WTF binary. It normally has a name like WTF.x1225.release.dfu.

	The WTF has a header that is of length 0x600 (on the S5L8720 at least). This header is mostly zeros but it also has the length of the certificate. The certificate is at the end of the WTF. On the S5L8720 the certificate is 0xBE3 bytes long.		The WTF has a header that is of length 0x600 (on the S5L8720 at least). This header is mostly zeros but it also has the length of the certificate. In the middle is the large encrypted payload. The certificate is at the end of the WTF. On the S5L8720 the certificate is 0xBE3 bytes long.

	==Preparing WTF==		==Preparing WTF==

Cmwslw at 01:20, 13 July 2010

2010-07-13T01:20:07Z

← Older revision		Revision as of 01:20, 13 July 2010
Line 1:		Line 1:
	~~==Overview==~~		Planetbeing has adapted the Pwnage 2.0 exploit to work on the iPod Nano and Classic line. This exploit is at the bootrom level, so it cannot be patched by Apple. Apple built in the functionality to upload a WTF recovery stage to the iPod when it is in DFU mode. There is a bug in the certificate parsing code that permits an unauthorized jump to an arbitrary location. It is also convenient that a payload can be embedded in the main body of the WTF. It is know that the entire WTF is copied to 0x22000000. If you put your exploit payload at 0x800 in the WTF, you should jump to 0x22000800. The iPod Classic and Nano lines are vulnerable to Pwnage 2.0, but this vulnerability has been patched starting with the 5G Nano.
	Planetbeing has adapted the Pwnage 2.0 exploit to work on the iPod Nano and Classic line. This exploit is at the bootrom level, so it cannot be patched by Apple. Apple built in the functionality to upload a WTF recovery stage to the iPod when it is in DFU mode. There is a bug in the certificate parsing code that permits an unauthorized jump to an arbitrary location. It is also convenient that a payload can be embedded in the main body of the WTF. It is know that the entire WTF is copied to 0x22000000. If you put your exploit payload at 0x800 in the WTF, you should jump to 0x22000800.
			==WTF==
			The WTF file is the first recovery stage. It is believed that this stage facilitates the loading of a second stage. The iPhoneWiki has some limited information about WTF binaries [http://theiphonewiki.com/wiki/index.php?title=WTF here]. WTF files for your device can be downloaded from Phobos, which hosts binaries for many of Apple's devices. There is a nice directory of Phobos downloads [http://www.trejan.com/projects/ipod/phobos.html here]. Go to the "DFU/Recovery Files" section and find the WTF for your device and download the corresponding ipsw. Extract this and find the actual WTF binary. It normally has a name like WTF.x1225.release.dfu.

			The WTF has a header that is of length 0x600 (on the S5L8720 at least). This header is mostly zeros but it also has the length of the certificate. The certificate is at the end of the WTF. On the S5L8720 the certificate is 0xBE3 bytes long.

	==Preparing WTF==		==Preparing WTF==
			In order to use the exploit, you must overwrite part of the WTF's main body with a payload. Offset 0x800 is a good place to start the payload.

	To be continued...		To be continued...

Cmwslw: Added overview of the Pwnage 2.0 exploit

2010-07-12T22:00:59Z

Added overview of the Pwnage 2.0 exploit

New page

==Overview==
Planetbeing has adapted the Pwnage 2.0 exploit to work on the iPod Nano and Classic line. This exploit is at the bootrom level, so it cannot be patched by Apple. Apple built in the functionality to upload a WTF recovery stage to the iPod when it is in DFU mode. There is a bug in the certificate parsing code that permits an unauthorized jump to an arbitrary location. It is also convenient that a payload can be embedded in the main body of the WTF. It is know that the entire WTF is copied to 0x22000000. If you put your exploit payload at 0x800 in the WTF, you should jump to 0x22000800.

==Preparing WTF==
To be continued...