Is it the same between o3DS and n3DS? The system settings on n3DS has Super Stable 3D settings which o3DS does not, so I'd expect them to be different, unless DSP1 comes before the differences in the code.bin, in which case we'd be very lucky.
Hacking NTRPack: PC-less b9s install using ntrboot
- Thread starter TheCyberQuake
- Start date
- Views 40,185
- Replies 227
- Likes 28
That's a good point. I'll be checking that in a moment.
--------------------- MERGED ---------------------------
Both n3ds and o3ds on same region have completely identical .code for system settings.
I see. I actually did that so the O3DS script would work in more situations, like the secret sector not decrypting due to a lack of keys. But since it won't break B9S not having a valid secret sector (see, that had me confused, because Safe B9S Installer requires it for systems that have A9LH installed), then I guess I could just have them all use the O3DS script with the Native_FIRM check removed. I can still have it try to replace it, with "-o -s" so that it continues either way. However, I do already include d0k3's scripts for returning to retail, along with a slightly modified copy of the N3DS one that checks and copies "secret_sector.bin" over instead of checking the original one (I still gave him full credit). So, I can just let those deal with the secret sector. I'm still going to need N3DS and O3DS options on my swap card because I include CFWs that use external firmware files. I don't want to break Cakes and Skeith after all. Though I will only need one on my same card installer now. Thank you very much. This simplifies things considerably.
I've talked to d0k3 about it. He said that "if" and "goto" are planned. So, just a matter of time.
Now that's some great news.
Last edited by Kazuma77,
As expected the sd ejection command was different on the official commit, so I've updated the script to fix that.
I also have the base code mostly done for obtaining dspfirm.cdc from godmode9. The only problem I can't really test right now is the fact that between regions the .app file has different names. On USA doing a simple find ????????.app within the correct folder pulls the right .app file (there are two for mset). Hopefully it would be the same story on other regions but can't test right now. Depending on how it works out I can either release the dspfirm version before if/goto is implemented, else I'll have to wait until after.
At this point I do have the new process and script finalized, but I'll wait until the commits used get pushed to an official release.
I also have the base code mostly done for obtaining dspfirm.cdc from godmode9. The only problem I can't really test right now is the fact that between regions the .app file has different names. On USA doing a simple find ????????.app within the correct folder pulls the right .app file (there are two for mset). Hopefully it would be the same story on other regions but can't test right now. Depending on how it works out I can either release the dspfirm version before if/goto is implemented, else I'll have to wait until after.
At this point I do have the new process and script finalized, but I'll wait until the commits used get pushed to an official release.
Actually, you could simply try to copy all 3 to $[GM9OUT] with the -o and -s options. You simply have all 3 commands name the destination .app file the same (something like "dsptemp.app" or whatever). Then just mount it, do the extraction, unmount, and delete the temporary copy.
I may have to do that with how the find command was changed in one of the most recent commits which breaks my previous beta script. I didn't want to do it that way (i have fiddled with it though) but I was trying to get it so the script wouldn't have hardcoded paths in order to allow it to work on any system version. The main issue with forcing a specific .app name is that they all change between versions. So if you encounter someone with a lower firmware or in the future an update to system settings happens, the script wouldn't work. The former could be fixed by adding every single .app name for every single version and attempt to copy all of them.
Ah, the change that makes "find" return the highest alphanumeric match. But it's good for restoring the latest backup of the firm partitions. Maybe the best thing would be to ask d0k3 to split this command into two? Leave the current one as is and add a "findlow" or something?
Last edited by Kazuma77,
I'm definately noobin right now... i'm ready to flash the firmware to the r4 but confused... am i using the .nds file from 3ds.guide? at what point do i use the alternate boot9strap_ntr? the folder structure of the sd card would be a huge help too... thanks guys
- Joined
- Nov 23, 2014
- Messages
- 15,144
- Trophies
- 0
- Location
- Canberra, Australia
- Website
- boot9strap.com
- XP
- 11,094
- Country
Use the files from the pack to flash the flashcart. So it will read ntrboot.firm instead of boot.firm.
- Joined
- Nov 23, 2014
- Messages
- 15,144
- Trophies
- 0
- Location
- Canberra, Australia
- Website
- boot9strap.com
- XP
- 11,094
- Country
You don't put the firm file in the card. That goes on your SD card. Read https://3ds.guide/ntrboot to get an idea of the process.
Well, I put in a request for you, and d0k3 did try to implement it. It just doesn't seem to work for some reason, atm. I'm thinking you might still need something like a "search" command to find the address if you really want it to work with all FW versions though. It's extremely unlikely that the offset hasn't changed a few times over the years.
EDIT: He's fixed it. So, now you can use "find -f" to return the first result. I tested it and it works. So, I hope that helps.
Not to be a total jerk or anything, but, technically you just linked to a site that's distributing copyrighted files (aeskeydb.bin and secret_sector.bin). Not that I care, but if they don't have a problem with this, then we should be able to include "dspfirm.cdc" in our packs. For that matter, I should be able to link to my full AIO, instead of having to do lite versions.
Last edited by Kazuma77,
Couldn't be bothered to go back and find it as I'm busy right now, but someone previously asked why download play was used instead of something no one uses like health & safety.
Some private beta tests have shown that DSP1 does not like to boot when being ran from h&s, but runs perfectly fine when launched from download play. And so far I've had no issues with homebrew when run from download play. So THAT is why the guide uses it, and so do I. Because after h&s it's probably the least used system app.
The only changes currently planned (Other than ones that rely on features not yet implemented in godmode9 or require additional data collection and testing to figure out) is detecting a changed secret sector, aborting if detected (meaning a previous a9lh installation) and then using a second script to update from a9lh to b9s instead of a b9s install onto a vanilla system. Could probably get that done tonight seemshow the second script is mostly the same script other than checking the sha of and copying secret_sector.bin from SD (which won't be provided but will link to the one place gbatemp seems to be okay with linking it, the holy 3ds bible)
Some private beta tests have shown that DSP1 does not like to boot when being ran from h&s, but runs perfectly fine when launched from download play. And so far I've had no issues with homebrew when run from download play. So THAT is why the guide uses it, and so do I. Because after h&s it's probably the least used system app.
The only changes currently planned (Other than ones that rely on features not yet implemented in godmode9 or require additional data collection and testing to figure out) is detecting a changed secret sector, aborting if detected (meaning a previous a9lh installation) and then using a second script to update from a9lh to b9s instead of a b9s install onto a vanilla system. Could probably get that done tonight seemshow the second script is mostly the same script other than checking the sha of and copying secret_sector.bin from SD (which won't be provided but will link to the one place gbatemp seems to be okay with linking it, the holy 3ds bible)
Well just found out that extracting decompressed .code was added to the latest commit, so time to start getting test scripts working and alpha tests started for dspfirm.cdc dumping.
Edit: Correction, you currently can't use a command to uncompress code.bin from .code. So I guess I'll be waiting some more before I can do that.
Edit: Correction, you currently can't use a command to uncompress code.bin from .code. So I guess I'll be waiting some more before I can do that.
Last edited by TheCyberQuake,
Yeah, it's really easy. I reused the basic layout of d0k3's scripts for going back to retail, actually. Very similar concept, except he's extracting NATIVE_FIRM from CTRNAND and copying it over. I would put a "find S:/sector0x96.bin NULL" on the one that will be doing the replacing to make sure it's available (it should be there for anyone using NTRBootHax, since that provides access to the keys, but it never hurts to double check).
However, since @AnalogMan has revealed (and I have confirmed this via testing) that B9S does not need a valid secret sector, I'm actually going to be removing this from my next release. Though I've made some tweaks to d0k3's scripts for returning to retail, like deleting the temporary copy of NATIVE_FIRM, and of course including an alternate version of the N3DS one with the copy option.
Sorry to hear it's still not possible. But it looks like it's getting closer to becoming a reality at least.
With the latest commit of GodMode9, here's a script to dump dspfirm.cdc:
Code:
# GodMode9 "Dump DSP"
# Dumps DSPFirm from 11.5 MSET
# last changed: 20170908
# author: AnalogMan
set SUCCESSMSG "DSPFIRM.CDC Dumped successfully"
# Find MSET title for region
set ERRORMSG "Could not find System Settings title"
find -f 1:/title/00040010/0002?000 MSET
find -f $[MSET]/content/*.app MSET
# Dumps Reverse-LZSS Decompressed .code
extrcode $[MSET] 9:/code.bin
# Extracts DSPfirm from code.bin to dspfirm.cdc
set ERRORMSG "DSPFIRM did not pass SHA check!\nIs this v11.5 firmware?"
inject 9:/code.bin@19A1C0:C25C 0:/3ds/dspfirm.cdc
sha 0:/3ds/dspfirm.cdc 8e213f3e71d2e3e45d1169bac6465a70eabeb22b303f1fa6d7679370ffad0f54I need to do a bit of data collection from EUR/JPN region consoles in order to verify if my current dspfirm script will work with other regions or if changes will need to be made in order to make it work across the three main regions. If anyone has a EUR or JPN console and wouldn't mind helping me out with data collection and testing the script shoot me a PM.
After just spending several hours researching and testing, I can conclude that with how godmode9 currently works, there is no possible way to use either find or find -f in order to properly find the correct mset .app file for dspfirm extraction.
As a remedy, I've instead opted to simply attempt a copy from set paths for each of the 3 main regions with the flags to ignore errors, and then use whatever got copied as the extraction file.
Code:
# attempt to copy mset .app from known paths
#9.6.0 - 11.5.0
cp -w -o -s 1:/title/00040010/00021000/content/0000004d.app 9:/mset.app #USA
cp -w -o -s 1:/title/00040010/00022000/content/0000003d.app 9:/mset.app #EUR
cp -w -o -s 1:/title/00040010/00020000/content/00000048.app 9:/mset.app #JPN
# Verify previous file copy, if failed unsupported region or firmware was used
find 9:/mset.app NULL
# LZSS reverse-compress .code to code.bin
extrcode 9:/mset.app 9:/code.binEdit: actually with if statements it would be easy to use find commands as well. I could just open up one of the two .app files using find -f and imgmount, checking if a .code is found, and if not proceeding to mount the other .app using find instead. It would also be possible to have differing offsets for other regions and firmwares. Though it would be even easier if d0k3 added a way to find an offset within a file by finding a hex match.
Last edited by TheCyberQuake,
Similar threads
