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.
**Se você está enfrentando um binário protegido por um canário e PIE (Executable Independente de Posição), você provavelmente precisa encontrar uma maneira de contorná-los.**
Note que **`checksec`** pode não encontrar que um binário está protegido por um canário se este foi compilado estaticamente e não é capaz de identificar a função.\
No entanto, você pode notar isso manualmente se descobrir 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 é apenas **forçá-lo com força bruta, 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 um canário de 8 Bytes (x64)** e distingue entre um byte adivinhado corretamente e um byte ruim apenas **verificando** se uma **resposta** é enviada de volta pelo servidor (outra maneira em **outra situação** poderia ser usando um **try/except**):
Threads do mesmo processo também **compartilharão o mesmo token canário**, portanto será possível **forçar** um canário se o binário gerar uma nova thread toda vez que um ataque acontecer. 
Um estouro de buffer em uma função com threads protegida com canário pode ser usado para modificar o canário mestre do processo. Como resultado, a mitigação é inútil porque a verificação é feita com dois canários que são iguais (embora modificados).
Observe que `vuln` é chamado dentro de uma thread. No GDB, podemos dar uma olhada em `vuln`, especificamente, no ponto em que o programa chama `gets` para ler os dados de entrada:
O acima representa o endereço de `data`, onde o programa irá gravar a entrada do usuário. O stack canary é encontrado em `0x7ffff7d7ee48` (`0x493fdc653a156800`), e o endereço de retorno está em `0x7ffff7d7ee50` (`0x00007ffff7e17ac3`):
Algumas das funções GDB acima estão definidas em uma extensão chamada [bata24/gef](https://github.com/bata24/gef), que possui mais recursos do que o usual [hugsy/gef](https://github.com/hugsy/gef).