Learn & practice AWS Hacking:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Learn & practice GCP Hacking: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
Para melhorar a eficiência de como os chunks são armazenados, cada chunk não está apenas em uma lista encadeada, mas existem vários tipos. Estes são os bins e há 5 tipos de bins: [62](https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=blob;f=malloc/malloc.c;h=6e766d11bc85b6480fa5c9f2a76559f8acf9deb5;hb=HEAD#l1407) bins pequenos, 63 bins grandes, 1 bin não ordenado, 10 bins rápidos e 64 bins tcache por thread.
O endereço inicial para cada bin não ordenado, pequeno e grande está dentro do mesmo array. O índice 0 não é usado, 1 é o bin não ordenado, bins 2-64 são bins pequenos e bins 65-127 são bins grandes.
Embora as threads tentem ter seu próprio heap (veja [Arenas](bins-and-memory-allocations.md#arenas) e [Subheaps](bins-and-memory-allocations.md#subheaps)), existe a possibilidade de que um processo com muitas threads (como um servidor web) **acabe compartilhando o heap com outras threads**. Nesse caso, a principal solução é o uso de **lockers**, que podem **reduzir significativamente a velocidade das threads**.
Portanto, um tcache é semelhante a um bin rápido por thread na forma como é uma **lista encadeada simples** que não mescla chunks. Cada thread tem **64 bins tcache encadeados**. Cada bin pode ter um máximo de [7 chunks do mesmo tamanho](https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=2527e2504761744df2bdb1abdc02d936ff907ad2;hb=d5c3fafc4307c9b7a4c7d5cb381fcdbfad340bcc#l323) variando de [24 a 1032B em sistemas de 64 bits e 12 a 516B em sistemas de 32 bits](https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c;h=2527e2504761744df2bdb1abdc02d936ff907ad2;hb=d5c3fafc4307c9b7a4c7d5cb381fcdbfad340bcc#l315).
**Quando uma thread libera** um chunk, **se não for muito grande** para ser alocado no tcache e o respectivo bin tcache **não estiver cheio** (já 7 chunks), **ele será alocado lá**. Se não puder ir para o tcache, precisará esperar pelo bloqueio do heap para poder realizar a operação de liberação globalmente.
Quando um **chunk é alocado**, se houver um chunk livre do tamanho necessário no **Tcache, ele o usará**, se não, precisará esperar pelo bloqueio do heap para poder encontrar um nos bins globais ou criar um novo.\
Há também uma otimização, nesse caso, enquanto tiver o bloqueio do heap, a thread **preencherá seu Tcache com chunks do heap (7) do tamanho solicitado**, para que, caso precise de mais, os encontre no Tcache.
No código a seguir, é possível ver os **max bins** e **chunks por índice**, a estrutura **`tcache_entry`** criada para evitar double frees e **`tcache_perthread_struct`**, uma estrutura que cada thread usa para armazenar os endereços de cada índice do bin.
O tcache possui vários bins dependendo do tamanho e os ponteiros iniciais para o **primeiro chunk de cada índice e a quantidade de chunks por índice estão localizados dentro de um chunk**. Isso significa que, ao localizar o chunk com essa informação (geralmente o primeiro), é possível encontrar todos os pontos iniciais do tcache e a quantidade de chunks do Tcache.
Os bins rápidos são projetados para **acelerar a alocação de memória para pequenos chunks** mantendo chunks recentemente liberados em uma estrutura de acesso rápido. Esses bins usam uma abordagem Last-In, First-Out (LIFO), o que significa que o **chunk mais recentemente liberado é o primeiro** a ser reutilizado quando há um novo pedido de alocação. Esse comportamento é vantajoso para a velocidade, pois é mais rápido inserir e remover do topo de uma pilha (LIFO) em comparação com uma fila (FIFO).
Além disso, **bins rápidos usam listas encadeadas simples**, não duplamente encadeadas, o que melhora ainda mais a velocidade. Como os chunks em bins rápidos não são mesclados com vizinhos, não há necessidade de uma estrutura complexa que permita a remoção do meio. Uma lista encadeada simples é mais simples e rápida para essas operações.
Basicamente, o que acontece aqui é que o cabeçalho (o ponteiro para o primeiro chunk a ser verificado) está sempre apontando para o último chunk liberado daquele tamanho. Então:
* Quando um novo chunk é alocado desse tamanho, o cabeçalho está apontando para um chunk livre para usar. Como esse chunk livre está apontando para o próximo a ser usado, esse endereço é armazenado no cabeçalho para que a próxima alocação saiba onde obter um chunk disponível.
* Quando um chunk é liberado, o chunk livre salvará o endereço do chunk atualmente disponível e o endereço desse chunk recém-liberado será colocado no cabeçalho.
O tamanho máximo de uma lista encadeada é `0x80` e elas são organizadas de modo que um chunk de tamanho `0x20` estará no índice `0`, um chunk de tamanho `0x30` estaria no índice `1`...
Chunks em bins rápidos não são definidos como disponíveis, portanto, são mantidos como chunks de bin rápido por algum tempo em vez de poderem ser mesclados com outros chunks livres ao seu redor.
Compile-o e depure-o com um breakpoint no opcode `ret` da função `main`. Então, com `gef`, você pode ver que o bin do tcache está cheio e um chunk está no fast bin:
───────────────────────────────────────────────────────────────────────── Fastbins for arena at 0xfffff7f90b00 ─────────────────────────────────────────────────────────────────────────
O unsorted bin é um **cache** usado pelo gerenciador de heap para tornar a alocação de memória mais rápida. Veja como funciona: Quando um programa libera um chunk, e se esse chunk não pode ser alocado em um tcache ou fast bin e não está colidindo com o top chunk, o gerenciador de heap não o coloca imediatamente em um bin pequeno ou grande específico. Em vez disso, ele primeiro tenta **mesclar com quaisquer chunks livres vizinhos** para criar um bloco maior de memória livre. Em seguida, coloca esse novo chunk em um bin geral chamado "unsorted bin."
Quando um programa **pede memória**, o gerenciador de heap **verifica o unsorted bin** para ver se há um chunk de tamanho suficiente. Se encontrar um, ele o utiliza imediatamente. Se não encontrar um chunk adequado no unsorted bin, ele move todos os chunks dessa lista para seus bins correspondentes, seja pequeno ou grande, com base em seu tamanho.
Assim, o unsorted bin é uma maneira de acelerar a alocação de memória reutilizando rapidamente a memória recentemente liberada e reduzindo a necessidade de buscas e mesclagens demoradas.
Note que mesmo que os chunks sejam de categorias diferentes, se um chunk disponível estiver colidindo com outro chunk disponível (mesmo que originalmente pertençam a bins diferentes), eles serão mesclados.
Note como alocamos e liberamos 9 chunks do mesmo tamanho para que eles **preencham o tcache** e o oitavo é armazenado no bin não ordenado porque é **grande demais para o fastbin** e o nono não é liberado, então o nono e o oitavo **não são mesclados com o chunk superior**.
Compile-o e depure-o com um breakpoint no opcode `ret` da função `main`. Então, com `gef`, você pode ver que o bin do tcache está cheio e um chunk está no bin não ordenado:
───────────────────────────────────────────────────────────────────────── Fastbins for arena at 0xfffff7f90b00 ─────────────────────────────────────────────────────────────────────────
Fastbins[idx=0, size=0x20] 0x00
Fastbins[idx=1, size=0x30] 0x00
Fastbins[idx=2, size=0x40] 0x00
Fastbins[idx=3, size=0x50] 0x00
Fastbins[idx=4, size=0x60] 0x00
Fastbins[idx=5, size=0x70] 0x00
Fastbins[idx=6, size=0x80] 0x00
─────────────────────────────────────────────────────────────────────── Unsorted Bin for arena at 0xfffff7f90b00 ───────────────────────────────────────────────────────────────────────
Cada bin dos 62 terá **chunks do mesmo tamanho**: 16, 24, ... (com um tamanho máximo de 504 bytes em 32 bits e 1024 em 64 bits). Isso ajuda na velocidade de encontrar o bin onde um espaço deve ser alocado e na inserção e remoção de entradas nessas listas.
Note como alocamos e liberamos 9 chunks do mesmo tamanho para que eles **preencham o tcache** e o oitavo é armazenado no bin não ordenado porque é **grande demais para o fastbin** e o nono não é liberado, então o nono e o oitavo **não são mesclados com o chunk superior**. Em seguida, alocamos um chunk maior de 0x110, o que faz **o chunk no bin não ordenado ir para o small bin**.
Compile e depure com um breakpoint no opcode `ret` da função `main`. Então, com `gef`, você pode ver que o bin do tcache está cheio e um chunk está no small bin:
───────────────────────────────────────────────────────────────────────── Fastbins for arena at 0xfffff7f90b00 ─────────────────────────────────────────────────────────────────────────
Fastbins[idx=0, size=0x20] 0x00
Fastbins[idx=1, size=0x30] 0x00
Fastbins[idx=2, size=0x40] 0x00
Fastbins[idx=3, size=0x50] 0x00
Fastbins[idx=4, size=0x60] 0x00
Fastbins[idx=5, size=0x70] 0x00
Fastbins[idx=6, size=0x80] 0x00
─────────────────────────────────────────────────────────────────────── Unsorted Bin for arena at 0xfffff7f90b00 ───────────────────────────────────────────────────────────────────────
[+] Found 0 chunks in unsorted bin.
──────────────────────────────────────────────────────────────────────── Small Bins for arena at 0xfffff7f90b00 ────────────────────────────────────────────────────────────────────────
Ao contrário dos pequenos bins, que gerenciam pedaços de tamanhos fixos, cada **grande bin lida com uma faixa de tamanhos de pedaços**. Isso é mais flexível, permitindo que o sistema acomode **vários tamanhos** sem precisar de um bin separado para cada tamanho.
Em um alocador de memória, os grandes bins começam onde os pequenos bins terminam. As faixas para grandes bins crescem progressivamente, o que significa que o primeiro bin pode cobrir pedaços de 512 a 576 bytes, enquanto o próximo cobre de 576 a 640 bytes. Esse padrão continua, com o maior bin contendo todos os pedaços acima de 1MB.
Os grandes bins são mais lentos para operar em comparação com os pequenos bins porque eles devem **classificar e pesquisar em uma lista de tamanhos de pedaços variados para encontrar o melhor ajuste** para uma alocação. Quando um pedaço é inserido em um grande bin, ele precisa ser classificado, e quando a memória é alocada, o sistema deve encontrar o pedaço certo. Esse trabalho extra os torna **mais lentos**, mas como as alocações grandes são menos comuns do que as pequenas, é uma troca aceitável.
2 grandes alocações são realizadas, então uma é liberada (colocando-a no bin não ordenado) e uma alocação maior é feita (movendo a liberada do bin não ordenado para o bin grande).
Compile e depure com um breakpoint no opcode `ret` da função `main`. Então, com `gef`, você pode ver que o bin tcache está cheio e um chunk está no bin grande:
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
All tcachebins are empty
───────────────────────────────────────────────────────────────────────── Fastbins for arena at 0xfffff7f90b00 ─────────────────────────────────────────────────────────────────────────
Fastbins[idx=0, size=0x20] 0x00
Fastbins[idx=1, size=0x30] 0x00
Fastbins[idx=2, size=0x40] 0x00
Fastbins[idx=3, size=0x50] 0x00
Fastbins[idx=4, size=0x60] 0x00
Fastbins[idx=5, size=0x70] 0x00
Fastbins[idx=6, size=0x80] 0x00
─────────────────────────────────────────────────────────────────────── Unsorted Bin for arena at 0xfffff7f90b00 ───────────────────────────────────────────────────────────────────────
[+] Found 0 chunks in unsorted bin.
──────────────────────────────────────────────────────────────────────── Small Bins for arena at 0xfffff7f90b00 ────────────────────────────────────────────────────────────────────────
[+] Found 0 chunks in 0 small non-empty bins.
──────────────────────────────────────────────────────────────────────── Large Bins for arena at 0xfffff7f90b00 ────────────────────────────────────────────────────────────────────────
Basicamente, este é um chunk que contém toda a heap atualmente disponível. Quando um malloc é realizado, se não houver nenhum chunk livre disponível para usar, este top chunk reduzirá seu tamanho, dando o espaço necessário.\
O ponteiro para o Top Chunk é armazenado na struct `malloc_state`.
Após compilar e depurar com um ponto de interrupção no opcode `ret` de `main`, vi que o malloc retornou o endereço `0xaaaaaaac12a0` e estes são os chunks:
Onde pode-se ver que o top chunk está no endereço `0xaaaaaaac1ae0`. Isso não é surpresa porque o último chunk alocado estava em `0xaaaaaaac12a0` com um tamanho de `0x410` e `0xaaaaaaac12a0 + 0x410 = 0xaaaaaaac1ae0`.\
Também é possível ver o comprimento do Top chunk em seu cabeçalho de chunk:
Quando malloc é usado e um chunk é dividido (do bin não ordenado ou do chunk superior, por exemplo), o chunk criado a partir do restante do chunk dividido é chamado de Último Resto e seu ponteiro é armazenado na struct `malloc_state`.
Aprenda e pratique Hacking AWS:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Aprenda e pratique Hacking GCP: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* **Junte-se ao** 💬 [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do telegram**](https://t.me/peass) ou **siga**-nos no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe truques de hacking enviando PRs para o** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repositórios do github.
