<summary><strong>Aprenda hacking no AWS do zero ao herói com</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se você quer ver sua **empresa anunciada no HackTricks** ou **baixar o HackTricks em PDF**, confira os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)!
* Adquira o [**material oficial PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção de [**NFTs**](https://opensea.io/collection/the-peass-family) exclusivos
* **Junte-se ao grupo** 💬 [**Discord**](https://discord.gg/hRep4RUj7f) ou ao grupo [**telegram**](https://t.me/peass) ou **siga-me** no **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
* **Compartilhe suas técnicas de hacking enviando PRs para os repositórios github** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
Para verificar se as chamadas de sistema são feitas corretamente, deve-se compilar o programa anterior e as chamadas de sistema devem aparecer em **strace ./PROGRAMA\_COMPILADO**
Ao criar shellcodes, pode-se usar um truque. A primeira instrução é um salto para um call. O call chama o código original e também coloca o EIP na pilha. Após a instrução call, inserimos a string que precisávamos, então com esse EIP podemos apontar para a string e também continuar executando o código.
Consiste em um pequeno código que percorre as páginas de memória associadas a um processo em busca da shellcode armazenada (procura por uma assinatura colocada na shellcode). Útil nos casos em que se tem apenas um pequeno espaço para injetar código.
Consistem em shells criptografadas que possuem um pequeno código que as descriptografa e salta para ela, utilizando o truque de Call-Pop este seria um **exemplo de cifra de César**:
Dessa forma, se for possível modificar o EBP ao sair de uma função (fvuln) que foi chamada por outra função, quando a função que chamou fvuln terminar, seu EIP pode ser modificado.
Em fvuln, pode-se introduzir um EBP falso que aponte para um local onde esteja o endereço da shellcode + 4 (deve-se adicionar 4 pelo pop). Assim, ao sair da função, será colocado no ESP o valor de &(\&Shellcode)+4, com o pop serão subtraídos 4 do ESP e este apontará para o endereço da shellcode quando o ret for executado.
Permite-se modificar apenas o byte menos significativo do EBP. Pode-se realizar um ataque como o anterior, mas a memória que guarda o endereço da shellcode deve compartilhar os 3 primeiros bytes com o EBP.
O ASLR faz com que em cada execução as funções sejam carregadas em posições diferentes da memória. Portanto, este método pode não ser eficaz nesse caso. Para servidores remotos, como o programa está sendo executado constantemente no mesmo endereço, pode ser útil.
Coloca-se o endereço da instrução system da libc e passa-se como argumento a string “/bin/sh”, normalmente de uma variável de ambiente. Além disso, usa-se o endereço da função exit para que, uma vez que a shell não seja mais necessária, o programa saia sem causar problemas (e escrever logs).
“A” \* DISTÂNCIA EBP + 4 (EBP: podem ser 4 "A"s, embora seja melhor se for o EBP real para evitar falhas de segmentação) + Endereço de **system** (sobrescreverá o EIP) + Endereço de **exit** (ao sair de system(“/bin/sh”) esta função será chamada, pois os primeiros 4 bytes da stack são tratados como o próximo endereço do EIP a ser executado) + Endereço de “**/bin/sh**” (será o parâmetro passado para system)
Dessa forma, o EIP será sobrescrito com o endereço de system, que receberá como parâmetro a string “/bin/sh” e, ao sair desta, executará a função exit().
Pode-se encontrar a situação em que algum byte do endereço de alguma função seja nulo ou espaço (\x20). Nesse caso, podem-se desmontar os endereços anteriores a essa função, pois provavelmente haverá vários NOPs que nos permitirão chamar algum deles em vez da função diretamente (por exemplo, com > x/8i system-4).
Este método funciona porque, ao chamar uma função como system usando o opcode **ret** em vez de **call**, a função entende que os primeiros 4 bytes serão o endereço **EIP** para o qual retornar.
Uma técnica interessante com este método é chamar **strncpy()** para mover um payload da stack para o heap e, posteriormente, usar **gets()** para executar esse payload.
Outra técnica interessante é o uso de **mprotect()**, que permite atribuir as permissões desejadas a qualquer parte da memória. Serve ou servia em BSD, MacOS e OpenBSD, mas não em linux (controla que não se possam conceder ao mesmo tempo permissões de escrita e execução). Com este ataque, poderia-se reconfigurar a stack como executável.
Dessa forma, podem-se encadear funções a serem chamadas. Além disso, se quiser usar funções com vários argumentos, podem-se colocar os argumentos necessários (ex. 4) e colocar os 4 argumentos e procurar um endereço com os opcodes: pop, pop, pop, pop, ret —> **objdump -d executável**
Esta shellcode pode ser repetida indefinidamente nas partes da memória às quais se tem acesso, de forma que se consiga uma shellcode facilmente divisível por pequenos pedaços de memória.
Útil quando não se pode colocar um endereço da stack no EIP (verifica-se que o EIP não contenha 0xbf) ou quando não se pode calcular a localização da shellcode. No entanto, a função vulnerável aceita um parâmetro (a shellcode irá aqui).
Dessa forma, ao mudar o EIP para um endereço de um **ret**, carregar-se-á o endereço seguinte (que é o endereço do primeiro argumento da função). Ou seja, carregar-se-á a shellcode.
O exploit seria: SHELLCODE + Preenchimento (até EIP) + **\&ret** (os bytes seguintes da pilha apontam para o início da shellcode, pois se coloca na stack o endereço do parâmetro passado)
Parece que funções como **strncpy** uma vez completas eliminam da pilha o endereço onde estava guardada a shellcode, impossibilitando esta técnica. Ou seja, o endereço que passam à função como argumento (o que guarda a shellcode) é modificado por um 0x00, então ao chamar o segundo **ret** encontra-se com um 0x00 e o programa termina.
Se não temos controle sobre o primeiro argumento, mas sim sobre o segundo ou o terceiro, podemos sobrescrever o EIP com um endereço para pop-ret ou pop-pop-ret, conforme necessário.
Observando como a pilha de um novo processo no Linux é construída, é possível desenvolver um exploit de forma que o programa seja iniciado em um ambiente cuja única variável seja a shellcode. O endereço desta pode ser calculado como: addr = 0xbfffffff - 4 - strlen(NOME\_executável\_completo) - strlen(shellcode)
Como o ESP sempre aponta para o início da pilha, esta técnica consiste em substituir o EIP pelo endereço de uma chamada a **jmp esp** ou **call esp**. Assim, a shellcode é armazenada após a sobrescritura do EIP, pois após a execução do **ret**, o ESP estará apontando para o endereço seguinte, exatamente onde a shellcode foi guardada.
Se o ASLR não estiver ativo no Windows ou Linux, pode-se chamar **jmp esp** ou **call esp** armazenadas em algum objeto compartilhado. Se o ASLR estiver ativo, pode-se procurar dentro do próprio programa vulnerável.
Além disso, o fato de poder colocar a shellcode após a corrupção do EIP, em vez de no meio da pilha, evita que instruções push ou pop executadas durante a função afetem a shellcode (o que poderia acontecer se estivesse no meio da pilha da função).
De forma muito semelhante, se soubermos que uma função retorna o endereço onde a shellcode está armazenada, podemos chamar **call eax** ou **jmp eax (ret2eax).**
Em algumas arquiteturas de processadores, cada instrução é um conjunto de 32 bits (MIPS, por exemplo). No entanto, na Intel, as instruções têm tamanhos variáveis e várias instruções podem compartilhar um conjunto de bits, por exemplo:
Este programa também é útil para criar os **payloads**. Você pode especificar a biblioteca da qual deseja extrair os ROPs e ele gerará um payload em Python. Você fornece o endereço onde a biblioteca está e o payload está pronto para ser usado como shellcode. Além disso, como usa chamadas ao sistema, não executa nada na pilha, apenas armazena endereços de ROPs que serão executados por meio de **ret**. Para usar este payload, deve-se chamar o payload por uma instrução **ret**.
Este tipo de overflow ocorre quando uma variável não está preparada para suportar um número tão grande quanto o fornecido, possivelmente devido a uma confusão entre variáveis com e sem sinal, por exemplo:
Não se sabe o valor que uma variável não inicializada pode assumir, e pode ser interessante observá-lo. Pode acontecer de ela assumir o valor que uma variável de uma função anterior tinha, e essa variável anterior pode ser controlada pelo atacante.
Em C, **`printf`** é uma função que pode ser usada para **imprimir** uma string. O **primeiro parâmetro** que esta função espera é o **texto bruto com os formatadores**. Os **parâmetros seguintes** esperados são os **valores** para **substituir** os **formatadores** no texto bruto.
A vulnerabilidade aparece quando um **texto do atacante é colocado como o primeiro argumento** nesta função. O atacante poderá criar uma **entrada especial abusando** das capacidades da string de formato do **printf** para **escrever qualquer dado em qualquer endereço**. Sendo capaz, dessa forma, de **executar código arbitrário**.
**`%n`** **escreve** o **número de bytes escritos** no **endereço indicado. Escrever** tantos **bytes** quanto o número hexadecimal que **precisamos** escrever é como você pode **escrever qualquer dado**.
Em um binário, o GOT tem os **endereços das funções ou** para a seção **PLT** que carregará o endereço da função. O objetivo deste exploit é **sobrescrever a entrada do GOT** de uma função que será executada mais tarde **com** o **endereço** da PLT da **função `system`**. Idealmente, você vai **sobrescrever** o **GOT** de uma **função** que **será chamada com parâmetros controlados por você** (assim você poderá controlar os parâmetros enviados para a função system).
Se **`system`** **não for usada** pelo script, a função system **não** terá uma entrada no GOT. Neste cenário, você precisará **vazar primeiro o endereço** da função `system`.
**Procedure Linkage Table** é uma tabela **somente leitura** no arquivo ELF que armazena todos os **símbolos que precisam de resolução**. Quando uma dessas funções é chamada, o **GOT** irá **redirecionar** o **fluxo** para o **PLT** para que possa **resolver** o **endereço** da função e escrevê-lo no GOT.
Então, na **próxima vez** que uma chamada for realizada para aquele endereço, a **função** é **chamada diretamente** sem precisar resolvê-la.
Como explicado anteriormente, o objetivo é **sobrescrever** o **endereço** de uma **função** na tabela **GOT** que será chamada mais tarde. Idealmente, poderíamos definir o **endereço para um shellcode** localizado em uma seção executável, mas provavelmente você não conseguirá escrever um shellcode em uma seção executável.
Portanto, uma opção diferente é **sobrescrever** uma **função** que **recebe** seus **argumentos** do **usuário** e **apontá-la** para a **função `system`**.
Para escrever o endereço, geralmente são feitos 2 passos: Você **escreve primeiro 2Bytes** do endereço e depois os outros 2. Para fazer isso, **`$hn`** é usado.
Essencialmente, esta é uma estrutura com **funções que serão chamadas** antes do programa terminar. Isso é interessante se você puder chamar seu **shellcode apenas pulando para um endereço**, ou em casos em que você precisa voltar ao main novamente para **explorar a string de formato uma segunda vez**.
Note que isso **não****criará** um **loop eterno** porque quando você voltar para o main, o canary perceberá, o fim da pilha pode estar corrompido e a função não será chamada novamente. Então, com isso, você será capaz de **ter mais 1 execução** da vulnerabilidade.
Uma string de formatação também pode ser abusada para **despejar conteúdo** da memória do programa.\
Por exemplo, na seguinte situação há uma **variável local na pilha apontando para uma flag.** Se você **encontrar** onde na **memória** o **ponteiro** para a **flag** está, você pode fazer o **printf acessar** esse **endereço** e **imprimir** a **flag**:
Note que seguindo o **exploit anterior** e percebendo que você pode **vazar conteúdo**, você pode **definir ponteiros** para **`printf`** para a seção onde o **executável** está **carregado** e **despejar** ele **inteiramente**!
Geralmente, você encontrará a seção **DTOR****entre** os valores `ffffffff` e `00000000`. Então, se você apenas ver esses valores, significa que **não há nenhuma função registrada**. Portanto, **sobrescreva** o **`00000000`** com o **endereço** para o **shellcode** para executá-lo.
O **sprintf move** uma string formatada **para** uma **variável**. Portanto, você pode abusar do **formato** de uma string para causar um **buffer overflow na variável** onde o conteúdo é copiado.\
Por exemplo, o payload `%.44xAAAA` irá **escrever 44B+"AAAA" na variável**, o que pode causar um buffer overflow.
**`atexit()`** é uma função à qual **outras funções são passadas como parâmetros**. Essas **funções** serão **executadas** ao executar um **`exit()`** ou o **retorno** do **main**.\
Se você conseguir **modificar** o **endereço** de qualquer uma dessas **funções** para apontar para um shellcode, por exemplo, você ganhará **controle** do **processo**, mas isso atualmente é mais complicado.\
Atualmente, os **endereços das funções** a serem executadas estão **ocultos** atrás de várias estruturas e, finalmente, o endereço para o qual apontam não são os endereços das funções, mas são **criptografados com XOR** e deslocamentos com uma **chave aleatória**. Portanto, atualmente esse vetor de ataque é **não muito útil pelo menos em x86** e **x64\_86**.\
A **função de criptografia** é **`PTR_MANGLE`**. **Outras arquiteturas** como m68k, mips32, mips64, aarch64, arm, hppa... **não implementam a função de criptografia** porque ela **retorna o mesmo** que recebeu como entrada. Então, essas arquiteturas seriam atacáveis por esse vetor.
O que acontece é que EIP e ESP são passados pela função **`PTR_MANGLE`**, então as **arquiteturas vulneráveis a esse ataque são as mesmas mencionadas acima**.\
No entanto, pelo que li, os outros registradores não são protegidos, **então se houver um `call ebx`, `call esi` ou `call edi`** dentro da função sendo chamada, o controle pode ser assumido. Ou você também poderia modificar o EBP para modificar o ESP.
Cada objeto de uma **classe** tem um **VPtr** que é um **ponteiro** para o array de sua classe. O VPtr faz parte do cabeçalho de cada objeto, então se uma **sobrescrita** do **VPtr** for alcançada, ele poderia ser **modificado** para **apontar** para um método fictício para que a execução de uma função fosse para o shellcode.
Código e dados iniciados e não iniciados: .text, .data e .bss —> 16bits de entropia na variável delta\_exec, esta variável é iniciada aleatoriamente com cada processo e é somada às direções iniciais
É uma técnica para converter um buffer overflow em um erro de string formatada. Consiste em substituir o EIP para que aponte para um printf da função e passar como argumento uma string formatada manipulada para obter valores sobre o estado do processo.
As bibliotecas estão em uma posição com 16bits de aleatoriedade = 65636 possíveis endereços. Se um servidor vulnerável chama a fork(), o espaço de endereçamento de memória é clonado no processo filho e mantido intacto. Portanto, pode-se tentar fazer um brute force na função usleep() da libc passando "16" como argumento de forma que, quando demorar mais do que o normal para responder, essa função terá sido encontrada. Sabendo onde está essa função, pode-se obter delta\_mmap e calcular os demais.
**StackGuard** insere antes do EIP —> 0x000aff0d(null, \n, EndOfFile(EOF), \r) —> Ainda são vulneráveis recv(), memcpy(), read(), bcoy() e não protege o EBP
Guarda em uma tabela (Global Return Stack) todos os endereços EIP de retorno de forma que o overflow não cause nenhum dano. Além disso, ambas as direções podem ser comparadas para ver se houve um desbordamento.
Também se pode verificar o endereço de retorno com um valor limite, assim se o EIP for para um local diferente do habitual, como o espaço de dados, será detectado. Mas isso é contornado com Ret-to-lib, ROPs ou ret2ret.
Coloca o canário antes do EBP. Reorganiza as variáveis locais para que os buffers estejam nas posições mais altas e assim não possam sobrescrever outras variáveis.
O canário é um número aleatório tirado de “/dev/urandom” ou senão é 0xff0a0000. É armazenado em TLS (Thread Local Storage). Os threads compartilham o mesmo espaço de memória, o TLS é uma área que tem variáveis globais ou estáticas de cada thread. No entanto, em princípio, estas são copiadas do processo pai, embora o processo filho possa modificar esses dados sem alterar os do pai ou dos outros filhos. O problema é que se fork() é usado mas não se cria um novo canário, então todos os processos (pai e filhos) usam o mesmo canário. Em i386 é armazenado em gs:0x14 e em x86\_64 é armazenado em fs:0x28
Esta proteção localiza funções que tenham buffer que possam ser atacados e inclui nelas código no início da função para colocar o canário e código no final para verificá-lo.
A função fork() realiza uma cópia exata do processo do pai, por isso mesmo se um servidor web chama a fork() pode-se fazer um ataque de força bruta byte por byte até descobrir o canário que está sendo utilizado.
Se a função execve() for usada após fork(), o espaço é sobrescrito e o ataque já não é possível. vfork() permite executar o processo filho sem criar um duplicado até que o processo filho tente escrever, então sim cria o duplicado.
**Relro (Read only Relocation)** afeta as permissões de memória de forma semelhante ao NX. A diferença é que enquanto o NX torna a pilha executável, o RELRO torna **certas coisas somente leitura** para que **não possamos escrever** nelas. A maneira mais comum que vi isso ser um obstáculo é impedindo-nos de fazer uma **sobrescrita da tabela `got`**, que será abordada mais tarde. A tabela `got` contém endereços para funções libc para que o binário saiba quais são os endereços e possa chamá-los. Vamos ver como são as permissões de memória para uma entrada da tabela `got` para um binário com e sem relro.
Para o binário **sem relro**, podemos ver que o endereço de entrada `got` para `fgets` é `0x404018`. Olhando para os mapeamentos de memória, vemos que ele está entre `0x404000` e `0x405000`, que tem as **permissões `rw`**, significando que podemos ler e escrever nele. Para o binário **com relro**, vemos que o endereço da tabela `got` para a execução do binário (pie está habilitado, então este endereço mudará) é `0x555555557fd0`. No mapeamento de memória desse binário, ele está entre `0x0000555555557000` e `0x0000555555558000`, que tem a **permissão de memória `r`**, significando que só podemos ler dele.
Então, qual é o **bypass**? O bypass típico que uso é simplesmente não escrever em regiões de memória que o relro faz serem somente leitura e **encontrar uma maneira diferente de obter execução de código**.
* Lazy binding: O endereço de uma função é procurado na primeira vez que a função é chamada. Assim, o GOT precisa ter permissões de escrita durante a execução.
* Bind now: Os endereços das funções são resolvidos no início da execução, depois permissões somente leitura são dadas a seções sensíveis como .got, .dtors, .ctors, .dynamic, .jcr. `` `** ``-z relro`**`e`**`-z now\`\*\*
Quando o binário é carregado na memória e uma função é chamada pela primeira vez, salta-se para a PLT (Procedure Linkage Table). Daqui, realiza-se um salto (jmp) para a GOT e descobre-se que essa entrada não foi resolvida (contém um endereço seguinte da PLT). Assim, invoca-se o Runtime Linker ou rtfd para resolver o endereço e guardá-lo na GOT.
Quando se chama uma função, chama-se a PLT, que tem o endereço da GOT onde se armazena o endereço da função, redirecionando o fluxo para lá e chamando a função. No entanto, se é a primeira vez que a função é chamada, o que está na GOT é a instrução seguinte da PLT, então o fluxo segue o código da PLT (rtfd) para descobrir o endereço da função, guardá-lo na GOT e chamá-lo.
Lazy binding —> O endereço da função é procurado na primeira vez que a função é invocada, então a GOT tem permissões de escrita para que, ao procurar, o endereço seja guardado lá e não seja necessário procurar novamente.
Bind now —> Os endereços das funções são procurados ao carregar o programa e as permissões das seções .got, .dtors, .ctors, .dynamic, .jcr são alteradas para somente leitura. **-z relro** e **-z now**
A segunda não permite que **%n** venha de uma seção com permissões de escrita. Além disso, o parâmetro para acesso direto de argumentos só pode ser usado se os anteriores forem usados, ou seja, só se pode usar **%3$d** se antes tiver usado **%2$d** e **%1$d**
Para mostrar a mensagem de erro, usa-se o argv[0], então se colocar no argv[0] o endereço de outro local (como uma variável global), a mensagem de erro mostrará o conteúdo dessa variável. Página 191
Intercepta chamadas a algumas funções inseguras por outras seguras. Não é padronizado. (só para x86, não para compilações com -fomit-frame-pointer, não compilações estáticas, nem todas as funções vulneráveis são seguradas e LD_PRELOAD não funciona em binários com suid).
Consiste em carregar as bibliotecas compartilhadas de 0x00000000 a 0x00ffffff para que sempre haja um byte 0x00. No entanto, isso realmente não impede quase nenhum ataque, especialmente em little endian.
Consiste em realizar um ROP de forma que se chame a função strcpy@plt (da plt) e se aponte para a entrada da GOT e se copie o primeiro byte da função que se quer chamar (system()). Em seguida, faz-se o mesmo apontando para GOT+1 e copia-se o segundo byte de system()... No final, chama-se o endereço guardado na GOT que será system()
Para funções que usam o EBP como registro para apontar para os argumentos, ao modificar o EIP e apontar para system(), deve-se ter modificado o EBP também para que aponte para uma área de memória que tenha 2 bytes quaisquer e depois o endereço para &"/bin/sh".
Se ao libertar um troço algum dos contíguos estiver livre, eles são combinados através da macro unlink() e o novo troço maior é passado para frontlink() para ser inserido no bin adequado.
Portanto, se conseguirmos modificar o P->bk com o endereço de um shellcode e o P->fd com o endereço de uma entrada na GOT ou DTORS menos 12, conseguimos:
BK->fd = FD -> *(&shellcode + 8) = (&__dtor_end__ - 12) —> Isso causa a escrita de 4 bytes a partir do 8º byte do shellcode, então a primeira instrução do shellcode deve ser um jmp para saltar isso e cair em nops que levam ao resto do shellcode.
No buffer1 colocamos o shellcode começando com um jmp para que caia nos nops ou no resto do shellcode.
Depois do shellcode, colocamos preenchimento até chegar aos campos prev_size e size do próximo troço. Nesses locais colocamos 0xfffffff0 (para sobrescrever o prev_size para que tenha o bit que diz que está livre) e "-4" (0xfffffffc) no size (para que, ao verificar no 3º troço se o 2º estava livre, na realidade vá para o prev_size modificado que dirá que está livre) -> Assim, quando free() investigar, irá para o size do 3º mas na realidade irá para o 2º - 4 e pensará que o 2º troço está livre. E então chamará **unlink()**.
Ao chamar unlink(), usará como P->fd os primeiros dados do 2º troço, então aí colocaremos o endereço que queremos sobrescrever - 12 (pois em FD->bk somará 12 ao endereço guardado em FD). E nesse endereço introduziremos a segunda direção que encontramos no 2º troço, que nos interessa que seja o endereço para o shellcode (P->bk falso).
**fake_size = pack("\<I”, 0xfffffffc) #-4, para que pense que o “size” do 3º troço está 4bytes atrás (aponta para prev_size) pois é aí que verifica se o 2º troço está livre**
**got_free = pack("\<I", 0x08048300 - 12) #Endereço de free() na plt-12 (será o endereço que será sobrescrito para que se lance o shellcode a 2ª vez que se chame a free)**
Então, o programa pensará que “a” está livre e num bin, então chamará unlink() para desvinculá-lo. No entanto, como o cabeçalho PREV_SIZE vale -4, pensará que o troço de “a” realmente começa em b+4. Ou seja, fará um unlink() num troço que começa em b+4, então em b+12 estará o ponteiro “fd” e em b+16 estará o ponteiro “bk”.
Dessa forma, conseguindo sobrescrever em dois mallocs de forma descontrolada e num de forma controlada mas que só se liberta esse um, podemos fazer um exploit.
Caso se queira voltar a usar um, será atribuído sem problemas. Caso se queira usar outro, será atribuído o mesmo espaço, então teremos os ponteiros “fd” e “bk” falseados com os dados que escreverá a reserva anterior.
Apenas uma chamada a free() é necessária para provocar a execução de código arbitrário. Interessa procurar um segundo troço que possa ser desbordado por um anterior e libertado.
Em [1] verifica o campo size o bit NON_MAIN_ARENA, o qual se pode alterar para que a verificação devolva true e execute heap_for_ptr() que faz um and a “mem” deixando a 0 os 2.5 bytes menos importantes (no nosso caso de 0x0804a000 deixa 0x08000000) e acede a 0x08000000->ar_ptr (como se fosse um struct heap_info)
Dessa forma, se podemos controlar um troço por exemplo em 0x0804a000 e vai-se libertar um troço em **0x081002a0** podemos chegar à direção 0x08100000 e escrever o que quisermos, por exemplo **0x0804a000**. Quando este segundo troço se libertar, encontrará que heap_for_ptr(ptr)->ar_ptr devolve o que escrevemos em 0x08100000 (pois aplica-se a 0x081002a0 o and que vimos antes e daí tira-se o valor dos 4 primeiros bytes, o ar_ptr)
Na direção que caia o endereço do segundo troço com os últimos 5 zeros temos que escrever o endereço a este primeiro troço para que heap_for_ptr() pense que o ar_ptr está no início do primeiro troço e tire daí o av->bins[2]
Dessa forma, chamar-se-á a _int_free(TROZO1, TROZO2) e seguir-se-ão as instruções para escrever em __DTOR_END__ o endereço do prev_size do TROZO2 que saltará para o shellcode.
Esta técnica já não é aplicável pois aplicou-se quase o mesmo patch que para unlink. Comparam-se se o novo sítio ao qual se aponta também está apontando para ele.
Dessa forma, se se colocar em “fb” a direção de uma função na GOT, nessa direção colocar-se-á a direção ao troço sobrescrito. Para isso será necessário que a arena esteja perto das direções de dtors. Mais exatamente que av->max_fast esteja na direção que
