@d0k3 you have really outdone yourself this time. I am loving the new chainloading capabilities, especially useful with this new exploit. Not that the RTC feature isn't handy so I can tell when files were modified. I also thoroughly enjoyed seeing the "encrypt" and "decrypt" options added. Now I can setup a dedicated folder for removing seed encryption from CIAs by decrypting and re-encrypting them with a script. It might be nice if there was a "log" command, so I could see which ones actually had seed encryption, though.
I think a "run" command would go well with this new chainloading feature. That or a configurable menu for the chainloader. I'm working on a drag-and-drop method for NTRBootHax that only requires one trip to the PC. The basic concept is already complete. Use GM9 to chainload Safe B9S Installer instead of running it directly. Then use a script to copy "boot.firm.bak" (a backup copy I'll be including with my configurations in the next version of my AIO pack) to "boot.firm" and delete the temporary installation files. It would be convenient if I could have Safe B9S Installer launch from a menu instead of having to tell people to find it on the SD card and launch it. It will still work as is, it's just that it would look more polished that way.
Though a "run" command has other possibilities as well. Renaming external firmware files for CFWs that still require them, for example. You could have a script copy "firmware90.bin" to "firmware.bin" right before launching Cakes or Corbenik/Skeith with a 9.2 EmuNAND, and have another copy "firmware114.bin" to "firmware.bin" so you could easily switch to running it with your updated SysNAND.
Thanks again for all you do for the scene.
@d0k3
Do you thing you can add a9lhaxed payloads support like BootCtr9 for backwards compatibility?
It actually already has some backwards compatibility. It can run some converted payloads (using the "-e 0" command from firmtool's readme file). Gateway and EmuNAND9 work just fine. Though Puma and Salt do not (then again, even BootCTR9 doesn't run Salt). So, if you've got an old A9LH payload you're wanting to run, convert it and see what happens. It very well may run.
Not sure why that isn't already included, honestly. On the v1.2.8 release he said this:
"Now, this is the last legacy release, meaning, starting from this release, all entrypoints older than A9LH will be removed from the source code."
A9LH payloads should still be in, since they aren't older than themselves, but it seems they were thrown out, too. Maybe a mistake?
The key words there are "source code" though. And you're better off building from the source now if you want an A9LH version. He's added a new feature where you can build the keys in. No more need for aeskeydb.bin as an external file on A9LH systems. But of course, he's not going to provide the key file (at least not on Github
). So, you'll either have to build it yourself, or wait for an unintended update to an AIO pack that was supposed to be final.
And now for something completely different, that will enable you to walk into an used console store with three common household items (DS flashcard, SD, and magnet) and walk out with a confused shopkeeper and a LocalFriendCodeSeed_B
Or to get some data out of your bricked console, although if you are not in a TAS you can normally just chainload the usual GM9 from B9S-ntr with the same result
Open sorca:
https://github.com/d0k3/GodMode9/compare/master...rboninsegna:ntrboot
Nice. Actually, I am already using GM9 as my default payload with this exploit because Safe B9S Installer is a dead end. GM9 can chainload the installer, then run a script that copies your chainloader of choice to "boot.firm" once it's installed. Technically this is even better, because you can have the desired chainloader in place right from the start. Though of course, as you've already mentioned, there are many things you could do without even installing a permanent exploit.