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
# 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]"
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).