RELEASE MM-LINX - Super Mario Maker 2 Level Injector

Discussion in 'Switch - Emulation, Homebrew & Software Projects' started by blawar, Jul 1, 2019.

Loading...
  1. _hexkyz_

    _hexkyz_ Member

    Newcomer
    3
    Oct 4, 2018
    United States
    Yeaaaah... no.
    The amount of wrong in all that even makes 4chan cry.
     
    chaoskagami and hippy dave like this.
  2. Mthodmn101

    Mthodmn101 GBAtemp Advanced Fan

    Member
    6
    Jan 31, 2008
    United States
    [​IMG]
     
  3. blawar
    OP

    blawar GBAtemp Maniac

    Member
    11
    Nov 21, 2016
    United States
    Ok lets make it easy then, prove me wrong on the nand write protection non-sense.
     
  4. _hexkyz_

    _hexkyz_ Member

    Newcomer
    3
    Oct 4, 2018
    United States
    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".
     
  5. Mthodmn101

    Mthodmn101 GBAtemp Advanced Fan

    Member
    6
    Jan 31, 2008
    United States
    So you're saying the nand protection is crap on atmos then? At least a bunch of people are switching to emunand now
     
  6. blawar
    OP

    blawar GBAtemp Maniac

    Member
    11
    Nov 21, 2016
    United States
    bis.

    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 :)
     
    Last edited by blawar, Jul 12, 2019
  7. _hexkyz_

    _hexkyz_ Member

    Newcomer
    3
    Oct 4, 2018
    United States
    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.
     
  8. blawar
    OP

    blawar GBAtemp Maniac

    Member
    11
    Nov 21, 2016
    United States
    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.
     
  9. _hexkyz_

    _hexkyz_ Member

    Newcomer
    3
    Oct 4, 2018
    United States
    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.
     
  10. blawar
    OP

    blawar GBAtemp Maniac

    Member
    11
    Nov 21, 2016
    United States
    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%.
     
  11. _hexkyz_

    _hexkyz_ Member

    Newcomer
    3
    Oct 4, 2018
    United States
    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.
     
  12. SciresM

    SciresM GBAtemp Advanced Fan

    Member
    16
    Mar 21, 2014
    United States
    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.
     
    Last edited by SciresM, Jul 12, 2019
  13. blawar
    OP

    blawar GBAtemp Maniac

    Member
    11
    Nov 21, 2016
    United States
    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.

    — Posts automatically merged - Please don't double post! —

    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.
     
    Last edited by blawar, Jul 12, 2019
  14. SciresM

    SciresM GBAtemp Advanced Fan

    Member
    16
    Mar 21, 2014
    United States
    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.
     
    Last edited by SciresM, Jul 12, 2019
    Goffrier likes this.
  15. Goffrier
    This message by Goffrier has been removed from public view by Joe88, Jul 12, 2019, Reason: Off topic.
    Jul 12, 2019
  16. blawar
    OP

    blawar GBAtemp Maniac

    Member
    11
    Nov 21, 2016
    United States
    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.
     
    Last edited by blawar, Jul 12, 2019
  17. SciresM

    SciresM GBAtemp Advanced Fan

    Member
    16
    Mar 21, 2014
    United States
    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.
     
  18. blawar
    OP

    blawar GBAtemp Maniac

    Member
    11
    Nov 21, 2016
    United States
    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.
     
  19. SciresM

    SciresM GBAtemp Advanced Fan

    Member
    16
    Mar 21, 2014
    United States
    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.
     
  20. blawar
    OP

    blawar GBAtemp Maniac

    Member
    11
    Nov 21, 2016
    United States
    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.
     
    Last edited by blawar, Jul 12, 2019
  21. SciresM

    SciresM GBAtemp Advanced Fan

    Member
    16
    Mar 21, 2014
    United States
    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.
     
Quick Reply
Draft saved Draft deleted
Loading...