Hacking Any way of deleting cfw?

[ibroxgaz]

I installed cfw using R4i 3DS Gold card, Is there anyway of returning the n3ds xl to ofw with no traces of fbi ,luma etc, As I want to trade it in for psvr thank you for any help.

 

[Quantumcat]

I installed cfw using R4i 3DS Gold card, Is there anyway of returning the n3ds xl to ofw with no traces of fbi ,luma etc, As I want to trade it in for psvr thank you for any help.

Follow https://3ds.guide/uninstall-b9s and don't skip the safety checks.

 

[ibroxgaz]

Follow https://3ds.guide/uninstall-b9s and don't skip the safety checks.

Thanks for the help links saying page not found.

 

[hiroakihsu]

Follow https://3ds.guide/uninstall-b9s and don't skip the safety checks.

@ibroxgaz That seems to be the wrong link...Should be https://3ds.hacks.guide/uninstall-cfw

 

[Quantumcat]

@ibroxgaz That seems to be the wrong link...Should be https://3ds.hacks.guide/uninstall-cfw

Oops thank you!

 

[ibroxgaz]

Ok thanks all I will give it a go.

 

[Kwyjor]

Apparently the uninstall process still leaves traces behind, but they will be undetectable to the typical end-user.

(I've never been entirely clear on just what those traces are and how you would detect them.)

 

[KleinesSinchen]

Apparently the uninstall process still leaves traces behind, but they will be undetectable to the typical end-user.

(I've never been entirely clear on just what those traces are and how you would detect them.)

• (If not using factory reset after uninstalling CFW: Activity log showing homebrew titles)
  
• GodMode9 embedded backup "essentials.exefs"
• Deleted files are not overwritten – you could find traces of Section VI of the finalizing setup when scanning a CTRNAND image with data recovery software.

 

[ibroxgaz]

Well @hiroakihsu and @Quantumcat following that guide worked, Trying out the psvr that I traded the 3ds for cheers.

 

[Kwyjor]

GodMode9 embedded backup "essentials.exefs"

Does that get copied to the NAND itself? I thought it was only embedded in NAND backups at the time when the NAND backup is created.

 

[KleinesSinchen]

Does that get copied to the NAND itself? I thought it was only embedded in NAND backups at the time when the NAND backup is created.

It is written to the NAND. When running GodMode9 for the first time on a console, the user is asked if they want to embed it. After that it is found in [S:] SYSNAND VIRTUAL/essentials.exefs



From arm9/source/godmode.c (v1.8.0)

    // check for embedded essential backup
    if (((entrypoint == ENTRY_NANDBOOT) || (entrypoint == ENTRY_B9S)) &&
        !PathExist("S:/essential.exefs") && CheckGenuineNandNcsd() &&
        ShowPrompt(true, "Essential files backup not found.\nCreate one now?")) {
        if (EmbedEssentialBackup("S:/nand.bin") == 0) {
            u32 flags = BUILD_PATH | SKIP_ALL;
            PathCopy(OUTPUT_PATH, "S:/essential.exefs", &flags);
            ShowPrompt(false, "Backup embedded in SysNAND\nand written to " OUTPUT_PATH ".");
        }
    }

 

[Kwyjor]

It is written to the NAND. When running GodMode9 for the first time on a console, the user is asked if they want to embed it. After that it is found in [S:] SYSNAND VIRTUAL/essentials.exefs

Well, gee. I thought that GM9 wouldn't write to the NAND at all without repeated, explicit warnings. What is even the purpose of doing that instead of only embedding it in the backups?

 

[Quantumcat]

Well, gee. I thought that GM9 wouldn't write to the NAND at all without repeated, explicit warnings. What is even the purpose of doing that instead of only embedding it in the backups?

It gives you warnings when you are doing something that could cause damage to your console - the whole point of GodMode9 is to write to and read from your NAND.

 

[TurdPooCharger]

Well, gee. I thought that GM9 wouldn't write to the NAND at all without repeated, explicit warnings. What is even the purpose of doing that instead of only embedding it in the backups?

Because lots of people don't backup their SysNAND *.bin images, softbrick their 3DS firmware from really dumb modifications, and then trash their systems that are otherwise perfectly fine hardware wise. Having that essential.exefs flashed to the NAND makes all the difference from rebuilding & keeping your with console unique files or recovering with less than ideal setup borrowing a donor NAND through Lazarus3DS.

 

[KleinesSinchen]

Because lots of people don't backup their SysNAND *.bin images, softbrick their 3DS firmware from really dumb modifications, and then trash their systems that are otherwise perfectly fine hardware wise. Having that essential.exefs flashed to the NAND makes all the difference from rebuilding & keeping your with console unique files or recovering with less than ideal setup borrowing a donor NAND through Lazarus3DS.

Yes. It happens. I remember this example where the embedded backup helped:
https://gbatemp.net/threads/movable-used-replacement.542930/

 

[Kwyjor]

Because lots of people don't backup their SysNAND *.bin images, softbrick their 3DS firmware from really dumb modifications, and then trash their systems that are otherwise perfectly fine hardware wise. Having that essential.exefs flashed to the NAND makes all the difference from rebuilding & keeping your with console unique files or recovering with less than ideal setup borrowing a donor NAND through Lazarus3DS.

I agree it makes complete sense to have essential.exefs embedded in a NAND backup, but why doesn't GM9 just copy essential.exefs to the NAND backup after the NAND backup is made, instead of permanently writing it to the NAND itself? I would have thought that anytime you'd be in a position where you couldn't just re-generate essential.exefs, you wouldn't be in a position to copy anything from the NAND either. And generating essential.exefs only takes a tiny fraction of the amount of time it takes to make the backup. Just wondering if I'm missing something here.

It gives you warnings when you are doing something that could cause damage to your console - the whole point of GodMode9 is to write to and read from your NAND.

Doesn't it require permission if you subsequently try to delete essential.exefs, even if that's not something that could cause damage?

 

[TurdPooCharger]

I agree it makes complete sense to have essential.exefs embedded in a NAND backup, but why doesn't GM9 just copy essential.exefs to the NAND backup after the NAND backup is made, instead of permanently writing it to the NAND itself? I would have thought that anytime you'd be in a position where you couldn't just re-generate essential.exefs, you wouldn't be in a position to copy anything from the NAND either. And generating essential.exefs only takes a tiny fraction of the amount of time it takes to make the backup. Just wondering if I'm missing something here.

Doesn't it require permission if you subsequently try to delete essential.exefs, even if that's not something that could cause damage?

I think you misread the purpose of the essential.exefs. The reason why this specific file (or rather collection of files) is flashed to the onboard NAND upon the first time launching GodMode9 is that @d0k3 had the foresight to understand people were going to softbrick their systems and fail to heed the advice about backing up a SysNAND *.bin image. I don't know if you know this, but there are so many first timers who don't complete the Finalizing Setup due to laziness, (willful) ignorance of their importance, or skipped out on due to following outdated video guides that don't cover it. This was a lesson most likely learned and observed in the days of A9LH and Decrypt9 when people played it fast and loose hacking their 3DS firmware with little regard to preserving their original files.

If a 3DS user ever softbricks their 3DS firmware to the point their CTRNAND partition was erased of everything or rendered unreadable AND they never made a SysNAND *.bin image to fall back on, that essential.exefs (chilling offside somewhere else on the NAND) serves as a final safety net in being able to restore console unique files that are considered irreplaceable. Basically, essential.exefs was an attempt to make 3DS custom firmware as idiot resistant as possible in terms of permanent softbricking.

***

If you look in the NANDManager.gm9 script, the <date>_<serial>_sysnand_###.bin is just the renamed, raw dump nand_minsize.bin from the [S:] SYSNAND VIRTUAL.

@nmopt_X_Backup_SysNAND
# SysNAND backup GM9 script
# This will create a backup named [SERIAL]_nandmin_???.bin
# author: d0k3
set ERRORMSG "SysNAND backup failed"
set SUCCESSMSG "SysNAND backup success"
if ask "Create a SysNAND backup in $[GM9OUT]?"
    findnot $[GM9OUT]/$[DATESTAMP]_$[SERIAL]_sysnand_???.bin OUTPATH
    cp -h S:/nand_minsize.bin $[OUTPATH]
    echo "Backup created succesfully:\n$[OUTPATH]"
end
goto nm_menu

The essential.exefs gets included like all the other files or partitions, except for bonus.bin which gets left out as apparently it does not contain anything of significance (aka, free space).

 

[Ryccardo]

I would have thought that anytime you'd be in a position where you couldn't just re-generate essential.exefs, you wouldn't be in a position to copy anything from the NAND either.

It's true that with ntrboot you can always have the console calculate your nand keys even if you completely blanked the nand without backups - but the essential backup predates that