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

Encryption Bot - HackTheBox

Vamos com mais um ctf do HTB, dessa vez sera o Encryption Bot, esse chamou-me um pouco a atenção jah que em relação a outros challenges do nível facil-medio a media de usuários que obtiveram a flag eh bem pequena, vamos descobrir o porque


Primeira fase: Estudando o comportamento (entrada e resposta) e Analise com r2 e gdb

nem preciso explicar muitas coisas sobre o binario, como jah falei varias vezes aqui, meu foco eh unix/linux, entao qndo extraimos o .zip fornecido pelo HTB obtemos um elf (x64) e um arquivo ascii flag.enc

- o arquivo flag.enc possui 36 bytes, equivalente a string "9W8TLp4k7t0vJW7n3VvMCpWq9WzT3C8pZ9Wz"

e ao executar o elf (com o nome chall) vemos o seguinte

ao inserir qualquer sequencia de caracteres obtemos a seguinte resposta

I'm encrypt only specific length of character.
(-_-) Find it (-_-)

então ja sabemos o primeiro que temos que fazer na nossa checklist (encontrar o tamanho da string que o binario ira receber como input ate gerar uma resposta diferente) e tmb seria interessante encontrar a relação do arquivo flag.enc com o binario


Analise com r2

bem, ao abrir o binario com r2 (e usar "aaaa" pra gerar uma analise automatica completa) pra analise estatica vemos a primeira característica, diferente do exatlon (outro desafio do HTB que usava UPX) no chall nao foi usado nenhum packer (*basicamente um packer eh uma ferramente bastante usada pra ofuscamento que comprime a seção de .data do binario (assim reduzindo o tamanho dele) e insere uma rotina de descompressao no começo do binario, assim descomprimindo ele unicamente durante a execuçao e alterando seu entrypoint*)
bem, então vamos ao main do binario e vamos analisar seu code

e aqui encontramos a rotina principal e suas chamadas a diversas funçoes, basicamente fcn.00001628 vai mostrar no terminal aquela mensagem ascii contendo (Encryption Bot), dps uma chamada a printf com a mensagem Enter the text to encrypt : como argumento e uma scanf com nosso input que sera armazenado na *var_30h*
Dps temos a criação de um arquivo com o nome data.dat (agora temos algo interessante a explorar) no modo read (no meio disso ha um pequeno salto condicional com JE, que verifica se o arquivo jah existia, se jah existisse algum arquivo com esse nome, passa a deletar ele usando uma chama system com o argumento rm data.dat) e dps passa a escrever um salto de linea ( \n | 0xa em hexa) com putchar

Sinceiramente nada muito interessante por aqui, fora a criação do arquivo data.dat, porem, agr temos nossa primeira chamada a uma funçao interna (fcn.000015dc), o argumento passado a essa funçao eh a *var_30h* (ou seja, nosso input)