/*
Off-Topic: Está disponível no Shell-Storm versão do Shell Bind TCP usando o método GetPC (GetEIP). Os demais shellcodes apresentados neste post também já foram disponibilizados no mesmo repositório. Tks again, Salwan.
*/
Enquanto que em muita área por aí o que importa é ter ou fazer algo grande, quando falamos em shellcodes sempre os queremos minúsculos, correto? E mesmo que isso não seja tão importante para as mais recentes técnicas de exploração, você não gostaria que o seu fosse menor? =D
Off-Topic: Está disponível no Shell-Storm versão do Shell Bind TCP usando o método GetPC (GetEIP). Os demais shellcodes apresentados neste post também já foram disponibilizados no mesmo repositório. Tks again, Salwan.
*/
Enquanto que em muita área por aí o que importa é ter ou fazer algo grande, quando falamos em shellcodes sempre os queremos minúsculos, correto? E mesmo que isso não seja tão importante para as mais recentes técnicas de exploração, você não gostaria que o seu fosse menor? =D
Bom, como sou teimoso, aproveitei o tempo de viagem de onde estou trabalhando até minha casa (10h de ônibus) para brincar um pouco com as versões anteriores que disponibilizei e consequentemente aprender mais. Meu notebook, graças ao Jupiter, aguentou 7h de pdfs, chrome (em offline), editores, compilação e muito debugging.
O que fazer para se diminuir o tamanho de um shellcode?
Com a questão em mente, condensei nas regras abaixo o que aprendi.
Regra n. 01 - Certificar-se da "pureza" dos registers antes de serem preenchidos com valores menores que o da arquitetura
Num ambiente de desenvolvimento e exploração, ao se testar um shellcode projetado, os registers se apresentam sem lixo, o que pode mascarar o seu real funcionamento.
Temos que ter em mente que um shellcode é um pedaço de código injetado em um programa já em execução com suas STACK e registers já em utilização. Se começarmos a simplesmente utilizar esses registers ou a STACK sem as devidas providências o shellcode não vai servir ao seu propósito.
Na arquitetura 32 bits, se eu movimentar (não gosto de usar o termo movimentar; mesmo a instrução se chamando MOV o que ela faz, em verdade, é copiar) um valor para um register [mov eax, 10], a instrução preenche totalmente o EAX com o valor imediato.
Se antes da cópia EAX tiver 0xffffffff, após ele ficará com 0x0000000a:
b8 0a 00 00 00 mov eax,0xa
Até então sem problemas, certo? Não, para um shellcode! O opcode B8 que movimenta o valor imediato 0xa (10) preenche todos os 32 bits de EAX, e você deve se recordar que não podemos ter null bytes para que o payload seja funcional.
Contornando a situação com [mov al, 10]:
b0 0a mov al,0xa
Like a charm? Copiamos agora apenas o byte necessário 0xa para o register AL de 8 bits.
Contudo, se EAX já estiver, hipoteticamente, com 0xffffffff, ao copiarmos apenas para AL, o valor final será 0xffffff0a (-246). Qualquer syscall ao usar EAX retornará erro.
Eu estava usando um truque com a instrução CDQ - convert double to quad - para zerar EDX, após preparar EAX com algum valor inicial, ex: PUSH 10 (6A, 0A), POP EAX (58). A CDQ é de apenas um opcode (99), por isso me encantou. Em suma, com ela eu podia despoluir EDX e já deixar EAX preparada com apenas 3 bytes.
Sendo que o zero é essencial para o preenchimento dos argumentos das syscalls mas não pode estar presente no shellcode, essa técnica permite termos o zero em EDX para utilização posterior.
E eu não poderia fazer isso usando XOR? Sim, mas a custo de mais um byte.
31 d2 xor edx,edx
...
99 cdq
E para limpar os demais registers necessários no início do shellcode sempre serão utilizados dois opcodes, seja com a técnica do XOR, com a do PUSH reg, POP reg ou com a do MOV reg, reg.
31 d2 xor edx,edx
...
52 push edx (que já será zero após o cdq)
5b pop ebx...
89 dd mov ebp,ebx
De tanto garimpar, descobri um truque com o uso da instrução MUL - unsigned multiply - que permite despoluir três registers de uma só vez (EAX, EBX [poderia ser outro: ECX, ESI, ...] e EDX).
31 db xor ebx,ebx
f7 e3 mul ebx
Ele gera um byte a mais, entretanto um a menos se usarmos um XOR, para zerar EBX logo após o uso do CDQ.
Temos também o mágico XCHG que permuta os valores de dois registers a custo de apenas um byte se um dos envolvidos na troca for o EAX; qualquer outro tipo de permuta terá dois opcodes.
95 xchg ebp,eax
96 xchg esi,eax
87 d9 xchg ecx,ebx
De toda sorte, essas formas (CDQ, MUL, MOV, XOR e XCHG) são boas e devem, se possível, ser utilizadas em conjunto. O sucesso na redução do tamanho irá depender de quais registers serão necessários às syscalls do shellcode e de que valores já estarão contidos neles, dando vantagem a uma forma em detrimento às demais.
Regra n. 02 - Reutilizar dados já inseridos na STACK
Eu estava simplesmente fazendo PUSH de todos os argumentos necessários a cada syscall, desprezando o que eu já havia inserido na STACK. Obviamente os primeiros valores a serem utilizados precisam ser inseridos por nós mesmos, pois não sabemos o que há na pilha (o contrário pode ser dito se se tratar de uma aplicação em específico, cujo exploit fora desenvolvido por nós mesmos).
Socket
52 push edx
53 push ebx
6a 02 push 0x2
89 e1 mov ecx,esp
Bind
b3 02 mov bl,0x2
52 push edx
66 68 2b 67 pushw 0x672b
66 6a 02 pushw 0x2
89 e1 mov ecx,esp
No exemplo acima, sem reutilizar os dados da STACK, ao criar a estrutura sockaddr_in para fazer o Bind, são gerados 12 bytes. Todavia, vejam a diferença fazendo uso dos dados já existentes.
5b pop ebx
5e pop esi
52 push edx
66 68 2b 67 pushw 0x672b
Fantasticamente geramos apenas 7 bytes (cinco a menos). É importante ressaltar que a instrução POP apenas copia o valor da pilha para algum destino, modificando o ponteiro (ESP) do topo da pilha e deixando o valor intacto na memória, contrariamente à PUSH que o substitui. Atente para o fato de que ECX já contém o ponteiro para os dados que estamos utilizando, portanto, não o alteramos.
Se algum dado distante na STACK precisar ser modificado para reutilização correta dos demais, tiramos proveito fazendo a modificação com a MOV e um ponteiro, gerando apenas 3 bytes.
89 51 04 mov DWORD PTR [ecx+0x4],edx
Mais uma vez, devemos ponderar qual método é mais eficaz em cada caso.
Regra n. 03 - Usar instruções com menor número de opcodes
Mesmo esta regra sendo óbvia e estar implícita nas anteriores, faço questão de exemplificar com algumas instruções, para que haja melhor entendimento.
43 inc ebx
b3 02 mov bl,0x2
No caso acima, se EBX já contivesse 1, mais inteligente seria apenas a incrementarmos com INC, em vez de a atribuirmos 2 com MOV. Abaixo, segue exemplo de redução usando a LEA - load effective address - para uso aritmético com vários operandos em vez da ADD (tks Pedro Fausto).
01 d8 add eax,ebx
83 c0 02 add eax,0x2
8d 44 18 02 lea eax,[eax+ebx*1+0x2]
Regra n. 04 - GetPC (GetEIP) - Adendo
Esqueci-me de mencionar, na postagem original, a técnica GetPC que utilizei como demonstração no shellcode Shell Bind TCP - GetPC (github: assembly, fluxograma).Se o shellcode tiver um tamanho considerável e houver uma certa quantidade de instruções que se repetem, esse método é válido para se diminuir o payload usando as CALL e RET.
Analisem os códigos! Vale à pena.
Os menores do mundo? Não sei, diga-me!
O resultado de tanto mexido foi o engendramento dos três, aparentemente, menores shellcodes do mundo nas suas respectivas especificidades.
Shellcode Improvements (github com os concernentes fluxogramas e shellcode launchers)
Eu desafio vocês!
Pensando nisso estou lançando um concurso para redução dos shellcodes apresentados. Para concorrer basta criar um shellcode dos tipos acima com menor tamanho em bytes e enviar para geyslan@gmail.com. Para redução podem ser utilizados, se preferirem, os que disponibilizei.
Aprendizado! E menos bytes! ;D
Vemo-nos em breve!
Mais Informações
Intel 64 and IA-32 Manuals
