pdf-files: resultados de “pdfid”

Question

Didier Stevens produziu um programa chamado "pdfid" ( link e link ).

Ele diz:

"I’ve developed a new tool to triage PDF documents, PDFiD. It helps you differentiate between PDF documents that could be malicious and those that are most likely not."

E é por isso que eu quero usá-lo.

"PDFiD will scan a PDF document for a given list of strings and count the occurrences (total and obfuscated) of each word:"

obj

endobj

stream

endstream

xref

trailer

startxref

/Page

/Encrypt

/ObjStm

/JS

/JavaScript

/AA

/OpenAction

/AcroForm

/JBIG2Decode

/RichMedia

/Launch

/XFA

Até onde eu sei, os valores de "obj" e "endobj" devem corresponder, o que significa que não há nenhum objeto aberto que não tenha sido fechado (talvez causando estouro de buffer) ou qualquer outra coisa).

E idealmente

/ JS / JavaScript / AA / OpenAction / AcroForm

deve ter valor zero.

Ainda vi muitos documentos em pdf com "obj" e "endobj" não combinando, mas os outros valores parecem ser o.k.

Exemplo: Using_FreeDOS.pdf do link .

Os resultados do pdfid:

 PDF Header: %PDF-1.4

 obj                  520

 endobj               519

 stream               193

 endstream            193

 xref                   1

 trailer                1

 startxref              1

 /Page                100

 /Encrypt               0

 /ObjStm                0

 /JS                    0

 /JavaScript            0

 /AA                    0

 /OpenAction            1

 /AcroForm              0

 /JBIG2Decode           0

 /RichMedia             0

 /Launch                0

 /EmbeddedFile          0

 /XFA                   0

 /URI                   8

 /Colors > 2^24         0

No entanto, este também tem "/ OpenAction 1". Não sei ao certo o quão relevante isso é.

No entanto:

qual a importância do fato de que "obj" e "endobj" coincidem quando o resto da lista de strings e count é o.k?

Como já foi dito: existem vários documentos em PDF com "obj" e "endobj" não correspondentes.

    

Answer 1

O pdfid aparentemente está fazendo um péssimo trabalho na contagem dos pares obj / endobj - em seu exemplo particular, o "obj" ímpar é parte de um fluxo FlateDecode:

$ cat pdf.pl
use Compress::Zlib qw(inflateInit Z_STREAM_END);
use strict;
my ($o);
while(<>){
        $o -= s/\bendobj\b//g;
        $o += s/\b\d+\s+\d+\s+obj\b//g;
        if(/\bstream\s*$/){
                local $/ = "endstream"; my $s = <>; $s =~ s/\s*endstream$//;
                if($s =~ /(\w*obj)/){
                        my ($d, $err) = inflateInit->inflate($s);
                        if(length($s) == 0 && $err == Z_STREAM_END){
                                warn "innocuous '$1' in well formed stream\n";
                        }else{
                                warn "WARNING: inflateInit: $err\n";
                        }
                }
        }
        if(/(\w*obj)\b/){ warn "WARNING: possible stray $1\n" }
}
warn "WARNING: unbalanced obj/endobj: $o\n" if $o;
$ perl pdf.pl using-freedos-24.pdf
innocuous 'obj' in well formed stream

Nota: pouco é para ilustrar o problema em questão; não use para verificar se um pdf é seguro; -)

O formato pdf é bastante desagradável & complexo; você realmente precisa de um analisador completo para entender sua estrutura. E um programa capaz de fazer isso (para identificar corretamente os arquivos maliciosos) está se tornando um vetor de ataque em si - não há razão para acreditar que um analisador ad-hoc é mais seguro que libpoppler ou libmupdf.