Stage2: Difference between revisions

Line 130:

|}

The 3DS TWL_FIRM verifies TWL RSA padding with the following~~, which is also valid~~ for this DSi bootloader padding:

The 3DS TWL_FIRM verifies all TWL RSA padding with the following. It's unknown whether the DSi Stage1 has the same code as TWL_FIRM for this, the RSA padding data(not the actual hashdata) contained in the DSi bootloader signature and TWL_FIRM bootloader are the same at least. This is different from how the main DSi "BIOS" RSA padding check code does it as well.

* The first byte must be 0x0.

* The second byte must be 0x1 or 0x2.

* Executes a while(<value of byte at current pos in RSA message>). When the second_byte in the message is 0x1, the byte at curpos must be 0xFF(otherwise the non-zero value of the byte at curpos doesn't matter). This loop must find a zero byte before offset 0x7F in the message otherwise an error is returned.

* Returns an address for msg_curpos+1.

With the code in 3DS TWL_FIRM, the actual "totalhashdatasize" in the RSA message must be <=0x74. The 3DS TWL_FIRM code copies the RSA "hashdata" to the output buffer, using the actual size of the RSA "hashdata".

With the code in 3DS TWL_FIRM, the actual "totalhashdatasize" in the RSA message must be <= <expected hashdata_size>(0x74 for bootloader). The 3DS TWL_FIRM code copies the RSA "hashdata" to the output buffer, using the actual size of the RSA "hashdata".

Note that this sector (and two similar ones at 0x400 and 0x600) appear to be the only unencrypted blocks on the NAND flash.

@@ Line 130: / Line 130: @@
 |}
-The 3DS TWL_FIRM verifies TWL RSA padding with the following, which is also valid for this DSi bootloader padding:
+The 3DS TWL_FIRM verifies all TWL RSA padding with the following. It's unknown whether the DSi Stage1 has the same code as TWL_FIRM for this, the RSA padding data(not the actual hashdata) contained in the DSi bootloader signature and TWL_FIRM bootloader are the same at least. This is different from how the main DSi "BIOS" RSA padding check code does it as well.
 * The first byte must be 0x0.
 * The second byte must be 0x1 or 0x2.
 * Executes a while(<value of byte at current pos in RSA message>). When the second_byte in the message is 0x1, the byte at curpos must be 0xFF(otherwise the non-zero value of the byte at curpos doesn't matter). This loop must find a zero byte before offset 0x7F in the message otherwise an error is returned.
 * Returns an address for msg_curpos+1.
-With the code in 3DS TWL_FIRM, the actual "totalhashdatasize" in the RSA message must be <=0x74. The 3DS TWL_FIRM code copies the RSA "hashdata" to the output buffer, using the actual size of the RSA "hashdata".
+With the code in 3DS TWL_FIRM, the actual "totalhashdatasize" in the RSA message must be <= <expected hashdata_size>(0x74 for bootloader). The 3DS TWL_FIRM code copies the RSA "hashdata" to the output buffer, using the actual size of the RSA "hashdata".
 Note that this sector (and two similar ones at 0x400 and 0x600) appear to be the only unencrypted blocks on the NAND flash.