Hacking Is my N3DS broken? Random crashes no matter what

[Elwyndas]

A few days ago, my SNES N3DS started crapping out. It began with the blue light turning on just for a little bit, before fading out. No boot.
I re-inserted SIM card, battery, and that did the trick, but not always.
Then, every day it got worse, with random crashes after a few seconds getting into the home screen (various forms of ARM11 crashes, I have some logs), so I suspected that the SD card might be corrupt. I followed the advice here for error checking and reformatting it (it's a Samsung 128gb from Amazon that had no issues in over 2 years).
It did nothing. It started crashing without SD card. It crashes during godmode9, with or without SD card.
Everything is up to date, Luma 10.1 (I tried older versions to no avail), Godmode9 1.9.1
In my despair I attempted to reflash the stock CTRNAND via Godmode9. The process started alright, but in the middle of the process, GodMode9 just froze (no error message). Now it boots straight into an ARM11 error (I guess because of the interrupted CTRNAND transfer).
I'm able to launch into GodMode9 still, but I fear that the unit might suffer from some severe hardware damage that is not related to the SD card, or a corrupted SYSNAND. The most worrysome sign is a GodMode9 crash without error message during CTRNAND transfer.
Is there any hope for repair? I have a backup of the SYSNAND, and the essentials, from the 3ds.hack.guide procedure.

 

[TurdPooCharger]

Question 1
Did you check the hardware condition of your Samsung 128 GB microSD by doing these steps?

1. Copy everything off the SD card to a computer.
2. Quadruple reformat.
3. Full Write + Verify the empty card in H2testw.

Question 2
Which exact CTRTransfer did you perform? Provide the link.

Question 3
What's the detailed readout of this ARM11 error?

• Processor
• Exception type
• Fault status
  
• Current process

Question 4
Do you have a spare/second microSD card, preferably something small like 4 GB?

Question 5
Do you own an ntrboot compatible DS flashcart by any chance?

 

[Elwyndas]

I had hoped that you would answer. Thank you so much for always providing your expert help around here.
I have read through tons of similar issues, and tried many things that you suggested in other threads.

To answer your questions:
1) Test and Quadruple Format:
Yes and no. I did reformat it twice, once with GUIFormat, and then with EaseUS Partition Master, which is my trusted program since forever. Windows explorer cannot format more than 64gb SD cards (?).
The H2testw procedure returned zero errors. After copying the contents back on, the problems persisted.

2) CTRTransfer
I downloaded the torrent of the N3DS US version from here
https://3ds.hacks.guide/region-changing

3) ARM11 error
When I boot now, without SD card, after that failed CTRNAND transfer, I boot into an ARM9 error
Exception type: prefetch abort (svcBreak) and a table with a bunch of cryptic code.
If you want, I can post the various crash dumps I have save over the last few days.

4) Spare SD card
I have plenty, including small ones. I just tried a fresh 64gb Samsung, formatted it with EaseUS as recommended (MBR, 32kb cluster, FAT32, but not quadruple and no h2testw) and copied everything from your Essentials package on it, plus my SYSNAND backup and the stock CTRNAND. Without the SD card in, I boot into Godmode9. Then, when inserting the SD card, and after it gets mounted, I initiate the CTRNAND transfer of the stock .bin again. It gets started, but after a few seconds in, it crashes, with a QR code screen and "exception: undefined (1)" error message, plus a table with code. I have a photo of that.

5) DS Flashcart
Yes, I have that thing, a R4i Gold 3DS Plus. It has its own SD card on the cartridge, and I can switch between regular mode and NTRBoot. It works great.

 

[TurdPooCharger]

Uck, late reply. Terrible morning. Yay for family feuds...

1) Test and Quadruple Format:
Yes and no. I did reformat it twice, once with GUIFormat, and then with EaseUS Partition Master, which is my trusted program since forever. Windows explorer cannot format more than 64gb SD cards (?).
The H2testw procedure returned zero errors. After copying the contents back on, the problems persisted.

• Double reformatting might not be sufficient enough. See this explanation about the sneakiness of a badly reformatted SD card in that follow-up reply post #6.
  
• Windows File Explorer doesn't support reformatting USB flash drives and SD cards bigger than 32 GB in FAT32, but that's okay as NTFS was specified as a substitution in place of this limitation.
• EaseUS Partition Master (free) should be comparable to the MiniTool Partition Wizard (free). As long as that program has fine tune controls for those four (4) parameters, I see no issue using one over the other.
  
• Did we conversed previously about using FAT32 + 64 KB cluster size for cards that are 128 GB or bigger?
  • Upgraded SD Card Causing Minor Problems [post #6]
  • Anyway, if your Samsung card is currently using 32 KB cluster size and when you get the chance, redo those steps 1-3 but substitute 32 KB for 64 KB 64 KB for 32 KB and MiniTool for EaseUS EaseUS for MiniTool.

2) CTRTransfer
I downloaded the torrent of the N3DS US version from here
https://3ds.hacks.guide/region-changing

I take this to mean you did the standard GodMode9 [3ds.hacks.guide] CTRTransfer, and not the (older) Decrypt9(WIP) CTRTransfer or the (newer) CTRTransfer (Type D9)?

3) ARM11 error
When I boot now, without SD card, after that failed CTRNAND transfer, I boot into an ARM9 error
Exception type: prefetch abort (svcBreak) and a table with a bunch of cryptic code.
If you want, I can post the various crash dumps I have save over the last few days.

The ARM9 error can be explained by the failed CTRTransfer, assuming the answer to Q2 was standard CTRTransfer. ARM9 error from an incomplete CTRTransfer could mean a frakenfirm softbrick where the replacement 1:/dbs/title.db, 1:/dbs/import.db, and title folder are not a matching set. Basically, the database records do not lineup with the actual installed system titles.

The bigger concern would be on why the CTRTransfer failing midrun in the first place. More about this point later.

ARM11 errors are another story. These you do have to be specific enough what the readout says for those 3 or 4 fields shown in the top screen.

Nah, I'm good with the crash dump logs. First order of business is to fix the current ARM9 softbrick before returning to the original ARM11 error.

4) Spare SD card
I have plenty, including small ones. I just tried a fresh 64gb Samsung, formatted it with EaseUS as recommended (MBR, 32kb cluster, FAT32, but not quadruple and no h2testw) and copied everything from your Essentials package on it, plus my SYSNAND backup and the stock CTRNAND. Without the SD card in, I boot into Godmode9. Then, when inserting the SD card, and after it gets mounted, I initiate the CTRNAND transfer of the stock .bin again. It gets started, but after a few seconds in, it crashes, with a QR code screen and "exception: undefined (1)" error message, plus a table with code. I have a photo of that.

I'm going to need you to find the smallest sized card you have that has at least 4 GB minimum. The smaller, the better.

1. Copy everything off that SD card to a computer.
   • For this task, use another card and not your Samsung 128 GB main one.
2. Quadruple reformat.
   • Yes, reformat it four (4) times in that specific order with those programs with the exception of the EaseUS ⇄ MiniTool substitution.
3. Full Write + Verify the empty card in H2testw.
   • This is where having a smaller card comes in handy.
4. If the card passes, delete the *.h2w test files.
   • Do not use the card if it was found to be defective. Replace it and go back to step 1.
5. Create this bare minimum setup. Do not add back files from your main setup.
   • sdmc:/gm9/scripts/NANDManager.gm9
     
   • sdmc:/luma/payloads/GodMode9.firm (GodMode9)
     
   • sdmc:/boot.firm (Luma3DS)
6. In GodMode9, backup your SysNAND.
   • (HOME) button → Scripts... → NANDManager → <X> Backup SysNAND
7. Go into the [1:] SYSNAND CTRNAND/dbs directory.
8. Press (A) on ticket.db → Copy to 0:/gm9/out.
   
9. Press (A) on ticket.bak → Copy to 0:/gm9/out.
10. Press (X) on ticket.db to delete this file.
    • This file was added in from standard CTRTransfer / region changing.
11. Hold (R)-shoulder and press (X) on ticket.bak. Rename this to ticket.db.
    • This will restore your original ticket database.
12. Repair the 3DS firmware + custom firmware with CTRTransfer (Type D9) - CTRTransfer.
    • Please carefully read and follow that page's Instructions.
    • The steps 1-4 and 8 in Instructions can be skipped as they're already covered here. * Adjust step 5 about not adding back the main setup.

What's done next depends on how this repair attempt goes.

5) DS Flashcart
Yes, I have that thing, a R4i Gold 3DS Plus. It has its own SD card on the cartridge, and I can switch between regular mode and NTRBoot. It works great.

Good. This will come in handy in case of a worst case scenario.

 

[Elwyndas]

I followed the formatting steps to the letter. A 4GB Toshiba card. I think I pulled it from some original hardware it came with.
In Godmode9, when creating the SYSNAND backup (step 6), after about 15 seconds, and the process having started, the system crashes with the QR code on the top screen. Exception: Data abort (4)



EDIT: Out of boredom, I simply tried to do it again, and I was lucky, the SYSNAND backup and title db backup finished before it crashed again.
Then after rebooting I proceeded to the CTRTransfer and went through the steps, but when I saw the red warning of level 3 writing permission I stopped. I sounds scary. I wonder what happens if the console crashes right in the middle of overwriting essential system code. Will I get an unrecoverable brick?

 

[TurdPooCharger]

I followed the formatting steps to the letter. A 4GB Toshiba card. I think I pulled it from some original hardware it came with.
In Godmode9, when creating the SYSNAND backup (step 6), after about 15 seconds, and the process having started, the system crashes with the QR code on the top screen. Exception: Data abort (4)

About that worst case scenario mentioned earlier. I think your motherboard's eMMC (NAND chip) has died.

I once helped the user, Jiyorude, who present a problematic n2DSXL at the 3ds noob thread.

• https://gbatemp.net/threads/3ds-noob-paradise-ask-questions-here.359035/page-2457#post-8704474

He and I continued our discussion in private message where we attempted to repair his n2DSXL with a cross system { CTRNAND + TWLN + TWLP } Transfer. This method involves dumping certain NAND images from a (source) system, flashing those on a like new/old (target) system, make the repairs as needed { ie, manual edits + file placements and CTRTransfer (Type D9) }, dump & return back the fixed images, and restore them on the (source) system. Except for several differences in backed/restored files and extra steps where the (target) system restores its own SysNAND later, this cross system { CTRNAND + TWLN + TWLP } Transfer is basically Lazarus3DS.

The details of the following official story versus what actually happened may or may not be the same.
Jiyorude mailed his n2DSXL by Pigeon Carrier Express to me where I tried to dump these three (3) partitions + one (1) other file from the [S:] SYSNAND VIRTUAL.

• [1:] SYSNAND CTRNAND | ctrnand_full.bin
  
• [2:] SYNAND TWLN(AND) | twln.bin
• [3:] SYSNAND P(HOTO) | twlp.bin
• GodMode9's mini backups of console unique files | essential.exefs

Spoiler: The n2DSXL crashed with this GodMode9 error.

Those four (4) files could not be extracted. Continual usage in GodMode9 revealed glitchy, strangely misspelled text exploring the different directories and files.

Similarly, observed over from the Nintendo Homebrew Discord Channel (the below quoted statement actually came from the GodMode9 Discord channel #general),

youd be surprised

ive had people get gm9 arm9 handlers in the middle of ctrtransfers

or this

While it's rare, this (believed to be) hardware failure has been reported from time to time.

***

If your repair using CTRTransfer (Type D9) - CTRTransfer had turned out differently where the 11.5.0-38U_ctrtransfer_n3ds.bin image was flashed successfully to the n3DSXL's NAND but strange behaviors continued to persist when booting to HOME Menu or doing anything under native firmware, that R4i 3DS Gold Plus flashcart would have come in handy to hardware check the eMMC using that gm9 script's other function, eMMC Status Checker. Short explanation of what that is: it's basically H2testw for the NAND chip. There's no point of running that function as your n3DSXL has demonstrated instability when it tried to back up the SysNAND.

***

I have more to write about in terms of moving forward (ie, other replacement or repair options) but will need to give these cranky fingers a rest and juice up me brain with coffee.

Edit - Probably won't talk about replacement/repair options in this post #6 to give myself breathing room. Please feel free to reply as I go get foodz.

 

[Elwyndas]

Did you see the edited post? I tried again and was able to create the SYSNAND backup. Shall I proceed with CTRNAND transfer, and not get intimidated by the red warning?

 

[TurdPooCharger]

Did you see the edited post? I tried again and was able to create the SYSNAND backup. Shall I proceed with CTRNAND transfer, and not get intimidated by the red warning?

Gonna go on break. Will be AFK. See this post later when edit in ~30 minutes.

-snip-

EDIT: Out of boredom, I simply tried to do it again, and I was lucky, the SYSNAND backup and title db backup finished before it crashed again.
Then after rebooting I proceeded to the CTRTransfer and went through the steps, but when I saw the red warning of level 3 writing permission I stopped. I sounds scary. I wonder what happens if the console crashes right in the middle of overwriting essential system code. Will I get an unrecoverable brick?

Lvl3 write permission means that the [ file / partition / component ] in question that if messed with or edited incorrectly will result in a bootrom 8046 softbrick. While the experience is unpleasant to those that it happens to, Blue Screens of Death (of the software variety) are especially devastating for those without an ntrboot flashcart. Bootrom brick means the 3DS cannot standalone boot, access GodMode9, and go in to do software repairs as needed. Excluding the nand.bin (which is everything) and nand_minsize.bin (which is nand.bin without the bonus.bin), these are five (5) items in the [S:] SYSNAND VIRTUAL that fall under this high risk category.

• nand_hdr.bin - The nand NCSD header; first 0x200 bytes of nand.bin.
• twlmbr.bin - The MBR partition table for twln.bin & twlp.bin; It's also the decrypted form of the last 66 bytes of the nand_hdr.bin.
• sector0x96.bin - Also known as secret_sector.bin. Found only on New 3DS series. One of Nintendo's later security implementations to try to prevent custom firmware.
• firm0.bin - Primary bootloader. This is where boot9strap or other FIRM payloads are flashed to. For New 3DS series, this is (encrypted?) behind sector0x96.bin.
  
• firm1.bin - Secondary or backup bootloader. If one or the other gets corrupt (ie, Gateway 3DS flashcart brick code), you're not SoL as long as one of the firm0/1 is still good.

CTRTransfer (Type D9) handles fixing those files where it sees fit depending on what sort of softbrick the 3DS system has. Basically when granting Lvl3 permission, you are placing your trust in metaphorically putting your n3DSXL under the knife where the other person who's operating on you is a medical surgeon that means well instead of some secret serial killer cosplaying as a doctor to have a McStabby McStab fun time.

I have my doubts about the CTRTransfer (Type D9) working or completing its run due to your n3DSXL having crashed from backing up the SysNAND, which is just a simple read-only task from the NAND side. If the n3DSXL does crash in the middle of the process (like the patient flat lining during the operation), you can recover from this with SysNAND Restore. While I don't believe your n3DSXL will end up with a bootrom 8046 from using the (Type D9)'s CTRTransfer option unless the NAND chip was on its last leg and decided to crap out on you right there and then [this would be the hardware variety], you have your R4i Gold 3DS Plus on the ready in case it's needed.

Note: The (Type D9)'s eMMC Status Checker that was mentioned earlier can result in bootrom 8046. Due to how this option works, it's not mean to fix anything but reserved for diagnosing a faulty NAND chip.

***

Edit - To answer your question about going through with (Type D9)'s CTRTransfer, you have your backed up SysNAND and R4i Gold 3DS Plus. That image can be used to decrypt, extract those ctr/twln/twlp partitions, and (temporarily) clone your n3DSXL's user profile on a donor system to backup DSiWare games + saves, everything in the Nintendo 3DS folder, and your user profile to migrate over to another n3DSXL if that's required.

I say you try it, but be ready to brace yourself. If the CTRTransfer crashes midrun, this more or less confirms the n3DSXL definitely has a hardware fault.

 

[Elwyndas]

I went through everything. For unknown reasons, the device didn't crash once this time during those long procedures. The CTRNAND reflash succeded, and also the eMMC Status checker. Everything worked out. No errors on eMMC. However, when I reboot, with or without SD card, I get the Arm9 error prefetch abort (svcBreak). I can boot into Luma and GodMode9, but that's it.

 

[AutumnWolf]

Your wifi card may be damaged

 

[TurdPooCharger]

I went through everything. For unknown reasons, the device didn't crash once this time during those long procedures. The CTRNAND reflash succeded, and also the eMMC Status checker. Everything worked out. No errors on eMMC. However, when I reboot, with or without SD card, I get the Arm9 error prefetch abort (svcBreak). I can boot into Luma and GodMode9, but that's it.

Take a look in this thread.

• "prefetch abort (svcbreak) processor ARM9" after CTRTransfer

Hex view these files in HxD editor. Don't post their images and don't upload the files here.

• [1:] SYSNAND CTRNAND/private/movable.sed
• [1:] SYSNAND CTRNAND/rw/sys/SecureInfo_A (or _B)

[post #7]
The movable.sed should be either 288 bytes or 320 bytes where the first four (4) MAGIC values should be 53 45 45 44 or 'SEED'. If this movable.sed is 320 bytes in size, the next four values are 00 01 00 00.

[post #13]
The SecureInfo_A (or _B, there should only be one unless you've region changed), the value at offset 0x100 should be 01 for (USA) region. SecureInfo_A|B also contains a copy of that 3DS system's Serial Number. Report back if have more than one of these (ie, *_A, *_B, and *_C) and/or the serial number does not match what's stated in the sticker found on the behind the n3DSXL's back plate.

***

Edit - I think I know what might have happened. The CTRTransfer might not have fixed all the CMACs for the files found in:

• 1:/data/<ID0>/
  • extdata/
    • etc.
  • sysdata/
    • etc.
• 1:/dbs/
  • certs.db
  • import.db
  • ticket.db
  • title.db
  • tmp_i.db
  • tmp_t.db
• 1:/private/movable.sed

There was a regression bug found in GM9 v1.9.1 where recursively searching and calculating files with CMACs will stop and fail if just one of the files are found to be bad.

• [BUG] 'Fix CMACs for drive' on '[A:] SYSNAND SD' will stop on corrupt/uninitialized *.sav.

 

[Elwyndas]

movable.sed is 320 bytes and the values are the same you listed.
SecureInfo_B shows 01 in that location. It also shows the correct serial of my device. There are no other SecureInfo files.
Something I forgot to mention, during the CTRNAND Transfer from your Type D9 script, the CIA dumping failed, I think on all titles. I had to constantly press B to abort and move on. This might be significant, I don't know. It seems to be about the DSi Ware.
Also, I noticed that while Luma on the SD card is Ver 9.1, the one in CTRNAND is 10.1.2, the newest one. I realized this after deleting the config.bin files in both locations. The console then boots into the Luma3DS configuration menu. It doesn't matter what I do there. After saving (START) it crashes with ARM9 (with or without SD card).
Could it be that the new Luma is screwing everything up?

 

[TurdPooCharger]

movable.sed is 320 bytes and the values are the same you listed.
SecureInfo_B shows 01 in that location. It also shows the correct serial of my device. There are no other SecureInfo files.
Something I forgot to mention, during the CTRNAND Transfer from your Type D9 script, the CIA dumping failed, I think on all titles. I had to constantly press B to abort and move on. This might be significant, I don't know. It seems to be about the DSi Ware.
Also, I noticed that while Luma on the SD card is Ver 9.1, the one in CTRNAND is 10.1.2, the newest one. I realized this after deleting the config.bin files in both locations. The console then boots into the Luma3DS configuration menu. It doesn't matter what I do there. After saving (START) it crashes with ARM9 (with or without SD card).
Could it be that the new Luma is screwing everything up?

(Type D9) failing to dump the CIAs for the DSiWare? This sounds like a familiar bug where games will not get dumped if the 1:/dbs/ticket.db is missing. Did you happen to use an older version of this script? The version can be seen in the first 3 pages introduction when the script is launched. The latest available version of this script is v1.8b. That failure to back up the DSiWare games & TWL system titles is found on v1.4 and older (I think). I'm currently on my Linux setup, so can't go back and cross compare where the code change occurred. * Work files on my Windows SSD; HP lappy does not dual boot.

I don't have enough hands on experience with the latest Luma3DS v10.1 / v10.1.1 / v10.1.2 on how it interacts between different versions of CTRNAND Luma3DS and SD card Luma3DS. Replace both with the same copies. For the sake of working with what's known, replace these with luma v9.1 for the time being.

• sdmc:/boot.firm
  
• 1:/boot.firm

Delete both of their configuration settings to reset.

• sdmc:/luma/config.bin
• 1:/rw/luma/config.bin

My last post was late edited about GodMode9 failing to calculate and calculate all NAND files CMACs. Having even just one (1) with the wrong CMAC will cause the 3DS to boot with a ARM9 error. I'll provide instructions on how to check for this once I learn which version of (Type D9) you used.

 

[Elwyndas]

Good grief... I have version 1.7b of the script.
Shall I repeat everything with 1.8b?

I changed Luma on both locations to 9.1 and deleted the configs.

 

[TurdPooCharger]

Good grief... I have version 1.7b of the script.
Shall I repeat everything with 1.8b?

I changed Luma on both locations to 9.1 and deleted the configs.

No, that's fine. The jump from v1.7b to v1.8b were very minute bug fixes. You can read the changes in the v1.8b release page.

• TL;DR - Stupid naming mistake on my part. Rename the 1:/ro/sys/HWCAL0.DAt & HWCAL1.DAt with the correct lower cases for their extension (*.dat).

Failure to dump those DSiWare saves & games will need to revisit with that backed up SysNAND image you've made.

To check if the ARM9 error is to due to incomplete CMAC calculations bug theory,

13. In the [1:] SYSNAND CTRNAND, hold (R)-shoulder and press (X) on data folder. Rename this to data2.

• Be careful with pressing only the (X) button as this brings up the delete option. Do not delete your user profile!
• This action will perform a (simulated) Format System Memory. Because the data folder contains multiple files where every single one of them have CMACs, it would take too long to find which one(s) might have been corrupted. Renaming this folder will set it aside.

14. Go in the dbs folder. For each of these six (6) files, individually press (A) → Calculate CMAC. Take mental note and report back if any of them were declared CMAC verification: failed!

• certs.db
• import.db
• ticket.db
• title.db
• tmp_i.db
• tmp_t.db

15. Back out with (B). Go in the private folder. Repeat the step 14's process for the movable.sed.

• Excluding the data folder, these are the only seven (7) ctrnand files that have CMACs.

16. Press (START) to exit GodMode9. If successful, your n3DSXL will ask you to create a new user profile.

• If the n3DSXL still shows ARM9 error by this point, our discussion may need to continue by PM.

 

[Elwyndas]

They all passed. And it boots into Arm9 error
When I look at the CTRNAND again, a new data folder was created, with the long string folder name in it, but no sub folders. Perhaps that's a hint?

Also, I saw it mentioned in your script that there is a known soft brick problem caused by ? titles, that your script can address.
I remember having seen such an entry under titles in FBI. One line with multiple ??? in the list of installed titles.

 

[TurdPooCharger]

They all passed. And it boots into Arm9 error
When I look at the CTRNAND again, a new data folder was created, with the long string folder name in it, but no sub folders. Perhaps that's a hint?

Also, I saw it mentioned in your script that there is a known soft brick problem caused by ? titles, that your script can address.
I remember having seen such an entry under titles in FBI. One line with multiple ??? in the list of installed titles.

Ooo... This is nuts. The new (dummy) data folder was to be expected, but the extdata and sysdata subsubfolders not being created were not. I'm surprised you ran the eMMC Status Checker, and results came back perfectly fine for all three (3) passes (00, FF, restore). If not the storage drive, your n3DSXL motherboard's problem could lay in either the RAM or SoC. The RAM is probably the more likely culprit.

Since that theory was shot out the window,

17. Go back to the 1:/ directory. Press (X) to delete the (blank) data folder.
18. Hold (R)-shoulder and press (X) on data2 to rename back to data.​

The '?' is something that happens to the 1:/title when (typically standard variety of) CTRTransfer is performed with a fake or faulty SD card. The replacement system titles damage the CTRNAND's partition file system because the SD card that was carrying the ctrnand .BIN image corrupted its data. Garbage in, garbage out.

About that PM, even though we currently live in tough times with shipping stuff because you know... CV, how much bird seeds do you have for air postage?

 

[Elwyndas]

Ooo... This is nuts. The new (dummy) data folder was to be expected, but the extdata and sysdata subsubfolders not being created were not. I'm surprised you ran the eMMC Status Checker, and results came back perfectly fine for all three (3) passes (00, FF, restore). If not the storage drive, your n3DSXL motherboard's problem could lay in either the RAM or SoC. The RAM is probably the more likely culprit.

Since that theory was shot out the window,

17. Go back to the 1:/ directory. Press (X) to delete the (blank) data folder.
18. Hold (R)-shoulder and press (X) on data2 to rename back to data.​

The '?' is something that happens to the 1:/title when (typically standard variety of) CTRTransfer is performed with a fake or faulty SD card. The replacement system titles damage the CTRNAND's partition file system because the SD card that was carrying the ctrnand .BIN image corrupted its data. Garbage in, garbage out.

About that PM, even though we currently live in tough times with shipping stuff because you know... CV, how much bird seeds do you have for air postage?

What I find funny is that now, after all these steps, the console does not randomly crash anymore in godmode9. I had it running for hours yesterday. The intense script actions and backups went through without a problem. I think this was after I flashed the stock CTRNAND. So I'm assuming that something must have happened that helped at least for "stability", which is what we desire most in Nintendo products

Also, since I still have the SYSNAND backup from way back, after I hacked the device in its virgin state, shouldn't that .bin be guaranteed to fix the mess and overwrite everything with a pristine image?
I do not care for the installed titles and saved games. I only use the console for emulators anyway, and maybe Mario Cart with my daughter.

I can re-install everything no problem. Shall I give it a try?

 

[TurdPooCharger]

What I find funny is that now, after all these steps, the console does not randomly crash anymore in godmode9. I had it running for hours yesterday. The intense script actions and backups went through without a problem. I think this was after I flashed the stock CTRNAND. So I'm assuming that something must have happened that helped at least for "stability", which is what we desire most in Nintendo products

I'm still curious as to why CTRTransfer (Type D9) failed to repair your 3DS firmware + custom firmware. When you ran the CTRTransfer, did you download and use the publicly available 11.5.0-38U_ctrtransfer_n3ds.bin found at [3ds.hacks.guide] CTRTransfer, or was the supplied .BIN & .SHA image set produced from the n3DSXL's SysNAND?

In post #5, you mentioned backing up the title.db alongside the SysNAND image. Was this title.db manually restored or put back in the 1:/dbs after CTRTransfer? The 3DS firmware will crash with ARM9 error if the NAND's import.db, title.db, and title folder are not a matching set.

Also, since I still have the SYSNAND backup from way back, after I hacked the device in its virgin state, shouldn't that .bin be guaranteed to fix the mess and overwrite everything with a pristine image?

Yes, restoring that very first SysNAND image will return the state of the 3DS firmware exactly as how it was when you first hacked it. In fact, another fellow GBAtemper had to do just that when (Type D9) came up short against his PTM brick.

• Problems with my N3DS

If you wish to try, you can retain your user profile and old settings by doing the following.

19. Restore the SysNAND with the very first original image.
20. Go to this folder that contains the dumped nand files created by CTRTransfer (Type D9).

• sdmc:/gm9/out/<date>_<serial>_sysnand ctrnand_000

21. Copy and paste these specific items back to the [1:] SYSNAND CTRNAND. Press the (Y) button to add items to the [CLIPBOARD]. Press the (SELECT) button to reset the clipboard. When moving the folder and files, press (Y) again and use Copy path(s).

• 1:/data
• 1:/dbs/ticket.db
• 1:/private/movable.sed
• Restore nothing else.

22. Back out with (B). While under the [root], scroll up and rest the white cursor on [1:] SYSNAND CTRNAND. Hold the (R)-shoulder and press (A) → Fix CMACs for drive → <A> yes → button combo → <A> yes → etc.

• Spoiler: Fix CMACs for drive

  

These steps will cover backing up and restoring the collection of DSiWare games & saves before the brickening.

23. Go in the [S:] SYSYNAND VIRTUAL → press (A) on the twln.bin → Copy to 0:/gm9/out
24. Find the SysNAND image that was created from step 6 in post #4. This will contain those DSiWare games & saves.
24. Press (A) on that <date>_<serial>_sysnand_###.bin → NAND image options... → Mount image to drive → <A> yes.
25. You will be in the 7:/ directory. Back out with (B). Go in the [I:] IMGNAND VIRTUAL → press (Y) on twln.bin to [CLIPBOARD].
26. Back out with (B). Go in the [S:] SYSNAND VIRTUAL → press (Y) → <A> yes → <A> yes → button combo.

• This will restore the [2:] SYSNAND TWLN containing those DSiWare games & saves.

27. Press (HOME) → Scripts... → CTRTransfer (Type D9) → DSiWare CIAs & Saves → Backup CIAs & Saves
28. Exit the script. Go to the 0:/gm9/out directory. Press (Y) on the twln.bin. Back out with (B). Go in the [S:] SYSNAND VIRTUAL. Press (Y) to paste.

• This will restore the pristine TWLNAND.

29. Press (START) to exit GodMode9 → HOME Menu → Homebrew Launcher → FBI

• SD → gm9/out/<date>_<serial>_dsiware_000 → <current directory> → Install all CIAs

30. Go back to GodMode9 → CTRTransfer (Type D9) → DSiWare CIAs & Saves → Restore Saves

31. Update the firmware to 11.13.0-45U with System Settings → Other Settings → System Update.

• If the n3DSXL does not update, FBI install the replacement system tickets dumped at:
• SD → gm9/out/<date>_<serial>_system tickets_(<region>)_000 → <current directory> → Install all tickets

Edit - Additional steps.

32. Missing tickets can be restored with faketik.
33. HOME Menu gift icons can be unwrapped with Cthulhu.
34. If not done so yet, start backing up the games' saves + extdata with Checkpoint, JKSM, and/or GBAVCSM.​

 

[Elwyndas]

I managed to flash the "virgin" sysnand. And voila, the console booted into the home menu! Alas, the joy lasted only a few seconds, and it crashed with ARM11.
I tried a few more things, but I'm giving up now. One thing I noticed is that when I boot into Godmode9 without SD card, the version number is 1.7.1. Is that because it's part of the SYSNAND backup?
One of the crazier crashes is documented in this video.
https://drive.google.com/open?id=1mciIBp9XOoC_0hfgiqkq92jR0KEJ5472
Or check the corrupted menu in GodMode9 (attached).
I'm certain now that this is not a normal brick. It's something deeper.
I'll be happy to ship it to you.