Guide_3ds: Use Decrypt9 for CTR transfer rather than GodMode9

From what I know, Decrypt9 can work with the NAND header. GodMode9 can do this as well, but it's a manual process

Can there be steps added for this part then? So it could say, if you were doing this because you got a black screen on boot or were otherwise bricked, if you still get a black screen, then do these extra steps? At the moment the only way anyone would ever know to use Decrypt9 to fix it is if they asked on Discord and someone on there knew to tell them, or gbatemp.

There is an issue already for an unbricking guide. #1278

Alright, trying to get a grasp of this. You're talking about using GM9 CTRtransfer to fix a brick, right? That can work, and it also may not. GM9 CTRtransfer was mainly designed to be a less intrusive means of doing a region switch (or otherwise resetting your console)

As far as unbricking goes - that's not what D9 CTRtransfer was designed for either, but it seems to have some limited success there. Still, I won't take 5 minutes to find a brick it cannot fix. The real be all, end all solution here is the Lazarus 3DS script for GM9, which may be part of the guide soon.

Will that solve your issue?

Probably, I don't know much about it, but as it stands you need a working console to get the files required (so it won't work on its own unless the required files are available by torrent), and it says it screws up super-stable 3D on N3DS.

Well... we don't want to go too much off-topic here, right? Just let me say that the "this needs another console" argument is moot. As you know yourself, so does the CTRtransfer, but there, conveniently someone has provided the files for you. Also, Lazarus3DS does not screw up super-stable 3DS on N3DS - whatever bricked you does, and in these edge cases, D9 CTRtransfer won't work anymore anyways. Lazarus3DS just saves what it can (and that's more than D9 does).

Back on-topic - what this issue really is about is: you need a as-good-as-possible unbricking method, and the method currently in the guide does not deliver, corrrect?

The issue is not with GodMode9 or Decrypt9, the issue is how bad your brick is and how lacking the CTR Transfer images are.

CTRTransfer images were designed for downgrading or region switching already functional consoles. They are missing very important things a bricked console may need, such as a proper NAND header, the TWL master boot record, the TWL nand and TWL photos partitions, a working movable.sed, a working SecureInfo and LCD calibration files for your particular 3DS.

Success with Decrypt9 or GodMode9 and using the CTRTransfer images is purely up to how bad your brick is. In the absolute worst case scenario where your NAND is so messed up that absolutely no files can be recovered from it, only then the Super Stable 3D on a n3DS would be affected, and that's not due to the process of the revive but due to the severity of your brick.

In most bricks the super stable 3D on n3DS units would be perfectly fine as long as the HWCAL0 and HWCAL1 files are still accessible on your NAND.

I do have pre-prepared images for the Lazarus3DS script that may get added to the guide via torrent for people to use, similar to CTRTransfer images. If a CTRTransfer is not working for you, then please wait to see if an additional "Unbricking" section is added to the guide, modifying the CTRTransfer instructions aren't going to help much.

This is not about unbricking totally fucked up consoles.

The issue is that there is a bunch of people with N3DS console on 2.1 (downgraded back during a9lh days and either bricked or forget about it) and that now manage to restore their console thanks to bootNTR. Luma boots into a "failed to mount ctr nand" screen and doing a ctr transfer with gm9 does not restore the original nand header that decrypt9 would store. Doing the ctr transfer with d9 fixes this issue.

The people don't need another 3ds to provide them sensitive unbricking files, they have their secureinfos and lfcs etc., they just need the tool to restore their original nand header backup that is still saved.

And yes, this happens a lot, several times a week.

You got a point there about the header replacement. On the other side... "this happens a lot"? All known methods of downgrading to 2.1 basically forced you to make a NAND backup, and what you're supposed to do is restore that to your console.

As A9LH and downgrades to 2.1 are by now considered legacy, there really shouldn't be a relevant number of users who did that and managed to lose their NAND backups coming in anymore. (Actually, was there ever? Even back in the days these cases were considered edge cases.)

I'll discuss the further course of action with @Plailect, I guess.

For a long time they didn't force you to make a NAND backup. People didn't make them and I remember people saying "well the guide says to make a backup and people wouldnt skip that would they?" when it was suggested to make the backup mandatory.

Then SafeCTRTransfer came, forced you to make one and (the guide) told you to delete it of the sd after backing it up. A lot of people didn't back it up, deleted it off of the sd -> no backup. Or people panicked on 2.1 and deleted everything off of the sd because "if I empty the sd I'm sure the 3ds will work again".

In the 3ds-assistance channels on the discord server these cases were never "edge cases". As a matter of fact, when I wrote my response 2 hours ago I was helping someone with this exact issue. A quick search in discord shows that there have been 4 of such cases in the past 7 days (possibly excluding those of people that didn't manage to type the error message correctly). Eight months ago I'm willing to bet there were several a day. Sure, it's not as many cases as it used to be, but it still happens.

And yes, I know that there shouldn't be a need for a CTRTransfer at all, but we aren't exactly dealing with the most tech-savy of users at times... so we have to deal with it one way or the other.

I'd be fine with a section in troubleshooting specifically talking about "Failed to mount CTR NAND" and linking to D9 in that one... or maybe a gm9 script or similar can be made to restore the old header backup and we can tell people to do that instead.

I would use a manual GM9 method or script before resorting to outdated and unsupported software. I'll look at this more this weekend.

@olliz0r it isn't just "Failed to mount CTR-NAND" that Decrypt9 fixes and GodMode9 doesn't. I had an Old 3DS with a black screen/blue light that GodMode9 didn't fix, but Decrypt9 did (which is what prompted me to make the issue).

This might all be a moot point if the unbricking page comes soon (with Lazarus & associated files). If it doesn't, it would be great to get the script with torrents to the required files added to the troubleshooting page so we can direct people there.

One more thing I just thought of, it would be handy to have a page that describes all common bootup problems and how to fix them or links to the correct page. The troubleshooting page could have an entry "bootup issue" that directs them to this page. The ctr transfer page could have a warning on top saying "this page is for upgrading/downgrading, not for fixing bootup issues, please see (link)". Some bootup issues are not proper bricks (e.g. missing/wrong boot.firm or home menu extdata) and others require different solutions to each other.

One of the main things dc9 does with nand backups and restores and ctrtransfers is NAND header backup and restore to 0x400 in NAND which can easily be restored with scripts. (note that gm9 also backs up the NAND header here with the essential.exefs backup however if it detects the existing current NAND header is mismatched like in a 2.1 n3ds then it won't make that backup and the dc9 header is still intact)

# allow nand writes
allow S:/nand.bin
# backup current nand header
inject S:/nand.bin@0:200 0:/nand_hdr_orig.bin
# inject dc9 nand header into current nand header
inject S:/nand.bin@400:200 S:/nand.bin@0

This would all be a lot of work and only really helps with some edge cases related to months old methods which aren't used anymore. Any "unbricking" related discussion will be in #1278