Eh, with something this horrendously egregious I think their customers have a right to know how carelessly their data was handled, regardless of the remediation steps taken after disclosure; that aside, who knows how many other AI SaaS vendors might stumble across this article and realize they've made a similarly boneheaded error, and save both themselves and their customers a huge amount of pain . . .
I think they're referring to the 'signed checksum' field on the document, and this line from the article
> Interestingly, the certificate page was identical in both documents, including the checksums, despite the content being different.
I think they took this to mean that the signed copy and the copy with the fraudulent addendum both hashed to the same checksum, but I'm not sure that's what was meant; based on the article it's not obvious to me that OP was able to check the signed checksum, though I can't imagine they didn't try. It's the 'original checksum' field that matched the base.pdf clean document without signature or addendum.
No, the modified copy included the same certificate page simply because it was a modified copy of the PDF with the certificate page. There's no actual way I've determined to verify the signed checksum field.
Ah, so the 'signed checksum' field isn't actually the checksum of the signed document? How odd . . . but yeah, now that I think about it, they couldn't know the hash of a document before they generate it, but they would need to in order to include it in the document, hence an impossible cycle; they must have overlooked that . . .
OP mentions in the article that the draft was uploaded on 9/22/25, so it can't have been a simple mix up where the version with the addendum was the one they had originally intended to have signed, since it didn't exist yet.
If you just mean that they had the second version in their system but never intended to send it at all, then I'm not sure what possible innocent explanation there would be for uploading a newly modified version of an already signed lease that's run its course.
Ok, that makes sense. I re-read the post. I thought the signed doc checksum was the same for both, but it seems like the certification page is inserted into the actual document, thus breaking your ability to verify the final document checksum? Seems strange that the provider doesn't email the final doc to both parties after signing. Also, kinda weird that they knew it would say uploaded 9/22 and still offered to screen share.
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?
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.
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.
No virus scanner understands how to run game console executables and could detect unusual code layout in ROMs, nor do they want to because those aren't viruses.
I’m not sure which rom hacks were being flagged, but most consoles use CPUs that were also at one point used in computers or phones as well. Is it likely that a virus scanner is going to flag a MIPS binary (PS1, PS2, N64)? Probably not. But what’s the difference to a virus scanner whether an x86, PowerPC, or ARM binary is meant for a console, phone, or a computer.
Or more simply, it could be packed with a README that links back to a modding group that hosts stuff on a site with malware or other “hacker” tools.
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.
> 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.
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.
>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.
See for example the practice of civil forfeiture in the US, where the police is able to seize your property until you prove that it wasn't gained through crime. The proceeds go directly to the police department. So the more passers-by they harass, the sooner the "pennies from heaven" will fund their margarita machine! [0]
I'm not sure how Spanish criminal law works, but even if it does work like in the US, the press release doesn't actually mention any seized funds or property at all
Not sure that such a heavily edited two-minute clip is fully representative of the over hour and a half-long meeting (which also includes a presentation detailing the years worth of science done in the leadup to that meeting)[0]
