> the MD5 is clearly in the plaintext here
Alright, I'll bite: at what byte offset in the binary file contents does a trivial encoding[0] of the MD5 hash occur?
> the NES ROM is only the first 40k of the file. It is not able to scan itself and print out a hash that way.
It is possible to encode the effects of multiple blocks of arbitrary[1] data on a hash function internal state (independently of what state you start in) in much less space than that data actually takes up, although I'll grant that actually doing so is somewhat impressive in it's own right, so I don't have a trivial translation to SHA 256 immediately ready to post.
Edit: tracked down my saved version:
$ md5sum pocorgtfo14.pdf
5eaf00d25c14232555a51a50b126746c pocorgtfo14.pdf
$ grep -aoi 5eaf00d pocorgtfo14.pdf || echo not found
not found
$ # using ...b126746c because 5eaf00... has a nul
$ grep -aoF $(printf '\xb1\x26\x74\x6c') pocorgtfo14.pdf || echo not found
not found
The MD5 is definitely not
clearly in the plaintext here, though it could be only mildly unclear.
0: Eg, I'd accept 31 34 63 63 38 35 63 34 ... as an encoding of 14cc85c4... from above.
1: Including random/incompressible data.
