Changes

::I'm not about converting a NAND image from system to another directly. Can we alculate for a various firmware byte-to-byte XOR-difference, which result the same xorpads for each system to annihilate. And for the same CTRNAND files untouched with a firmware update this difference will be zero. So applying this difference for another console CTRNAND will update a firmware without the need of the actual console-unique xorpad--[[User:Duke srg|Duke srg]] 21:48, 10 April 2014 (CEST)

::I'm not about converting a NAND image from system to another directly. Can we alculate for a various firmware byte-to-byte XOR-difference, which result the same xorpads for each system to annihilate. And for the same CTRNAND files untouched with a firmware update this difference will be zero. So applying this difference for another console CTRNAND will update a firmware without the need of the actual console-unique xorpad--[[User:Duke srg|Duke srg]] 21:48, 10 April 2014 (CEST)

:::The CTRNAND files /w console-unique AESMACs I'm referring to get updated when sys-updates get installed, if those don't get updated properly(invalid AESMACs for example) you would have a system which would fail to boot when it tries to launch titles from CTRNAND-FS. There's no way to properly update those files without proper NAND xorpads/etc. --[[User:Yellows8|Yellows8]] 22:11, 10 April 2014 (CEST)

:::The CTRNAND files /w console-unique AESMACs I'm referring to get updated when sys-updates get installed, if those don't get updated properly(invalid AESMACs for example) you would have a system which would fail to boot when it tries to launch titles from CTRNAND-FS. There's no way to properly update those files without proper NAND xorpads/etc. --[[User:Yellows8|Yellows8]] 22:11, 10 April 2014 (CEST)

::::Ok, just to clarify, during system update AESMAC init file IS updated with the new console-unique data. So after transferring firmware canges from one system to another without complete decypher, during next boot at least AESMAC file on CTR NAND partition contents will have wrong data and REG_AESMAC being initialized with that will fail the following boot process. Smart enough.--[[User:Duke srg|Duke srg]] 05:59, 11 April 2014 (CEST)

::::Ok, just to clarify, during system update AESMAC init file IS updated with the new console-unique data. So after transferring firmware changes from one system to another without complete decypher, during next boot at least AESMAC file on CTR NAND partition contents will have wrong data and REG_AESMAC being initialized with that will fail the following boot process. Smart enough.--[[User:Duke srg|Duke srg]] 05:59, 11 April 2014 (CEST)