-
Notifications
You must be signed in to change notification settings - Fork 33
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Cleanup + made it clear to not use this with sysNAND Gateway mode.
- Loading branch information
Showing
3 changed files
with
6 additions
and
6 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
76a37c8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I know this is not the same as the private CIA I have. When I tested this, I did NOT use the private CIA. I did everything with sysupdater. The issue is, that there's nothing particularly special about the private CIA I was given to test.
All it does is execute the AM:InstallFirm service and this works for me even in Gateway mode. (this just isn't the ideal method of doing this, because I have to use Devmen to install the update CIAs, then exit out of that and start that homebrew CIA separately)
The fact that this one doesn't work for me in Gateway mode means that it isn't doing something right. If it works in PBT CFW, that's odd. I wonder why it wouldn't work in Gateway mode if this supposedly does AM:InstallFirm as well. There's probably something wrong with how it's built or something. But if that's not what this was intended for then I understand. I was simply testing this. :P
Also, daxtsu (the guy who had given me that unreleased homebrew that does AM:InstallFirm had supposedly fixed your homebrew to work with Gateway mode. From what he told me it was an issue with
something in ctrulib.
Here's a quote of what he said to me:
"I rebuilt profi's sysupdater to use the old InstallNativeFIRM command with the proper titleID instead of the newer ctrulib one".
I do have the modified version of this he gave me, but I have not had a chance to test it. He didn't provide the modified source code however, so it probably wouldn't be much use to you.
Sounds like yours just uses the wrong titleID for NATIVE_FIRM? Not sure, I don't personally know the details on the exact machanics of how these homebrew work besides the "It uses AM:InstallFirm" stuff. :P
76a37c8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AM_installFIRM() got replaced by AM_installNativeFirm() because the later takes no title ID and determines it automatically. In the end both do exactly the same except the later get's the title ID automatically and then internally calls the other version which takes a title ID. This saves code for determining if it runs on old or new 3DS.
I can't do something about it. Gateway must have patched the later to do nothing (I think even Nintendos uodater uses the more simple version. Laziness wins!).
76a37c8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting. I suppose one way around that is to use a separate command to retrieve the current NATIVE_FIRM title id and use that with the old command. But you don't have any plans for that right now.
Understood. None the less good work! Next I have to use this, I may use PBT CFW as the entry point instead. This will probably find the most use once Karl3DS gets released and that will be geared mostly to n3DS users. I would imagine your 3DSX build would work in Karl3DS. Since no gateway will be involved I would assume how you got it coded now will work just fine.
76a37c8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found out why it fails. It's "firmware spoofing" which breaks it. Because it loads a higher NATIVE_FIRM version the command to update the FIRM partitions will do nothing (It thinks it's already updated.).
I don't plan to do a workaround for this. It's just the wrong way to launch a higher NATIVE_FIRM version. It's useless anyway if Nintendo introduces new crypto tricks. Whoever wants, feel free to make a separate branch/fork implementing the old update command which seems to not care about versions.
76a37c8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think firmware spoofing is directly the cause (at least when it comes to why Gateway mode doesn't allow sysupdater to work). Because I did get a brick a long time ago even though I "disabled" the firmware spoof feature in Gateway to allow a CCI loaded from gateway card to prompt for and install an update. (unless their firmware spoofing isn't actually disabled? But then how does the CCI suddenly know my firmware was out of date once I disabled the firmware spoof while booting into Gateway mode?)
it's probably firmlaunching newer native firm that's doing it? If so, a lot of the available CFW are starting to incorprate that even when launching sysnand. I would think a proper workaround could be a higher priority in the future if rxTools/CakesFW/PastaCFW decide to continue using firmlaunch on sysnand. They'd have to do something similar to Palantine CFW or PastaCFW (specifically the limited 4.x MSET version) where they don't firmlaunch and instead patch what ever the current native_firm on sysnand happens to be. rxTools and CakesFW now use firmlaunch to launch 9.6 native firm (9.5 for n3DS if they have firmlaunch working for that yet) and may be doing so even when booting sysnand.
So I'm afraid more bricks will start happening if this isn't addressed properly soon. ;)
Perhaps have sysupdater refuse to boot if it detects an active native_firm newer then what it will be installing. (this means either using the older service command for firm install or not allowing the user to install any CIAs at all to prevent them from accidently bricking)
76a37c8
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's definitely launching of higher NATIVE_FIRM versions as intended which is what every Brickway based solution does now. At install, i assume, it will check the to be installed version against the currently running version. If the running version is >= the installed version on NAND ---> skip installing it. The kernel and FIRM versions are globally visible for all apps and every app can read them.