Hacking NTRPack: PC-less b9s install using ntrboot

[Quantumcat]

Maybe for this. You won't for mine. Godmode9 can chainload. So there's really no need to have NTRBootHax launch a separate payload. Actually, there's no need to have Godmode chainload another app, either. Godmode9 can install B9S itself if you know how to code the script to do it safely. I've actually got installing B9S, copying Luma to CTRNAND, and copying the files to the RAM drive being done by the same script now.

Don't advertise your own stuff on someone else's thread. That's just rude.

 

[Kazuma77]

Don't advertise your own stuff on someone else's thread. That's just rude.

Who's advertising? Did I give a name or link to something? I'm just saying, you can have Godmode9 chainload Safe B9S Installer. But there's no need, because you can have Godmode9 do everything Safe B9S Installer does via the "verify" "sha" and "cp" commands. I'm just being open and sharing what I've discovered to try to help. CyberQuake can implement it or not. But the more complicated he leaves it, the less people are going to want to use it. And how many competitors do you know of that show their hand? I'm being more than generous.

 

[TheCyberQuake]

Who's advertising? Did I give a name or link to something? I'm just saying, you can have Godmode9 chainload Safe B9S Installer. But there's no need, because you can have Godmode9 do everything Safe B9S Installer does via the "verify" "sha" and "cp" commands. I'm just being open and sharing what I've discovered to try to help. CyberQuake can implement it or not. If not, he'll get left behind for making people install custom NTRBootHax payloads and requiring extra steps when other projects do it all with only Godmode9 and two scripts, because yes, there is competition. But how many competitors do you know of that show their hand? I'm being more than generous.

I've been busy, but before I was busy installing firms hadn't made it into an official release, only the latest commits. Ive been planning on modifying my process when I'm not busy with school and work and when it makes it to an official release (haven't checked recently because again I've been busy with the school semester just starting).

 

[TheCyberQuake]

Who's advertising? Did I give a name or link to something? I'm just saying, you can have Godmode9 chainload Safe B9S Installer. But there's no need, because you can have Godmode9 do everything Safe B9S Installer does via the "verify" "sha" and "cp" commands. I'm just being open and sharing what I've discovered to try to help. CyberQuake can implement it or not. If not, he'll get left behind for making people install custom NTRBootHax payloads and requiring extra steps when other projects do it all with only Godmode9 and two scripts, because yes, there is competition. But how many competitors do you know of that show their hand? I'm being more than generous.

Plus the latest releases of godmode9 had issues with init meaning they had to be chainload with Luma to work. And those fixes have yet to be pushed to an official release. I can prepare by building myself but I don't plan on releasing until it gets pushed as an official godmode9 release. Don't want to be held accountable for any issues caused by my own build.
If there was a way to dump dspfirm.cdc (unless there is and I just don't know) I could probably get an install completed in a minute.

 

[Kazuma77]

Plus the latest releases of godmode9 had issues with init meaning they had to be chainload with Luma to work. And those fixes have yet to be pushed to an official release. I can prepare by building myself but I don't plan on releasing until it gets pushed as an official godmode9 release. Don't want to be held accountable for any issues caused by my own build.
If there was a way to dump dspfirm.cdc (unless there is and I just don't know) I could probably get an install completed in a minute.

Well, there is a dsp.mem in M: now. Since the "inject" command can create new files now, it's probably just a matter of figuring out which part of it to copy with it. The full versions of my releases are on sites that don't care, so I'm just going to include it outright, but, I'm considering having a look at it for the lite version.

EDIT: Well, none of my searches turned up any matching data, so, apparently it's not in that file. But it has to be somewhere, I would think.

 

[TheCyberQuake]

Well, there is a dsp.mem in M: now. Since the "inject" command can create new files now, it's probably just a matter of figuring out which part of it to copy with it. The full versions of my releases are on sites that don't care, so I'm just going to include it outright, but, I'm considering having a look at it for the lite version.

I've already been looking at dsp.mem but couldn't figure out if or how to turn it into the cdc file. I may take a look into again later.

 

[N7Kopper]

I have to wonder, why suggest having Rosalina boot the Homebrew Launcher over Download Play? That title is actually useful sometimes. Why not the eternally useless Health and Safety instead?

 

[Quantumcat]

I have to wonder, why suggest having Rosalina boot the Homebrew Launcher over Download Play? That title is actually useful sometimes. Why not the eternally useless Health and Safety instead?

The official guide says to use it. I think it has best compatibility with all homebrew.

 

[TheCyberQuake]

Just to make an official announcement I am in fact re-working the process again. This time I'm planning on installing boot9strap from godmode9. I'm currently writing scripts and will be testing them later. If I get everything working it should be ready for release but I won't release until the build of godmode9 I am using becomes official (currently using a personally compiled version with the latest commits). The only thing I want to do after that is figure out if there is a way to get dspfirm.cdc from godmode9. If that could happen I could probably get the install process down to a minute and just two scripts.
Otherwise I will have to continue to use 3 scripts and booting DSP1 as boot.3dsx first.

 

[Khim09]

Just to make an official announcement I am in fact re-working the process again. This time I'm planning on installing boot9strap from godmode9. I'm currently writing scripts and will be testing them later. If I get everything working it should be ready for release but I won't release until the build of godmode9 I am using becomes official (currently using a personally compiled version with the latest commits). The only thing I want to do after that is figure out if there is a way to get dspfirm.cdc from godmode9. If that could happen I could probably get the install process down to a minute and just two scripts.
Otherwise I will have to continue to use 3 scripts and booting DSP1 as boot.3dsx first.

But I am already used to your old guide..

Sent from my SM-G955F using Tapatalk

 

[TheCyberQuake]

But I am already used to your old guide..

Sent from my SM-G955F using Tapatalk

Not a whole lot has changed. In fact it's pretty much the same right now except you chop off the first few steps that involve booting into safeb9sinstaller. everything else is pretty much the same.

Also I pretty much have the new scripts ready, I'm just going to see if I can figure out a way to verify if the system is unhacked or had a9lh, and then refuse to install if on an a9lh system to prevent bricking.

 

[Khim09]

Not a whole lot has changed. In fact it's pretty much the same right now except you chop off the first few steps that involve booting into safeb9sinstaller. everything else is pretty much the same.

Also I pretty much have the new scripts ready, I'm just going to see if I can figure out a way to verify if the system is unhacked or had a9lh, and then refuse to install if on an a9lh system to prevent bricking.

I see, thankyou. I am looking forward to this new guide.

Sent from my SM-G955F using Tapatalk

 

[TheCyberQuake]

I figured out how to checked a modified secret sector to prevent use on an a9lh system (which would brick on either n3ds or o3ds, can't remember which). I'm also creating a few emergency repair scripts in case the boot9strap install fails from godmode9. One will attempt to copy the firm1.bin and firm0.bin backed up before the install attempted, and another two that will pull native firm from NCCH in ctrnand and use that to replace firm0 and firm1. That way you won't leave someones console as a brick until you can get to a computer if something were to go wrong.
Also I found a fork of godmode9 by @AnalogMan that adds commands for SD mounting and unmounting, meaning I can now have one script install boot9strap, copy contents from SD to ramdrive, unmount and remount then copy from ramdrive to SD. Seems it's already getting pulled for the next release.
At that point the only real change I could possibly make to make the process faster would be getting dspfirm.cdc from godmode9. Currently need two scripts, one for the setup and the finalization script to do things like removing useless files, replacing the dspfirm.cdc dumping homebrew with the standard homebrew launcher, and copying luma. But if I could dump the dspfirm from godmode9 I could put everything into a single script.
With what I currently have I've gotten it down to 2:13.

 

[Kazuma77]

I figured out how to checked a modified secret sector to prevent use on an a9lh system (which would brick on either n3ds or o3ds, can't remember which). I'm also creating a few emergency repair scripts in case the boot9strap install fails from godmode9. One will attempt to copy the firm1.bin and firm0.bin backed up before the install attempted, and another two that will pull native firm from NCCH in ctrnand and use that to replace firm0 and firm1. That way you won't leave someones console as a brick until you can get to a computer if something were to go wrong.
Also I found a fork of godmode9 by @AnalogMan that adds commands for SD mounting and unmounting, meaning I can now have one script install boot9strap, copy contents from SD to ramdrive, unmount and remount then copy from ramdrive to SD. Seems it's already getting pulled for the next release.
At that point the only real change I could possibly make to make the process faster would be getting dspfirm.cdc from godmode9. Currently need two scripts, one for the setup and the finalization script to do things like removing useless files, replacing the dspfirm.cdc dumping homebrew with the standard homebrew launcher, and copying luma. But if I could dump the dspfirm from godmode9 I could put everything into a single script.
With what I currently have I've gotten it down to 2:13.

It's N3DS. I actually use 3 scripts, atm. Two for N3DS, one for O3DS. The second N3DS one will replace the secret sector with "secret_sector.bin" if found on the card (if it passes an SHA check) instead of checking to see if it's good. Basically, if the first one fails, it tells you to run the second one, and if that one fails, it will tell you to find a "secret_sector.bin" and put it on the card. The N3DS ones also do a "find S:/sector0x96.bin NULL" to make sure GM9 has access to the proper keys. If it doesn't show up, you can't know if it's good or not, after all. The O3DS one doesn't check the secret sector at all since the O3DS doesn't use it (unless it's running A9LH). To keep this from being abused, I also implemented a hardware check by doing a "find" for the appropriate Native_FIRM. "find 1:/title/00040138/00000002/content/????????.app NULL" for the O3DS one, for example (got the idea from d0k3's scripts that restore to retail). That way it will absolutely refuse to run on an N3DS.

I don't have a release up here yet (and I'm not sure if it's worth it as much stuff as I'll have to rip out), but you can find it on a certain iso site in the "CFW Discussion" section if you'd like to take a look at my scripts. I hope that doesn't seem too much like advertising to some people, but, it's an AIO, so, different target audience for the most part. If you want to reuse any part of it, by all means, feel free.

And good find on the fork with the "unmount" command. I have it down to running two scripts, but with that, it should be possible to do everything in one.

 

[DocKlokMan]

I figured out how to checked a modified secret sector to prevent use on an a9lh system (which would brick on either n3ds or o3ds, can't remember which). I'm also creating a few emergency repair scripts in case the boot9strap install fails from godmode9. One will attempt to copy the firm1.bin and firm0.bin backed up before the install attempted, and another two that will pull native firm from NCCH in ctrnand and use that to replace firm0 and firm1. That way you won't leave someones console as a brick until you can get to a computer if something were to go wrong.
Also I found a fork of godmode9 by @AnalogMan that adds commands for SD mounting and unmounting, meaning I can now have one script install boot9strap, copy contents from SD to ramdrive, unmount and remount then copy from ramdrive to SD. Seems it's already getting pulled for the next release.
At that point the only real change I could possibly make to make the process faster would be getting dspfirm.cdc from godmode9. Currently need two scripts, one for the setup and the finalization script to do things like removing useless files, replacing the dspfirm.cdc dumping homebrew with the standard homebrew launcher, and copying luma. But if I could dump the dspfirm from godmode9 I could put everything into a single script.
With what I currently have I've gotten it down to 2:13.

@zetaPRIME is actually the one who added SD mounting/unmounting for GodMode9, I just happened to already have a fork of GodMode9 for other reasons and the code was very little so I just added it into mine. But yes, I use the same feature for my very own NTRBootHax Pack which is all done with a single script. Also, Boot9Strap kicks in before secret sector is used, so the state of secret sector does not matter when you have boot9strap installed, restoring it first is just done so that should you ever remove boot9strap your console will boot normally again. Leaving an A9LH secret sector when installing boot9strap won't brick it.

As for dspfirm, there's a feature request for LZSS decompress for .code files. With that, we may be able to use the inject command to extract a dspfirm from either the Home menu's code.bin or from the System Settings code.bin. For now though, you could just include the DSP1 cia in the package. When this CIA is run it has the option to exit and delete itself, so it only takes 2-3 seconds to run.

It's N3DS. I actually use 3 scripts, atm. Two for N3DS, one for O3DS. The second N3DS one will replace the secret sector with "secret_sector.bin" if found on the card (if it passes an SHA check) instead of checking to see if it's good. Basically, if the first one fails, it tells you to run the second one, and if that one fails, it will tell you to find a "secret_sector.bin" and put it on the card. The N3DS ones also do a "find S:/sector0x96.bin NULL" to make sure GM9 has access to the proper keys. If it doesn't show up, you can't know if it's good or not, after all. The O3DS one doesn't check the secret sector at all since the O3DS doesn't use it (unless it's running A9LH). To keep this from being abused, I also implemented a hardware check by doing a "find" for the appropriate Native_FIRM. "find 1:/title/00040138/00000002/content/????????.app NULL" for the O3DS one, for example (got the idea from d0k3's scripts that restore to retail). That way it will absolutely refuse to run on an N3DS.

I don't have a release up here yet (and I'm not sure if it's worth it as much stuff as I'll have to rip out), but you can find it on a certain iso site in the "CFW Discussion" section if you'd like to take a look at my scripts. I hope that doesn't seem too much like advertising to some people, but, it's an AIO, so, different target audience for the most part. If you want to reuse any part of it, by all means, feel free.

And good find on the fork with the "unmount" command. I have it down to running two scripts, but with that, it should be possible to do everything in one.

You don't need separate scripts, since the o3DS doesn't use secret sector in normal operation, you can just restore secret sector on both n3DS and o3DS. Also, it's not entirely needed either, since boot9strap doesn't use the secret sector. But to make it safer you can just reduce it to the one script that always restores it from a file on the SD.

 

[TheCyberQuake]

Well I already found the offsets of dsp1 within home menu code.bin, so I'm looking forward to seeing lzss decompression added to godmode9 eventually. Other than that I basically have the new process and scripts done. Down to 1 script now and a time of 2:05. After the addition of lzss decompression gets added I don't think there would be anything more I could do to improve the process.
I'll either release what I have when it gets the changes used gets added to an official release, or I my have to change the script a bit depending on if d0k3 changes the way sd unmounting/mounting is enabled or if lzss decompress gets added as well.

 

[DocKlokMan]

Well I already found the offsets of dsp1 within home menu code.bin, so I'm looking forward to seeing lzss decompression added to godmode9 eventually. Other than that I basically have the new process and scripts done. Down to 1 script now and a time of 2:05. After the addition of lzss decompression gets added I don't think there would be anything more I could do to improve the process.
I'll either release what I have when it gets the changes used gets added to an official release, or I my have to change the script a bit depending on if d0k3 changes the way sd unmounting/mounting is enabled or if lzss decompress gets added as well.

Keep in mind that the folder and offset for DSP1 will vary depending on what region the 3DS is.

 

[TheCyberQuake]

Keep in mind that the folder and offset for DSP1 will vary depending on what region the 3DS is.

Hopefully d0k3 will add some kind of script flow control in the future. It would greatly help if something like goto or if then statements were implemented. That way I could potentially use the find command to figure out which region the console is, except it would need to be edited to simply return NULL instead of aborting script. Because unless I'm missing something, there is no good way to do that with current commands unless I create separate scripts for each region.

 

[DocKlokMan]

Hopefully d0k3 will add some kind of script flow control in the future. It would greatly help if something like goto or if then statements were implemented. That way I could potentially use the find command to figure out which region the console is, except it would need to be edited to simply return NULL instead of aborting script. Because unless I'm missing something, there is no good way to do that with current commands unless I create separate scripts for each region.

The folder names for the Home Menu differ drastically but the folder names for System Setting only differ by one letter. So finding the file would be easy just by doing:

find 1:/title/00040010/0002?000 SETTINGS
find $[SETTINGS]/content/0000004d.app SETTINGS
imgmount $[SETTINGS]
find G:/exefs/code.bin CODE               # when LZSS decompression is available
inject $[CODE]@x:y 0:/3ds/dspfirm.cdc     # issue here is offsets X&Y may differ
imgumount

 

[TheCyberQuake]

The folder names for the Home Menu differ drastically but the folder names for System Setting only differ by one letter. So finding the file would be easy just by doing:

find 1:/title/00040010/0002?000 SETTINGS
find $[SETTINGS]/content/0000004d.app SETTINGS
imgmount $[SETTINGS]
find G:/exefs/code.bin CODE               # when LZSS decompression is available
inject $[CODE]@x:y 0:/3ds/dspfirm.cdc     # issue here is offsets X&Y may differ
imgumount

For USA/EUR/JPN regions apparently the .code file is identical for mset (system settings), so the offset shouldn't be different between those three regions. So at the very least I could add automatic dspfirm.cdc dumping for the three main regions before we get some kind of flow control.