Hacking Does some one know about CTRnand\transfer?

[gkoelho]

Just curious about, I did a little of research but couldn't find much.

I understand using this process instead has extra protections involving the partitions, but what else it has different from the old method? Can some one with the knowlede explain this in more details:

For people like me that always likes to learn something new

 

[Rak]

I too want to know this. It seems like something interesting to read.

 

[shadow910512]

me three
feels like its a premade 2.1.0 image that can be installed in any 3ds right now, but how??

 

[Clydefrosch]

besides apparently saving us a bunch of emunand installs, dumps and reflashes, this new method actually doesn't downgrade the system like we would have to going from say 10.7 to 9.2 using sysupdater. sysupdater has always been a little finicky, requiring sometimes hundreds of reloads just to get it running even then it sometimes messed up installing a title for some reasons, ending downgrades in partial frankenfirmwares.


this new method basically just applies a universally usable nand backup to the system making it load a 2.1.0 firmware thats good enough to install a9lh and get your otp file.
its as save and quick as applying any other nand backup you made using emunand9 or decrypt9. no countless titles, no real chance for it to stop halfway through (other than batteries giving out on you or you dropping the system or removing the sd card, or having a corrupted 2.1.0 file)

as to how they managed to present us with a nand backup that works on every console (when usually, nand backups are kinda specific to your console) i have no idea. but they did. and thats nice.

the guide itself is, apart from the part 1 table (which is irrelevant for everyone who already is on 9.2 sysnand), much more easy to follow and unless you have like 60 gb of installed cias to backup, you can make it to a working a9hl/luma setup within an hour (+however long it takes for you to download all the files)

 

[Urbanshadow]

Until someone (@d0k3 , @Plailect ?) lands here and explains it deeper (if possible!): CTRNAND is just a partition of the nand, the bigger one, responsible of containing system titles. The direct difference between a CTRNAND backup and a full NAND backup is you don't touch FIRM0/FIRM1 or TWL,AGB or key storage partitions. So what you are really doing is a backup of the system titles.

They might found a way to trick N3DS in properly booting a 3DS CTRNAND since 2.1 system software version is only available to 3DS, perhpahs with a dedicated franken-ctrnand modified enough to grab the otp but not agressively changed to provide universal support. From my point of view we are not directly changing FIRM partitions by the CTRNAND restore, but then again the process is called CTRNAND transfer for a reason so modification of FIRM0 might be done manually afterwards because afaik the "bug" responsible for the OTP register to be left open is located in the 2.1.0 FIRM.

It really gets me the point of being "universal". That might mean nand backup sharing between hacked systems.

EDIT: From d0k3's release notes:

• CTRNAND Transfer...: This menu contains various options to enable transfer of CTRNAND partitions between consoles.
  • Auto CTRNAND Transfer: Automatically transfer a transferable CTRNAND image to this consoles NAND. Without A9LH installed, this will overwrite the FIRM0, FIRM1, CTRNAND. With A9LH installed, this will only overwrite CTRNAND. O3DS images can be transferred into N3DS consoles, but the NCSD header of the NAND may be overwritten.
  • Dump transferable CTRNAND: Dump a CTRNAND image for later use in the feature above. Transferables images can be shared between consoles.
  • Autofix CTRNAND: Use this to automatically fixes the CMACs for movable.sed, *.db and system saves inside the CTRNAND. It will also fix the inside the data folder. This is useful f.e. when a CTRNAND from another console was previously injected the regular way.SO

So this means we might not need to downgrade anymore. Just make a 9.2 CTRNAND transfer (even o3ds to n3ds). I wonder if this might bypass the N's 11.0 hardcoded min system title version list as I don't think the transfer is using the direct installing/removal of titles into the system. Then again, running d9 requires arm9 and I highly doubt the CTRNAND transfer functionality uses arm11k services only so I think it doesn't make any changes to the 11.0 people.

 

[Quantumcat]

I wonder if we can flash a lower CTRNand to an 11.0 backup obtained with a hardmod or DSiWareHax, to save time compared to modifying NATIVE_FIRM and downgrading with sysupdater?

 

[DarkKaine]

So this means we might not need to downgrade anymore. Just make a 9.2 CTRNAND transfer (even o3ds to n3ds). I wonder if this might bypass the N's 11.0 hardcoded min system title version list as I don't think the transfer is using the direct installing/removal of titles into the system. Then again, running d9 requires arm9 and I highly doubt the CTRNAND transfer functionality uses arm11k services only so I think it doesn't make any changes to the 11.0 people.

Pretty sure after 9.2 a backdoor was used to simply downgrade titles while not actually having permission to other services. As such, I don't think a full CTRNAND transfer is possible without having the proper access.

I wonder if we can flash a lower CTRNand to an 11.0 backup obtained with a hardmod or DSiWareHax, to save time compared to modifying NATIVE_FIRM and downgrading with sysupdater?

This will not work either, as the dump is encrypted and can only be decrypted by utilizing functions in 3DS mode (with the proper access level).

In short, CTRNAND is extremely convenient and safe, as you're not dealing with different 3DS configurations and flashing a universal image with your 3DS console information.

 

[Urbanshadow]

Pretty sure after 9.2 a backdoor was used to simply downgrade titles while not actually having permission to other services. As such, I don't think a full CTRNAND transfer is possible without having the proper access.

As I said, most likely there's no possibility of a proper access. This means, even with full access to services you can't do it.
Most probably needs direct physical address space access and that can only be achieved by arm9.

 

[trinhno]

I guess the transferrable image is decrypted. Decrypt9 will re-encrypt as it's writing to the nand.

Edit: more info https://www.reddit.com/r/3dshacks/comments/4zhe4a/ctrtransfer_what_it_is_and_why_it_works_and_why/

 

[gkoelho]

Very useful information here. I hope there will be a deep technical explanation about this as a9lh has got, its so interesting.

 

[d0k3]

Until someone (@d0k3 , @Plailect ?) lands here and explains it deeper (if possible!): CTRNAND is just a partition of the nand, the bigger one, responsible of containing system titles. The direct difference between a CTRNAND backup and a full NAND backup is you don't touch FIRM0/FIRM1 or TWL,AGB or key storage partitions. So what you are really doing is a backup of the system titles.

They might found a way to trick N3DS in properly booting a 3DS CTRNAND since 2.1 system software version is only available to 3DS, perhpahs with a dedicated franken-ctrnand modified enough to grab the otp but not agressively changed to provide universal support. From my point of view we are not directly changing FIRM partitions by the CTRNAND restore, but then again the process is called CTRNAND transfer for a reason so modification of FIRM0 might be done manually afterwards because afaik the "bug" responsible for the OTP register to be left open is located in the 2.1.0 FIRM.

It really gets me the point of being "universal". That might mean nand backup sharing between hacked systems.

EDIT: From d0k3's release notes:

• CTRNAND Transfer...: This menu contains various options to enable transfer of CTRNAND partitions between consoles.
  • Auto CTRNAND Transfer: Automatically transfer a transferable CTRNAND image to this consoles NAND. Without A9LH installed, this will overwrite the FIRM0, FIRM1, CTRNAND. With A9LH installed, this will only overwrite CTRNAND. O3DS images can be transferred into N3DS consoles, but the NCSD header of the NAND may be overwritten.
  • Dump transferable CTRNAND: Dump a CTRNAND image for later use in the feature above. Transferables images can be shared between consoles.
  • Autofix CTRNAND: Use this to automatically fixes the CMACs for movable.sed, *.db and system saves inside the CTRNAND. It will also fix the inside the data folder. This is useful f.e. when a CTRNAND from another console was previously injected the regular way.SO

So this means we might not need to downgrade anymore. Just make a 9.2 CTRNAND transfer (even o3ds to n3ds). I wonder if this might bypass the N's 11.0 hardcoded min system title version list as I don't think the transfer is using the direct installing/removal of titles into the system. Then again, running d9 requires arm9 and I highly doubt the CTRNAND transfer functionality uses arm11k services only so I think it doesn't make any changes to the 11.0 people.

I suggest everyone check @Plailect's new guide.

 

[Halvorsen]

Until someone (@d0k3 , @Plailect ?) lands here and explains it deeper (if possible!): CTRNAND is just a partition of the nand, the bigger one, responsible of containing system titles. The direct difference between a CTRNAND backup and a full NAND backup is you don't touch FIRM0/FIRM1 or TWL,AGB or key storage partitions. So what you are really doing is a backup of the system titles.

They might found a way to trick N3DS in properly booting a 3DS CTRNAND since 2.1 system software version is only available to 3DS, perhpahs with a dedicated franken-ctrnand modified enough to grab the otp but not agressively changed to provide universal support. From my point of view we are not directly changing FIRM partitions by the CTRNAND restore, but then again the process is called CTRNAND transfer for a reason so modification of FIRM0 might be done manually afterwards because afaik the "bug" responsible for the OTP register to be left open is located in the 2.1.0 FIRM.

It really gets me the point of being "universal". That might mean nand backup sharing between hacked systems.

EDIT: From d0k3's release notes:

• CTRNAND Transfer...: This menu contains various options to enable transfer of CTRNAND partitions between consoles.
  • Auto CTRNAND Transfer: Automatically transfer a transferable CTRNAND image to this consoles NAND. Without A9LH installed, this will overwrite the FIRM0, FIRM1, CTRNAND. With A9LH installed, this will only overwrite CTRNAND. O3DS images can be transferred into N3DS consoles, but the NCSD header of the NAND may be overwritten.
  • Dump transferable CTRNAND: Dump a CTRNAND image for later use in the feature above. Transferables images can be shared between consoles.
  • Autofix CTRNAND: Use this to automatically fixes the CMACs for movable.sed, *.db and system saves inside the CTRNAND. It will also fix the inside the data folder. This is useful f.e. when a CTRNAND from another console was previously injected the regular way.SO

So this means we might not need to downgrade anymore. Just make a 9.2 CTRNAND transfer (even o3ds to n3ds). I wonder if this might bypass the N's 11.0 hardcoded min system title version list as I don't think the transfer is using the direct installing/removal of titles into the system. Then again, running d9 requires arm9 and I highly doubt the CTRNAND transfer functionality uses arm11k services only so I think it doesn't make any changes to the 11.0 people.

I swear I will start fucking crying if you can transfer consoles without having to swap motherboards or do a system transfer.

And even make a stock system into an a9lh one? Whew.


Oh my gosh this will be amazing in the future.

 

[d0k3]

I swear I will start fucking crying if you can transfer consoles without having to swap motherboards or do a system transfer.

And even make a stock system into an a9lh one? Whew.


Oh my gosh this will be amazing in the future.

You can transfer consoles, but with the current auto method, system data from the receiving system is kept, and you might want a full transfer from System A -> System B. To do this, dump CTRNAND (that's in a different submenu) from System A, inject to System B. Then Autofix CTRNAND on System B, done. I may make this more comfortable later, but it is already just two steps on System B anyways.

As I said, also take a look at Plailect's new guide.

Edit: This goes without saying, but if you do this, don't be a Jackass, have a hardmod. There are no bricks with Plailect's new guide so far, but you could still mess up.

 

[Urbanshadow]

Edit: This goes without saying, but if you do this, don't be a Jackass, have a hardmod. There are no bricks with Plailect's new guide so far, but you could still mess up.

Not to send the hobbits down a hole, but this looks way more safe than before. Is just false confidence?

 

[d0k3]

Not to send the hobbits down a hole, but this looks way more safe than before. Is just false confidence?

It is way more safe than before. There is also much less user messup potential now.

 

[Urbanshadow]

It is way more safe than before. There is also much less user messup potential now.

Really good news. Good job!

 

[DavidRO99]

It is way more safe than before. There is also much less user messup potential now.

Wait... we can now install A9LH with just a CTRNAND img? So if somebody has A9LH and they backup the CTRNAND someone else on 9.2 can install that CTRNAND and copy arm9loaderhax.bin to their SD and it will work?

 

[Urbanshadow]

Wait... we can now install A9LH with just a CTRNAND img? So if somebody has A9LH and they backup the CTRNAND someone else on 9.2 can install that CTRNAND and copy arm9loaderhax.bin to their SD and it will work?

Nope. CTRNAND backups of a9lh systems are just CTRNAND partition backups. Forcing it to do that will brick the target system (and only hardmod recoverable!), because the otp of both systems are different.

In practice, decrypt9 protects itself from that brick and only recover CTRNAND partition, with potentially unexpected results if FIRM0/FIRM1 are in different versions than CTRNAND but not a brick.

 

[d0k3]

In practice, decrypt9 protects itself from that brick and only recover CTRNAND partition, with potentially unexpected results if FIRM0/FIRM1 are in different versions than CTRNAND but not a brick.

FIRMs are taken care of in that method, too, meaning either the A9LH FIRMs will be kept (if A9LH installed) or the correct ones will be installed.

 

[Urbanshadow]

FIRMs are taken care of in that method, too, meaning either the A9LH FIRMs will be kept (if A9LH installed) or the correct ones will be installed.

Extracted from CTRNAND? That's clever.
(inb4 People transferring CTRNAND with a9lh 11.0 sysnand to another system and expecting to get a9lh but get fully updated to 11.0)