Hacking When will there be support for Emunand via USB with atmosphere?

[makazula]

Yes, the main (and only) reason why atmosphere doesn't bundle the patches is because their main use is piracy. Same for XCI etc.

One can argument that they can be used for other uses, like launching legit backups and all. But try to see things from scires and others' side: They are devs working on legal grey areas. Nintendo is fierce fighting piracy, and puts a great effort onto it. Would you risk your own career (and possibly worse than that) to have a piracy friendly OS?

I mean, if you can't put yourself in the shoes of scires and others, then think of this: It's undeniable that atmosphere is the driving force of the scene. This is no attack to other OS's, please refrain from "X is better than Y comments. But, if you're ninty and you had an opportunity to take down such pillar like scires, do you think they would think twice? If they didn't already, is because he's been careful enough to not go to far.

So for us, wether using atmosphere or any other CFW, we should be thankful that atmo is avoiding all piracy. It's much better to waste a minute or two replacing sigpatches once a while, than having the motor of the scene being taken down.

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

Regarding going around the XCI in the sept way, probably no one could find a way to do that without breaking ninty's copyrights. There are a lot of devs in the scene. If for example Rei, who is a little less conservative in this matter, doesn't want to give a take on XCI, is certainly not for lack of knowledge / ability. It's because there's just too much heat around XCI, and TX can go around that because they abide to different rules.

Needless to say, this is all just my opinion.

 

[Rahkeesh]

Atmosphere doesn't want to enable piracy. Not because they couldn't do it "legally", but because they are against it.

Kosmos and Reinx provide sigpatches that are themselves original and open source code. So these sigpatches aren't themselves copyright infringement, but they enable copyright infringement and might be actionable under DMCA.

XCI loading on SX OS uses massive amounts of Nintendo code and therefore is copyright infringement. There isn't a reasonable way to build on their work without retaining that code. You will never see that kind of thing on common code hosts or within the homebrew community because they don't support the posting of copyrighted code.

 

[hippy dave]

Well I guess that was the problem, whatever my google search turned up for sigpatches wasn't good enough. Because after I used the link to "sweet patches" that you provided, it works finally.

But this is just the problem I have with Atmosphere, it's kind of half-baked CFW. Why are the sigpatches missing from Atmosphere? Shouldn't they be bundled in? It seems that the justification for missing XCI support is "piracy", so is that also the reason why the sigpatches aren't there?

Maybe a more accurate explanation of why XCI will never be included with Atmosphere is that they would have to include illegal keys in the Atmosphere distribution for XCI to work. But even that argument doesn't hold water. If that's the reason, then all they have to do is a little gymnastics like they did for Sept-- just include a bunch of code to dynamically derive the keys during start-up, and presto now you don't have to embed illegal keys in your distribution. So the whole excuse of "piracy" or "illegal keys" for not including XCI support seems like a cop out.

Look, maybe ScireS doesn't want to be bothered with XCI support, because he doesn't care. But surely some other dev does? My opinion is that if someone took the source code to Atmosphere and extended it to include XCI support, and called it Stratosphere (or whatever) and properly gave credit to ScireS for the original work, then Atmosphere would go extinct overnight.

Funny thing is, I am actually a dev. Yeah yeah I know everyone says that so blah blah blah, but the fact is I've been writing C code for embedded devices for over 20 years, so I'm an expert at it. But I've never written a line of code for a game console, so it would be a large learning curve to get acclimated. Honestly that's the only thing that keeps me from doing exactly what I described above.

The needed cert/whatever for xci can't be derived from the console. Maybe it could be dumped from your own cartridge.

I think the reason a lot of devs, including the atmosphere ones, don't want to do anything related to piracy is to keep their names/reputations clean, in the eyes of potential employers or whoever else. Some of them will be personally against piracy too, but I'm sure there are some devs in the scene (honestly not pointing fingers in any particular direction because I wouldn't know or care who) who are happy to pirate games in their own private lives but don't want to be associated with it publicly. You can call that hypocrisy, but it's just sensible in terms of employment etc.

Back to xci support, most devs honestly aren't interested. If someone is interested enough and skilled enough, they could add it themselves. Maybe reinx will get it eventually, it's been talked about forever - then maybe someone will steal that code for an atmosphere add-on/fork. If it's important to you and you enjoy coding, then why not get started on that learning curve, either you'll be the first to manage it and will be loved and revered by those who want it, or someone will beat you to it and you'll still have had a good learning experience. Complaining on gbatemp isn't going to make anything happen tho.

 

[kamesenin888]

How do you get this to work???

Well there are guides on how to setup an emuNAND that will do the trick you just do not install what breaks compatibility

 

[deltamind106]

Complaining on gbatemp isn't going to make anything happen tho.

I've have no desire/intention to "make anything happen" by "complaining on gbatemp". My posts may sound like complaining to you, but it's just my way of talking when I'm trying to understand something that doesn't make sense to me. The last few posts have all contained interesting comments, and I thank everyone for the discussion.

XCI loading on SX OS uses massive amounts of Nintendo code and therefore is copyright infringement. There isn't a reasonable way to build on their work without retaining that code.

That's odd, surely there is a way to patch the OS to intercept the requests to read the ROM cartridge without using "massive amounts of Nintendo code". But as I said, although I've easily written over a million lines of C code in my career, not one of those lines of code was for a game console, so I honestly don't really know the architecture.

Since I'm a mix of hardware and software, if really wanted a fun project, I would build a small device that fits into the Switch's cartridge slot, into which you insert your microSD card (containing XCI dumps), and it would emulate the cartridge at the hardware level. That would be interesting for me. Actually, it will no doubt happen. Once the switch is retired and people want to use it for nostalgic retro-gaming 15 years from now, someone will build exactly that device. The switch has become popular enough to warrant sustaining it for decades after Ninny has long forgotten about it.

 

[hippy dave]

That's odd, surely there is a way to patch the OS to intercept the requests to read the ROM cartridge without using "massive amounts of Nintendo code". But as I said, although I've easily written over a million lines of C code in my career, not one of those lines of code was for a game console, so I honestly don't really know the architecture.

Since I'm a mix of hardware and software, if really wanted a fun project, I would build a small device that fits into the Switch's cartridge slot, into which you insert your microSD card (containing XCI dumps), and it would emulate the cartridge at the hardware level. That would be interesting for me. Actually, it will no doubt happen. Once the switch is retired and people want to use it for nostalgic retro-gaming 15 years from now, someone will build exactly that device. The switch has become popular enough to warrant sustaining it for decades after Ninny has long forgotten about it.

It's not Nintendo code, but Nintendo's cartridge certificate, afaik, that's copyrighted by Nintendo and used in SX OS's xci loading. That's what I said maybe a user would be able to dump their own for an otherwise-legal xci loading method, but I don't know if it's actually that simple.

The devs who reverse engineered the Switch's system since the beginning said that a flash cart like you describe isn't possible on the Switch. I can't tell you why exactly, and I don't have a source link, but I believe them.

 

[deltamind106]

It's not Nintendo code, but Nintendo's cartridge certificate, afaik, that's copyrighted by Nintendo and used in SX OS's xci loading. That's what I said maybe a user would be able to dump their own for an otherwise-legal xci loading method, but I don't know if it's actually that simple.

Ah, well that makes sense, but that's not "massive amounts of Nintendo code" then, which is what someone described it as.

The devs who reverse engineered the Switch's system since the beginning said that a flash cart like you describe isn't possible on the Switch. I can't tell you why exactly, and I don't have a source link, but I believe them.

Well it might not be possible right now with the keys we know, and it's definitely not possible with any kind of passive device because it would require significant CPU brains to present the right signals. But it's definitely "possible". At the end of the day, with sufficient knowledge, you can emulate *anything*.

 

[ZachyCatGames]

Ah, well that makes sense, but that's not "massive amounts of Nintendo code" then, which is what someone described it as.


Well it might not be possible right now with the keys we know, and it's definitely not possible with any kind of passive device because it would require significant CPU brains to present the right signals. But it's definitely "possible". At the end of the day, with sufficient knowledge, you can emulate *anything*.

To use flashcarts you’d need Nintendo’s private key, good luck getting that

 

[deltamind106]

To use flashcarts you’d need Nintendo’s private key, good luck getting that

Okay fair enough. So the only way a "Nintendo private key" could provide the cartridge security you're implying would be if all cartridge comms start out by first doing a public-key handshake to negotiate a variable single-use session-key to encrypt the primary comms between the switch and cartridge slot. This would make sense from the standpoint of increasing security, but it also means that the cartridges must contain a processor capable of performing said handshake/negotiation of the variable session-key. Out of curiosity, where did you learn all this to make your comment?

 

[ZachyCatGames]

Okay fair enough. So the only way a "Nintendo private key" could provide the cartridge security you're implying would be if all cartridge comms start out by first doing a public-key handshake to negotiate a variable single-use session-key to encrypt the primary comms between the switch and cartridge slot. This would make sense from the standpoint of increasing security, but it also means that the cartridges must contain a processor capable of performing said handshake/negotiation of the variable session-key. Out of curiosity, where did you learn all this to make your comment?

You can read about gamecards shit here https://switchbrew.org/wiki/Gamecard_Format here https://switchbrew.org/wiki/Gamecard_ASIC and here https://switchbrew.org/wiki/Gamecard

LOTUS handles the signature shit iirc