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 Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo telegram**](https://t.me/peass) ou **siga-nos** no **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Compartilhe truques de hacking enviando PRs para os repositórios** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
**Se você estiver lidando com um binário protegido por um canário e PIE (Position Independent Executable), provavelmente precisará encontrar uma maneira de contorná-los.**
Observe que o **`checksec`** pode não detectar que um binário está protegido por um canário se ele foi compilado estaticamente e não é capaz de identificar a função.\
No entanto, você pode perceber manualmente isso se encontrar que um valor é salvo na pilha no início de uma chamada de função e esse valor é verificado antes de sair.
A melhor maneira de contornar um canário simples é se o binário for um programa **que cria processos filhos toda vez que você estabelece uma nova conexão** com ele (serviço de rede), porque toda vez que você se conecta a ele **o mesmo canário será usado**.
Então, a melhor maneira de contornar o canário é simplesmente **forçá-lo caractere por caractere**, e você pode descobrir se o byte do canário adivinhado estava correto verificando se o programa travou ou continua seu fluxo regular. Neste exemplo, a função **força bruta um canário de 8 Bytes (x64)** e distingue entre um byte adivinhado correto e um byte ruim apenas **verificando** se uma **resposta** é enviada de volta pelo servidor (outra forma em **outras situações** poderia ser usando um **try/except**):
As threads do mesmo processo também **compartilharão o mesmo token canary**, portanto será possível **forçar a barra** de um canary se o binário gerar uma nova thread sempre que um ataque ocorrer. 
Além disso, um **estouro de buffer em uma função com thread** protegida com canary poderia ser usado para **modificar o canary mestre armazenado no TLS**. Isso ocorre porque pode ser possível alcançar a posição de memória onde o TLS é armazenado (e, portanto, o canary) por meio de um **estouro de buffer na pilha** de uma thread.\
Como resultado, a mitigação é inútil porque a verificação é feita com dois canaries que são iguais (embora modificados).\
Este ataque é realizado no writeup: [http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads](http://7rocky.github.io/en/ctf/htb-challenges/pwn/robot-factory/#canaries-and-threads)
Confira também a apresentação de [https://www.slideshare.net/codeblue\_jp/master-canary-forging-by-yuki-koike-code-blue-2015](https://www.slideshare.net/codeblue\_jp/master-canary-forging-by-yuki-koike-code-blue-2015) que menciona que geralmente o **TLS** é armazenado por **`mmap`** e quando uma **pilha** de **thread** é criada, também é gerada por `mmap` de acordo com isso, o que pode permitir o estouro conforme mostrado no writeup anterior.