It's especially bizarre that ROMhacks would be suppressed from IA, when IA has played host to plain-old 100%-infringing ROMs for years now, with nobody seeming to care.
(I will not directly link to these collections, for the fates are cruel. I'll just say that these IA collections are 'complete' per-console ROM collection archives created by "GoodMerge", a ROM collection validation and repacking tool — and are named very intuitively given that.)
CBMPET2001 · 2h ago
Per the post, the takedowns are due to false positive malware flags, not because of copyright takedowns. So I guess the unmodified, 100% genuine ROMs don't trip the malware detection, whereas the mods do?
VoidWhisperer · 1h ago
The mention that it is the patchers for the ROMs that AVs/Antimalware are flagging, presumably due to them employing similar methods to those employed by malware.
waltbosz · 2h ago
I half read that but didn't absorb it fully. I wonder what about a ROM matches the signature of malware.
jonhohle · 21m ago
It’s probably too long form and stream of consciousness, but a few weeks ago I looked at GameShark “codes” and what they look like in when we having matching decompiled code and can we decompile a GameShark modded function. https://m.youtube.com/watch?v=h4398rWE1kg
Short answer is that no compiler would produce similar code and it’s probably a red flag that there’s odd dead code, jumps, or places where padding or nops are expected but there is code.
Rom hacks are more in depth, but often play the same tricks because they need to fit into possibly sections they shouldn’t exist in (say, code in BSS), encode instructions in a way that known compilers wouldn’t, long jumps to odd places.
shazbotter · 1h ago
A ROM does not. A ROMhack, however, might. A ROMhack injects code into a ROM, the same way a virus or Trojan might inject code into an executable.
fluoridation · 1h ago
I thought ROM hacks were just modified ROMs, not programs that modify ROMs. In any case, that still wouldn't make much sense. Surely an automatic patcher is a pretty trivial piece of software, system-wise. It just reads a binary file and writes out a different binary file after doing some in-memory manipulations. Why would a an AV flag such a program? I don't buy this explanation.
EDIT: Furthermore, what's the proposed workflow? Does the Internet Archive run AVs over its collections? There's no way, right? That would be a massive compute expense.
wolrah · 41m ago
> I thought ROM hacks were just modified ROMs, not programs that modify ROMs.
Distributing a modified ROM is as much copyright infringement as distributing the base ROM itself, so generally hacks are distributed as just the patch file and you have to provide your own copy of the base ROM and patch it from there.
It sounds like this site is packing the two together, and the patchers are causing the flagging issues. That also to me seems like the simple solution is to not do that and just distribute the patches without the software and have a note in the description pointing to a separate source for the patcher.
> Surely an automatic patcher is a pretty trivial piece of software, system-wise. It just reads a binary file and writes out a different binary file after doing some in-memory manipulations. Why would a an AV flag such a program? I don't buy this explanation.
A virus that wants to infect other executables on the system is going to have patching code in it where it's relatively rare in "legitimate" software so it makes sense for antimalware heuristics to find it suspicious.
fluoridation · 7m ago
>A virus that wants to infect other executables on the system is going to have patching code in it where it's relatively rare in "legitimate" software so it makes sense for antimalware heuristics to find it suspicious.
Sure, but what an AV is going to look for is code that manipulates executable files, not random binary files. If the patchers are designed to apply patch files to ROMs rather than having the patches embedded then it makes even less sense that they get flagged.
duskwuff · 1h ago
IA has always been a little haphazard with regards to copyright. Console ROMs aren't the half of it; they have an absolutely massive collection of old movies and TV shows.
boomboomsubban · 1h ago
IA works the same way as much of the internet, they allow users to upload whatever and respond to DMCA claims.
waltbosz · 2h ago
Did they host the full ROMs or patch files? Seems to me the patches would be safe to host ... but I could still see legal action taken even if the patches were legal and non-infringeing.
lemoncookiechip · 1h ago
ROMs, both modded and unmodded. For years, the most reliable way to get Fire Red (U) (Squirrels), which is one of the most used base Pokemon ROMs for modding is the Archive. Luckily it's still there with 1,574,966 views.
nativeit · 1h ago
How expensive is it to run these archives through a zipping software with encryption as part of the mirroring process? I don't have any real context to know how large these file archives are...
estimator7292 · 1h ago
A password protected zip file is just as suspicious to AVs as the original rom
cantrevealname · 39m ago
In that case, how about using extremely trivial encryption (eg., XOR every byte with 0x3B) and on the website give a one-line perl command to decrypt. Now it's random data and not a known format (like a password-protected zip file).
Of course, any AV company could add a rule to their signature checking to undo the XOR if they were targeting the romhack.ing site, but it sounds like they aren't being targeted but just getting caught up in the dragnet.
de6u99er · 58m ago
Blog post says at the bottom:
>We are open to alternative solutions and support on the matter.
(I will not directly link to these collections, for the fates are cruel. I'll just say that these IA collections are 'complete' per-console ROM collection archives created by "GoodMerge", a ROM collection validation and repacking tool — and are named very intuitively given that.)
Short answer is that no compiler would produce similar code and it’s probably a red flag that there’s odd dead code, jumps, or places where padding or nops are expected but there is code.
Rom hacks are more in depth, but often play the same tricks because they need to fit into possibly sections they shouldn’t exist in (say, code in BSS), encode instructions in a way that known compilers wouldn’t, long jumps to odd places.
EDIT: Furthermore, what's the proposed workflow? Does the Internet Archive run AVs over its collections? There's no way, right? That would be a massive compute expense.
Distributing a modified ROM is as much copyright infringement as distributing the base ROM itself, so generally hacks are distributed as just the patch file and you have to provide your own copy of the base ROM and patch it from there.
It sounds like this site is packing the two together, and the patchers are causing the flagging issues. That also to me seems like the simple solution is to not do that and just distribute the patches without the software and have a note in the description pointing to a separate source for the patcher.
> Surely an automatic patcher is a pretty trivial piece of software, system-wise. It just reads a binary file and writes out a different binary file after doing some in-memory manipulations. Why would a an AV flag such a program? I don't buy this explanation.
A virus that wants to infect other executables on the system is going to have patching code in it where it's relatively rare in "legitimate" software so it makes sense for antimalware heuristics to find it suspicious.
Sure, but what an AV is going to look for is code that manipulates executable files, not random binary files. If the patchers are designed to apply patch files to ROMs rather than having the patches embedded then it makes even less sense that they get flagged.
Of course, any AV company could add a rule to their signature checking to undo the XOR if they were targeting the romhack.ing site, but it sounds like they aren't being targeted but just getting caught up in the dragnet.