Hacking 2DS brick (some advises and feedback needed)

[mvmiranda]

hello all,

I have a 2DS bricked and I need your thoughts about the whole story. Please, bear with me for a lengthy post

I received this bricked 2DS some days ago. It was bricked by the customer while he was trying to upgrade and install rxTools (yeah, yeah! I know, right!? )
The rxTool didn't work out the way he wanted (something related to H&S disappearing) so, since he had a working NAND backup, he reverted and it worked (so indeed we have a working NAND backup). He tried once more the rxTool unlock and got the same result, so when he was trying to revert to his NAND backup a second time the console bricked.

He then sent to another technician who kept the console for a long time, giving excuses everytime (like the hardmod didn't work, my reader is not working, I have to change laptop, etc). After many days he returned the console to the owner, and here comes what I need your thoughts and feedback.

My experience tells me that:
1) hardmod is farirly easy (once you get used to is and I do it since 2013)
2) the bootrom error message (the blue screen one) tells you much about the hardmod and other NAND related stuff

Now to the weird stuff.

When I got the console, after a good board cleaning, the hardmod worked flawlessly and I could read/write to the NAND. So I did it with the NAND that was in the SD card and for my surprise the console didn't come up. I still had a blue screen with a number in the last row. This tells me that the NAND was Ok (meaning it was valid for the board) but for some hardware failure it didn't work. I looked for apparent shorts, missing components or ripped traces and couldn't find anything.

Speaking to the owner he told me he had a working NAND and he sent me (in fact this was the same NAND he sent to the first technician), and when I flashed that NAND the bootrom error code (last row) changed from some number to all 0s (which tells me the NAND is either broken or wrong for that board). I then MD5'd the file and sent direction to the customer to hash his file as well and it turns out they are the exact file (remember this NAND was used once to repair the console, so it works).

So, even if the SD NAND, somehow, got corrupted and is jamming the console boot sequence, the new NAND should have worked, right!?

So, after all of this "mumble jumble" about the case, I ask you:
1) Am I totally wrong about what I know regarding bootrom error codes (numbers and zeroes)?
2) Is there any other possibility other then the NAND the customer has does not belong to the board?

I can be wrong and it's totally fine if I turn out to be. I just want to learn more

Thanks!

 

[ArmoredGuns1]

I had a similar case when I tried to hardmod a N3DS. It kept showing the blue screen every time, even after writing a good NAND backup, so I sent it to someone who had more experience. He told me that a capacitor was shorting, hence it wasn't allowing proper data flow to the NAND writes. This was due to a not so good hardmod work. So you should check on that.

 

[gamesquest1]

a blue screen even after restoring would imply its either another hardware fault or a bad nand dump, afaik the only requirement to getting a black screen of death (rather than blue which signifies a complete failure to start up) is a valid NCSD header (which is the first 200 bytes) which is console specific but you can use one from another console, it just means DS mode will be broken, but it will at least allow you to find out if its a separate hardware error or just a bad nand dump with invalid NCSD header