Thanks for making my heart skip a few beats thinking I was going to have a butt load of mitigation work to do for my cifs shares at the office starting immediately and ruining the last day of my weekend....
no, of course not, but I can't leave security holes wide open regardless. Having the possibility of the users privilege escalating or something like that is enough to ruin a guy's weekend regardless of the lack of direct internet access.
I genuinely did not know that the acronym had another use, apologies. Apparently Wikipedia thinks it can refers to Server Messaging Block, Super Mario Bros 3 or Super Mega Baseball 3:
Looks great. In the same vein I also enjoyed the rom hack "Super Mario Bros. 3mix". One of the worlds is space themed and features Mario Galaxy style gravity hijinks.
Oh yeah I remember 3Mix. It's got some incredibly interesting mechanics and world themes, and it felt like a huge step forward for the Mario 3 hacking scene.
I also interviewed its developer at one point too:
In a sane world, it should be as easy as sending them a counter-notice and if they decide to escalate, sending a cardboard cutout of yourself to the court with a printed "no copyrighted materials (except for some screenshots, which is fair use for illustrative purposes) exist on the website" sign to win the case.
Nintendo has shut down a bunch of fan games in the past (e.g. Pokemon Uranium) but I have never heard of any DMCA request on Mario rom hacks. I think it speaks for itself here.
The patch file will create 95% of a working ROM when applied to a blank file, but not enough to actually create a working ROM. Some important bytes are missing.
Some ROM hack patches WILL create a complete working ROM when applied to a blank file. I don't think those can even be called patches anymore.
These patch files are supposed to be diffs between the final version of the ROM after your modifications, against the original upstream ROM you started with. Ideally, they're only supposed to contain the code and assets you upserted into the game yourself.
And if you don't move anything around, then that's all they will contain.
But if you do start moving things around — sliding sections of code or data forward in memory and fixing up references to them so as to make more room for new stuff — then you run into the problem, at release time, that an .IPS file is literal binary bytewise diff. So, by moving a section forward by one byte, the .IPS file will now contain a complete copy of that section, in order to overwrite [SECT_START+1:SECT_START+N+1] with [SECT_START:SECT_START+N].
What is needed, to avoid this, is an alternative patch format, that doesn't just blindly say "overwrite [X:Y] with [binary]" but rather says something like (a binary encoding of) the following "data-unpacking command language" (here as pseudo-Elixir code):
expected_output(size: 1000, sha256: <<0x012345...abcdef>>)
require_external_data_source(id: :upstream, size: 1000, sha256: <<0x6789ab...beefee>>, description: "Super Mario World (U) v1.0 SFC ROM image")
embed_data_source(id: :patch, size: 100, sha256: <<0x777777...cafefe>>)
write_at(offset: 0, constant_u8(<<0x00>>, repeat: 100))
write_at(offset: 100, embedded_data_slice(:patch, offset: 0, len: 100)) # some patch data
write_at(offset: 200, external_data_slice(:upstream, offset: 0, len: 400)) # then some source data
write_at(offset: 204, constant_u32(<<0xaabbccdd>>, repeat: 1)) # fixup one little bit of the copied source data
embed_data(:patch, compression: :deflate, data: <<...>>)
...where the patcher tool would ask you for "Super Mario World (U) v1.0 SFC ROM image"; check that the file you provide matches the given SHA; allocate a 1000-byte output buffer; run through the write ops against the output buffer; validate that the output buffer now matches the given SHA; and then write out the output (or pass the pointer to the buffer back to the caller, if being used as a library.)
I'm not sure why no patchfile format with these semantics exists. It'd be relatively straightforward to write a library that computed such patch-op sequences from one or more infiles + one outfile, using (essentially) LZ77 to discover shifted partially-overwritten repeats, and gradient-descent optimization over alternative equivalent formulations to find minimal such descriptions.
---
Alternately, though, maybe we just shouldn't be making arbitrary low-level byte-delta patches to opaque ROM images in the first place!
IMHO we're at a point now with understanding the entire libraries of most of these old systems, that we could very well write a single program for each console that:
1. disassembles a source ROM into sections (individual assets, plus position-independent-code -ified assembly);
2. patches the text sections with git-commit-like textual diff hunks over the PIC ASM (where the tool could very well extract these from a git worktree!);
3. replaces assets wholesale with new per-asset binaries (that can be different sizes, or with different numbers in lists, or with individual assets in different formats — in which cases, the code that loads them will be automatically modified to compensate);
4. and then reassembles the ROM, computing all the fixups in the process.
Given the current state of whole-library game preservation (we've had GoodTools for a good 20 years now); and given the experience that game modders now have with building "perfect" build pipelines for game decompilation projects, that build the original ROM image... we should (IMHO) be able to set up these "high-level patchers" in such a way as to guarantee that each tool works on 100% of known titles, to losslessly reproduce the input ROM after a disasm+reasm pass.
I'd wondered why the patches could contain unmodified game code, thanks for the explanation. I know a decent chunk of the ROM hacking community has moved to UPS patches but it seems that was done for efficiency and overcoming size limitations. According to this guy, xdelta does what you describe.
Neat! I'd never heard of xdelta or BPS. Which is weird; you'd think that any large host in the ecosystem (ROMHacking.net, SMWCentral, etc) would force all posters to switch over to these formats, just to ensure that no copyrighted material is making it onto their servers.
I would assume that the less vanilla a given hack is, the likelier it is that the patch is actually a full fledged ROM. If all of the code, textures and music have been replaced, there isn't anything left.
Adding on with a wall of text diving into the specific differences in projects that either have or haven't attracted Nintendo's legal attention (tl;dr: it's a lot more than just visibility/popularity).
While it's always possible Nintendo will just decide to go after these one day (right or wrong in doing so) that they didn't even attempt to touch this particular type of Mario romhacking scene when Mario Maker came out ~10 years ago makes me think these particular types of projects (patchsets on old games without copyright protection) won't receive much trouble. Doubly so for these types of projects which don't (in and of themselves) make the game playable on unofficial systems.
Nintendo seems largely focused on direct redistribution, non-patchset based remakes, "cracking" of modern game DRM/security to allow modification/unauthorized playing, and distribution of gameplay content on media which have stricter takedown requirements than the law strictly requires (e.g. YouTube). This makes some sense as Nintendo has either previously demonstrated these types of cases in court or has previously signalled they believe they could easily do so if challenged.
While Nintendo, right or wrong in a specific instance, could definitely get away with a decent amount of "legal bullying" of individuals not interested in fighting a legal battle with a large company over their hobby website they aren't necessarily going to be interested in picking tons of such battles if they aren't relatively sure they'd win should one actually result in a real court battle. Setting precedent in court that something is explicitly okay (like 3rd party games, emulation, personal game backups) can sometimes be worse than just letting it ride as an "underground" thing. Particularly if they are defending their property elsewhere and it'd be hard for someone to argue in court these romhacks existing is counter to that.
Anyways, this wall of text is to say: sure, nobody knows what Nintendo is going to do tomorrow, but 20 years of romhacks later they've never hinted at going after this particular type of project, despite going after many nearly identical but slightly differently implemented projects, so the same "get it before Nintendo DMCAs it" comment that one would expect from those threads doesn't necessarily hold the same weight. Not that it's an absolute possibility, anything is possible, but if this type of project were the only one then people wouldn't have the "it'll be DMCA'd by tomorrow" notion.
But do back it up anyways... a great deal many more early efforts have been lost to the sands of time than Nintendo's lawyers.
Eh, 99.9% of fan projects are left alone. The worries about takedowns are seriously overblown alone, even for the likes of Nintendo properties like Mario, Zelda and Pokemon.
There have been projects and sites for those games online for over a decade without any issue, and ones played by hundreds of YouTubers that didn't have anything happen to them.
Thanks for making my heart skip a few beats thinking I was going to have a butt load of mitigation work to do for my cifs shares at the office starting immediately and ruining the last day of my weekend....
same - I was like "Oh GAWD, what now...."
On the bright side, our hearts passed the stress test.
Seriously. Change the damn title.
I hope you don't have shares exposed to the Internet.
no, of course not, but I can't leave security holes wide open regardless. Having the possibility of the users privilege escalating or something like that is enough to ruin a guy's weekend regardless of the lack of direct internet access.
It's called SMB. CIFS is an oooooold dialect, not used any longer.
google.com/search?q=smb+3 agrees - SMB 3 is the network file sharing protocol
This is super Mario bros 3, not server messaging block v3 if you were as confused as me
I genuinely did not know that the acronym had another use, apologies. Apparently Wikipedia thinks it can refers to Server Messaging Block, Super Mario Bros 3 or Super Mega Baseball 3:
https://en.wikipedia.org/wiki/SMB3
BRB going back in time and drugging Sega into making Super Monkey Ball 3 instead of whatever they were thinking with Adventure...
Really glad to see Super Mega Baseball 3 is getting the recognition it deserves.
Used to hang in the same irc room as the author. The asm hacks were impressive at the time. It's crazy it's been 20 years
Looks great. In the same vein I also enjoyed the rom hack "Super Mario Bros. 3mix". One of the worlds is space themed and features Mario Galaxy style gravity hijinks.
https://www.romhacking.net/hacks/2068/
Oh yeah I remember 3Mix. It's got some incredibly interesting mechanics and world themes, and it felt like a huge step forward for the Mario 3 hacking scene.
I also interviewed its developer at one point too:
https://gamingreinvented.com/interview/lets-interview-super-...
(also did the same for the creator of the hack mentioned in this post too)
Better archive this before Nintendo DMCAs it.
Mario rom hacks are perfectly legal since the only thing that gets distributed is a patch file - the original ROM has to be provided by the user.
Sites like SMW Central[1] contain thousands of hacks and Nintendo hasn't done anything about it.
[1] https://www.smwcentral.net/
IP holders (or their representatives) don't always let legality get in the way of issuing DMCA notices for content they don't like.
In a sane world, it should be as easy as sending them a counter-notice and if they decide to escalate, sending a cardboard cutout of yourself to the court with a printed "no copyrighted materials (except for some screenshots, which is fair use for illustrative purposes) exist on the website" sign to win the case.
We are not living in the sane world, of course.
Nintendo has shut down a bunch of fan games in the past (e.g. Pokemon Uranium) but I have never heard of any DMCA request on Mario rom hacks. I think it speaks for itself here.
Are you sure it's not a derivative work?
https://www.copyright.gov/circs/circ14.pdf
Then I guess we better archive that entire site before someone new in middle management decides to make a name for themselves by killing it.
The patch file will create 95% of a working ROM when applied to a blank file, but not enough to actually create a working ROM. Some important bytes are missing.
Some ROM hack patches WILL create a complete working ROM when applied to a blank file. I don't think those can even be called patches anymore.
Is there an agreed part everyone leaves out, or can you just apply one patch to another patch to get a complete ROM?
These patch files are supposed to be diffs between the final version of the ROM after your modifications, against the original upstream ROM you started with. Ideally, they're only supposed to contain the code and assets you upserted into the game yourself.
And if you don't move anything around, then that's all they will contain.
But if you do start moving things around — sliding sections of code or data forward in memory and fixing up references to them so as to make more room for new stuff — then you run into the problem, at release time, that an .IPS file is literal binary bytewise diff. So, by moving a section forward by one byte, the .IPS file will now contain a complete copy of that section, in order to overwrite [SECT_START+1:SECT_START+N+1] with [SECT_START:SECT_START+N].
What is needed, to avoid this, is an alternative patch format, that doesn't just blindly say "overwrite [X:Y] with [binary]" but rather says something like (a binary encoding of) the following "data-unpacking command language" (here as pseudo-Elixir code):
...where the patcher tool would ask you for "Super Mario World (U) v1.0 SFC ROM image"; check that the file you provide matches the given SHA; allocate a 1000-byte output buffer; run through the write ops against the output buffer; validate that the output buffer now matches the given SHA; and then write out the output (or pass the pointer to the buffer back to the caller, if being used as a library.)I'm not sure why no patchfile format with these semantics exists. It'd be relatively straightforward to write a library that computed such patch-op sequences from one or more infiles + one outfile, using (essentially) LZ77 to discover shifted partially-overwritten repeats, and gradient-descent optimization over alternative equivalent formulations to find minimal such descriptions.
---
Alternately, though, maybe we just shouldn't be making arbitrary low-level byte-delta patches to opaque ROM images in the first place!
IMHO we're at a point now with understanding the entire libraries of most of these old systems, that we could very well write a single program for each console that:
1. disassembles a source ROM into sections (individual assets, plus position-independent-code -ified assembly);
2. patches the text sections with git-commit-like textual diff hunks over the PIC ASM (where the tool could very well extract these from a git worktree!);
3. replaces assets wholesale with new per-asset binaries (that can be different sizes, or with different numbers in lists, or with individual assets in different formats — in which cases, the code that loads them will be automatically modified to compensate);
4. and then reassembles the ROM, computing all the fixups in the process.
Given the current state of whole-library game preservation (we've had GoodTools for a good 20 years now); and given the experience that game modders now have with building "perfect" build pipelines for game decompilation projects, that build the original ROM image... we should (IMHO) be able to set up these "high-level patchers" in such a way as to guarantee that each tool works on 100% of known titles, to losslessly reproduce the input ROM after a disasm+reasm pass.
I'd wondered why the patches could contain unmodified game code, thanks for the explanation. I know a decent chunk of the ROM hacking community has moved to UPS patches but it seems that was done for efficiency and overcoming size limitations. According to this guy, xdelta does what you describe.
https://www.reddit.com/r/Roms/comments/wj29mf/comment/ijhrak...
Neat! I'd never heard of xdelta or BPS. Which is weird; you'd think that any large host in the ecosystem (ROMHacking.net, SMWCentral, etc) would force all posters to switch over to these formats, just to ensure that no copyrighted material is making it onto their servers.
SMW Central does require all hacks to be submitted in the form of BPS files.
I think ROM Hacking.net had similar requirements, though given it's closed for submissions now, it's not relevant anymore.
I believe .bps allow you to you essentially what you describe. Spec here: https://github.com/blakesmith/rombp/blob/master/docs/bps_spe...
theseus's copyright infringement
I would assume that the less vanilla a given hack is, the likelier it is that the patch is actually a full fledged ROM. If all of the code, textures and music have been replaced, there isn't anything left.
Adding on with a wall of text diving into the specific differences in projects that either have or haven't attracted Nintendo's legal attention (tl;dr: it's a lot more than just visibility/popularity).
While it's always possible Nintendo will just decide to go after these one day (right or wrong in doing so) that they didn't even attempt to touch this particular type of Mario romhacking scene when Mario Maker came out ~10 years ago makes me think these particular types of projects (patchsets on old games without copyright protection) won't receive much trouble. Doubly so for these types of projects which don't (in and of themselves) make the game playable on unofficial systems.
Nintendo seems largely focused on direct redistribution, non-patchset based remakes, "cracking" of modern game DRM/security to allow modification/unauthorized playing, and distribution of gameplay content on media which have stricter takedown requirements than the law strictly requires (e.g. YouTube). This makes some sense as Nintendo has either previously demonstrated these types of cases in court or has previously signalled they believe they could easily do so if challenged.
While Nintendo, right or wrong in a specific instance, could definitely get away with a decent amount of "legal bullying" of individuals not interested in fighting a legal battle with a large company over their hobby website they aren't necessarily going to be interested in picking tons of such battles if they aren't relatively sure they'd win should one actually result in a real court battle. Setting precedent in court that something is explicitly okay (like 3rd party games, emulation, personal game backups) can sometimes be worse than just letting it ride as an "underground" thing. Particularly if they are defending their property elsewhere and it'd be hard for someone to argue in court these romhacks existing is counter to that.
Anyways, this wall of text is to say: sure, nobody knows what Nintendo is going to do tomorrow, but 20 years of romhacks later they've never hinted at going after this particular type of project, despite going after many nearly identical but slightly differently implemented projects, so the same "get it before Nintendo DMCAs it" comment that one would expect from those threads doesn't necessarily hold the same weight. Not that it's an absolute possibility, anything is possible, but if this type of project were the only one then people wouldn't have the "it'll be DMCA'd by tomorrow" notion.
But do back it up anyways... a great deal many more early efforts have been lost to the sands of time than Nintendo's lawyers.
[dead]
Eh, 99.9% of fan projects are left alone. The worries about takedowns are seriously overblown alone, even for the likes of Nintendo properties like Mario, Zelda and Pokemon.
There have been projects and sites for those games online for over a decade without any issue, and ones played by hundreds of YouTubers that didn't have anything happen to them.
This looks incredibly well-designed and documented, can't wait to watch some speed runs!
I read this as Samba and was super worried for a moment.
I might just not be seeing it but is there any video with the gameplay to watch?
Most I can find is the trailer for the demo:
https://www.youtube.com/watch?v=VN1ORLvuamI
Unfortunately, the author seems to market their work on Facebook more than anywhere else, without much of a YouTube presence or what not.
She does have multiple videos on that channel [1] tough, including development videos [2].
[1] https://www.youtube.com/@DahrkDaiz/videos
[2] https://www.youtube.com/watch?v=Pb7HQ6jSCf0
I watched a 4 hour stream today. I know, I had no idea I was going to watch that long either.
It's really fascinating what has been accomplished