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 3 days ago | parent [-]

> 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.

▲

derefr 2 days ago | parent | next [-]

I think you're just guessing here without an accurate mental model of what is being described.

> It sounds like this site is packing the two together,

1. No; as you said, no ROM hacking site distributes the original ROM. This one is no exception. They don't want to flagrantly violate copyright. (And in fact, modern patch formats — xDelta, UPS, BPS — are designed to avoid even minor "quotations" of the original copyrighted material, by using "copy offset:length" ops, or by storing partial/sparse patch segments as XOR deltas of the old and new files.)

> and the patchers are causing the flagging issues

2. No ROM hacking site distributes a patcher executable along with the patch. It'd be a huge waste of both bandwidth and storage space on their CDN. Besides the very reason coming up here (novel archives containing executables make anti-virus programs unhappy), there's also the fact that modern emulators, when loading a ROM, will auto-apply a patch in-memory if one is found in the same directory + with the same basename as the ROM. (Similar to how VLC auto-loads subtitle files if found beside a video file.) Creating an on-disk modified ROM using an explicit patcher utility is, for the most part, unnecessary today.

FYI, I downloaded the first ROMhack I saw from the referenced site (romhack.ing). It was a .zip file. Decompressing it, all it contained was a set of .ips files (variants of the patch) and a README.txt.

In short, there is no inherent, structural reason that a site hosting only archive files like this one, would trigger any anti-virus system.

▲

fluoridation 3 days ago | parent | prev [-]

>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.

▲

shazbotter 2 days ago | parent [-]

An executable is a random binary file...

	▲	fluoridation 2 days ago \| parent [-]
		Every file is binary. So are AVs going to start flagging every program that does anything to any file?