Hacking Hardmod issues

[Matthew B]

Sorry, this is more a downgrade issue than hard mod issue as title suggests.

Ok, so I hardmodded my new 3ds xl and ordered the proper sd card reader to dump the nand, I dumped it 3 times and the md5 and sha1 hashes matched on 2 of them, so I proceeded with one of those 2 dumps. I ran through autofirm and it evenutually was written to the nand on my system, it says the writing was completed OK, but when I goto restart my 3ds after unplugging the sdcard, I get a blue screen with the "signature failed verification" error code. This happens still when I try to write back the original nand. My question is, what are some possible reasons for this? I feel as though if it were the soldering that I would have never gotten 2 dumps with matching hashes that were exact same size (1.84G). Is something wrong with my writing?

 

[vb_encryption_vb]

So 3 dump only 2 matched? Soldering was bad, probably a bad nand dump to begin with.

 

[leerz]

New nand chip version? Autofirm might not be detecting it probably, but I'd check my wiring

 

[Matthew B]

So 3 dump only 2 matched? Soldering was bad, probably a bad nand dump to begin with.

I was thinking that - but then remembered I may had restarted my 3DS in between 1st and 2nd/3rd dumps, which from what I understand would cause my dump hash to change. I'm curious though if it was bad soldering, how I could get 2 identical NAND dump hashes? The solder job looks clean to me, double and triple checked the connections against the wiring diagram.

I will also add, the sd card adapter I am using does not have the r/w protection switch on it anymore, it's missing, could that have anything to do with it?

 

[astronautlevel]

Try using firmswap rather than autofirm: https://github.com/ihaveamac/firmswap

 

[vb_encryption_vb]

It wouldn't even write back if it's missing the r/w chip unless you taped it off or something to make it write.

I'd like to see pictures of your soldering.

--------------------- MERGED ---------------------------

Try using firmswap rather than autofirm: https://github.com/ihaveamac/firmswap

He stated he tried to write the original unpatched NAND back and still has BSOD.

 

[Matthew B]

It wouldn't even write back if it's missing the r/w chip unless you taped it off or something to make it write.

I'd like to see pictures of your soldering.

Fair, I will upload pictures as soon as I can - at work currently. Thanks in advance for taking a look.

Try using firmswap rather than autofirm: https://github.com/ihaveamac/firmswap

OK, I will try this later when I get home - thanks for the tip.

 

[Matthew B]

I also read this somewhere:

Try USBWriter. It's worked for me when W32DI has failed.http://sourceforge.net/projects/usbwriter/

Wonder if it would make any difference, assuming I had a good dump anyway.

 

[vb_encryption_vb]

I also read this somewhere:



Wonder if it would make any difference, assuming I had a good dump anyway.

The dump you had, may have not been good is the thing. It may have read the data, but could be missing some things. Open the dump in a hex editor and look at it.

 

[Matthew B]

The dump you had, may have not been good is the thing. It may have read the data, but could be missing some things. Open the dump in a hex editor and look at it.

I opened one of the matching dumps in a hex editor after I dumped it and seen in plain text "NCSD" somewhere in there, assumed it was good. Anything specific I am supposed to look for?

 

[vb_encryption_vb]

garbled text, but at this point I think it's a soldering issue.

 

[Matthew B]

garbled text, but at this point I think it's a soldering issue.

OK, definitely garbled text in there, I'll upload some pictures when I get home around 5 EST of my soldering work, hopefully you'll be around then to take a peek and see what you think.

Thanks again.

 

[Selver]

I opened one of the matching dumps in a hex editor after I dumped it and seen in plain text "NCSD" somewhere in there, assumed it was good. Anything specific I am supposed to look for?

It's not enough to find that. Also need to look for any sector where the last eight bytes are identical (except for 0xFF or 0x00 for whole sector, indicating unwritten flash). Because it's encrypted, it's astronomically unlikely this will happen in a correct dump. However, it does happen with hardmods, likely due to a very low-level interaction between the SD reader and the MMC device.

In such a situation where the hardmod is slightly flaky, or interacts poorly with the SD reader, or picks up occasional noise on one of the lines, certain corruption patterns can occur that are detectable.
The first few bytes are valid, but then the last byte is repeated for the remainder of that sector.

Spoiler: Example of bad dump of this type

Correct dump of sector X:

6E 32 A4 7F 3E CC 4E 88-91 F6 5C 77 E3 CD DB 67
4F 75 C9 94 E4 69 95 28-58 B1 2D 3D C4 C0 82 DB
32 16 74 AA 13 E6 FD E3-ED 8C 05 63 F3 EC 3E 27
37 85 10 57 DD 0C 9A B8-66 19 FE 55 0C 77 48 9A
BB 4B AA 02 F4 FC FD 84-02 47 3E 67 97 C6 87 2D
...
14 C5 B2 01 42 77 7F 77-02 D3 9B 4C 57 16 D7 E5
9D 5F C0 F6 3D 1A B5 27-F8 A0 92 97 41 18 98 50

While one with this problem would look like:

6E 32 A4 7F 3E CC 4E 88-0A 0A 0A 0A 0A 0A 0A 0A
0A 0A 0A 0A 0A 0A 0A 0A-0A 0A 0A 0A 0A 0A 0A 0A
0A 0A 0A 0A 0A 0A 0A 0A-0A 0A 0A 0A 0A 0A 0A 0A
0A 0A 0A 0A 0A 0A 0A 0A-0A 0A 0A 0A 0A 0A 0A 0A
0A 0A 0A 0A 0A 0A 0A 0A-0A 0A 0A 0A 0A 0A 0A 0A
...
0A 0A 0A 0A 0A 0A 0A 0A-0A 0A 0A 0A 0A 0A 0A 0A
0A 0A 0A 0A 0A 0A 0A 0A-0A 0A 0A 0A 0A 0A 0A 0A

Spoiler: Technical conjecture

SD cards and eMMC use slightly different protocols. The biggest problem I've found is where the eMMC device, for a single READ, has a problem.
eMMC devices report that a READ had an error at the next command.
SD cards likely report the error immediately (unconfirmed).
It might also be caused by eMMC indicating a busy state in a way that is not recognized via an SD interface.
Either of these would correspond to the corruption pattern listed above, especially if the problem is an intermittent connection with CLK, which is a tough point on N3DS XL.

As you know, the NAND is updated every time the console boots, so the following only applies where you perform the dumps without powering off the device.

1. Dump the NAND via hardmod
2. Dump a second time via hardmod
3. Hash both images
4. If non-matching, dump a third time via hardmod
5. Use a specialized utility for merging

I wrote the following specialized merge utility. Here's the source and a precompiled binary:
https://github.com/Selver-gba/MergeImages - .NET (C#) source
https://filetrip.net/dl?czvVVbb7F7 - Precompiled .NET binary

Let me know if that is useful.

 

[Matthew B]

It's not enough to find that. Also need to look for any sector where the last eight bytes are identical (except for 0xFF or 0x00 for whole sector, indicating unwritten flash). Because it's encrypted, it's astronomically unlikely this will happen in a correct dump. However, it does happen with hardmods, likely due to a very low-level interaction between the SD reader and the MMC device.

In such a situation where the hardmod is slightly flaky, or interacts poorly with the SD reader, or picks up occasional noise on one of the lines, certain corruption patterns can occur that are detectable.
The first few bytes are valid, but then the last byte is repeated for the remainder of that sector.

Spoiler: Example of bad dump of this type

Correct dump of sector X:

6E 32 A4 7F 3E CC 4E 88-91 F6 5C 77 E3 CD DB 67
4F 75 C9 94 E4 69 95 28-58 B1 2D 3D C4 C0 82 DB
32 16 74 AA 13 E6 FD E3-ED 8C 05 63 F3 EC 3E 27
37 85 10 57 DD 0C 9A B8-66 19 FE 55 0C 77 48 9A
BB 4B AA 02 F4 FC FD 84-02 47 3E 67 97 C6 87 2D
...
14 C5 B2 01 42 77 7F 77-02 D3 9B 4C 57 16 D7 E5
9D 5F C0 F6 3D 1A B5 27-F8 A0 92 97 41 18 98 50

While one with this problem would look like:

6E 32 A4 7F 3E CC 4E 88-0A 0A 0A 0A 0A 0A 0A 0A
0A 0A 0A 0A 0A 0A 0A 0A-0A 0A 0A 0A 0A 0A 0A 0A
0A 0A 0A 0A 0A 0A 0A 0A-0A 0A 0A 0A 0A 0A 0A 0A
0A 0A 0A 0A 0A 0A 0A 0A-0A 0A 0A 0A 0A 0A 0A 0A
0A 0A 0A 0A 0A 0A 0A 0A-0A 0A 0A 0A 0A 0A 0A 0A
...
0A 0A 0A 0A 0A 0A 0A 0A-0A 0A 0A 0A 0A 0A 0A 0A
0A 0A 0A 0A 0A 0A 0A 0A-0A 0A 0A 0A 0A 0A 0A 0A

Spoiler: Technical conjecture

SD cards and eMMC use slightly different protocols. The biggest problem I've found is where the eMMC device, for a single READ, has a problem.
eMMC devices report that a READ had an error at the next command.
SD cards likely report the error immediately (unconfirmed).
It might also be caused by eMMC indicating a busy state in a way that is not recognized via an SD interface.
Either of these would correspond to the corruption pattern listed above, especially if the problem is an intermittent connection with CLK, which is a tough point on N3DS XL.

As you know, the NAND is updated every time the console boots, so the following only applies where you perform the dumps without powering off the device.

1. Dump the NAND via hardmod
2. Dump a second time via hardmod
3. Hash both images
4. If non-matching, dump a third time via hardmod
5. Use a specialized utility for merging

I wrote the following specialized merge utility. Here's the source and a precompiled binary:
https://github.com/Selver-gba/MergeImages - .NET (C#) source
]https://filetrip.net/dl?czvVVbb7F7 - Precompiled .NET binary

Let me know if that is useful.

Thats great, thanks. I definitely will try the merge on the dumps and look for instances of such repetition - Let me ask you though, do you think its possible to get 2 identical in size and hash dumps that are "bad dumps" from the NAND? I have 2 that are identical.

 

[Selver]

Possible? Yes. Possible causes: NAND was actually corrupt for some reason before the dump.

Likely if the NAND booted after the dump? No. (astronomically unlikely)

 

[Matthew B]

Possible? Yes. Possible causes: NAND was actually corrupt for some reason before the dump.

Likely if the NAND booted after the dump? No. (astronomically unlikely)

I see, so you recommend looking at the dumps in hex, try to identify any bad sectors - and trying a merge on all 3 dumps, or just the 2 identical ones?

 

[Matthew B]

https://filetrip.net/dl?czvVVbb7F7

The zip file in the compiled version of the merger is damaged it says.

 

[vb_encryption_vb]

Pic of soldering.

 

[Selver]

The zip file in the compiled version of the merger is damaged it says.

Sorry, it appears that filetrip deleted the binary. It seems FileTrip pretends to have it, then sends the 403 error message (HTML) as the file requested. Weird.

Given the source code is available, please use that (or use it as a baseline to write your own checker).

I see, so you recommend looking at the dumps in hex, try to identify any bad sectors - and trying a merge on all 3 dumps, or just the 2 identical ones?

Well, you said two of them are identical to each other.
Even so, go ahead and try to merge... the log file would show anything of interest.

You could also modify the source code to just scan a single file for those patterns of corruption, if you only have one file. It doesn't guarantee the data is valid if nothing is found, but it could definitely identify if something's wrong.

You wouldn't happen to already have generated the XORPADs for the system nand, using Decrypt9 or the like? If you have, then many more options (although none automated) become available.....