Hacking Official [Source Release] ReiNand CFW

[The Catboy]

Btw, does anyone still use ninjhax, mset, menuhax etc? like getting rid of it would be lighten the load, but idk. I like to give options and it looks like luma forces a9lh

I am still standing by my previous suggestion to drop support for those features

 

[el_gonz87]

Btw, does anyone still use ninjhax, mset, menuhax etc? like getting rid of it would be lighten the load, but idk. I like to give options and it looks like luma forces a9lh

I mainly use it with A9LH, but I know there is still quite a few ppl with menuhax. If you would to condense it would be good to just go down to these 2.

Also, could consider the demographic of your fan base.

If going just down to A9LH would better serve the ambition of this great project, I'm all for it LOLz.

 

[Wolfvak]

Btw, does anyone still use ninjhax, mset, menuhax etc? like getting rid of it would be lighten the load, but idk. I like to give options and it looks like luma forces a9lh

imo i'd be nice to just build/distribute a regular Brahma binary (entrypoint is 0x23F00000, uses the fb pointers, etc) and have a separate loader with a menu to load payloads for *hax/mset users.
But that's just me ¯\_(ツ)_/¯

 

[TuxSH]

This is what Luma3DS does somehow. The .3dsx and .dat are just fancy chainloaders that load arm9loaderhax.bin (which is a regular Brahma binary) (or anything pointed by the path text file)

 

[Wolfvak]

>read nand partition to memory
>decrypt with proper keyslot
>???
>PROFIT

> decrypt

Just use a predecrypted FIRM on SD :^)
not sure why people like removing files, its not like 3MB are gonna make a difference anyways

 

[lonewolf08]

Btw, does anyone still use ninjhax, mset, menuhax etc? like getting rid of it would be lighten the load, but idk. I like to give options and it looks like luma forces a9lh

Well I mean you're the dev, so only really you can decide, I would say drop them if you really want to lighten up the load. Alternatively you could just drop them slowly as things start phasing out, for example a very small amount of people still use mset so you can push that out and so on.

 

[Wolfvak]

[...]for example a very small amount of people still use mset so you can push that out and so on.

oldspider, mset and hax entrypoints are all managed by the same software (CakeHax/CakeBrah) so it doesn't make sense to remove only a portion. It's much saner to either keep as many as possible or remove CakeHax/Brah, and take them down as well...

This is what Luma3DS does somehow. The .3dsx and .dat are just fancy chainloaders that load arm9loaderhax.bin (which is a regular Brahma binary) (or anything pointed by the path text file)

Yeah but it makes more sense (again, imo) to have a unified/standard way of launching new payloads from older entrypoints. Just have a single dat payload on root which acts as a sort of boot manager, this way instead of having multiple versions of CakeHax lying around in random 3dsx's all over the place you just have to provide your own binary payload.

This'd also bring an advantage once sighax comes out since we would have a more standard environment to work with. For example, I've seen a9lh setups where DTCM is enabled, others where it's disabled, then we have the screen init problem, etc.

 

[CreAtor135]

i use MSET and Cakehax ROP.
no im fucking lying just drop support lmao

 

[lonewolf08]

oldspider, mset and hax entrypoints are all managed by the same software (CakeHax/CakeBrah) so it doesn't make sense to remove only a portion. It's much saner to either keep as many as possible or remove CakeHax/Brah, and take them down as well

Then fuck it, take it all down except the newest method and start paving the way for a more unified system. Only by dropping support will more and more people continue moving forward and the less developers supporting old methods the more the users will need to move up but I digress this is all the devs decision to make.

 

[Wolfvak]

Then fuck it, take it all down except the newest method and start paving the way for a more unified system. Only by dropping support will more and more people continue moving forward and the less developers supporting old methods the more the users will need to move up but I digress this is all the devs decision to make.

Sooner or later it'll be done, that's just how it is. Might as well rip the band aid quickly while the project has some momentum...

 

[Reisyukaku]

oldspider, mset and hax entrypoints are all managed by the same software (CakeHax/CakeBrah) so it doesn't make sense to remove only a portion. It's much saner to either keep as many as possible or remove CakeHax/Brah, and take them down as well...


Yeah but it makes more sense (again, imo) to have a unified/standard way of launching new payloads from older entrypoints. Just have a single dat payload on root which acts as a sort of boot manager, this way instead of having multiple versions of CakeHax lying around in random 3dsx's all over the place you just have to provide your own binary payload.

This'd also bring an advantage once sighax comes out since we would have a more standard environment to work with. For example, I've seen a9lh setups where DTCM is enabled, others where it's disabled, then we have the screen init problem, etc.

You got a point. Makes more sense for entries to add support to a9lh payloads (since literally its just a basic payload thats loaded to a known address, nothing fancy). But I've also been preaching for a while that the sane thing to do with a9lh payload itself is add chainloading since thats essentially our BIOS. Leaving chain loading to a cfw is absurd imo. lol
I'll have to add that to my already overloaded list of things to do.

 

[el_gonz87]

You got a point. Makes more sense for entries to add support to a9lh payloads (since literally its just a basic payload thats loaded to a known address, nothing fancy). But I've also been preaching for a while that the sane thing to do with a9lh payload itself is add chainloading since thats essentially our BIOS. Leaving chain loading to a cfw is absurd imo. lol
I'll have to add that to my already overloaded list of things to do.

That's almost common sense lol

 

[The Catboy]

You got a point. Makes more sense for entries to add support to a9lh payloads (since literally its just a basic payload thats loaded to a known address, nothing fancy). But I've also been preaching for a while that the sane thing to do with a9lh payload itself is add chainloading since thats essentially our BIOS. Leaving chain loading to a cfw is absurd imo. lol
I'll have to add that to my already overloaded list of things to do.

I am going to be honest, devs should start pushing for A9LH only. At this point, if you can install one entrypoint like Menuhax, you can install A9LH. The process has been boiled down so much, that it requires actually trying to brick your system to fail.
Plus with SigHAX right around the corner, there will be less of a reason to support these entrypoints.
And ReiNAND really doesn't need a bootloader. Since it's payloads aren't tethered to the launcher, a user can easily rename the file and have it work with current bootloaders.

 

[chocoboss]

If you remove, then you will see many ppl that use mset come back lol
Many ppl here still use MenuHAx, so please keep it

 

[The Catboy]

If you remove, then you will see many ppl that use mset come back lol
Many ppl here still use MenuHAx, so please keep it

There's really no reason to keep using MenuHAX with how easy and safe it is to install A9LH. You are basically keeping yourself out of date and causing CFWs to lag behind to continue to support out of date entrypoints

 

[nechigawara]

There's really no reason to keep using MenuHAX with how easy and safe it is to install A9LH. You are basically keeping yourself out of date and causing CFWs to lag behind to continue to support out of date entrypoints

Menuhax now works with 11.2. So I don't think it's outdate yet.
But, I agree with you that if you're not scare freak, just go A9LH.

 

[lonewolf08]

Menuhax now works with 11.2. So I don't think it's outdate yet.
But, I agree with you that if you're not scare freak, just go A9LH.

I think by out of date, crystal meant functionality wise. Menuhax has a set limited functions whereas a9lh you can boot any number of functions. For example on my n3ds when it boots, it starts from 3dsafe a9lh to bootanim9 to finally luma. 3dsafe to keep my whole 3ds safe and private (for the most part) but outside of luma that's only possible because of a9lh and if devs continue building for the future there's more possibilities with a9lh over menuhax.

 

[nechigawara]

I think by out of date, crystal meant functionality wise. Menuhax has a set limited functions whereas a9lh you can boot any number of functions. For example on my n3ds when it boots, it starts from 3dsafe a9lh to bootanim9 to finally luma. 3dsafe to keep my whole 3ds safe and private (for the most part) but outside of luma that's only possible because of a9lh and if devs continue building for the future there's more possibilities with a9lh over menuhax.

Limited function doesn't have anything to do with the word "out of date" if it's still getting update.
Feature phone A that out of the same day as Smart Phone B and has less function, does Feature phone A count as "out of date" too?
ReiNAND has a lastest update but still has some Limited function compare to other CFW, does ReiNAND count as "out of date" too?
Well, I agree that people should go to A9LH if they willing to risk since A9LH offer more than just CFW.

 

[Wolfvak]

You got a point. Makes more sense for entries to add support to a9lh payloads (since literally its just a basic payload thats loaded to a known address, nothing fancy). But I've also been preaching for a while that the sane thing to do with a9lh payload itself is add chainloading since thats essentially our BIOS. Leaving chain loading to a cfw is absurd imo. lol
I'll have to add that to my already overloaded list of things to do.

Actually a couple of months ago I had the idea of having a sort of common runtime environment, a bunch of routines that would be installed to ITCM on startup and that could be called through software interrupt (SWI) from payloads. Not complex stuff like NAND/SD reading (well, considering we have unprotboot9_sdmmc now we might as well do it lol) but simple parts like I2C (poweroff, reboot, etc), optimized copy/fill routines that take advantage of DMA (when possible), SPI, maybe some crypto code... you get the idea

 

[StarTrekVoyager]

Thank you so much @Issac for the cleanup