Hacker News Reader

Comment by y4mi | Hacker News Reader

The files are also often delivered via USB Stick which are usually formatted with a filesystem without bitrot detection. That would be indistinguishable from someone manually screwing with the file too.

You can never be certain wherever the damage was caused by bitrot or a person screwing with the file, but certain patterns are very unlikely to occur naturally so a reasonable guess is at least somewhat possible

View on HN

My whole form of copy protection on AIR apps through about 2013 was basically to have the login system side-load another SWF once the user logged in - but the SWF's bytecode would be tweaked and corrupted in a way that required a valid response to the login to de-corrupt on the client side before it could be executed. Probably just the fact that you would've had to decompile the side-loader was enough to prevent it from being stolen.

Hey, I had a similar copy protection scheme for binaries during the 90s :)

Hah. It's pretty awesome to hear that from a Firefox dev. I look back at it and wonder... what was the point? I think I was just having fun. I even went as far as having two "patches", where the first one made the software work but without the second one, it would send your VM and browser into a death loop after about 30 seconds. It was just the right amount of time to cause an SWF decompiler on Windows to crash the whole system. Anyone who wanted it badly enough would have gotten it, and I doubt anyone ever put in the effort to hit that spiral, so I must have just been entertaining myself ;)

Based on OP comment about showing the hex to the clas, my bet is the perp opened the file in notepad, jammed on the keyboard (ascii characters) or worse yet, typed a message proceeding or following the content (depending on the format), making it very obvious that it was an intentionally introduced error.

Reply on news.ycombinator.com