Neither NFO is "corrupted" in the sense of being incomplete or having been modified as both files clearly contain the exact same visible text. The difference comes from the
EOL format the NFOs were saved in. This modifies the file's binary data by changing all instances of
0x0D 0x0A
to simply
0x0A
, which decreases the size by 1 byte for each line and causes a different hash to be calculated.
Conversion between the EOL formats can easily be done with
(
Edit
->
EOF conversion
) or from the terminal (note the hashes):
Code:
# apt install libarchive-zip-perl
$ file idaprov9.nfo && crc32 idaprov9.nfo
idaprov9.nfo: ASCII text, with CRLF line terminators
33265862
# apt install dos2unix
$ dos2unix idaprov9.nfo 2> /dev/null && file idaprov9.nfo && crc32 idaprov9.nfo
idaprov9.nfo: ASCII text
3507b2b7
$ unix2dos idaprov9.nfo 2> /dev/null && crc32 idaprov9.nfo
33265862
Both admin's source ("AXX") and that of the
srrDB upload have a Unix EOL format NFO, which may have been caused by a misconfigured FTP client as speculated in the last paragraph of the comment linked above. This would also explain why the NFOs of some non-0DAY scene releases "leak" to P2P in the Unix EOL format, but their SFVs all still use the standard Windows one.
Though for this particular release one can be certain which EOL format is "correct" because rule 2.3 of the current
requires an NFO to be "included in at least the first disk of the release" (most groups put them into all ZIP parts) and
all eleven match the Windows CRC32 shown above:
Code:
$ 7z l -slt "Hex.Rays.IDA.Pro.v9.0.240925-HEXRAYS/*.zip" idaprov9.nfo | grep ^CRC
CRC = 33265862
CRC = 33265862
CRC = 33265862
CRC = 33265862
CRC = 33265862
CRC = 33265862
CRC = 33265862
CRC = 33265862
CRC = 33265862
CRC = 33265862
CRC = 33265862