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)

int fcn.000015dc (var_30h)

e aqui temos a resposta a nosso primeiro elemento da checklist, basicamente aqui nosso input eh passado pra a library strlen e caso seja menor que 0x1b (27), ira nos retornar aquela mensagem de erro, entao vamos executar novamente e inserir 27 caracteres e observar a resposta

input com 27 caracteres

a resposta eh uma mensagem criptografa com 36 caracteres, equivalente a nosso input, com essa resposta podemos observar algumas coisas, como por exemplo, a saida eh igual ao tamanho da flag.enc, entao ja sabemos o que deve ser feito pra obter nossa flag, entrar com um input que gere de forma equivalente o conteúdo da flag.enc
Uma resposta possivel seria usar alguma tecnica de bruteforce como a execução simbólica, mas pra isso precisamos encontrar o algoritmo de cifrado dentro do binario e o comportamento da entrada

- - -

ateh agr encontramos a quantidade de caracteres do input necessário pra nao receber um erro, agr vamos continuar nossa analise, jah sabemos que devemos procurar um comportamento parecido a um algoritmo da criptografia ou alguma chamada relativa

voltando pra main no radare2 temos que dps da função fcn.00001628 (que verifica o tamanho da entrada observamos que dps de sair da funçao, o 0 eh movido pra rax e ha outra chamada a fcn.0000128a (nada relevante nela, eh soh um alinhamento da stack), dps na main podemos ver que variavel que armazena nosso input eh usado como argumento pra funçao fcn.0000131d
Eu ateh pensei em colocar ela aqui e explicar passo a passo como tenho feito até agr, porem ela eh bastante grande e parece mais complexa do que realmente eh (jah que inclui as optimizaçoes do compilador), mas basicamente vou fazer um pequeno resumo dela aqui

basicamente a funçao pega nosso input (como um vetor armazenado em *var_30h*) e usa um loop para extrair cada elemento do vetor e converte ele em ascii (em hexadecimal, que no nosso caso seria equivalente a "a" = 0x61) e chama uma funçao interna dentro do loop, que converte o elemento hexadecimal a binario ( 0x61 = 01100001) e faz isso ateh o final do vetor e escrevendo a saida no arquivo *data.dat* 
assim, o arquivo *data.dat* possui 216 bytes (27 * 8

)

Assim sabemos que o arquivo data.dat eh o equivalente em binario a nosso input, vamos agr pra seguinte funçao fcn.000014ba pra descobrir o que o binario faz com o arquivo