Not the parent and not sure what s/he meant, but one could imagine software that borks when there are invalid (but nonobvious) characters in the filename, for example. Or file permissions or other extended filesystem attributes / resource forks if somehow you can get them delivered to the teacher that way.

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

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.

You could just do what I did instead. To make it less evident that it was tempered with, I'd copy a random chunk of the original file and insert it a few times with random offsets.

Another way: corrupt the formatting such that the file doesn’t show anything. Think the equivalent of adding a CSS property like body {margin-left: -10000px}. File would be perfectly valid but display as blank.

That's not too useful when plenty of students just send in a plain blank document. Corrupting it in one way that looks like a -different- way of slacking isn't so useful.

Why not send a blank file then? The point is that you want the editor to error and fail to read so they can’t tell that you didn’t do the work.

Because a blank file will have a tiny file size and will look like... a blank file. You want it to look like something went wrong such that the file couldn't be opened, but that it would have content if you could.

I'd bet that for the average tech illiterate teacher that's used to lazy students, it would be more work to explain how it could possibly NOT be the student's fault if they got an empty(looking) docx.

Mr. McGuire : I just want to say one word to you. Just one word.

Benjamin : Yes, sir.

Mr. McGuire : Are you listening?

Benjamin : Yes, I am.

Mr. McGuire : Metadata.

(also see https://en.wikipedia.org/wiki/Resource_fork)

"The Windows NT NTFS can support forks (and so can be a file server for Mac files), the native feature providing that support is called an alternate data stream."

you could just truncate it at page (4k multiple) boundary. very hrad to prove intent