Hacking NTRBootHax vs Bricked N3DS, help required

[DocKlokMan]

This is as good a time as any for me to thank you for your time and effort. I appreciate it a lot. Hopefully my example will help even more people in the future, not that I wish anybody to get such convoluted bricks.

Here are some more files to run the CMAC fix on. These are all located inside the 1:/data/<id0>/sysdata/ folder:

/0001000F/00000000
/0001002C/00000000
/00010038/00000000
/00010032/00000000
/00010017/00000000

Press A on the 00000000 file and run CMAC fix for all 5 of them. If any state they need fixing, go ahead and try to boot. If they all say they're fine, then we'll need a way to figure out your id0 folder.

 

[eworm]

Everything passed no problem.

 

[Quantumcat]

Did you see zoogie's solution for 2DS consoles facing the same problem (on 2.1 then updated, now only showing failed to mount CTR-NAND)? It's in the 2DSaver thread.

 

[DocKlokMan]

Everything passed no problem.

Okay, I've attached a GodMode9 script. Place it in your SD:/gm9/scripts/ folder and then run it in GodMode9 by pressing Home > More > Scripts > Check and see if it tells you the serial and ID0 folder name. Make note of it and compare it to what's in 1:\data\.

Did you see zoogie's solution for 2DS consoles facing the same problem (on 2.1 then updated, now only showing failed to mount CTR-NAND)? It's in the 2DSaver thread.

Will check this out now, thanks for the heads up.

 

[eworm]

It worked. 4b423f7b0b83e8205e971493a6c73651 and it matches the folder in 1\data exactly.

 

[DocKlokMan]

It worked. 4b423f7b0b83e8205e971493a6c73651 and it matches the folder in 1\data exactly.

Damn, I expecting it to be different. That means the variable just pulls from 1:/data instead of recalculating it like D9 did. The only difference between D9 and GM9 when it comes to CTRNAND transfers is fixing the ID0 folder in 1:/data after the transfer. Since I don't know of a way to get your ID0 without Decrypt9, which fails to do so, I think we're at an impasse.

According to Zoogie you can try going to 1:\private\movable.sed and Show in Hex Editor. Press A to enter edit mode (input the key combo), then make sure the first line reads:

53 45 45 44 00 00 00 00

Hold A and use Up and Down to alter the value of a byte. If any changes are made, press B to exit edit mode and A to save changes.

That's the last thing I can recommend until d0k3 comes out with an update.

 

[HiddenRambler]

That's the last thing I can recommend until d0k3 comes out with an update.

Can you patch D9 code so it would spit out the errorlevel reason so we can figure out which validation failure caused it to fail:

https://github.com/d0k3/Decrypt9WIP/blob/master/source/main.c#L91

I would do it but I don't have a build enviornment at the moment.

 

[eworm]

The first line was ever so slightly different (01 instead of the second-to-last 00), nothing changed after correcting it.
Seems we're stuck. Thanks for your efforts anyway though.

My other N3DS, now that I look, has two <id> folders for whatever reason. I don't suppose copying the unused one to the bricked console and changing the id0 to that would work, huh?

 

[DocKlokMan]

The first line was ever so slightly different (01 instead of the second-to-last 00), nothing changed after correcting it.
Seems we're stuck. Thanks for your efforts anyway though.

My other N3DS, now that I look, has two <id> folders for whatever reason. I don't suppose copying the unused one to the bricked console and changing the id0 to that would work, huh?

No, that's completely unrelated. Your 3DS only uses one of those folders, so use Properties to find which is smaller and delete it. Or compare the folders on the SD to the one in 1:/data and delete the one that doesn't match.

 

[eworm]

I don't suppose it would be possible to recreate a System Transfer with GodMode9 in order to move my working console's data to the brick and then set up the working one afresh? I'm grasping at straws here, of course...

 

[iAqua]

I don't suppose it would be possible to recreate a System Transfer with GodMode9 in order to move my working console's data to the brick and then set up the working one afresh? I'm grasping at straws here, of course...

Forced CTR Transfer is still a option, wait a bit though, decrypt9 debug might be able to help you.

 

[eworm]

While the issue is awaiting a solution (in a form of a new GodMode9 release or something), I would appreciate a simple explanation of what is happening and what is wrong and what is needed.

Also:

Transfer CTRNAND images between systems: Transfer the file located at S:/ctrnand_full.bin (or E:/ I:/). On the receiving system, press A, select CTRNAND Options..., then Transfer to NAND.

Would that be of any help? I do have another working N3DS after all.

Alternatively, wouldn't doing a format force the creation of a new id0 folder or something? Though I don't even know if GodMode9 can do a system format in the first place...

 

[DocKlokMan]

While the issue is awaiting a solution (in a form of a new GodMode9 release or something), I would appreciate a simple explanation of what is happening and what is wrong and what is needed.

Also:

Would that be of any help? I do have another working N3DS after all.

Alternatively, wouldn't doing a format force the creation of a new id0 folder or something? Though I don't even know if GodMode9 can do a system format in the first place...

The instructions you posted is how I've assumed you've been doing the CTRNAND transfer in GodMode9. If you've been doing other steps, then yes, go ahead and do that.

If that fails, can you open GodMode9 and go to 1:/rw/sys and tell me what's in there?

Lastly, I was re-reading your posts and you said your other 3DS has two id0 folders in the Nintendo 3DS folder. Was the memory card in your working 3DS previously used on the bricked one?

 

[eworm]

Oh wait, yeah, that is what I did already. Got confused.

1:/rw/sys has:
LocalFriendCodeSeed_B
native.log
rand_seed
SecureInfo_A
updater.log

No, I didn't use the same SD card for the consoles. That other id folder must be a remnant of something way in the past, maybe from before a System Transfer, I dunno.

 

[Kubas_inko]

I know this is irelevant, but is there a guide on how to unbirck console via NTRBootHax?

 

[Quantumcat]

I know this is irelevant, but is there a guide on how to unbirck console via NTRBootHax?

Follow the guide to install it but instead of using SafeB9SInstaller, use Decrypt9 and perform a 9.2 CTR transfer.

 

[DocKlokMan]

@eworm I've got something in the works for you. Can you tell me what region your n3DS is? USA, EUR or JPN?

 

[HugaTheFox]

Have you tried CTRTransfer9? (What ever its called)

 

[SonicMC]

Wow you guys tried a bunch of stuff. Wish it were working for you. I used decrypt9 to restore my 2ds from a 9.2 backup when I bricked it using the wrong otp on 2.1... (don't do cfw stuff at 2am...) So I am a big fan of backups. I thought the thing a brick for good.

I know you said you probably don't have the nand backup and wouldn't be able to tell from which 3ds you had one from should you find it...
But if you do find one; I would probably try booting to decrypt9 and dumping your nonworking nand as it currently is; so you have a broken place to go back to. Then look and see if you can find your old nand backup and just try it anyway (even if it is from the other 3ds);
If you are lucky and it is from the right one; then it should boot up and you can go from there. If it is from the wrong one; just boot back into decrypt9 and load the backup of the nonworking nand that you backed up and keep trying fixes from there.

 

[eworm]

@eworm I've got something in the works for you. Can you tell me what region your n3DS is? USA, EUR or JPN?

All my consoles are EUR ones.