open my $ZIP, '+<', 'test.zip';
local $/ = undef;
my $data = <$ZIP>;
my @offset;
while ($data =~ /PK\x03\x04/g) { # find all file headers
   push @offset, pos($data) - 4;
}
print "Found headers at: @offset\n";
substr($data, $offset[1]+14, 1) ^= "\x01"; # change the crc
seek $ZIP, 0, 0;
print $ZIP $data;
[download]

Ok so now I'm confused. I was able to corrupt the CRC on a zip file. The unzip utility run with the -t shows the corruption

# unzip -t bad.zip
Archive:  bad.zip
    testing: testfile.txt             OK
    testing: testfile2.txt            bad CRC 32e1dbe6  (should be 32f
+0dbe6)
At least one error was detected in bad.zip.
[download]

But when I run the ziptest.pl utility from the examples directory it shows the CRC as good

# ./ziptest.pl bad.zip
 Length    Size         Last Modified         CRC-32  Name
-------- --------  ------------------------  -------- ----
      26       14  Mon Aug 28 18:07:58 2017  75b0ca95 testfile.txt
      15        9  Mon Aug 28 18:08:10 2017  32e1dbe6 testfile2.txt
All CRCs check OK
[download]

So what exactly is $member->crc32 doing? Shouldn't it be checking the crc listing as expected in the zip file and not getting the CRC after the file is extracted?

Buried treasure! A zip file contains two copies of the file metadata, one just before the data and one at the end of the zip. Unzip uses the first one, and ziptest.pl uses the second. Neither one notices that the two copies don't match. You can modify my little script like this to make ziptest.pl complain:

while ($data =~ /PK\x01\x02/g) ... # find all file headers
substr($data, $offset[1]+16, 1) ^= "\x01"; # change the crc
[download]