tem mais no meu github, pra aqueles que nao tem uma noçao sobre shellcoding e pode parecer estranho, fiz um post apenas pra explicar como funcionam os segmentos de memoria e como podemos executar memoria diretamente em um segmento (seja atraves de alguma vulnerabilidade ou outorgando as permissoes pra testes)

https://github.com/0x177git/memfd_pos-exploiting/blob/main/basic_concepts_of_stack.md

pessoal publiquei um shellcode no github, eh um sample bem basico onde encripto o /bin/sh usando xor e uma chave e dps decripto na stack e mando o endereço como ponteiro pra a syscall execve()
deixei no README um algoritmo pra que vc teste seu propio argumento, lembrem de sempre usar strings de 8 a 16 bytes

https://github.com/0x177git/xor-encrypted-execve-sh/tree/main

pra quem quisser aprender a desenvolver tem meu repositorio explicando as bases e conceitos do shellcoding

https://github.com/0x177git/memfd_pos-exploiting/blob/main/principios%26estrategias.md

se tiverem alguma pergunta basta abrir uma issue que assim que puder irei responder

deixei varias referencias em portugues, porem a maioria estao em ingles, mas se acompanharem o conteudo com cuidado, vao ver que as ideias se conetam aos poucos

Hj trago um ctf que achei bastante interessante, eh bem simples na vdd, mas pelo que vi nos foruns mta gente ta se perdendo nele

Bem, o ctf eh o Golfer - Part 1 do hackthebox

Como vcs ja sabem eu uso bastante radare2 entao nesse post iremos usar ele, o ctf consiste quase que unicamente de analise estatica, entao eh bem de boas porem achei uma proposta interessante para aproveitar e falar de opcodes e patching (com editor hexa msm)
O primeiro elemento que iremos observar ao analisar com rabin2 ou dentro do framework do r2 eh que ele ta codado em x86, entao o que veremos serao algumas instruçoes x86
Ao tentar procurar a main veremos que esse pequeno elf nao tem, ele se executa no ponto de entrada

vemos tmb que ha multiplas chamadas a uma funçao (fcn.0800012f
), entao vamos olhar ela

nela temos uma syscall (1) cm o argumento passado e armazenado na stack, como estamos lidando com um elf x86 ao olhar a tabela de syscall do linux x86 podemos ver que ele ta desviando pra uma chamada ao nucleo do tipo write

Mas ao olhar com detalhe os argumentos sendo passados a cada syscall veremos que eles literalmente nao fazem sentido algum, vamos olhar a codificação deles??

2   0x0000012a 0x0000012a 4   7            utf8  3*U blocks=Basic Latin,Combining Diacritical Marks

eh uma codificação de combinação de caracteres diacríticos baseada em basic latin
entao o que temos ateh agora??

sabemos que existem 27 chamadas a uma funçao com esses parametros escrevendo no descritor de saida, com uma combinaçao de caracteres propia

acho que jah sabemos o fluxo de execução para obter nossa flag

e o que nos detem de atingir essas instruçoes para continuar nossa analise??, bem, um JMP proximo ao endereço 0x08000127

esse jump nos retorna 42 como codigo de saida, o que isso representa??
Bem, oo 42 basicamente eh um numero que representa os segredos da galaxia e alguma coisa do tipo (https://en.wikipedia.org/wiki/Phrases_from_The_Hitchhiker%27s_Guide_to_the_Galaxy#Answer_to_the_Ultimate_Question_of_Life,_the_Universe,_and_Everything_(42))

Aqui nao estamos procurando isso por enquanto (ou talvez??)
Entao essa instruçao basicamente nao nos serve de nada, apenas desvia o fluxo de execuçao evitando que aquele bloco de instruçao nao sejam executados

E era nessa parte do ctf que eu queria chegar, eh aqui onde iremos falar de patching (de forma mto simples)

como podemos ver, esse salto nao eh condicional, logo nao podemos modificar ele com um debugger ou coisa do tipo

porem, e se modificamos os opcodes para literalmente deixar a instruçao ao nosso favor??
como o r2 nos permite ver, o conjunto de opcode relativo a essa instruçao sao e9d6000000
entao vamos modificar ele afim de literalmente evitar a instruçao, jah vou avisando que simplesmente zerar ela vai quebrar o fluxo de execuçao, entao vamos modifica-la ao nosso favor
para isso podemos olhar no manual de referencia em x86
eu jah expliquei sobre opcodes e set instruction no meu github qndo falamos sobre desenvolvimento de shellcode

Basicamente temos prefixos que aponta a instruçao ou o tipo de dados que iremos modificar,nesse caso o prefixo eh e9 seguido de d6
ao olhar as referencias de instruçao veremos que e9 consistem em um JMP proximo seguido do tamanho do salto
em assmebly existem diferentes tipos de JMP (proximo, de segmento, apontando pra instruçao e extraido da stack), tdo isso eh melhor explicado no livro do Mente binaria (https://mentebinaria.gitbook.io/assembly/a-base/saltos)

Nesse caso e9 (JMP) e d6 (SIZE em hexa) se referem a um salto de 214 bytes (d6 = 214)

entao basicamente o que podemos fazer eh modificar o opcode pra outra instruçao tipo nop-slide ou coisa do tipo, nesse caso podemos deixar o prefixo e simplesmente deixar o tamanho do salto igual a 1

ficaria e900000000

e agr ao executar atingiriamos o fluxo de execuçao que queriamos, assim obtendo a flag

HTB{y0U_4R3_a_g0lf3r}

isso pode ser feito com qlqr editor hexa,basta encontrar o byte que queriamos modificar


Bem, eh um ctf bem tranquilo e facil, porem achei mto interessante pra explicar como funciona o patching de binarios

O que fizemos aqui foi identificar a instrução que queriamos modificar, analisar os opcodes para modificar arbitrariamente em linguagem de maquina (usando um editor hexa) e desviar ao fluxo para encontrar a flag, todo sem modificar durante a depuraçao

Isso pode ser util em alguns casos e eh interessante conhecer o patching diretamente, existem ferramentas que fazem isso, mas ao saber como funciona, podemos desenvolver as nossas ou corrigir erros em ferramentas, isso eh bem mais interessante que soh usar uma interface pronta, dessa forma realmente entendemos