Homebrew SigHax Updates and Discussion Thread

  • Thread starter Thread starter adrifcastr
  • Start date Start date
  • Views Views 532,181
  • Replies Replies 3,813
  • Likes Likes 43
They wouldn't be patching a9lh, that's impossible, they would just be removing it from any systems it is installed on.
I can see one way around that. The devs behind a9lh would probably just change the name of the required payload and have people with a9lh re-install arm9loaderhax before updating.
 
I can see one way around that. The devs behind a9lh would probably just change the name of the required payload and have people with a9lh re-install arm9loaderhax before updating.
Queue 11.6/12.1. Alternative way of preventing a Nintonda a9lh removal, read my previous post.
 
Last edited by Deleted member 414991,
Queue the infinite loop. Who gives up first? The home-brew devs who never give up and are motivated by breaking the 3ds, or Nintendo's security team, who are motivated by money and can't patch the 3ds to save their life.
Or have luma update to patch out modifications to arm9loaderhax.bin/arm9loaderhax_si.bin while the system is on, minus arm9 payloads.
Edit: The homebrew devs are already focusing a lot on the switch.
 
What are you referring to?
You said there was an a9lh payload in CTRNAND earlier. If nintendo threw that out and the ones on the SD card, it would be pretty tricky to access CTRNAND. Godmode9 needs it to access the NAND. Luma needs it. Virtually anything that modifies NAND requires that payload.
 
You said there was an a9lh payload in CTRNAND earlier. If nintendo threw that out and the ones on the SD card, it would be pretty tricky to access CTRNAND. Godmode9 needs it to access the NAND. Luma needs it. Virtually anything that modifies NAND requires that payload.
They can remove it from ctrnand, but they would restore arm9loaderhax(_si).bin to the sd card to avoid legal trouble. If you managed to get through the update with a9lh intact, you could access your ctrnand fine. arm9loaderhax.bin on ctrnand is not required to access your nand, it just lets you boot without an sd card.
 
They can remove it from ctrnand, but they would restore arm9loaderhax(_si).bin to the sd card to avoid legal trouble. If you managed to get through the update with a9lh intact, you could access your ctrnand fine. arm9loaderhax.bin on ctrnand is not required to access your nand, it just lets you boot without an sd card.

Not even released yet talking about blocking it, how can a hardware flaw be blocked?
 
They can remove it from ctrnand, but they would restore arm9loaderhax(_si).bin to the sd card to avoid legal trouble. If you managed to get through the update with a9lh intact, you could access your ctrnand fine. arm9loaderhax.bin on ctrnand is not required to access your nand, it just lets you boot without an sd card.
They wouldn't restore it. The NAND is their property, if they were to put a modified or deleted file on the sd card, any deleted game, any deleted game save, any time the make a revision to their OS, would be on your SD card.
 
They wouldn't restore it. The NAND is their property, if they were to put a modified or deleted file on the sd card, any deleted game, any deleted game save, any time the make a revision to their OS, would be on your SD card.
Yeah, I know. Arm9loaderhax(_si).bin would be removed from ctrnand, but kept on sd card to avoid legal trouble.
 
Yeah, I know. Arm9loaderhax(_si).bin would be removed from ctrnand, but kept on sd card to avoid legal trouble.
No it wouldn't. If nintendo placed every file they delete on your sd card, then why isn't the old version of my sound app on my SD card. The way nintendo updates their apps is by deleting it and reinstalling the new version.
 
No it wouldn't. If nintendo placed every file they delete on your sd card, then why isn't the old version of my sound app on my SD card. The way nintendo updates their apps is by deleting it and reinstalling the new version.
For one, all system apps are installed on the ctrnand, as well as dsiware and gba vc. Nintendo can't legally delete a file on the sd card placed by the users, there are laws against it. So instead, they temporarily replace arm9loaderhax(_si).bin with one that removes a9lh, and restore the now unusable previous arm9loaderhax(_si).bin to the sd card. Legal and effective.
 
For one, all system apps are installed on the ctrnand, as well as dsiware and gba vc. Nintendo can't legally delete a file on the sd card placed by the users, there are laws against it. So instead, they temporarily replace arm9loaderhax(_si).bin with one that removes a9lh, and restore the now unusable previous arm9loaderhax(_si).bin to the sd card. Legal and effective.
Then I can sue Nintendo? I did inject FBI into H&S, then when I was updating to 11.3, FBI in H&S was replaced with H&S, and I didn't see the original injected FBI on my sd card. (Also, no doubt, once we get Greg's bootrom, Nintendo's lost this battle.)
 
Then I can sue Nintendo? I did inject FBI into H&S, then when I was updating to 11.3, FBI in H&S was replaced with H&S, and I didn't see the original injected FBI on my sd card. (Also, no doubt, once we get Greg's bootrom, Nintendo's lost this battle.)
What the fuck are you talking about with the injected FBI thing? You can inject files to ctrnand, but you can't sue nintendo for removing it from your nand as it is a proprietary medium that is not removable. On something like an sd card, nintendo can't remove user-placed files without their consent; therefore, they temporary replace arm9loaderhax(_si).bin on the sd card with an a9lh-removing payload, remove the ctrnand payload, and restore the arm9loaderhax(_si).bin that the user had placed, which is rendered useless by not having arm9loaderhax.
 
they can't just replace files on the sdcard, which is YOUR property, and doesn't contain their code.

they could try to update firm without calling the functions, but the architecture might not allow it.
 
Last edited by Zaphod77,
  • Like
Reactions: trainboy2019
What the fuck are you talking about with the injected FBI thing? You can inject files to ctrnand, but you can't sue nintendo for removing it from your nand as it is a proprietary medium that is not removable. On something like an sd card, nintendo can't remove user-placed files without their consent; therefore, they temporary replace arm9loaderhax(_si).bin on the sd card with an a9lh-removing payload, remove the ctrnand payload, and restore the arm9loaderhax(_si).bin that the user had placed, which is rendered useless by not having arm9loaderhax.
...You do realize that the a9lh payload was injected into NAND, just like FBI was injected into H&S in NAND, right? So if I can't sue them for injecting FBI into NAND, then why would they worry about being sued for removing the a9lh payload? Also, they probably have thrown a lot at a9lh, so they probably thought of a lot to try to block it, but it would most likely result in a brick.

EDIT: Ninja'd
 
deleting the payload will just soft brick until the payload is replaced.

wont' accomplish a thing.

normally, functions in the protected bootrom are used to update firm. cfw patches those. if nintendo included other routines to do the update we woudl spot them.
For the fifth time, they temporarily replace arm9loaderhax(_si).bin with a nintendo made payload that removes a9lh. The now useless arm9loaderhax(_si).bin would be restored to what it was originally to avoid legal trouble due to altering user-placed files without the users' consent.

--------------------- MERGED ---------------------------

...You do realize that the a9lh payload was injected into NAND, just like FBI was injected into H&S in NAND, right? So if I can't sue them for injecting FBI into NAND, then why would they worry about being sued for removing the a9lh payload? Also, they probably have thrown a lot at a9lh, so they probably thought of a lot to try to block it, but it would most likely result in a brick.

EDIT: Ninja'd
They can't be sued for removing/replacing user-placed files on NAND. They can for doing the same to SD cards.
 

Site & Scene News

Popular threads in this forum