78
edits
Changes
no edit summary
::::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)
::::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)
:::::Yeah, at least one of those console-unique AESMACs would be rendered invalid with method you're describing. --[[User:Yellows8|Yellows8]] 06:21, 11 April 2014 (CEST)
:::::Yeah, at least one of those console-unique AESMACs would be rendered invalid with method you're describing. --[[User:Yellows8|Yellows8]] 06:21, 11 April 2014 (CEST)
::::::Aren't you talking about a movable.sed file or there are others not mentioned explicitly?--[[User:Duke srg|Duke srg]] 14:01, 11 April 2014 (CEST)