Hacking Hardmod issues

Matthew B

Member
OP
Newcomer
Joined
Sep 8, 2016
Messages
14
Trophies
0
Age
37
XP
66
Country
United States
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?
 
Last edited by Matthew B,

Matthew B

Member
OP
Newcomer
Joined
Sep 8, 2016
Messages
14
Trophies
0
Age
37
XP
66
Country
United States
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?
 

vb_encryption_vb

That hardmod guy....
Member
Joined
Nov 21, 2015
Messages
1,989
Trophies
2
Age
40
Location
Acworth, GA
XP
1,630
Country
United States
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

Member
OP
Newcomer
Joined
Sep 8, 2016
Messages
14
Trophies
0
Age
37
XP
66
Country
United States

Matthew B

Member
OP
Newcomer
Joined
Sep 8, 2016
Messages
14
Trophies
0
Age
37
XP
66
Country
United States
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?
 

Selver

13,5,1,14,9,14,7,12,5,19,19
Member
Joined
Dec 22, 2015
Messages
219
Trophies
0
XP
406
Country
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.

Correct dump of sector X:
Code:
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:
Code:
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

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.
 
Last edited by Selver,

Matthew B

Member
OP
Newcomer
Joined
Sep 8, 2016
Messages
14
Trophies
0
Age
37
XP
66
Country
United States
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.

Correct dump of sector X:
Code:
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:
Code:
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

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.
 
Last edited by Matthew B,

Selver

13,5,1,14,9,14,7,12,5,19,19
Member
Joined
Dec 22, 2015
Messages
219
Trophies
0
XP
406
Country
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

Member
OP
Newcomer
Joined
Sep 8, 2016
Messages
14
Trophies
0
Age
37
XP
66
Country
United States
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?
 

Selver

13,5,1,14,9,14,7,12,5,19,19
Member
Joined
Dec 22, 2015
Messages
219
Trophies
0
XP
406
Country
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.....
 

You may also like...

General chit-chat
Help Users
  • No one is chatting at the moment.
    M4x1mumReZ @ M4x1mumReZ: I thought he was going to use an actual PS4 to cook. +1