vou explicar aqui uns trechinhos bem interessantes,ainda to lendo mas algumas coisa merecem alguns comentario

Começo dos Post sobre a Estrutura e Corpo do PDF, seus Vetores de Ataque e seus Exploits Conceituais e Desenvolvidos)
se quiser pular os post's sobre este state of the art acabam aqui

https://news.1rj.ru/str/rubyofsec/1972

Antes de tudo, eh necessário construir uma visao conceitual da estrutura dos arquivos pdf

pdfs são arquivos polimórficos, ou seja, constituídos de duas estruturas primarias (physical and logical)

alterar a estutura física, não alterar necessariamente a estutura logica,
ou seja, o conteudo do pdf

a estutura física é compostra por quatro elementos fundamentais

header
eh a definiçao do arquivo(pdf) e a versao, alem de poder conter metadados, informações do usuario criador e outras informaçoes referentes aos tags do arquivo

pdf1.x

body
eh a parte interessante em si, já que consiste em grupos de objects que constroem o conteudo bruto do arquivos, esses objects podem ser representados como arvores binarias
eles seguem uma ordem inicial de (1..n), essa ordem inicial nao precisa necessariamente ser em ordem sequencial, jah que como falamos, a
alteraçao do corpo esturutural nao modifica o conteudo (obviamente alterar a esturutura que constroi explicitamente o conteudo vai
alterar o conteudo)
vamos ver mais sobre lah na frente


cross-reference
xref
eh composto por um tipo de tabela que aponta a cada inicio de object, assim como seu identificador (1..n), seu tamanho e eh apontado por offset

Trailer
aponta á cross-reference, inclui o tamanho de elementos, indica o
cross-reference por offset e o ponto inicial do body (1..n | 1) ou seja o primeiro object do body
cabe dizer que este espaço eh o primeiro a ser posto na fila de
processamento, ou seja, a ser processado durante abertura

por isso contem os apontadores fundamentais do arquivo, que eh o cross-reference, onde podemos localizar os objects por offset ou seja
xref

esses dois últimos elementos (xref & trailer)são importantíssimos
pra o processamento do pdf, já que definem uma sintaxe rapida de localizaçao do conteudo (body)
jah que o trailer, aponta a quantidades de objects esperada pelo leitor (independente do sistema ou arch) e a tabela de referencia (xref) que permite acceder o conteudo do pdf como parte do pre-processamento, ou seja, o leitor jah sabe qual eh o primeiro item a acceder
alem disso tmb permite que o arquivo seja processado sem encher (alocar) sua memoria com o arquivo inteiro nela, apenas processando o pedaço de body contendo os objects necessario, lendo esse pedaço de bytes
ou seja, apenas os objects necessarios pra a posiçao do usuario no pdf, mais objects podem ser carregados pela interaçao do usuario guiando-se do xref (o offset)
eh interessante lembrar que se um object possui sub-objects dentro de si, seu id vai ser a quantidade dentro dele

lembrando tmb que existem formas mais complexas de encontrar as xref, por exemplo a partir do pdf1.7 que implementou as incrementally ups, os xref possuim subtipos chamado xref streams, essa implementaçao permitiu pdf com mais de 10 gb e que tivesse diversas formas de object
alem dos linearized
outra curiosidade bem interessante, eh que caso o pdf esteja encriptado ele iria conter dois elementos dentro
/encrypt atribui o tipo de diccionario pra o processo de cifra
/info contem o offset que aloca o diccionario


porem, isto eh soh pra criar uma ideia fudamental do corpo estutural
tem bastante conteudo por ai caso algm se interesse em dev estes tipos de arquivos
porem ficou claro as bases que permitem que esse tipo de arquivo seja tao flexivel e tao amplamente utilizado, basta um leitor minimamente bem
trabalhado (ou nem tanto) que sua implementaçao sera bem incorporada por qlqr sistema e arch

caso tenha interesse em saber mais, recomendo pymudf, uma api bem interessante e com bastante docs, alem da iso 32000, tem tmb disponivel uma documentaçao aqui https://www.oreilly.com/library/view/developing-with-pdf/9781449327903/ch01.html e aqui https://blog.didierstevens.com/2008/04/09/quickpost-about-the-physical-and-logical-structure-of-pdf-files/
e é aquilo, basta usar algumas palavras chaves que você acha bastante no duck (physical structure of pdf, reversing on pdf format, pdf syntax, dev docs of pdf files)


bem,agr vamos pra parte mais interessante

body content (tipos de elementos objects)
bem, como jah comentei, o body, eh composto de objects
e como explicar os object??
"eles são os blocos de construção sobre os quais o PDF se sustenta”

os objects sao elementos com os quais podemos criar as propiedades do pdf, alem de escrever o conteudo (logical), existem 8 tipos de dados elementais do tipo object
Boolean, integer, real, name, string, array, dictionary, and stream

cada um deles compartilha suas funçoes e propiedades, mas aqui vamos focar especificamente em dois tipos bem especiais


dictionary
geralmente eh o tipo de object que mais vamos ver presentes numa analise do corpo de um pdf, este tipo de elemento consiste em uma chave e seu valor,
pode ser recursivo e invocar outros tipos de dados, vou explicar melhor

aqui vemos o corpo esturutural e o conteudo de um pdf o qual mostra uma pagina em branco com um hello world (criado como com um tipo stream)em
helvetica e 1 pagina
se vc observou com calma esse code, conseguiu enxergar tdo o que temos comentado ateh agr

a parte em azul eh o body e nele existem essas chaves definindo o
conteudo do corpo, isso sao o tipo de elemento dictionary, um dado associativo com uma chave invocada por /xxxx e sua funçao ou tipo de dado, lembrando que sempre precissamos implementar << ao começo
outra parte interessante eh observar o numero dos objects ( 1..n) ao lado
do seu id e observar que tdo object eh invocado por obj e terminado por endobj
pra aqueles que jah desenvolveram code em c ou python podem encontrar uma sintaxe bem familiar

existem multiplos tipos de definiçoes dictionary, alem de ser recursivo,
ou seja pode definir outro dictionary dentro de si


streams
esse tipo de elemento eh o mais expressivo dentro de um arquivo, ou seja, eh o conteudo bruto em si, podem ser dados comprimidos, imagens, graficos e ateh outros objects dentro de si
fazem que o pdf seja mais potente e pequeno
elementos streams permite carregar javanoscript dentro do pdf, alem de carregar grandes dados dentro de si, que podem ser representados de varias maneiras
por poderem ser codificadas e comprimidas de diferentes tipos de codigo arbitrarios (xml, js, imagens, anotaçoes especiais) outros objects e elementos especiais invisiveis ao usuario final
bem, nem precisso explicar o potencial disso neh

O Espirito Dentro Do Corpo (entendendo o sistema interno do pdf)
bem,tendo entendido esses conceitos, vamos pra uma partezinha bem legal

stream(filters)
certo, jah sabemos que stream podem ser blocos de bytes de grande tamanho, entao a pergunta que fica eh, como comprimimos e descomprimimos (lembrando que essa compressao em multiplos casos eh definida como uma interpretaçao, ou seja, digamos que queremos "comprimir" um tipo de fonte ou imagem de grande tamanho, o mecanismo em si pode ser chamado de codificaçao, mas vamos usar compressao pq geralmente eh o termo que mais veremos na documentaçao original) e eh ai que entra a necessidade dos filters (do tipo dictionary). Como eles podem definir as propiedades de compressao do tipo stream????
alguns filters que geralmente vamos ver em diversos documentos


flateDecode
geralmente vamos ver pra comprimir imagens e fontes, uma propiedade interessante eh que esse filter utiliza o mesmo mecanismo de compressao que zip


DCTDecode/DPXDecode
geralmente veremos em compressao de imagens compativeis com jpeg/jfif

soh uma observaçao que poderia ter feito antes, ha varias formas de chamar e definir os atributos de um tipo stream. existe um tipo de object chamado de external object, geralmente eh um tipo de stream grafico auto-contido, ou seja, ele eh definido dentro do object que invoca o elemento stream, porem fora do bloco de bytes stream, um exemplo facil eh qndo vc define alguns atributos antes de compilar alguma coisa com gcc, ou seja, um external object eh uma diretiva pra invocar um elemento stream onde seu tipo e compressao eh atribuido dentro do propio object e no modulo external-object

jah que comentei sobre; tmb existem indirect objects, ou seja objects que podem ser chamados diversas vezes em outros objects ou streams (polimorfismo), vou explicar melhor


Indirect-Object
digamos que temos o object 5 que define uma pagina ou eh uma folha de uma arvore de paginas (lembre-se que os object sao tidos como arvores binarias), entao esse object chama o object 4, porem, lah na frente iremos precissar do object 4 qndo estivermos utilizando o object 8, logo podemos definir o object 4 como um indirect object e como invocamos o object 4 varias vezes ao longo do body?? bem, tdos os indirect object possuim um id unico, que pode ser invocado dentro de outros objects e streams e eh alocado dentro do xref (lembre qndo comentei sobre subobject)
isto eh uma propiedade do polimorfismo

'alguns atributos e objetos podem ser utilizados em objetos distintos, porém,com implementações lógicas diferentes.’

uma explicaçao do orielly
‘Indirect objects are those that are referred to (indirectly!) by reference and a PDF reader will have tojump around the file to find the actual value. In order to identify which object is being referred to, every indirect object has a unique(per-PDF) ID, which is expressed as a positive number, and a
generation number, which is always a nonnegative number and usuallyzero (0).’


nossa, não achei que esse post ficaria dese tamanho, bem, agora vamos pra os nossos vetores de ataque, jah tendo entendido toda a visao conceituale esturutural do pdf

um grafico bem legal, veja bem, temos todos os componentes dos quais falamos anteriormente

olha por exemplo aqui, temos nosso object que invoca um stream, dentro temos o stream dictionary onde podemos ter as diretivas de compressao do stream (pode ser um external object criando as diretivas da invocaçao do stream ou podem ser propiedades da pagina ou do object nao relacionado diretamente com o stream) e o stream pode conter seus propios tipo de objects comprimidos apartir de filters (lembrando que filters podem cooperar dentro do stream pra comprimir de forma alterada ou simbioticamente)

Vetores de Ataque

bem, antes de publicar o restante quero explicar o que eh uma flaw "Nativa", quis expressar dessa forma pra classificar as flaws ou os conceitos de exploiting que nascem original e exclusivamente da prova de conceito do pdf, ou seja, pra exploitar essas flaws basta usar mecanismos jah presentes nos pdf, sem necessidades de uma supplychains de flaws externas
Mais a frente vou tentar explicar o que chamarei de flaws hibridas, que consistem em flaws jah existentes no sistema que suporta ou no cliente que renderiza, alem de outros tipos, nas quais usaremos o arquivo pdf pra jah expoitar elas ou carregar payloads como meio de infiltraçao ou ataque pra atingir o target
pra entender um pouco das flaws hibridas eh um pouco mais facil se jah entendermos alguns mecanismos conceituais como

| entender o mecanismo de heap spraying (class of stack overflow)(estouro do heap, geralmente utilizando javanoscript em documentos pdf (o conceito eh bem amplo, porem to me referindo apenas a ideia de flaws conhecidas em espaços que carregam tipos de arquivos pdf)) resumindo, ao estourar o heap (memoria alocada dinamicamente), se repetem codes ateh encontrar uma parte do heap que aponte a outros espaços de memoria ou funçoes fora da alocada e se escrevem bytes arbitrarios (geralmente shellcode ou bypass ( ASLR | nops leds ) pra outras funçoes com acceso privilegiado) |

| tmb eh interessante a injeçao de code arbitrario, ou seja, quando um proccesso permite ao usuario ou ao arquivo escrever dentro processo ou thread, se houver vulnerabilidade de injeçao, o usuario pode carregar sequencias arbitrarias de vetores pra injetar code que ative algum recurso ou explore alguma vulnerabilidade local |
caso nao conheça, recomendo dar uma olhada, se acha bastante conteudo e eh soh pra entender o conceito, nao eh nda mto avançado

Vetores de Ataque:
Observando os detalhes silenciosos (flaws nativas)

vamos conhecer alguns elementos que podem ser invocados (do tipo dictionary) dentro do corpo de um pdf, geralmente invocados em objects (ou suas subespécies) tmb podendo ser combinados e possuem uma relaçao simbiotica pra ofuscar ou burlar sua açao, tmb podem ser embebados e comprimidos dentro de blocos de bytes (streams ou objects-streams)


OpenAction
executa uma funçao quando o pdf for aberto, geralmente libreoffice carrega esse elemento (dictionary) pra carregar sempre a primeira pagina ao ser aberto (geralmente servidores de e-mails bem configurados ou com diretrizes estritas bloqueiam este elemento-açao)

URI
invoca uma url, combinada com outro tipo de elementos permite abrir paginas sem o conhecimento do usuario, baixar arquivos em segundo plano,enfim, cria uma açao relacionada a abertura, chamada, embebeda ou carrega pagina quando declarada e invocada

LaunchAction
invoca um parâmetro pra execuçao de comandos ou abertura de recursos do OS, pode ser adaptado pra diversos sistemas operacionais segundo a documentaçao original

GoToEmbebbed
invoca blocos de streams ou bodys incorporados dentro de outros bodys, pode chamar arquivos pdf encriptados dentro de streams e escondidos pra evitar a deteçao automatica durante a analises estatica

tmb existem alguns filters e dictionarys que possuim flaws amplamente exploitados, aqui eu coletei apenas alguns dos elementos internos que mais sao usados e bem documentados pela comunidade, porem na documentaçao vc pode se aprofundar neste elementos e seus mecanismo que como falei, geralmente sao integrados pra dificultar a deteçao automatica

referencias
Original Docs
Artigo sobre vetores de ataque EN

OPA UMA ATENÇÃO AQUI PRA SEU QUERIDO USER

pessoal, como esse post relacionado a pdf ta ficando mto mais grande do que imaginei, irei postar o restante no github

vou postar dps o link aqui, lah irei postar o restante e algumas PoC's existentes que serão a conclusão desse post, meu objetivo sempre foi que vcs conseguissem dps de tdo isso entender claramente como funcionam os exploits em arquivos pdfs e nada melhor que explicar utilizando states of the art existentes
LEMBRANDO TDO ESSE CONTEUDO EH LIVRE, COPIEM, MODIFIQUEM, COMPARTILHEM MAS PFVR SEMPRE DANDO OS CREDITOS A @rubyofsec e se possivel ao meu user