Sinais de fraude em PDF: o guia de campo

Vocabulário de severidade

Quatro severidades, em hierarquia estrita. Elas descrevem quanto um achado isolado estabelece por si só, não a probabilidade de fraude.

• alta Por si só estabelece que o documento mudou após a geração, ou que uma ferramenta com intenção de edição esteve envolvida.
• média Um desvio real do padrão "escrito uma única vez por uma única ferramenta", com explicações legítimas comuns.
• baixa Fraca ou baseada em ausência; remove um fato corroborante em vez de acrescentar um.
• info Contexto. Não entra no signalCount e não contribui em nada para a pontuação.

Um relatório contém no máximo um sinal por família — isso é uma invariante do relatório. Uma família ou dispara uma única vez, com todos os seus achados reunidos em um único objeto evidence, ou não aparece de forma alguma. Os sinais são ordenados do mais severo para o menos severo e, em seguida, alfabeticamente por id, de modo que os relatórios são estáveis byte a byte entre execuções.

1. Histórico de revisões

2. Metadados

3. Conteúdo da página

4. Assinaturas e estrutura

Documentos criptografados: o que o relatório diz que não fez

Quando o trailer referencia um dicionário /Encrypt, as strings e os streams do arquivo são texto cifrado. Valores de metadados, nomes de fontes incorporadas e streams de conteúdo de página não podem ser lidos sem a senha, que a Tamperlens não possui e nunca pede.

O comportamento ingênuo seria rodar todas as famílias de sinais mesmo assim e reportar o que disparasse sobre o ruído. Em vez disso, as cinco famílias dependentes de conteúdo não rodam de forma alguma e a omissão é divulgada como parte de primeira classe do relatório:

• metadata-mismatch
• date-anomalies
• producer-fingerprint
• font-anomalies
• hybrid-page

A divulgação chega como o sinal structure-warnings, com o título "Documento criptografado — conteúdo não analisado", carregando evidence.code: "encrypted-content-not-analysed", a lista explícita suppressedFamilies, contentAnalysed: false e structuralAnalysisRan: true. Ela viaja em structure-warnings em vez de chegar como sinal próprio por causa da invariante de um sinal por família.

A análise estrutural não é afetada e de fato roda. A contagem de revisões, o par /ID do trailer, os intervalos de bytes das assinaturas e a consistência das referências cruzadas são todos legíveis sem a senha, assim como a detecção de dicionários de ação — chaves de dicionário também não são criptografadas. Metadados que por acaso sejam legíveis como texto simples ainda são reportados: um produtor pode deixar o pacote XMP em claro via /EncryptMetadata false, e um teste de plausibilidade de texto deixa isso passar enquanto descarta campos cujos bytes não são texto legível. Quaisquer campos descartados dessa forma são nomeados em metadataFieldsSuppressed.

Como os sinais viram uma pontuação

summary.riskScore é uma agregação ponderada de 0 a 100, não uma probabilidade e não uma confiança. As regras são curtas o bastante para serem enunciadas por completo — e esse é o ponto: você deve conseguir reconstruir o número a partir da lista de sinais.

• Pesos. high 70, medium 25, low 10, info 0.
• Pisos. Um sinal high força a pontuação para pelo menos 70; um medium força pelo menos 30.
• Retornos decrescentes. Os dois primeiros sinais de uma dada severidade contribuem com seu peso integral; a partir daí, cada sinal adicional da mesma severidade contribui com uma fração que decai acentuadamente. Um acúmulo de achados fracos converge em vez de somar indefinidamente.
• A faixa alta é reservada. Sem nenhum sinal high presente, a pontuação é limitada a 69, diga o que disser a aritmética. Assim, riskBand === "high" é exatamente equivalente a "pelo menos um achado que, por si só, estabelece uma mudança".
• Faixas. Abaixo de 30, low; de 30 a 69, elevated; 70 ou mais, high.
• signalCount conta os sinais acima de info. Um achado informativo é visível no relatório, mas invisível para a contagem e para a pontuação.

Os pesos são versionados por engineVersion: alterá-los é uma mudança de versão, então uma pontuação que você registrou no trimestre passado continua significando o que significava. O motor é determinístico — bytes idênticos produzem um relatório idêntico, exceto pelo id de cada chamada — o que significa que você pode fixar fixtures e testar por regressão os seus próprios limiares contra nós.

Como usar isto com honestidade

Três hábitos que separam uma etapa de triagem útil de um gerador de clientes furiosos:

1. Estabeleça a baseline antes de definir limiares. Rode pelo motor documentos que você acredita serem genuínos, agrupados por emissor, e observe quais sinais disparam normalmente na sua população. Strings de producer e hábitos de revisão variam enormemente entre instituições.
2. Reporte o fato, não a inferência. "Este arquivo contém duas revisões e nomeia um editor de PDF online" é defensável e específico. "Nosso sistema marcou este documento como fraudulento" não é nenhum dos dois — e é a frase que acaba em uma reclamação.
3. Correlacione. Um único sinal de severidade média é uma pergunta. Um editor de consumo mais uma revisão que sobrescreve conteúdo mais dois subconjuntos de um mesmo tipo de letra é uma história coerente — e a história é aquilo sobre o que um revisor humano pode agir.

Leitura relacionada

• Forense de metadados de PDF (em inglês) Onde cada peça de evidência vive fisicamente no formato de arquivo.
• Como saber se um PDF foi editado As mesmas verificações feitas à mão, com comandos de shell.
• Sinais de fraude em extratos bancários (em inglês) O guia de campo aplicado a fluxos de crédito, BNPL, proptech e onboarding.
• Guia rápido e preços da API Autenticação, as duas formas de requisição, o JSON do relatório anotado, cotas.