Hacking Official [Source Release] ReiNand CFW

nechigawara · Jan 23, 2017

Ominous66521 said:
Yeah but still,the odds are very rare if we compare it to the percentage of people who don't brick and follow the guide perfectly.

I oppose you cause you said "can't really brick" while the truth is there still a chance, but very very very low.

gnmmarechal said:
AFAIK, 11.2's MenuHax aka BannerHax doesn't autoboot.

I know that, atleast it's work as another option.

Deleted User · Jan 23, 2017

nechigawara said:
I oppose you cause you said "can't really brick" while the truth is there still a chance, but very very very low.

You can't go wrong with a NAND backup if you can get your 3ds hardmodded.So you can't really brick entirely with one made if your 3ds can still be recovered.Otherwise get a cheap 2ds if its that much of a risk on your main console.

gnmmarechal · Jan 23, 2017

Ominous66521 said:
You can't go wrong with a NAND backup if you can get your 3ds hardmodded.So you can't really brick entirely with one made if your 3ds can still be recovered.Otherwise get a cheap 2ds if its that much of a risk on your main console.

Actually, you *can* have a brick that can't be fixed by restoring a NAND backup. Technically anyway.

proflayton123 · Jan 23, 2017

gnmmarechal said:
Actually, you *can* have a brick that can't be fixed by restoring a NAND backup. Technically anyway.

Good ol' MCU brick, although they are rare if you don't mess with the light things

Deleted User · Jan 23, 2017

gnmmarechal said:
Actually, you *can* have a brick that can't be fixed by restoring a NAND backup. Technically anyway.

I'm not shure how that could happen during a a9lh installation,but I guess anythings possible at this point in the 3ds hacking community.

nechigawara · Jan 23, 2017

Ominous66521 said:
You can't go wrong with a NAND backup if you can get your 3ds hardmodded.So you can't really brick entirely with one made if your 3ds can still be recovered.Otherwise get a cheap 2ds if its that much of a risk on your main console.

Getting Brick then recovering using hardmod, doesn't that count as brick but restoreable?

The Catboy · Jan 23, 2017

Wolfvak said:
Sorry if I sound like a dick, but who're you/the devs to tell other people what they should use? It's not like you can force other people to think the same way you do. You just gotta present the pros and cons and let them make a decision.

This is one of the things I really dislike about this "scene", and ironically it bashes against your stance (on this thread). Whenever a newbie comes up all they're told is "get a9lh and luma" instead of properly explained what they are. It's borderline ridiculous how many messages I read saying "lol idk anything about this but I did it anyways". Most people consider it a good thing because they didn't brick and such. I share this sentiment, but on the other hand I consider it a negative part because then you get a flood of people that know absolutely nothing about the topic.

You are the second person to pull this logic on me, so let me explain everything.
First, what it boils down to is simple evolution of software. Much like how recently software like Google Chrome and Linux Distros have started to drop 32Bit support. They aren't doing it because they hate 32Bit, they are doing it because it's no longer beneficial for them to continue supporting 32Bit. This is the same thing for these old entrypoints. It's longer benefits for the end user to continue using them. And to be fair, I listed some pretty good reasons right here.

Crystal the Glaceon said:
The issue with these old entrypoints is that they are vulnerable. In entrypoints like Ninjahax and MSET, you need to boot into an unprotected sysNAND to get to your CFW. That leaves your sysNAND completely vulnerable. With Menuhax, it can be removed through a targeted update and again launches through an unprotected sysNAND.
Yes, it's their choice to continue using this software and honestly I am not completely against them doing so. But devs shouldn't have to be held behind. It's a lot like devs dropping hardware support. Sooner or later, the user needs to upgrade.

The lack of protection behind these entrypoints only makes them a risk, more so with entrypoints like MSET and Ninjhax. And considering how many thread's we've gotten in the past of "Help my 3DS was accidentally updated!" Followed by exampling they were using an old entrypoint, I prove my case that they come with their own risks.

Again, I am not completely against people using these entrypoints. They are free to do so and their goat. But at the same time it's getting to the point where devs should consider removing this legacy code.
I am not trying to force people to change their setups. What I am trying to do explain why their setup is a risk and why using these options poses a risk to the future of the CFW. As well I am trying to explain the evolution of software.

proflayton123 · Jan 23, 2017

The above statement is something everyone should take in if you're using older entry points, people are only trying to make the risk of you updating essentially unprotected sysnand then complaining and making a thread, user error? In a sense.

Wolfvak · Jan 23, 2017

Crystal the Glaceon said:
You are the second person to pull this logic on me, so let me explain everything.
First, what it boils down to is simple evolution of software. Much like how recently software like Google Chrome and Linux Distros have started to drop 32Bit support. They aren't doing it because they hate 32Bit, they are doing it because it's no longer beneficial for them to continue supporting 32Bit. This is the same thing for these old entrypoints. It's longer benefits for the end user to continue using them. And to be fair, I listed some pretty good reasons right here.

The lack of protection behind these entrypoints only makes them a risk, more so with entrypoints like MSET and Ninjhax. And considering how many thread's we've gotten in the past of "Help my 3DS was accidentally updated!" Followed by exampling they were using an old entrypoint, I prove my case that they come with their own risks.

Again, I am not completely against people using these entrypoints. They are free to do so and their goat. But at the same time it's getting to the point where devs should consider removing this legacy code.
I am not trying to force people to change their systems. What I am trying to do explain why their setup is a risk and why using these options poses a risk to the future of the CFW. As well I am trying to explain the evolution of software.

Two counter arguments:
1. The 32bit argument is unapplicable since it's referring to a hardware update, not software. If someday in the future comes an exploit that works better/only on new 3DS then I might accept it, but otherwise it's useless. The only difference between mset/spider/*hax and a9lh/sighax is how early the exploit occurs, nothing else (oh and FIRM partitions/secret sector getting rekt but that's not really important and easy to bypass)

2. While it's true that running a sysnand leaves you more "vulnerable" to system updates, it's the same deal with CFWs (especially those that read the FIRM CXIs from CTRNAND, namely Luma and family like SFW, etc). A very specific update could be put out that either blocks most patches (ridiculously easy to do, due to how patching works) or maybe a more specific one with checks. As you all know, a9lh loads "/arm9loaderhax.bin" from SD, therefore that string should be present in a FIRM0 (or simply a brick FIRM. Who knows?). Simply checking for the string (when patching is detected) could lead the NFIRM to overwrite the FIRM0 partition with its correct self (maybe the secret sector too, again, if Nintendo is feeling benevolent...).
This would be detected pretty quickly and could be patched out by CFWs, but the fallout from "early updaters" (aka, idiots) would be huge.

tl;dr pretty much all exploits are vulnerable themselves lol

The Catboy · Jan 23, 2017

Wolfvak said:
Two counter arguments:
1. The 32bit argument is unapplicable since it's referring to a hardware update, not software. If someday in the future comes an exploit that works better/only on new 3DS then I might accept it, but otherwise it's useless. The only difference between mset/spider/*hax and a9lh/sighax is how early the exploit occurs, nothing else (oh and FIRM partitions/secret sector getting rekt but that's not really important and easy to bypass)

2. While it's true that running a sysnand leaves you more "vulnerable" to system updates, it's the same deal with CFWs (especially those that read the FIRM CXIs from CTRNAND, namely Luma and family like SFW, etc). A very specific update could be put out that either blocks most patches (ridiculously easy to do, due to how patching works) or maybe a more specific one with checks. As you all know, a9lh loads "/arm9loaderhax.bin" from SD, therefore that string should be present in a FIRM0 (or simply a brick FIRM. Who knows?). Simply checking for the string (when patching is detected) could lead the NFIRM to overwrite the FIRM0 partition with its correct self (maybe the secret sector too, again, if Nintendo is feeling benevolent...).
This would be detected pretty quickly and could be patched out by CFWs, but the fallout from "early updaters" (aka, idiots) would be huge.

tl;dr pretty much all exploits are vulnerable themselves lol

Honestly I think my comparison is pretty far. It's not completely the same, but a decent enough example. It's more of an example of cutting off old code that no longer shows benefit.
The thing is, Nintendo can't do a targeted update to remove A9LH. Because the code used to install A9LH is console specific, the big N would need that code. Otherwise an update through the system setting would brick the system. They could in theory block the launcher, but that's pretty easy fix and would easily be worked around in a few minutes by just changing a few strings of code. Even then, adding a code like that would be caught pretty quickly.
Yes, A9LH isn't perfect either, but the added risk of bricking both hacked and unhacked systems has appeared to deterred Nintendo from trying to remove it. Realistically, the only way Nintendo could remove it, would be through the hack itself. Which if they tried, they would still have to legally get the user to agree to remove it.

Wolfvak · Jan 23, 2017

Crystal the Glaceon said:
Honestly I think my comparison is pretty far. It's not completely the same, but a decent enough example. It's more of an example of cutting off old code that no longer shows benefit.
The thing is, Nintendo can't do a targeted update to remove A9LH. Because the code used to install A9LH is console specific, the big N would need that code. Otherwise an update through the system setting would brick the system. They could in theory block the launcher, but that's pretty easy fix and would easily be worked around in a few minutes by just changing a few strings of code. Even then, adding a code like that would be caught pretty quickly.

Fun fact: due to the way CakeHax/CakeBrah works, there's absolutely zero difference between an A9LH payload and an mset/*hax payload. They're exactly the same, bit by bit, their only difference is the executing environment. Abandoning the old entrypoints would do nothing other than remove the CakeHax submodule and a few lines in the Makefile.

It's not like the old entrypoints are limiting CFWs in any way...

Crystal the Glaceon said:
Yes, A9LH isn't perfect either, but the added risk of bricking both hacked and unhacked systems has appeared to deterred Nintendo from trying to remove it. Realistically, the only way Nintendo could remove it, would be through the hack itself. Which if they tried, they would still have to legally get the user to agree to remove it.

Not really. I'm not entirely sure on other regions (EUR, JPN, etc.) but on USA they're perfectly able to rewrite any part of the NAND as they see fit without user consent (they'd get your consent when you agree to the System Update).

And btw if they do anything similar to what I've described there's no way they'd brick unhacked systems. Absolutely zero chance.
Then again, their check would be patched out pretty quickly by devs over here... unless they added time checks in in order to have it kick in when special conditions are met (for example, date/time).

Ironically enough, the safest users would be the ones running the old entrypoints

Then again, this is all hypothetical...

The Catboy · Jan 23, 2017

Wolfvak said:
Fun fact: due to the way CakeHax/CakeBrah works, there's absolutely zero difference between an A9LH payload and an mset/*hax payload. They're exactly the same, bit by bit, their only difference is the executing environment. Abandoning the old entrypoints would do nothing other than remove the CakeHax submodule and a few lines in the Makefile.

It's not like the old entrypoints are limiting CFWs in any way...

Not really. I'm not entirely sure on other regions (EUR, JPN, etc.) but on USA they're perfectly able to rewrite any part of the NAND as they see fit without user consent (they'd get your consent when you agree to the System Update).

And btw if they do anything similar to what I've described there's no way they'd brick unhacked systems. Absolutely zero chance.
Then again, their check would be patched out pretty quickly by devs over here... unless they added time checks in in order to have it kick in when special conditions are met (for example, date/time).

Ironically enough, the safest users would be the ones running the old entrypoints

Then again, this is all hypothetical...

Let me level with you. I honestly don't care what entrypoint people are using. I am only giving an argument in favor of removing older ones. At the end of the day, it's up to devs to decide this one for their CFWs. At the same time, I am always in favor of software evolution and evolution requires some sacrifices to be made.

The thing is, it would still come with an increased brick chance. Look at what happens when you update your sysNAND with Gateway, instant brick the second they touch the FIRM0/1. And be honest, Nintendo hasn't even added a NATIVE_FIRM requirement to their homemenu. I don't think they are up to the task of making a method to remove A9LH without bricking the system.

Wolfvak · Jan 23, 2017

Crystal the Glaceon said:
Let me level with you. I honestly don't care what entrypoint people are using. I am only giving an argument in favor of removing older ones. At the end of the day, it's up to devs to decide this one for their CFWs. At the same time, I am always in favor of software evolution and evolution requires some sacrifices to be made.

And I'm presenting an argument in favor of keeping them. As a matter of fact, I think I presented several.
Getting rid of the old entrypoints won't do any harm to the main payload/CFW whatsoever. On the other hand, I do think they're "obsolete", for lack of a better word...

Crystal the Glaceon said:
The thing is, it would still come with an increased brick chance. Look at what happens when you update your sysNAND with Gateway, instant brick the second they touch the FIRM0/1. And be honest, Nintendo hasn't even added a NATIVE_FIRM requirement to their homemenu. I don't think they are up to the task of making a method to remove A9LH without bricking the system.

Yeah, I think the same. Seems they're putting all of their energy into the Switch. Let's see how that turns out...

The Catboy · Jan 24, 2017

Wolfvak said:
And I'm presenting an argument in favor of keeping them. As a matter of fact, I think I presented several.
Getting rid of the old entrypoints won't do any harm to the main payload/CFW whatsoever. On the other hand, I do think they're "obsolete", for lack of a better word...

Yeah, I think the same. Seems they're putting all of their energy into the Switch. Let's see how that turns out...

I can agree with that. There's no reason to get of them as they aren't really doing any harm. But they are obsolete and sooner or later devs should really look into removing them. With Sighax bond to come out, it's something to consider.
BTW, something I forgot to make clear. I am heavily against blindly following any guide. I don't care if it's the Guide, Menuhax guide, a youtube guide, ect. That's how most bricks end up happening. People blindly follow the guide without looking ahead or doing research and end up on a point that causes them problems. It's amazing how many thread popup with issues that are covered in the Guide and people just didn't bother to read a little further ahead. Personally I love seeing a thread open up where someone admits they don't know what they are doing and asks the community for help. Because it means they are actually going that extra mile to understand what they are getting into.

Click This · Feb 3, 2017

Hi there!

I've been out of the scene for a while and I'm currently on ReiNAND 10.6.0-31J and wanted to update my emunand. Do I need to do anything special to update, or can I just drop 11.x (or whatever's the current latest) in without a problem, or do I need to do some updating? Anything special happen to the scene since then?

Thanks!

Zidapi · Feb 3, 2017

Click This said:
Hi there!

I've been out of the scene for a while and I'm currently on ReiNAND 10.6.0-31J and wanted to update my emunand. Do I need to do anything special to update, or can I just drop 11.x (or whatever's the current latest) in without a problem, or do I need to do some updating? Anything special happen to the scene since then?

Thanks!

Just update via system settings as normal.

Click This · Feb 3, 2017

Zidapi said:
Just update via system settings as normal.

Good to know. To clarify, I don't need to drop any update files in for Reinand? Just going through a quick browse, it looks like Reinand has updated since then.

Edit: I've forgotten a lot of stuff. I think I'm on Reinand v3.2 and I'm running it through menuhax? Is it safe to just drop in Reinand v5?

CrimsonMaple · Feb 3, 2017

Click This said:
Good to know. To clarify, I don't need to drop any update files in for Reinand? Just going through a quick browse, it looks like Reinand has updated since then.

Edit: I've forgotten a lot of stuff. I think I'm on Reinand v3.2 and I'm running it through menuhax? Is it safe to just drop in Reinand v5?

Yeah it will work. Just drag and drop it. Replace the files that confict and your golden.

The Catboy · Feb 7, 2017

The new update brings a NATIVE_FIRM requirement to the homemenu! ReiNAND does not work on this update! Do not update until ReiNAND updates!

CrimsonMaple · Feb 7, 2017

Crystal the Glaceon said:
The new update brings a NATIVE_FIRM requirement to the homemenu! ReiNAND does not work on this update! Do not update until ReiNAND updates!

I'll get on it ASAP. Might take a while. Or I'll have to deal with a couple of sleep deprived days. I'll try and bundle it with agb and twl.

Hacking Official [Source Release] ReiNand CFW

Citizen of Gamindustri

Deleted User

Guest

Well-Known Member

The Temp Loaf'

Deleted User

Guest

Citizen of Gamindustri

GBAtemp Official Catboy™: Boywife

The Temp Loaf'

nyaa~

GBAtemp Official Catboy™: Boywife

nyaa~

GBAtemp Official Catboy™: Boywife

nyaa~

GBAtemp Official Catboy™: Boywife

Surgite!

Well-Known Member

Surgite!

Developer • She/Her

GBAtemp Official Catboy™: Boywife

Developer • She/Her

Similar threads

Popular threads in this forum