It’s the second time now that a friend reports to me that PDFiD produces no output at all when a pdf is analyzed.
In both cases, the filename was something like sample[1].pdf (a file you could find in Internet Explorer’s cache, for example).
PDFiD can process multiple files, and accepts UNIX shell-style wildcards. Not only * and ?, but also []. So with a filename like sample[1].pdf, PDFiD is actually looking for a file with filename sample1.pdf. Which it doesn’t find, and thus produces no output.
About two years ago, when first a friend reported this, I added option -l –literal. If you use this option, then PDFiD will do no wildcard expansion, and will thus find file sample[1].pdf.
Recently, another friend had the same problem. And was not aware of the existence of option -l.
This new version of PDFiD will display a warning when you use wildcard characters in filenames (without option -l) and when no files match. Like this:
I also renamed option –literal to –literalfilenames, to be consistent across my tools.
pdfid_v0_2_5.zip (https)
MD5: 9B835D9E934A7AA7E68C3649A7AA5DAF
SHA256: 4DD43D7BDA885C5A579FC1F797E93A536E1DB5A4AB52A9337759A69D3B0250E0
Didier Stevens 
[…] Update: PDFiD.py Version 0.2.5 […]
Pingback by Overview of Content Published in August | Didier Stevens — Wednesday 5 September 2018 @ 0:00