MM-LINX - Super Mario Maker 2 Level Injector

_hexkyz_ · Jul 12, 2019

blawar said:
ReiNX existed months before atmosphere, and was wildly popular. The name is also recognizable for 3DS CFW.

Scires has done a lot of great things for the scene, and is a talented hacker. However this does not give him a blank check to consistently make mistakes with atmosphere and not have people switch to better CFW's. Atmosphere has a lot of issues, and unfortunately a lot of that cancer gets forced into other CFW's by users. Scires is not a good person to be maintaining a popular project such as atmosphere.

blawar said:
A great example would be scires poor implementation of nand write protection to protect users from malicious homebrew. He did not block all nand writes, only some of them. He bricked a lot of people when he released that and choi only wrote to half of the nand. Rather than remove the bad feature, he double downed and added a hack to AMS whose sole purpose was to stop existing choi from bricking (he did nothing to solve the underlying problem, it was just a stop gap). So then choi updates to not brick users to work around scires' bad programming. What does choi do? Well scires had the brilliant idea to use empty file flags on the SD card to determine if an application should have permission to write to the nand. It is meant for users to manually crate these flags, however scires did not prevent applications from doing so, so choi simply writes its own bis_write flag to give itself write permission to the nand. That is right, homebrew casn trivally bypass scires entire weak nand protection scheme by writing an empty file first. You dont have to be a programmer to know why scires idea is completely stupid, and he basically bricked a bunch of users for nothing. To this day, he has not removed this aweful code from his code base. Bad decisions like this permeate throughout atmosphere's code because scires is a good hacker, but a terrible programmer. It is easy to break things down and hack them. It is much harder to create new things that are great.

blawar said:
The most toxic anti-social people in the scene, are Scires / Re-Switched by miles. They have the reputation of labeling apps piracy and refusing to troubleshoot any AMS issues affecting them, they ban hoards of people for innocuous statements. Some times they ban people who dont violate the rules, just because they do not like them politically. Reswitched is the primary source of political discord in the scene, most of the big issues are caused or catalyzed by them. This behavior is directly responsible for why the scene was fragmented early on, and continues to be fragmented.

There is a lot I can be criticized about, however I have never taken adverse action against software without trying to work out the issue with the developers first. Kosmos was a great example, I tried to work that out with Team Atlas for a month before I implemented the block, and I agreed to remove the block once the issue was fixed (and it was). Scires / Re-switched are just political hacks / drama factories.

blawar said:
Where did I complain about dev's trollling me? My comments about reswitched toxic behavior a) that isnt trolling, that is just them being political hacks and hypocrites b) that doesnt just affect me, they do that to everyone in the scene.

blawar said:
I have never trolled on reswitched. Can you cite some statements that are trolling?

Yeaaaah... no.
The amount of wrong in all that even makes 4chan cry.

Mthodmn101 · Jul 12, 2019

hippy dave said:
Sure man sure, just being your lovely abrasive self I guess then - it just strongly resembles trolling to the rest of the world.

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

I'm going offline to tend to a headache, so I'll just pre-empt whatever you're going to come up with by saying if you don't think ban evasion and concealing your identity/actively pretending not to be yourself in order to criticise a project to its devs doesn't sound like trolling then I don't know what to tell you.

blawar · Jul 12, 2019

_hexkyz_ said:
Yeaaaah... no.
The amount of wrong in all that even makes 4chan cry.

Ok lets make it easy then, prove me wrong on the nand write protection non-sense.

_hexkyz_ · Jul 12, 2019

blawar said:
Ok lets make it easy then, prove me wrong on the nand write protection non-sense.

I'm well aware of your tactics and how pointless it is to even attempt discussing a topic with you.
The NAND write protection was just as much non-sense as you publicly stating your interest in "bricking users on purpose just to prove scires wrong".

Mthodmn101 · Jul 12, 2019

_hexkyz_ said:
I'm well aware of your tactics and how pointless it is to even attempt discussing a topic with you.
The NAND write protection was just as much non-sense as you publicly stating your interest in "bricking users on purpose just to prove scires wrong".

So you're saying the nand protection is crap on atmos then? At least a bunch of people are switching to emunand now

blawar · Jul 12, 2019

_hexkyz_ said:
I'm well aware of your tactics and how pointless it is to even attempt discussing a topic with you.
The NAND write protection was just as much non-sense as you publicly stating your interest in "bricking users on purpose just to prove scires wrong".

https://github.com/Atmosphere-NX/At...s_mitm/source/fs_mitm/fsmitm_service.cpp#L260

Code:

 /* Allow HBL to write to boot1 (safe firm) + package2. */
            /* This is needed to not break compatibility with ChoiDujourNX, which does not check for write access before beginning an update. */
            /* TODO: get fixed so that this can be turned off without causing bricks :/ */

How can choi brick the nand if atmosphere's nand protection was properly implemented? That is really the only question that needs to be answered

_hexkyz_ · Jul 12, 2019

blawar said:
View attachment 172946

There is no way to have a non-bypassable NAND protection and no one ever claimed it was. Any system designed to protect against NAND writes can and will be trivially defeated.
This was added for homebrew authors to selectively disable NAND writing at their discretion for a variety of reasons (such as fearing their application could be compromised in a way to "brick" users).

I'm pretty sure this wasn't advertised as more than what it is.

blawar · Jul 12, 2019

_hexkyz_ said:
There is no way to have a non-bypassable NAND protection and no one ever claimed it was. Any system designed to protect against NAND writes can and will be trivially defeated.
This was added for homebrew authors to selectively disable NAND writing at their discretion for a variety of reasons (such as fearing their application could be compromised in a way to "brick" users).

I'm pretty sure this wasn't advertised as more than what it is.

Wait, you are saying scires added the nand protection, for programmers to disable their own access to the nand if they dont think they can write to the nand without bricking the user? what?

Homebrew developers fearing their programs could be compromised to allow arbitrary code execution? LOL. Even if they did fear that, and a user somehow got code execution through a homebrew app, that arbitrary code could just disable the write protection as well. Just admit it, the feature is completely useless and bricked users for no reason. People lost their switches because scires is a bad programmer and they didnt have backups.

Do you have any links to public statements made as to the use of that feature, because 99.99% of users think the protection is there to keep them safe from brickachu, which is 100% false.

_hexkyz_ · Jul 12, 2019

blawar said:
Wait, you are saying scires added the nand protection, for programmers to disable their own access to the nand if they dont think they can write to the nand without bricking the user? what?

Homebrew developers fearing their programs could be compromised to allow arbitrary code execution? LOL. Even if they did fear that, and a user somehow got code execution through a homebrew app, that arbitrary code could just disable the write protection as well. Just admit it, the feature is completely useless and bricked users for no reason. People lost their switches because scires is a bad programmer and they didnt have backups.

Do you have any links to public statements made as to the use of that feature, because 99.99% of users think the protection is there to keep them safe from brickachu, which is 100% false.

Where are those people who bricked their Switches with that? I honestly never seen anyone complaining about that specifically.
ChoiDujourNX has bricked my units several times without using Atmosphere at all.

blawar · Jul 12, 2019

_hexkyz_ said:
Where are those people who bricked their Switches with that? I honestly never seen anyone complaining about that specifically.
ChoiDujourNX has bricked my units several times without using Atmosphere at all.

There isnt a brick registry. It is a foregone conclusion that atmosphere users on that version would brick when using choi, even scires concedes this. it sounds like you are trying to argue that the bug was not public long enough for anyone to actually brick. I would argue there are over 500,000 hacked switches, the chances of some people downloading the latest AMS and upating their firmware is pretty much certain. I can calculate the odds for you, but I know its above 95%.

_hexkyz_ · Jul 12, 2019

blawar said:
There isnt a brick registry. It is a foregone conclusion that atmosphere users on that version would brick when using choi, even scires concedes this. it sounds like you are trying to argue that the bug was not public long enough for anyone to actually brick. I would argue there are over 500,000 hacked switches, the chances of some people downloading the latest AMS and upating their firmware is pretty much certain. I can calculate the odds for you, but I know its above 95%.

Now you're just bordering on delusion. There's little point in arguing with someone who doesn't take things seriously and only cares about shitting on everyone else.
I'm not going to derail this further. Have fun and good luck.

SciresM · Jul 12, 2019

blawar said:
There isnt a brick registry. It is a foregone conclusion that atmosphere users on that version would brick when using choi, even scires concedes this. it sounds like you are trying to argue that the bug was not public long enough for anyone to actually brick. I would argue there are over 500,000 hacked switches, the chances of some people downloading the latest AMS and upating their firmware is pretty much certain. I can calculate the odds for you, but I know its above 95%.

Bis protect stuff serves its purpose.

Re: "bricks" -- the Choi brick in question caused the wrong package2 data to be present. There's nothing unique about package2 so it was trivially fixable by anyone using hacdiskmount or similar, so I never stressed about it.

Re: writing flags -- bis protect was added because people asked me to add it after a malicious homebrew was going around writing garbage to PRODINFO.

bis protect aims to prevent unrecoverable bricks, and put a barrier in the way for recoverable bricks -- however, preventing sufficiently dedicated malicious homebrew isn't really possible, so we don't put in particularly tough barriers against recoverable bricks.

Writing flags will allow you to cause recoverable bricks, yes -- but homebrew that would brick stock and isn't particularly targeting atmosphere is stopped, so it's a minor win in my view.

There's no way to write a flag to enable writing to PRODINFO, which could cause bricks that aren't recoverable. In addition, atmosphere was made to backup CAL0 and persist a write handle to prevent homebrew from interfering with the backup. Both of these measures are, I believe, fairly effective in what they're meant to do, and address the user requests that led to bis protect.

I don't think there's anything of poor design there -- the threat model we're using is coherent.

Besides, there are other uses as well -- the exact same bis protect code paths allow for updating the system normally without worrying about AutoRCM being lost. That's a feature users love/was in high demand before implementation.

blawar · Jul 12, 2019

_hexkyz_ said:
Now you're just bordering on delusion. There's little point in arguing with someone who doesn't take things seriously and only cares about shitting on everyone else.
I'm not going to derail this further. Have fun and good luck.

I just want to make clear that I respect and appreciate your reverse-engineering (and scires / reswitched) work in the scene. I am purely criticizing the politics and the programming skill / work. Hackers making bad programmers isnt something unique to reswitched or the switch scene in general, its always thats way typically. I just wish reswitched would do more "getting shit done" and less political theater.

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

SciresM said:
Bis protect stuff serves its purpose.

Re: "bricks" -- the Choi brick in question caused the wrong package2 data to be present. There's nothing unique about pakxgae2 so it was trivially fixable by anyone using hacdiskmount or similar, so I never stressed about it.

Re: writing flags -- bis protect was added because people asked me to add it after a malicious homebrew was going around writing garbage to PRODINFO.

bis protect aims to prevent unrecoverable bricks, and put a barrier in the way for recoverable bricks -- however, preventing sufficiently dedicated malicious homebrew isn't really possible, so we don't put in particularly tough barriers against recoverable bricks.

Writing flags will allow you to cause recoverable bricks, yes -- but homebrew that would brick stock and isn't particularly targeting atmosphere is stopped, so it's a minor win in my view.

There's no way to write a flag to enable writing to PRODINFO, which could cause bricks that aren't recoverable. In addition, atmosphere was made to backup CAL0 and persist a write handle to prevent homebrew from interfering with the backup. Both of these measures are, I believe, fairly effective in what they're meant to do, and address the user requests that led to bis protect.

I don't think there's anything of poor design there -- the threat model we're using is coherent.

Besides, there are other uses as well -- the exact same bis protect code paths allow for updating the system normally without worrying about AutoRCM being lost. That's a feature users love/was in high demand before implementation.

I feel you are being misleading with these statements. You say "bis protect aims to prevent unrecoverable bricks" but then you also say that bypassing bis-write will only produce recoverable bricks. Therefore bis-write is completely useless.

the PRODINFO writing is not the same thing as bis-write. Prodinfo writing can cause currently unrecoverable bricks yes, but that is not what we are discussing here. Furthermore, if you actually cared about unrecoverable bricks, you would update atmosphere to boot with modified prodinfo device cert. If you did that, all nand based bricks would be recoverable and we wouldnt be having this conversation.

furthermore, as mike said (and the quote of mine that was taken out of context), you cant stop nand writes. You did more harm to the community giving them all a false sense of security (and bricking some users) that I was trying to correct by pointing out that ams's nand write (and prodinfo) protection is near worthless.

I know, you dont ever think or admit your designs are bad. Luckily enough information was posted here for normal users to know better without having to be a programmer.

SciresM · Jul 12, 2019

blawar said:
I feel you are being misleading with these statements. You say "bis protect aims to prevent unrecoverable bricks" but then you also say that bypassing bis-write will only produce recoverable bricks. Therefore bis-write is completely useless.

the PRODINFO writing is not the same thing as bis-write. Prodinfo writing can cause currently unrecoverable bricks yes, but that is not what we are discussing here. Furthermore, if you actually cared about unrecoverable bricks, you would update atmosphere to boot with modified prodinfo device cert. If you did that, all bricks would be recoverable and we wouldnt be having this conversation.

furthermore, as mike said (and the quote of mine that was taken out of context), you cant stop nand writes. You did more harm to the community giving them all a false sense of security (and bricking some users) that I was trying to correct by pointing out that ams's nand write (and prodinfo) protection is near worthless.

I know, you dont ever think or admit your designs are bad. Luckily enough information was posted here for normal users to know better without having to be a programmer.

I disagree that I'm being misleading.

First, it's bis-protect, not bis-write, which is a term I've never used.

Second....yes? Bis protect aims to prevent unrecoverable bricks and mitigate recoverable bricks. Malicious homebrew that writes flags can produce recoverable bricks but not unrecoverable bricks, as I said above. That's not "useless", and it addresses the threat model I care about.

And...PRODINFO protection is part of bis protection. It was added in the bis_protect branch PR, and all of that logic was intended to serve the threat model and use case described above. I don't understand how you can claim PRODINFO protection, which prevents writing to a specific part of bis, is not a part of atmosphere's bis protection?

Also, PRODINFO contains unrecoverable device specific battery configuration. Allowing to boot without correct configuration could cause hardware damage -- losing PRODINFO is unsafe.

I disagree that I've done harm, because I don't think the sense of security is false. The code in question prevents damage that the user can't fix. That's a genuine net gain in security.

And I can and have admitted to bad design -- the original libstratosphere ipc serializarion was dogshit, so I rewrote it. Even now libstratosphere suffers from bad design choices, and I've been heavily critical of e.g. old loader's design and choices, which is why I've been rewriting stratosphere.

I absolutely make design mistakes and bad choices, and I'm pretty open about them when I do. I don't think bis protect is a design mistake or a bad choice, since it accomplishes what I wanted it to accomplish.

blawar · Jul 12, 2019

SciresM said:
I disagree that I'm being misleading.

First, it's bis-protect, not bis-write, which is a term I've never used.

Second....yes? Bis protect aims to prevent unrecoverable bricks and mitigate recoverable bricks. Malicious homebrew that writes flags can produce recoverable bricks but not unrecoverable bricks, as I said above. That's not "useless", and it addresses the threat model I care about.

And...PRODINFO protection is part of bis protection. It was added in the bis_protect branch PR, and all of that logic was intended to serve the threat model and use case described above. I don't understand how you can claim PRODINFO protection, which prevents writing to a specific part of bis, is not a part of atmosphere's bis protection?

Also, PRODINFO contains unrecoverable device specific battery configuration. Allowing to boot without correct configuration could cause hardware damage -- losing PRODINFO is unsafe.

I disagree that I've done harm, because I don't think the sense of security is false. The code in question prevents damage that the user can't fix. That's a genuine net gain in security.

And I can and have admitted to bad design -- the original libstratosphere ipc serializarion was dogshit, so I rewrote it. Even now libstratosphere suffers from bad design choices, and I've been heavily critical of e.g. old loader's design and choices, which is why I've been rewriting stratosphere.

I absolutely make design mistakes and bad choices, and I'm pretty open about them when I do. I don't think bis protect is a design mistake or a bad choice, since it accomplishes what I wanted it to accomplish.

The battery stuff is just calibration info, its not critical. As long as there arent crazy values written there, the user will be fine. Losing prodinfo is absolutely recoverable (though you will likely never boot OFW or go online again).

If what you said was true, battery replacement would not be possible, and it is.

SciresM · Jul 12, 2019

blawar said:
The battery stuff is just calibration info, its not critical. As long as there arent crazy values written there, the user will be fine. Losing prodinfo is absolutely recoverable (though you will likely never boot OFW or go online again).

Newer devices store information on what kind of battery is used, not just calibration -- see boot sysmodule source code. I have a unit with this information in PRODINFO.

Having the wrong value would result in the OS writing incorrect parameters over i2c for e.g. capacity and voltage min/max. It is my honest belief that that could cause hardware damage.

blawar · Jul 12, 2019

SciresM said:
Newer devices store information on what kind of battery is used, not just calibration -- see boot sysmodule source code. I have a unit with this information in PRODINFO.

Having the wrong value would result in the OS writing incorrect parameters over i2c for e.g. capacity and voltage min/max. It is my honest belief that that could cause hardware damage.

By "newer devices", do you mean ipatched switches? because those cant boot without real prodinfo anyway since the OS needs to boot OFW to load hacks, so your point is moot.

SciresM · Jul 12, 2019

blawar said:
By "newer devices", do you mean ipatched switches? because those cant boot without real prodinfo anyway since the OS needs to boot OFW to load hacks, so your point is moot.

I have a device that is not ipatched and has that information in CAL0, so no that's not what I meant.

Also, atmosphere has some support for ipatched devices via deja vu and intends for better support in the future.

Anyway, it really is my belief that prodinfo stuff is unsafe due to battery version info loss.

In the event that that's demonstrably recoverable/safe, I have no qualms about potentially e.g. automatically repairing prodinfo with sane default values to ensure a bootable system when corruption is detected.

However, I can't find any documentation on the risks of writing incorrect voltage min/max to a max17050 battery.

blawar · Jul 12, 2019

SciresM said:
I have a device that is not ipatched and has that information in CAL0, so no that's not what I meant.

Also, atmosphere has some support for ipatched devices via deja vu and intends for better support in the future.

Anyway, it really is my belief that prodinfo stuff is unsafe due to battery version info loss.

In the event that that's demonstrably recoverable/safe, I have no qualms about potentially e.g. automatically repairing prodinfo with sane default values to ensure a bootable system when corruption is detected.

However, I can't find any documentation on the risks of writing incorrect voltage min/max to a max17050 battery.

Then how do you reconcile switch battery replacements working and not frying IC's?

Also, as im sure you know, there is a factory calibration tool. I would not be surprised if you had RE'd that already to know how those values are calibrated in the first place.

I just think you are uninterested in making atmosphere nand brick proof, or recovering the consoles of brickachu victims. And thats fine, its your time to do with as you please. It just would have been a better use of your time to focus on that, than memey bis-write protection that doesnt work.

SciresM · Jul 12, 2019

blawar said:
Then how do you reconcile switch battery replacements working and not frying IC's?

Also, as im sure you know, there is a factory calibration tool. I would not be surprised if you had RE'd that already to know how those values are calibrated in the first place.

The first N (unknown but large) produced units all used the same battery. I don't know whether the replacement is this model, and I don't know if anyone has done a battery replacement on a newer model. I don't know whether some kind of degradation happens or not in those cases -- I agree, battery replacements are suggestive in a safe direction. However, caution is a habit, and I don't want to risk users hardware without being sure. It may be that incorrect voltage min/max causes damage only under extreme conditions, for example (and it could be equally possible that there's no risk, but I don't know and don't know how to find out). Are you aware of documentation I could read?

The factory calibration tool takes battery info from PC over USB, which isn't something we can mimic.

Attachments

Well-Known Member

Well-Known Member

Developer

Well-Known Member

Well-Known Member

Developer

Well-Known Member

Developer

Well-Known Member

Developer

Well-Known Member

Developer

Developer

Developer

Developer

Developer

Developer

Developer

Developer

Developer

Similar threads

Popular threads in this forum