839
edits
Changes
Jump to navigation
Jump to search
Line 12:
Line 12: +
Talk:3DS Development Unit Software (edit)
Revision as of 16:23, 19 October 2011
, 16:23, 19 October 2011no edit summary
The NAND image of a development 3DS as called here (it is actually a test unit, not development unit) cannot be flashed to a retail 3DS, as there are most likely hardcoded fuses identifying if debug unit, test unit, or retail unit. Not to mention that the NAND image will contain encrypted files coupled with the console ID of the development 3DS, and any other console will have a different ID. --[[User:Neimod|Neimod]] 13:24, 19 October 2011 (CEST)
The NAND image of a development 3DS as called here (it is actually a test unit, not development unit) cannot be flashed to a retail 3DS, as there are most likely hardcoded fuses identifying if debug unit, test unit, or retail unit. Not to mention that the NAND image will contain encrypted files coupled with the console ID of the development 3DS, and any other console will have a different ID. --[[User:Neimod|Neimod]] 13:24, 19 October 2011 (CEST)
:Okay, I'm now a bit confused why would Nintendo label the "development 3DS" which is in my possession that is actually a "Test Unit" with a sticker saying "Development Unit". Is Nintendo purposely trying to confuse everyone, or am I missing something? Also if you can, can you tell me the differences between a Test unit and a Development unit?(considering i don't actually have a development unit). And about the custom flash, I was only speculating about what we could do if we found a method to extract the unique console ID/key and i purposely left out the steps of decrypting and re-encrypting 3DS flashes as I was speculating. And you're probably right about there being a hardware flag distinguishing between Test Dev and Retail units, no doubt for added un-hackability.--[[User:3dsguy|3dsguy]] 17:23, 19 October 2011 (CEST)