Afinal, o que é um cheat sheet? Basicamente um “guia rápido”, uma “folha de consulta” para possíveis dúvidas que você possa ter sobre o assunto abordado. Este tipo de guia pode abordar diversos assuntos, desde comandos/scripts específicos para pentest até definições rápidas sobre registradores e alinhamento de memória (que é o nosso caso).
A quantidade de informações disponíveis em um cheat sheet é enorme, mas não há sentido em ter tanta informação se não entendermos de fato o que é aquilo. Tendo em vista isto detalharemos um pouco mais um ponto em específico deste guia, deixando o resto para a sua curiosidade
Que tal darmos uma breve olhada em uma seção? Considere o código abaixo:
#include <stdio.h> int main(void){ printf("Isto eh um teste\n"); return 0; } Se utilizarmos o comando readelf --sections test veremos que a seção .data(seção de dados inicializados), por exemplo, tem apenas 16 bytes (em hexa):
... [22] .got PROGBITS 0000000000200fd8 00000fd8 0000000000000028 0000000000000008 WA 0 0 8 [23] .got.plt PROGBITS 0000000000201000 00001000 0000000000000020 0000000000000008 WA 0 0 8 [24] .data PROGBITS 0000000000201020 00001020 0000000000000010 0000000000000000 WA 0 0 8 [25] .bss NOBITS 0000000000201030 00001030 0000000000000008 0000000000000000 WA 0 0 1 … Podemos verificar o que tem nestes bytes com objdump -d -j .data test:
test: file format elf64-x86-64 Disassembly of section .data: 0000000000201020 <__data_start>: ... 0000000000201028 <__dso_handle>: 201028: 28 10 20 00 00 00 00 00 (. ..... Mas e se nosso código fosse da seguinte forma:
#include <stdio.h> int a = 10; int main(void){ printf("Isto eh um teste\n"); return 0; } Note que o tamanho da seção aumentou em 4 bytes, que “coinscidentemente” é o tamanho de uma variável do tipo inteiro na arquitetura onde os testes foram feitos :
... [23] .got.plt PROGBITS 0000000000201000 00001000 0000000000000020 0000000000000008 WA 0 0 8 [24] .data PROGBITS 0000000000201020 00001020 0000000000000014 0000000000000000 WA 0 0 8 [25] .bss NOBITS 0000000000201034 00001034 0000000000000004 0000000000000000 WA 0 0 1 [26] .comment PROGBITS 0000000000000000 00001034 … Se olharmos o que há na seção veremos o seguinte resultado:
test: file format elf64-x86-64 Disassembly of section .data: 0000000000201020 <__data_start>: ... 0000000000201028 <__dso_handle>: 201028: 28 10 20 00 00 00 00 00 (. ..... 0000000000201030 <a>: 201030: 0a 00 00 00 .... Agora temos um valor de 4 bytes disponível para nossa variável a que possui o valor 0a em hexa (ou seja, 10 como declarado anteriormente).
Caso a variável fosse, por exemplo, long long a = 10 o resultado seria:
est: file format elf64-x86-64 Disassembly of section .data: 0000000000201020 <__data_start>: ... 0000000000201028 <__dso_handle>: 201028: 28 10 20 00 00 00 00 00 (. ..... 0000000000201030 <a>: 201030: 0a 00 00 00 00 00 00 00 .....… 8 bytes disponíveis, exatamente o valor que sizeof(long long) representa nesta arquitetura. Não ficou satisfeito ainda? Você também pode olhar as seções com o gdb(GNU Debugger) utilizando o comando maintenance info sections:
... [22] 0x00201000->0x00201020 at 0x00001000: .got.plt ALLOC LOAD DATA HAS_CONTE---Type <return> to continue, or q <return> to quit--- NTS [23] 0x00201020->0x00201038 at 0x00001020: .data ALLOC LOAD DATA HAS_CONTENTS [24] 0x00201038->0x00201040 at 0x00001038: .bss ALLOC [25] 0x00000000->0x0000001c at 0x00001038: .comment READONLY HAS_CONTENTS ... É extremamente interessante ir a fundo em cheat sheets como este, mais interessante ainda é montar um você mesmo, seja para uso particular ou para disponibilizar para todos. Espera, não entendeu direito os comandos, ordenação dos bytes ou algo desta notícia? Que tal assistir ao curso do CERO? A última aula fala justamente sobre o formato ELF (executáveis Linux) e sua especificação.
Agora que sua curiosidade foi instigada, que tal aplicar seus conhecimentos sobre arquitetura de computadores e mostrar pra gente?
