Probably incorrect output running Binwalk on a Panasonic PVR firmware file about binwalk HOT 4 CLOSED

I agree, all of the PNGs are definitely false positives. In fact, all of those results look like false positives. I've updated those signatures with better false positive detection in the 2.0 branch; will close this issue once the 2.0 branch is merged with master (soon).

from binwalk.

Trying with the 2.0 branch gives other interesting results, not quite right yet still.

DECIMAL       HEXADECIMAL     DESCRIPTION
------------------------------------------------------------------------------------------------------------------------------------------------------
3775813       0x399D45        gzip compressed data, from VMS, last modified: Sat Feb 2 13:33:24 2013
22228649      0x1532EA9       TIFF image data, big-endian
24074975      0x16F5ADF       ELF 32-bit LSB
25198157      0x1807E4D       mcrypt 2.2 encrypted data, algorithm: SAFER-SK64, mode: CFB, keymode: MD5 hash
25250984      0x1814CA8       ELF 32-bit LSB
57543449      0x36E0B19       Zip archive data, compressed size: 901619, uncompressed size: 565116672, name: "" 
59213730      0x38787A2       Foscam WebUI filesystem, checksum: 0xE0DA, first file name: "~D" 

This file seems to be packed or encrypted, so I'm not expecting miracles, I'm doing this more for interest's sake.

from binwalk.

The gzip signature already performs quite a bit of validation on the header, and from the output it does look like a valid gzip header. From a signature standpoint, that's probably going to be as good as it gets. I could add a gzip validation plugin to check the first block of compressed data and make sure that it looks valid though - I'll put it on the TODO list.

The TIFF signature could certainly be more robust - I'll have to look into the TIFF file format in more detail to see if additional pieces of the header can be validated.

The ELF headers could be automatically marked as invalid since the architecture is unknown. The problem is that I've seen vendors set custom values for such fields, so I'd be hesitant to do this; it's probably best to leave that decision up to the user. I'm open to suggestions though.

mcrypt has always been a pain to validate. I don't think there's much else that can be done for that signature (except for potentially a plugin, as with gzip).

I've updated the ZIP and Foscam signatures in the repository, you shouldn't be getting those false positives anymore.

from binwalk.

Finally added a validation plugin for gzip, which should all but eliminate false positive gzip results.

from binwalk.