This is a continuation of post #135 found here. If you are unfamiliar about this script, please read the previous post before proceeding.

For version 2.0 of Inject and Restore Apps, these updates warrant a dedicated post explaining in detail the benefits, drawbacks, and mechanics behind this revamped script. The script can be downloaded here.

As usual, I’ll try to Q&A the role of the skeptical user who insists on grilling me.

Safety checks? Pfff. Who do you think I am?
Someone who deserves some peace of mind. Don’t take what I wrote next the wrong way as I’m not calling into question anyone’s intelligence. If a script (or program) allows you to do something you shouldn’t or didn’t intend to do in the first place, that makes it a bad script, and the blame solely rests on the person who coded it.

With that in mind, this script was created from the onset with as much idiot proofing as possible, but that doesn’t cover the flip side of those safety checks. There is one factor neither you (as the script user) nor I (as the programmer) can ever fully account for: nefarious CIA malware intended to corrupt your 3DS system titles. In the case of CIA files, this is as simple as renaming a file as Game A.cia to Game B.cia . Sounds harmless? Not really.

In the very unlikely but possible scenario that you unsuspectedly download/receive a fake or bad CIA file from somewhere or someone who wishes to harm your prized possession, those safety checks listed above should foil the most basic entries of causing injection mayhem.

System app injection is no joke. Just because something is named with a .cia extension and is image mountable by GodMode9 does not necessarily mean the file in question is injectable or safe to inject to begin with. It basically boils down to this: garbage in, garbage out.

This is probably going off topic from the stated question, but I feel it’s important to mention this.

GM9 scripting has its limitations. This script can’t account for every conceivable bad or harmful injection cases, like seemingly legitimately CIA homebrew re-coded to wreck havoc once installed on your 3DS and that can pass those above sniff tests. As the end user, it is your responsibility to download CIA titles from reputable and trustworthy sources.

And if you don’t believe 3DS malware is a thing, here is the tragic and cautionary tale of the once prodigious dev best known for creating Themely, Erman and his fall from grace in the UnbanMii debacle.

… Bro, you scare me. This inject app script biz sounds bad.
You have every reason to be concern with whichever homebrew you use on your 3DS/2DS. My job here is to help assuage this and answer to the best of my abilities those concerns regarding this script.

The Inject and Restore Apps script is geared towards those who are hitting their 300 titles limit and are looking to utilize homebrew titles in place of those 10 listed Nintendo sys apps. With the “stealth” injection method that’ll later be covered below this post, this type of injection may prove useful for those who favor quickly launching a select few homebrews straight from HOME Menu instead of first booting into Homebrew Launcher.

While there’s nothing technically stopping you from deleting those Nintendo titles using GodMode9 or FBI to free up title count, it has been mentioned elsewhere on this forum that Nintendo is able to detect when those sys apps are missing. Should you connect online with deleted system titles, you can get hit with a ban. The same rule applies for installing CIA homebrews straight onto HOME Menu.

This script allows you to put those “wasted” titles to good use but only if it has determined your shoe-in homebrew titles are deemed safe for injection.

Here are the reasons why certain CIA types cannot or should not be injected:

Fake CIA (renamed from any file) – a real .cia file contains at minimum one .app file (your game). If that’s not present, there’s nothing injectable to begin with. It would be amazing if this could inject Switch ROM dumps, but renaming something like LoZ - BotW.iso to LoZ - BotW.cia doesn’t change the fact it’s not real and won’t work on the 3DS.

Real but corrupted CIA (not intact) – If GM9 can’t read it, this is just as bad as reason #1.

DSiWare – DSiWare CIAs are structured differently than typical CIA dumped from .3ds/.3dsx . Perhaps a DSiWare version of this script is in order for later development if this type of injection can be extended and is determined feasible. Maybe NTR Launcher “stealth” injected into Zelda Four Swords?

Updates & DLCs – These are accessory or appendages to whichever titles they belong to. While some are very similar file structure wise when compared to complete CIA titles, launching them at HOME Menu will throw an exception.

eShop demos – Officially released 3DS titles are injectable but (universally?) incompatible when launched from HOME Menu. In case this incompatibility bug is ever fixed, eShop demos were thrown in because I’m democist. I hate getting teased. Stick to the full copy versions.

CIAs with .app larger than 16 MB – Most homebrews come nowhere near 16 MB. The largest Nintendo sys app is StreetPass Mii Plaza at 15.3 MB for 00000021.app. Your 3DS internal NAND has a capacity of 1 GB. Approximately 600 MB of that NAND is used to house your 3DS operating system. The rest goes to your DSiWare library, photos, game notes, etc. You wouldn’t want to accidentally inject a CIA that is 3.76 GB onto 400 MB, right?

One other noteworthy safety check is that the script does not attempt injection for missing system titles deleted off the 3DS.

You’re not the boss of me. What if I have this killer CIA homebrew I want to inject, but it’s bigger than 16 MB? What then, huh!?
There are two ways to overcome this script’s size safety limiter. The permanent method is to open the script in Notepad, and edit the values for these variables from the beginning.

CIA_SIZE_LIMIT
CIA_SIZE_NUMBER

CIA_SIZE_LIMIT is the byte size of the largest allowable injection written in hex number.

1 MB (megabyte) equals 10242 bytes.

10242 is equal to 1,048,576

Add +1 byte to have the limiter triggered for anything over exactly 1 MB.

1,048,577 in decimal is equal to 0x100001 in hex.

The 0x is not written in the CIA_SIZE_LIMIT input value. This notation is for denoting it’s a hex number.

So the formula is: ( # of MB ) x 1024 x 1024 + 1 = decimal numbers
Convert the decimal numbers to hex numbers using the calculator like the one above.

Here are some other provided values for raising the limiter if you’re not comfortable calculating the hex numbers.

Set CIA_SIZE_LIMIT “2000001”
Set CIA_SIZE_NUMBER “32 MB”

Set CIA_SIZE_LIMIT “4000001”
Set CIA_SIZE_NUMBER “64 MB”

Set CIA_SIZE_LIMIT “8000001”
Set CIA_SIZE_NUMBER “128 MB”

The second method of overcoming the default 16 MB safety limiter is by user discretion. Right after selecting a CIA for injection, quickly press and hold the B button for a few seconds. This will skip the warning message that the file is too big, override the limiter, and continue injection.

Due to limitations of GM9 script, there is no way to patch out this bug without negatively affecting the user experience. The alternative would have been error nags every time you elect to inject. Although not intended this way, you may treat this is a feature in case the first method is too cumbersome. Just keep in mind of the physical 1 GB NAND when employing method two.

What is this “stealth” injection you speak of? Why the quotation marks? Is it or is it not stealth?
Before I start referring to this subject without those quotations, we need to be clear about several points.

Nintendo does not differentiate the difference between homebrew and piracy. The company treats the two as one and the same.

Nintendo can and will ban your 3DS if they detect there is non-licensed installed software on your handheld system.

Except for Nintendo itself, no person can claim knowing the exact extent of Nintendo’s homebrew detection capabilities. We only have theories and speculations. Nothing more.

Also, anyone claiming to have a sure proof method of avoiding said detection is either lying or needs to come spill the beans in how, ASAP. We the community would greatly appreciate that you share and demonstrate a working proof of concept.

Homebrewers have to assume the possibility it is not a matter of if but when they’ll get banned. Any of us who has ever hacked their 3DS/2DS and went online may have already been marked for a future ban. If you’re still able to use Nintendo’s online services despite having CFW, assume that your system is living on borrowed time staying ban-free by Nintendo’s own discretion.

With that said, “stealth” injection is a bit of a misnomer. Stealth(ier) is arguable a better term that describes it. “Stealth” is meant to denote the intended purpose of said injection method but does not necessarily mean it actually achieves that purpose. I don’t want to mislead you as the reader, so any pretenses that this type of injection will completely disguise your injected titles from Nintendo’s watchful eyes should be dropped. Okay? Thanks. *Quotation marks will now be removed from here on out.

Get to the point already! What the hell is stealth injection?
Stealth injection is an advancement of GM9’s original method of H&S injection. Its function is to attempt passing off your homebrew title as the “real thing”. Stealth incorporates certain identifier data from the ncch.bin [NCCH0 header], extheader.bin [extended header], and icon [title meta info] files. When a homebrew title gets stealth injected, that title is given the identity of its container system title.

Whenever you launch a title from HOME Menu and stay connected to the Internet, it is believed Nintendo has the ability to search up and track what title you last played. This is speculation from my part, but I believe the biggest dead giveaway in how Nintendo knows this is due mostly in part from those identifier data in those files.

Observe by injecting FBI using GM9’s built-in H&S injector. I recommend having WiFi turned off beforehand and Cthulhu at the ready for cache clearing if you intend to verify this.

Launch your injected FBI and do a Titles lookup for where Health & Safety should be. Notice anything amiss?

Left: FBI (normal) injected in H&S as-is. Right: Health & Safety without injection in place. System titles are highlighted red. On the left, H&S is missing due to FBI’s occupation.

Let’s see another effect of FBI injected in H&S. I’m sure some of you out there are familiar with this one. Turn off the 3DS, remove the SD card, turn the 3DS on, and check where injected FBI is located on HOME Menu. Do not launch FBI.

If you ever had FBI icon stuck in place of H&S and needed Cthulhu to fix this issue, this is why. Your HOME Menu icon cache updated to FBI’s icon on both SD card and NAND.

This same phenomena appears when injecting into other system titles using prior versions of the script. Here is freeShop injected in Nintendo eShop:

As the old saying goes about looking and quacking like a duck, stealth injection might be enough to masquerade something like freeShop to its official namesake counterpart. This all depends if Nintendo does not look past this as an initial telemetric call back.

What exactly happens to my titles when injecting? I don’t want any funny business going on when using your script. No bueno if not explained in details.
This Q&A wasn’t meant to be an introductory crash course studying the structure of CIA-related title/game files, but here we are. For the general user, I suppose it helps to not only know what this script does but how it does it. Let’s peel back some layers off the onion we know as a CIA file. We will primarily focus on its .app file; there are other files within the CIA like the ticket, certificate, secondary .app (e-manual), etc., but those are not of relevance to this script. The .app of interest will be the primary or game/title one.

Take a moment to study and familiarize yourself with this diagram. When decompiled and cross compared with a hex viewer, the .app file is an archive that contains those constituents “stacked” or place in that order.

Brief Description of Each File

ncch.bin (HeaderNCCH0.bin, Nintendo Content Container Header) – When launching a title, this file instructs the 3DS system the basic layout, locations, and sizes of the other files. Size: 512 bytes.

extheader.bin(ExHeader.bin, Extended Header) – This instructs the 3DS what sort of system and access controls the title requires. Size: 2 KB (2048 bytes).

logo.bin (LogoLZ.bin, logo) – This is the splash screen you see after launching a title while it loads. The file may either be located after the extended header, contained within ExeFS.bin, or sometimes in both locations. Size: 8 KB (8192 bytes).

plain.bin (PlainRGN.bin) – I’m not entirely sure of this file’s purpose. My best guess is that this instructs the 3DS the minimum version update for the title to work. Newer CIA titles seem to lack it. Size: 512 bytes.

Next, look at the close-up hex view of the Nintendo eShop NCCH header and its data field. You’ll need this to follow what gets injected when making freeShop into freeShop.

Unlike the previous method, stealth injection employs carrying over anything that could, from eShop. Essential items are left only or modified at the bare minimum to keep freeShop portion working as intended.

Similar changes are made in the first 1024 bytes of extheader.bin. For Application Title (in case this is read off), eShop’s internal codename is “tiger”. The Program ID is matched to keep freeShop from throwing ARM9 crashes.

Lastly, icon and its hash gets swapped in ExeFSand HeaderExeFS.

And that’s it. That’s the secret behind stealth injection. If you wish to audit the script and verify that it does indeed do what I said it does, you’re free to examine the source code at my GitHub page here.

What is the splash screen option? How do I use it?
The splash screen option allows you to inject either the homebrew or Nintendo logo. This component is not believed to contribute to stealth. It’s a personal preference feature if you like switching to the Nintendo splash. The script’s startup default is homebrew. To change the splash screen you wish to inject, press the B button during your system title’s menu choices.

What the crap? I’ve used older versions of this script. Injection is slow as shiet now. Also, why is the script’s file size so much bigger than v1.9?
These are the sore points of this script… Stealth injection requires reading hex offsets from HeaderExeFS. Without those addresses, injection wouldn’t be possible in modifying and rebuilding the ExeFS container. GM9 script (v1.6.1) can’t directly copy hex values from a file and use them in variables. The only way to get around this hurdle is by converting a hex number into a SHA-256 hash value and then reconverting it back with a hash-to-hex lookup table. Most of the increase in file size is because of that table housing all 256 possible hex numbers from 00 to FF.

Version 1.9, file size = 16.3 KB
Version 2.0, file size = 53.2 KB

Up to 12 individual hex numbers, 4 numbers for each file, are retrieved when injecting banner, icon, and/or logo. As for .code, that’s a freebie because its offset is always 0.

You’ll notice the injection start to finish run time has sharply increased.

While I would like to improve this script’s speed performance and reduce the file size to something more reasonable in a version 2.1 update, we’ll have to wait first until GM9 script offers a ‘hexget’ command before that happens.

You’ve said too much. -But, anything left to add?
Practice safe injection. Word of advice, don’t pick up programming if you don’t have to. That stuff should be placed in the schedule 1 drug list. It’ll hurt your brains real good, kids.

Click to expand...

I think that we all need to give this man a round of applause. Not only for the countless hours it must have taken him to discover and verify all of this, but because of how long it must have taken him to type and format this entire post all for the purpose of infroming us to practice safe injecting, among a lot of other things. Also, you should probably add a TL;DR.

Member

I think that we all need to give this man a round of applause. Not only for the countless hours it must have taken him to discover and verify all of this, but because of how long it must have taken him to type and format this entire post all for the purpose of infroming us to practice safe injecting, among a lot of other things. Also, you should probably add a TL;DR.

Could the ability to extract enctitlekey.bin from ticket.db with a script be implemented? It was a really helpful feature of d9. And it doesn't seem like it would be too hard to implement, considering this can be done manually.

Member

Something else entirely - as a lot of ou may have noticed, GM9 scripting is in some dire need for proper documentation. I think a Wiki may be a good way to solve this, so I set up this GitHub issue to discuss the further course of action. Maybe some of you guys are willing to help me with that. To be honest, you guys do actually know more about the scripting quirks than me .

Member

@d0k3 - For fulfilling my very niche command request. And to boot, he did it in a really quicktoo quick neck breaking pace, workaround time frame creating them. I wanted this, but now the keyboard bacons (yes, food bacon) for moAr GM9 scripts. Argrghgugghh!!

TitleDB.com - For the supplied information

... What is it this time? This better be good.
Presenting a script no one was asking for in the first place and probably almost no one needs or wants either:

Homebrew Checker.gm9

This script was written to test and validate two new gm9 script commands, fget and fset, in the guise of checking your CIA files against a homebrew database.

If your selected CIA file is a known homebrew title, you get output information about its Name, Description, Author, Title ID, and Product ID. If it's not a known homebrew title, you're either warned what kind of CIA file it is, or that the selected title is unknown if it's a legitimate game/title-type CIA.

You wrote this just to mess around with two commands? KISS, learn it.
Sometimes the easy way is great if you're in a pinch. This was created as a means to be creative in testing out those new commands as normal testing procedures, IMO, can be a real chore. I wanted to put them to real practice while cooking up a script that might be useful to some 3DS users.

And if that wasn't thorough or stringent enough for controlling testing variables, a second test script was eventually written in making sure fget and fset weren't doing anything they weren't suppose to. You can find that other one over at GM9 GitHub here (look forfget_fset_debug.zip), which is better in studying how these new commands work.

Lastly, the real tertiary reason I wrote this is, you guessed it, for another gm9 script. Details of why this script was created can be read starting at post #992 here.

Hey! Your script is broken. This doesn't work on GodMode9 v1.6.3.
Stable v1.6.3 release don't have fget and fset command. You'll need the latest nightly found here. There's a good chance the official debut of these two commands will find their way in the v1.6.4 release.

Member

Newcomer

I've scoured this post ... hopefully all of it as best that I can ... and haven't been able to see an answer. Is there a script to dump all installed SD titles at once to CIA's? Or are we stuck having to do them one at a time? I'm very sorry if I missed this in the thread here.

Member

I've scoured this post ... hopefully all of it as best that I can ... and haven't been able to see an answer. Is there a script to dump all installed SD titles at once to CIA's? Or are we stuck having to do them one at a time? I'm very sorry if I missed this in the thread here.

Thanks!

Click to expand...

Oh, you sweet summer child. Lol.

Hold the L-shoulder button and highlight select everything in yellow to do mass CIA building.

TL;DR - Basically, CTRTransfer is like a universal SysNAND image used for recovering from softbricks and region changing the firmware.
If you're familiar with computer operating systems, this is similar to Windows Recovery and Mac Time Machine.

***

This is a gm9 script for performing a variation of Decrypt9 CTRTransfer. Homebrew 3DS users are likely to be more familiar with standard or (built-in) GodMode9 CTRTransfer. While both types are used for repairing or region changing the 3DS firmware, there are stark differences in how they go about changing or correcting the CTRNAND.

Decrypt9 Method

A few console unique files such as the movable.sed, configsave.bin, LocalFriendCodeSeed_B, and SecureInfo_A/B are first extracted from the CTRNAND drive. Afterwards, Decrypt9 (the program) flashes the entire raw donor CTRNAND *.bin image file onto the CTRNAND partition. Those backed up files are moved back in the drive to their respective locations and CMAC hash corrections are done throughout such as for the *.db datebase files and user's extdata + sysdata.

GodMode9 Method

GodMode9 (the program) selectively replaces only the title folder and *.db files. This is to surgically fix the broken system apps while keeping the rest of the user's personal and console unique files intact. Once these folders and files are replaced as needed, this is followed by CMAC hash corrections for those *.db files.

To put this into a comparable life analogy of the two, GM9 CTRTransfer is like replacing worn houseware parts, patching holes for stone walls to a structurally sound but very old house, and renovating its dainty decorations, flooring, and walls. D9 CTRTransfer is like removing your furnishings and personal belongs out of the house, knocking that house down because it's deemed too decrepit, building a replica in its place, and then moving as much of your stuff back in, assuming you haven't forgotten leaving behind anything before the teardown.

GodMode9 is the safer and less intrusive of the two while fixing most general softbricks. Although Decrypt9 is arguably more effective at dealing with severe softbricks, the older app's implementation fails to back up and restore crucial files such as hardware calibration HWCAL0.dat and HWCAL1.dat, personal legit tickets, and [seed|nag|friend|nnid|etc.]save.bin.

With those differences in mind, this script was created with the goal of combining the Decrypt9 approach of flashing a clean slate CTRNAND drive while also maintaining as much of the user's original setup like that of GodMode9.

Files and folders that are partially or fully deleted off the [1:] SYSNAND CTRNAND.

For whatever reason, the 3DS or 2DS system you have had its setup accidentally erased. Perhaps you bought/received yours prehacked from a previous owner who was neglectful. As long as something called the essential.exefs is present and has not been tampered with, it's possible to create a fresh firmware setup.

The [1:] SYSNAND CTRNAND is missing.

Let's imagine you experienced a catastrophic softbrick which required remedying the issue by restoring the SysNAND with a personal image backup. However, luck would have it that the one and only SysNAND *.bin image you kept was trashed by an unknowingly fake SD card. To add further insult to injury, during your restoration of the corrupted image, your system has a very old and untrustworthy battery that dies on you during mid-restore. This incident bricks the CTRNAND partition where GodMode9 doesn't even acknowledge the presence of the drive. Again, this is recoverable so long as the essential.exefs is present and hasn't been tampered with.

Strange '?' files that are stubbornly stuck in CTRNAND or cannot be deleted/replaced by conventional means.

Despite H2testw checking the SD card for issues, updating the custom firmware & 3DS firmware, and troubleshooting for any and all hardware issues, your system has unexplainable boot issues, poor GUI functionality, or random crashes. You (surprise, surprise!) don't have the benefit of a clean, backed up SysNAND *.bin image to recovery from. Attempts at using standard CTRTransfer are not providing favorable results. You may very well have a broken file allocation table at hand. If those damaged files are limited to replaceable or non-unique items, this script will try maintaining anything that's salvageable.

During script run,do not press and hold the (B) buttonwhen the DSiWare games are being dumped and especially for the system tickets.

These are the two sections I could not idiot proof. If you try to cancel building a DSiWare CIA, it'll ask you to try again with the choice to cancel. For the system tickets, the script will fail to completely mount ticket.db.

Exit the script, and press (POWER) → Poweroff system. Turn the system back on, and hold the (SELECT) button to access Luma3DS v#.# configuration. Use these exact settings. Press (START) to save and exit. The system should boot to HOME Menu.

Note:In the off chance the 3DS fails to boot HOME Menu with the below (or similar) error, fixing this requires manually finding and deleting the (ext/sys)data subfolder that is causing the hang-up: Debugging "gamecoin"-type brick

Open the Nintendo 3DS Camera to access Homebrew Launcher. If region changing the 3DS firmware and there are no system titles shown in HOME Menu, press the { (L)-shoulder + (R)-shoulder } button combo to launch the camera applet → Nintendo 3DS Camera→ Homebrew Launcher.

Note: If you have a [ o3DS | o3DSXL | o2DS ] and it gets stuck with black screens, press the { (L)-shoulder + (DOWN) d-pad + (SELECT) } button combo to open Rosalina menu → Reboot. This should restart the system and open Homebrew Launcher.

Note: If the shoulder buttons and/or cameras are broken, rerun the Inject HBL to Camera with an inserted 3DS game cartridge.

Install the system tickets and DSiWare CIAs with FBI. Restore missing tickets for nonlegit titles with faketik. If you have a lot of games, mass unwrap them all with Cthulhu.

The tickets and CIAs folders will be found at sdmc:/gm9/out named in these formats.

Certain DSiWare games will refuse to work if the TWLFontTable.dat is missing. When launched without this file, the game gets stuck at white screens. Because this is a copyright material, this is also up to the end user to find the file on their own. The TWLFontTable.dat is the same for every 3DS and DSi system with the following size/hash(es).

0xD8E08066 - The system tickets may fail to install due to something called the certs.db (certificates). Your setup at one point either corrupted it or erased & regenerated that file with a dummy nonfunctional copy. A replacement copy borrowed from the CTRTransfer image would then be required. The script can replace that file if you come across this issue. Do not use this option if the problem doesn't exist;certs.dbis partially involved with transiting 3DS online play.

0xD8E0806C - The backed up DSiWare titles may fail to install. This is likely to occur if the CTRTransfer was used to region change the firmware. To fix this, install a different DSiWare *.cia file that's not from that backed up set. I have no clue why this hiccup occurs...

0xD8E0806A - The backed up DSiWare legit game titles may fail to install. To fix this, either redownload these previously purchased games from Nintendo eShop or convert the dumped legit CIAs into standard CIAs.

DSiWare CIAs & Saves → Convert CIAs (legit to standard)

Install the files in '3. cias (converted)' first followed by '5. tickets (legit)' to retain your private legit dsiware tickets.

Additional FeaturesFinding and restoring the KeyY.
If you have the Nintendo 3DS folder backed up from a previous profile that was removed from (1) Format System Memory and (2) NOT involved in a System Transfer, this script can brute force up to 256 iterations finding the lost KeyY in the movable.sed linked to a specific <ID0> subfolder. To read more how this works,

Assuming the rest of the KeyY string is correct, finding the 0x118 hex counter that matches the target <ID0> can take up to 1.5 hour to complete or as little as 1 minute. This depends on the search order (this script looks backwards, ex: 03 → 02) versus value of the "correct" hex counter relative to the starting search value (ex, "correct" value is 04 but script is looking backwards, which will take a long time to find and calculate).
Update March-21-2019: Version 1.1 includes backing up the user's original sysnand ctrnand data profile if the KeyY is fixed. Changing the KeyY will automatically delete the 1:/data/<ID0> that's in place due to mismatch in encryption upon the next HOME Menu boot. This would force the user to create a new profile. The script provides the option to correct the 1:/data/<ID0> to the new KeyY. However, certain previous items like Friends List will be corrupted; the Friend Code is directly derived from KeyY.

Update May-21-2019: Version 1.3 does bi-directional searching where it splits the effort in looking both backwards (ex: 03 → 02) and forwards (ex: 03 → 04). There is now the option to quit the search run by pressing and holding the (B) button long enough. A 200 MB free space safety check was implement in case the data folder is backed up.

Backing up the DSiWare CIAs and saves only.Update March-21-2019: Version 1.1 - You can use this script for the ease of moving or importing nonlegit DSiWare titles and their saves involved in System Transfer or library duping.Update April-27-2019: Version 1.2 - The TWL system titles are no longer backed up in order to prevent reinstalling bad copies. This is to prevent bricking the DS mode with fake tickets.Update May-21-2019: Version 1.3 - Saves are no longer restored by mass dumping everything so as to not leave behind orphaned files. Saves are individually restored by cross checking for installed titles.

General Warnings 1. (Re-)installing a CIA over a previously installed game will overwrite and delete its save currently in place. The Rebuild 3DS Database options were designed to fix the import.db and title.db without losing the saves and to keep whatever legit tickets you might have acquired from real Nintendo eShop purchases and updates.

2. During the options' script runs,do not press the (B) button. There is no way to idiot proof the CIA building process. If you press (B) button, you are forced to manually rebuild those titles into CIAs if they were interrupted. Just plug the 3DS system to a AC charger, flip the clam shell closed to let the script do its thing, and leave it alone. Except for Option (C) and if everything goes smoothly without error, the script will turn off the 3DS/2DS to let you know to move onto the next part.

3. Each option has two parts (1 - starting , 2 - finalizing) with an intermediate step of installing CIAs. Do not mix and match the parts between different options.

4. Certain games have anti-cheat save protection that will erase itself if tampering or swapping is detected.

Option (A) - Quick
The fastest of the three where dummy CIAs are generated, and all installed titles (saves included) are relocated offside to a temporary title_<ID0> folder. Once the dummy CIAs are installed:

The original ticket.db is restored to keep the user's real tickets in place.

To prevent accidental reinstallations of the dummy CIAs, the cias (dummy)_<ID0> folder is deleted.

The titles are moved back to the title folder.

Their individual *.cmd header CMACs are corrected.

A minimum 256 MB of free space is required when making the dummy CIAs. Installing dummy DLCs with lots of contents can make FBI appear to crash or become stuck frozen. However, the progress is rather really slow for these titles. Look at the top row's moving clock for proof; be patient and don't force shut off! The sizes and blocks will be reported wrong in FBI and System Settings. There's no away around this annoyance except to use or redo rebuilding the database with one of the other two options.

If curiosity got the better of you, where you completed both parts (1a) Generate Dummy CIAs and (2a) Restore Setup, and you want to restore your SD setup just like how it was before having started Option (A), this is entirely reversible with the backed up files found in dbs_cmd_<ID0> folder.

Option (B) - Full
This is the slowest option when rebuilding the database. Alongside with Option (C), however, the final reported sizes and blocks in FBI and System Settings will be correct. For each title that is successfully backed up as a CIA, its <TID LOW> subfolder within title/<TID HIGH> folder will be deleted. In case of errors, outside files and titles that aren't made into CIAs are not deleted but moved over to a collection title_<ID0> folder for your later examination. If found, saves are decrypted and extracted to a separate saves_<ID0> folder regardless if their parent games were built into a CIA.

Once the CIAs are backed up, and the titles are reinstalled:

The original ticket.db is restored to keep the user's real tickets in place.

The saves are individually restored depending if the parent games were found to be reinstalled.

A minimum 4 GB of free space is required to account for building the largest possible CIAs. To avoid misuse or misunderstanding, option (B) requires a certain action outside of the script. Read the option description on what to do before using (1b) Backup CIAs & Saves. Unlike Option (A), the cias (proper)_<ID0> output folder is left alone. You can keep copies of those backed up CIAs on your computer. If your SD card has less free space than the total amount of all the CIAs, use:

Option (C) - Manual
In case your SD card does not have 4 GB of free space, or you already have all your games, DLCs, and updates previously backed up as CIAs, this option requires your due diligence supplying a 1-to-1 collection of CIAs for all the titles installed in the Nintendo 3DS folder. A simple installed_titles_list.txt can be cross referenced by TitleIDs against those found at:

The original ticket.db is restored to keep the user's real tickets in place.

The saves are individually restored depending if the parent games were found to be reinstalled.

A minimum 512 MB of free space is required when backing up the saves. Unlike Option (B), you're not tasked to do anything outside of the script. The title folder will be left as-is once the saves are copied. The two (2) DB files do not necessarily have to bad. While not recommended compared to Checkpoint or JKSM, you can use (1c) Backup Saves to extract copies of your (decrypted) saves. On a different 3DS system with a cloned SD setup, you can use the (2c) Restore Saves (with minor naming adjustments to saves_<ID0> folder) if you intend to import over the saves.Just make sure you remove theticket.dbout of saves_<ID0> if the saves are going on a different system!!

Remapping the Rosalina menu button combo.
If your 3DS system has broken buttons where the default { (L)-shoulder + (DOWN) d-pad + (SELECT) } can't be used, the combo can be remapped with one of these choices:

(L)-shoulder

(R)-shoulder

(Y)

(X)

(START)

(SELECT)

(UP) d-pad

(DOWN) d-pad

Once you can gain access to Rosalina menu, change the combo preference:

Bypassing the new user profile setup.
3DS systems that have broken 3D slider switch will get stuck at the 3D Screen Check after performing a system reformat.

System Settings → Other Settings → Format System Memory

Those who have hacked their o2DS by following outdated 2.1.0 CTRTransfer downgrade guides may also get theirs stuck at that screen, albeit with a distorted appearance.

This pitfall scenario can be skipped with this script. Once HOME Menu is reached, filling out personal information and user agreements is still mandatory for access to online services and system updates.

Looking up the Parental Controls PIN number.
Did you forget the four-digit password to the Parental Controls? Did you receive or purchase a 3DS system that the previous owner didn't unlock? No problem!

For "best" case brick scenarios where nothing is missing, this script will only replace import.db, title.db, and title folder.

In the 1:/ drive, only data, dbs, fastboot3ds, fixdata, private, ro, rw, ticket, title, tmp,__journal.nn_, and boot.firm will be backed up. Everything else will be overwritten/deleted.

The user's original ticket.db is kept in place so that personal legit tickets can still be individually dumped if the user chooses to do so later.

GodMode9 does not appear to recognize personal legit tickets installed on a different or replacement ticket.db.

However, universal legit tickets like system titles can be installed on any ticket.db and still be recognized by GodMode9 .

Due to the two bulletin points above, this is the reason why Homebrew Launcher is injected in Nintendo 3DS Camera in order to install those system tickets in a round about way.

With that said, this script isn't appropriate for those region changing the firmware with broken shoulder buttons and broken cameras.

Anyone examining the script's code might be baffled as to why certain sections may seem very redundant. Let's just say trial and error has made this deliberately overprotective as possible.

This script wasn't made with speed in mind. Besides, repairing a firmware softbrick isn't a race. Much of the script has comments with pauses so anyone using the script can know what's going on at a given moment.

While I hope this script finds good use to those who may need it, I also wish that no one finds himself or herself of having to do so in the first place. But, shit happens.

TL;DR - Basically, CTRTransfer is like a universal SysNAND image used for recovering from softbricks and region changing the firmware.
If you're familiar with computer operating systems, this is similar to Windows Recovery and Mac Time Machine (?).

***

What is this?
This is a gm9 script for performing a variation of Decrypt9 CTRTransfer. Homebrew 3DS users are likely to be more familiar with standard or (built-in) GodMode9 CTRTransfer. While both types are used for repairing or region changing the 3DS firmware, there are stark differences in how they go about changing or correcting the CTRNAND.

Decrypt9 Method

A few console unique files such as the movable.sed, configsave.bin, LocalFriendCodeSeed_B, and SecureInfo_A/B are first extracted from the CTRNAND drive. Afterwards, Decrypt9 (the program) flashes the entire raw donor CTRNAND *.bin image file onto the CTRNAND partition. Those backed up files are moved back in the drive to their respective locations and CMAC hash corrections are done throughout such as for the *.db datebase files and user's extdata + sysdata.

GodMode9 Method

GodMode9 (the program) selectively replaces only the titles folder and *.db files. This is to surgically fix the broken system apps while keeping the rest of the user's personal and console unique files intact. Once these folders and files are replaced as needed, this is followed by CMAC hash corrections for those *.db files.

To put this into a comparable life analogy of the two, GM9 CTRTransfer is like replacing worn houseware parts, patching holes for stone walls to a structurally sound but very old house, and renovating its dainty decorations, flooring, and walls. D9 CTRTransfer is like removing your furnishings and personal belongs out of the house, knocking that house down because it's deemed too decrepit, building a replica in its place, and then moving as much of your stuff back in, assuming you haven't forgotten leaving behind anything before the teardown.

GodMode9 is the safer and less intrusive of the two while fixing most general softbricks. Although Decrypt9 is arguably more effective at dealing with severe softbricks, the older app's implementation fails to back up and restore crucial files such as hardware calibration HWCAL0.DAt and HWCAL1.DAt, personal legit tickets, and [seed|nag|friend|nnid|etc.]save.bin.

With those differences in mind, this script was created with the goal of combining the Decrypt9 approach of flashing a clean slate CTRNAND drive while also maintaining as much of the user's original setup like that of GodMode9.

Bricks that this can fix.

Files and folders that are partially or fully deleted off the [1:] SYSNAND CTRNAND.

For whatever reason, the 3DS or 2DS system you have had its setup accidentally erased. Perhaps you bought/received yours prehacked from a previous owner who was neglectful. As long as something called the essential.exefs is present and has not been tampered with, it's possible to create a fresh firmware setup.

Let's imagine you experienced a catastrophic softbrick which required remedying the issue by restoring the SysNAND with a personal image backup. However, luck would have it that the one and only SysNAND *.bin image you kept was trashed by an unknowingly fake SD card. To add further insult to injury, during your restoration of the corrupted image, your system has a very old and untrustworthy battery that dies on you during mid-restore. This incident bricks the CTRNAND partition where GodMode9 doesn't even acknowledge the presence of the drive. Again, this is recoverable so long as the essential.exefs is present and hasn't been tampered with.

Strange '?' files that are stubbornly stuck in CTRNAND or cannot be deleted/replaced by conventional means.

Despite H2testw checking the SD card for issues, updating the custom firmware & 3DS firmware, and troubleshooting for any and all hardware issues, your system has unexplainable boot issues, poor GUI functionality, or random crashes. You (surprise, surprise!) don't have the benefit of a clean, backed up SysNAND *.bin image to recovery from. Attempts at using standard CTRTransfer are not providing favorable results. You may very well have a broken file allocation table at hand. If those damaged files are limited to replaceable or non-unique items, this script will try maintaining anything that's salvageable.

During script run,do not press and hold the (B) buttonwhen the DSiWare games are being dumped and especially for the system tickets.

These are the two sections I could not idiot proof. If you try to cancel building a DSiWare CIA, it'll ask you to try again with the choice to cancel. For the system tickets, the script will fail to completely mount ticket.db.

If region changing the 3DS firmware and there are no system titles shown in HOME Menu, launch the camera applet → Nintendo 3DS Camera → Homebrew Launcher.

* March-12, 2019: At the time of writing this, the hacks.guide has/had outdated CIAs for the Old 3DS TWL_FIRM and New 3DS TWL_FIRM.

For firmware 11.9.0-42, the TWL_FIRM should be:

0004013800000102

Old_3DS TWL_FIRM

Version: 10864 (10.39.0)

Product Code: CTR-P-CTAP

0004013820000102

New_3DS TWL_FIRM

Version: 10962 (10.45.2)

Product Code: CTR-P-CTAP

FBI errors 0xD8E08066 and 0xD8E0806C

0xD8E08066 - The system tickets may fail to install due to something called the certs.db (certificates). Your setup at one point either corrupted it or erased & regenerated that file with a dummy nonfunctional copy. A replacement copy borrowed from the CTRTransfer image would then be required. The script can replace that file if you come across this issue. Do not use this option if the problem doesn't exist;certs.dbis partially involved with transiting 3DS online play.

0xD8E0806C - The backed up DSiWare titles may fail to install. This is likely to occur if the CTRTransfer was used to region change the firmware. To fix this, install a different DSiWare *.cia file that's not from that backed up set. I have no clue why this hiccup occurs...

Additional Feature: finding and restoring the KeyY.
If you have the Nintendo 3DS folder backed up from a previous profile that was removed from (1) Format System Memory and (2) NOT involved in a System Transfer, this script can brute force up to 256 iterations finding the lost KeyY in the movable.sed linked to a specific <ID0> subfolder. To read more how this works,

Assuming the rest of the KeyY string is correct, finding the 0x118 hex counter that matches the target <ID0> can take up to 1.5 hour to complete or as little as 1 minute. This depends on the search order (this script looks backwards, ex: 03 → 02) versus value of the "correct" hex counter relative to the starting search value (ex, "correct" value is 04 but script is looking backwards, which will take a long time to find and calculate).

Some details of this script, what it does, and why. Ending comment.

For "best" case brick scenarios where nothing is missing, this script will only replace import.db, title.db, and titles folder.

The user's original ticket.db is kept in place so that personal legit tickets can still be individually dumped if the user chooses to do so later.

GodMode9 does not appear to recognize personal legit tickets installed on a different or replacement ticket.db.

However, universal legit tickets like system titles can be installed on any ticket.db and still be recognized by GodMode9 .

Due to the two bulletin points above, this is the reason why Homebrew Launcher is injected in Nintendo 3DS Camera in order to install those system tickets in a round about way.

With that said, this script isn't appropriate for those region changing the firmware with broken shoulder buttons and broken cameras.

Anyone examining the script's code might be baffled why certain sections may seem very redundant. Let's just say trial and error has made this deliberately overprotective as possible.

This script wasn't made with speed in mind. Besides, repairing a firmware softbrick isn't a race. Much of the script has comments with pauses so anyone using the script can know what's going on at a given moment.

While I hope this script finds good use to those who may need it, I also wish that no one finds himself or herself of having to in the first place. But, shit happens.

TL;DR - Basically, CTRTransfer is like a universal SysNAND image used for recovering from softbricks and region changing the firmware.
If you're familiar with computer operating systems, this is similar to Windows Recovery and Mac Time Machine (?).

***

What is this?
This is a gm9 script for performing a variation of Decrypt9 CTRTransfer. Homebrew 3DS users are likely to be more familiar with standard or (built-in) GodMode9 CTRTransfer. While both types are used for repairing or region changing the 3DS firmware, there are stark differences in how they go about changing or correcting the CTRNAND.

Decrypt9 Method

A few console unique files such as the movable.sed, configsave.bin, LocalFriendCodeSeed_B, and SecureInfo_A/B are first extracted from the CTRNAND drive. Afterwards, Decrypt9 (the program) flashes the entire raw donor CTRNAND *.bin image file onto the CTRNAND partition. Those backed up files are moved back in the drive to their respective locations and CMAC hash corrections are done throughout such as for the *.db datebase files and user's extdata + sysdata.

GodMode9 Method

GodMode9 (the program) selectively replaces only the titles folder and *.db files. This is to surgically fix the broken system apps while keeping the rest of the user's personal and console unique files intact. Once these folders and files are replaced as needed, this is followed by CMAC hash corrections for those *.db files.

To put this into a comparable life analogy of the two, GM9 CTRTransfer is like replacing worn houseware parts, patching holes for stone walls to a structurally sound but very old house, and renovating its dainty decorations, flooring, and walls. D9 CTRTransfer is like removing your furnishings and personal belongs out of the house, knocking that house down because it's deemed too decrepit, building a replica in its place, and then moving as much of your stuff back in, assuming you haven't forgotten leaving behind anything before the teardown.

GodMode9 is the safer and less intrusive of the two while fixing most general softbricks. Although Decrypt9 is arguably more effective at dealing with severe softbricks, the older app's implementation fails to back up and restore crucial files such as hardware calibration HWCAL0.DAt and HWCAL1.DAt, personal legit tickets, and [seed|nag|friend|nnid|etc.]save.bin.

With those differences in mind, this script was created with the goal of combining the Decrypt9 approach of flashing a clean slate CTRNAND drive while also maintaining as much of the user's original setup like that of GodMode9.

Bricks that this can fix.

Files and folders that are partially or fully deleted off the [1:] SYSNAND CTRNAND.

For whatever reason, the 3DS or 2DS system you have had its setup accidentally erased. Perhaps you bought/received yours prehacked from a previous owner who was neglectful. As long as something called the essential.exefs is present and has not been tampered with, it's possible to create a fresh firmware setup.

Let's imagine you experienced a catastrophic softbrick which required remedying the issue by restoring the SysNAND with a personal image backup. However, luck would have it that the one and only SysNAND *.bin image you kept was trashed by an unknowingly fake SD card. To add further insult to injury, during your restoration of the corrupted image, your system has a very old and untrustworthy battery that dies on you during mid-restore. This incident bricks the CTRNAND partition where GodMode9 doesn't even acknowledge the presence of the drive. Again, this is recoverable so long as the essential.exefs is present and hasn't been tampered with.

Strange '?' files that are stubbornly stuck in CTRNAND or cannot be deleted/replaced by conventional means.

Despite H2testw checking the SD card for issues, updating the custom firmware & 3DS firmware, and troubleshooting for any and all hardware issues, your system has unexplainable boot issues, poor GUI functionality, or random crashes. You (surprise, surprise!) don't have the benefit of a clean, backed up SysNAND *.bin image to recovery from. Attempts at using standard CTRTransfer are not providing favorable results. You may very well have a broken file allocation table at hand. If those damaged files are limited to replaceable or non-unique items, this script will try maintaining anything that's salvageable.

During script run,do not press and hold the (B) buttonwhen the DSiWare games are being dumped and especially for the system tickets.

These are the two sections I could not idiot proof. If you try to cancel building a DSiWare CIA, it'll ask you to try again with the choice to cancel. For the system tickets, the script will fail to completely mount ticket.db.

If region changing the 3DS firmware and there are no system titles shown in HOME Menu, launch the camera applet → Nintendo 3DS Camera → Homebrew Launcher.

* March-12, 2019: At the time of writing this, the hacks.guide has/had outdated CIAs for the Old 3DS TWL_FIRM and New 3DS TWL_FIRM.

For firmware 11.9.0-42, the TWL_FIRM should be:

0004013800000102

Old_3DS TWL_FIRM

Version: 10864 (10.39.0)

Product Code: CTR-P-CTAP

0004013820000102

New_3DS TWL_FIRM

Version: 10962 (10.45.2)

Product Code: CTR-P-CTAP

FBI errors 0xD8E08066 and 0xD8E0806C

0xD8E08066 - The system tickets may fail to install due to something called the certs.db (certificates). Your setup at one point either corrupted it or erased & regenerated that file with a dummy nonfunctional copy. A replacement copy borrowed from the CTRTransfer image would then be required. The script can replace that file if you come across this issue. Do not use this option if the problem doesn't exist;certs.dbis partially involved with transiting 3DS online play.

0xD8E0806C - The backed up DSiWare titles may fail to install. This is likely to occur if the CTRTransfer was used to region change the firmware. To fix this, install a different DSiWare *.cia file that's not from that backed up set. I have no clue why this hiccup occurs...

Additional Feature: finding and restoring the KeyY.
If you have the Nintendo 3DS folder backed up from a previous profile that was removed from (1) Format System Memory and (2) NOT involved in a System Transfer, this script can brute force up to 256 iterations finding the lost KeyY in the movable.sed linked to a specific <ID0> subfolder. To read more how this works,

Assuming the rest of the KeyY string is correct, finding the 0x118 hex counter that matches the target <ID0> can take up to 1.5 hour to complete or as little as 1 minute. This depends on the search order (this script looks backwards, ex: 03 → 02) versus value of the "correct" hex counter relative to the starting search value (ex, "correct" value is 04 but script is looking backwards, which will take a long time to find and calculate).

Some details of this script, what it does, and why. Ending comment.

For "best" case brick scenarios where nothing is missing, this script will only replace import.db, title.db, and titles folder.

In the 1:/ drive, only data, dbs, fastboot3ds, fixdata, private, ro, rw, ticket, title, tmp,__journal.nn_, and boot.firm will be backed up. Everything else will be overwritten/deleted.

The user's original ticket.db is kept in place so that personal legit tickets can still be individually dumped if the user chooses to do so later.

GodMode9 does not appear to recognize personal legit tickets installed on a different or replacement ticket.db.

However, universal legit tickets like system titles can be installed on any ticket.db and still be recognized by GodMode9 .

Due to the two bulletin points above, this is the reason why Homebrew Launcher is injected in Nintendo 3DS Camera in order to install those system tickets in a round about way.

With that said, this script isn't appropriate for those region changing the firmware with broken shoulder buttons and broken cameras.

Anyone examining the script's code might be baffled as to why certain sections may seem very redundant. Let's just say trial and error has made this deliberately overprotective as possible.

This script wasn't made with speed in mind. Besides, repairing a firmware softbrick isn't a race. Much of the script has comments with pauses so anyone using the script can know what's going on at a given moment.

While I hope this script finds good use to those who may need it, I also wish that no one finds himself or herself of having to do so in the first place. But, shit happens.

Click to expand...

glad to be your test monkey XD

EDIT: So what can i do with this new software now? I managed to install it and now i want to know what else it's capable of... I read your WHOLE thread and want to know what else it can do... can it MCU unbrick my ds mode

Member

EDIT: So what can i do with this new software now? I managed to install it and now i want to know what else it's capable of... I read your WHOLE thread and want to know what else it can do... can it MCU unbrick my ds mode

Click to expand...

To be clear, the script is technically an add-on to the actual software, GodMode9. Because you already attempted a specialized form of (CTR+TWL)Transfer that's closely related to D9 CTRTransfer, this script won't fix your very strange DS(i) mode brick. As was explained in PM, MCU bricks (if assuming yours is MCU related) is for all intents and purposes, permanent and not fixable.

TL;DR - Basically, CTRTransfer is like a universal SysNAND image used for recovering from softbricks and region changing the firmware.
If you're familiar with computer operating systems, this is similar to Windows Recovery and Mac Time Machine (?).

***

What is this?
This is a gm9 script for performing a variation of Decrypt9 CTRTransfer. Homebrew 3DS users are likely to be more familiar with standard or (built-in) GodMode9 CTRTransfer. While both types are used for repairing or region changing the 3DS firmware, there are stark differences in how they go about changing or correcting the CTRNAND.

Decrypt9 Method

A few console unique files such as the movable.sed, configsave.bin, LocalFriendCodeSeed_B, and SecureInfo_A/B are first extracted from the CTRNAND drive. Afterwards, Decrypt9 (the program) flashes the entire raw donor CTRNAND *.bin image file onto the CTRNAND partition. Those backed up files are moved back in the drive to their respective locations and CMAC hash corrections are done throughout such as for the *.db datebase files and user's extdata + sysdata.

GodMode9 Method

GodMode9 (the program) selectively replaces only the titles folder and *.db files. This is to surgically fix the broken system apps while keeping the rest of the user's personal and console unique files intact. Once these folders and files are replaced as needed, this is followed by CMAC hash corrections for those *.db files.

To put this into a comparable life analogy of the two, GM9 CTRTransfer is like replacing worn houseware parts, patching holes for stone walls to a structurally sound but very old house, and renovating its dainty decorations, flooring, and walls. D9 CTRTransfer is like removing your furnishings and personal belongs out of the house, knocking that house down because it's deemed too decrepit, building a replica in its place, and then moving as much of your stuff back in, assuming you haven't forgotten leaving behind anything before the teardown.

GodMode9 is the safer and less intrusive of the two while fixing most general softbricks. Although Decrypt9 is arguably more effective at dealing with severe softbricks, the older app's implementation fails to back up and restore crucial files such as hardware calibration HWCAL0.DAt and HWCAL1.DAt, personal legit tickets, and [seed|nag|friend|nnid|etc.]save.bin.

With those differences in mind, this script was created with the goal of combining the Decrypt9 approach of flashing a clean slate CTRNAND drive while also maintaining as much of the user's original setup like that of GodMode9.

Bricks that this can fix.

Files and folders that are partially or fully deleted off the [1:] SYSNAND CTRNAND.

For whatever reason, the 3DS or 2DS system you have had its setup accidentally erased. Perhaps you bought/received yours prehacked from a previous owner who was neglectful. As long as something called the essential.exefs is present and has not been tampered with, it's possible to create a fresh firmware setup.

Let's imagine you experienced a catastrophic softbrick which required remedying the issue by restoring the SysNAND with a personal image backup. However, luck would have it that the one and only SysNAND *.bin image you kept was trashed by an unknowingly fake SD card. To add further insult to injury, during your restoration of the corrupted image, your system has a very old and untrustworthy battery that dies on you during mid-restore. This incident bricks the CTRNAND partition where GodMode9 doesn't even acknowledge the presence of the drive. Again, this is recoverable so long as the essential.exefs is present and hasn't been tampered with.

Strange '?' files that are stubbornly stuck in CTRNAND or cannot be deleted/replaced by conventional means.

Despite H2testw checking the SD card for issues, updating the custom firmware & 3DS firmware, and troubleshooting for any and all hardware issues, your system has unexplainable boot issues, poor GUI functionality, or random crashes. You (surprise, surprise!) don't have the benefit of a clean, backed up SysNAND *.bin image to recovery from. Attempts at using standard CTRTransfer are not providing favorable results. You may very well have a broken file allocation table at hand. If those damaged files are limited to replaceable or non-unique items, this script will try maintaining anything that's salvageable.

During script run,do not press and hold the (B) buttonwhen the DSiWare games are being dumped and especially for the system tickets.

These are the two sections I could not idiot proof. If you try to cancel building a DSiWare CIA, it'll ask you to try again with the choice to cancel. For the system tickets, the script will fail to completely mount ticket.db.

If region changing the 3DS firmware and there are no system titles shown in HOME Menu, launch the camera applet → Nintendo 3DS Camera → Homebrew Launcher.

* March-12, 2019: At the time of writing this, the hacks.guide has/had outdated CIAs for the Old 3DS TWL_FIRM and New 3DS TWL_FIRM.

For firmware 11.9.0-42, the TWL_FIRM should be:

0004013800000102

Old_3DS TWL_FIRM

Version: 10864 (10.39.0)

Product Code: CTR-P-CTAP

0004013820000102

New_3DS TWL_FIRM

Version: 10962 (10.45.2)

Product Code: CTR-P-CTAP

FBI errors 0xD8E08066 and 0xD8E0806C

0xD8E08066 - The system tickets may fail to install due to something called the certs.db (certificates). Your setup at one point either corrupted it or erased & regenerated that file with a dummy nonfunctional copy. A replacement copy borrowed from the CTRTransfer image would then be required. The script can replace that file if you come across this issue. Do not use this option if the problem doesn't exist;certs.dbis partially involved with transiting 3DS online play.

0xD8E0806C - The backed up DSiWare titles may fail to install. This is likely to occur if the CTRTransfer was used to region change the firmware. To fix this, install a different DSiWare *.cia file that's not from that backed up set. I have no clue why this hiccup occurs...

Additional Feature: finding and restoring the KeyY.
If you have the Nintendo 3DS folder backed up from a previous profile that was removed from (1) Format System Memory and (2) NOT involved in a System Transfer, this script can brute force up to 256 iterations finding the lost KeyY in the movable.sed linked to a specific <ID0> subfolder. To read more how this works,

Assuming the rest of the KeyY string is correct, finding the 0x118 hex counter that matches the target <ID0> can take up to 1.5 hour to complete or as little as 1 minute. This depends on the search order (this script looks backwards, ex: 03 → 02) versus value of the "correct" hex counter relative to the starting search value (ex, "correct" value is 04 but script is looking backwards, which will take a long time to find and calculate).

Some details of this script, what it does, and why. Ending comment.

For "best" case brick scenarios where nothing is missing, this script will only replace import.db, title.db, and titles folder.

In the 1:/ drive, only data, dbs, fastboot3ds, fixdata, private, ro, rw, ticket, title, tmp,__journal.nn_, and boot.firm will be backed up. Everything else will be overwritten/deleted.

The user's original ticket.db is kept in place so that personal legit tickets can still be individually dumped if the user chooses to do so later.

GodMode9 does not appear to recognize personal legit tickets installed on a different or replacement ticket.db.

However, universal legit tickets like system titles can be installed on any ticket.db and still be recognized by GodMode9 .

Due to the two bulletin points above, this is the reason why Homebrew Launcher is injected in Nintendo 3DS Camera in order to install those system tickets in a round about way.

With that said, this script isn't appropriate for those region changing the firmware with broken shoulder buttons and broken cameras.

Anyone examining the script's code might be baffled as to why certain sections may seem very redundant. Let's just say trial and error has made this deliberately overprotective as possible.

This script wasn't made with speed in mind. Besides, repairing a firmware softbrick isn't a race. Much of the script has comments with pauses so anyone using the script can know what's going on at a given moment.

While I hope this script finds good use to those who may need it, I also wish that no one finds himself or herself of having to do so in the first place. But, shit happens.

Click to expand...

Almost two days late, but...

Quantumcat said:

Very impressive, nice work!!

Click to expand...

I tried my best to understand all the technicalities. The fact I think I did so with most shows the write-up (your nightmare) was a success. So,

Every so often, the official Pokemon Kids TV YouTube channel will upload cute animations featuring various Pokemon in cartoon shorts, geared towards younger audiences in Japan. This time, their latest...

Electronic Arts continues to bring their games and services to Steam, following the publisher making an announcement last year where they said select titles would no longer be exclusive to their own...

After nearly a year in court, an Australian court case against Sony Interactive Entertainment Network Europe has wrapped up and come to a conclusion. The Australian Competition & Consumer Commission...