Fabiano Furtado

Segue o programa e o binário. /* * GCC 8.3.0: gcc -Wall -s -O2 helloworld.c -o helloworld */ #include<stdio.h> int main(void) { puts("Hello World!"); return 0; } helloworld

Fiz o teste com o seu PEDA, copiando o peda.py para o diretório do meu peda. Não deu muito certo. O resultado foi esse: $ gdb ./helloworld GNU gdb (GDB) 8.3 Copyright (C) 2019 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./helloworld... (No debugging symbols found in ./helloworld) gdb-peda$ start No unwaited-for children left. Display various information of current execution context Usage: context [reg,code,stack,all] [code/stack length] gdb-peda$ O que estou fazendo de errado? Valeu.

Fernando... encontrei uma maneira de se fazer isso em https://reverseengineering.stackexchange.com/questions/19598/find-base-address-and-memory-size-of-program-debugged-in-gdb Combinando essa informação do Entry Point do cabeçalho e os comandos starti, info inferior e shell pmap -x <PID>, dá pra se chegar na _start ou main(). Valeu!

Oi Fernando... vou testar sim, mas tem que ser amanhã. Legal essa iniciativa! Vou lhe dar um retorno em breve. Bom... testei esse comando "info files" que você mencionou no video e deu certo, mas deu errado! 😞 "Stripando" o binário com o strip, funciona, mas com o sstrip, não. O sstrip é um utilitário que vem no pacote elfkickers (http://www.muppetlabs.com/~breadbox/software/elfkickers.html). Enfim... parece que ele retira mais coisas do binário e o "info files" não consegue identificar o entry point. Usei o "readelf -a" para comparar e analisar os dois binários e não há nehhuma informação sobre os Section Headers no arquivo gerado pelo sstrip. Só para efeito comparativo, com o strip, o meu binário ficou com 6160 bytes. Com o sstrip ficou com 4144! Neste caso, há algum outro comando que possa ser usado no GDB? Valeu!

Fernando, obrigado pelo video! Não conhecia essa "info files". Com certeza ajudará MUITO!! Valeu!!!

Pessoal, preciso de uma ajuda com o GDB depurando arquivos binários stripped. Fiz um "Hello World!" básico em C, compilei ele com "gcc -Wall -z noseparate-code hw64.c -o hw64" e logo em seguida executei um sstrip em cima do binário. O parâmetro "-z noseparate-code" foi usado pra deixar o binário menor (leia o man deste parâmetro). Em tempo, o gcc compilou o binário com PIE habilitado, ou seja, a cada execução o SO aloca o programa em um endereço de memória diferente. Eu consegui fazer a depuração no GDB, mas precisei usar o Ghidra para descobrir os offsets do binário, uma vez que o objdump com o binário sstrip não mostra nada. Para isso, executei o GDB (estou usando a versão 8.3 com o peda 1.1): * starti --> ele executa a primeira instrução, no caso, uma instrução da lib ld-linux * info proc mappings --> para saber qual endereço de memória o programa foi alocado devido ao ASLR * breakpoint na main() --> depois de ter obtido o offset desta função com o Ghidra + informação do endereço de memória * continue --> fim da depuração Alguém conhece alguma técnica melhor que não precise do Ghidra (ou outro disassembly) para obtermos os offsets das funções? Desde já, agradeço.

Tudo bem! Não precisa utilizar funções naked. Pode ser ofuscação utilizando outros métodos. Por exemplo, me lembro uma vez que você postou um artigo/comentário sobre substituição de uma insrtução call por outras equivalentes (push e jmp) para enganar o decompiler.... enfim... acho que você deve ter algum material bom sobre isso. Valeu!!!!

Mais um link com dicas para deixar o seu binário menor: http://ptspts.blogspot.com/2013/12/how-to-make-smaller-c-and-c-binaries.html

Segue o link do NASM: https://blog.stalkr.net/2014/10/tiny-elf-3264-with-nasm.html O programa ficou com 132 bytes com o NASM versão 2.14.02.

Fernando.... blza? Vc tem mais exemplos de ofuscação? Eu achei bem interessante, apesar de ser "meio fraco". :)

Pessoal... Olhem isso: https://www.cirosantilli.com/elf-hello-world/ http://timelessname.com/elfbin/ O pessoal está usando o NASM para gerar os bytes diretamente para o binário, sem usar o GCC. Bem interessante.

Blza.... vou pesquisar sobre o assunto. Se sair algo, eu divulgo aqui. Obrigado!

Pessoal, boa noite. Estava pensando em fazer um programa em C para inserir NOPs entre duas funções quaiquer da section .text de um binário ELF. Seria mais para fins de estudos mesmo, sem muito objetivo prático. Alguém já pesquisou sobre isso? Será que vale o esforço? Imagino que não seja algo muito fácil de se fazer, uma vez que temos várias referências de chamadas de funções dentro de um binário. Desde já, agradeço.

Muito bom os artigos!!!! Realmente fica quase impossível adivinhar esses números diante de tantas possíveis combinações.

Pessoal, desenvolvi recentemente 2 programas em C para gerar e filtrar números/combinações numéricas das loterias Dupla Sena e Lotofácil (eles podem ser adaptados facilmente para outros tipos de concursos, por exemplo). Gostaria de um feedback de vocês pois não sei se fiz da melhor forma possível. Achei a leitura do arquivo texto contendo as combinações um pouco lenta. Enfim... todas as críticas são bem-vindas pois tenho certeza que poderia ter feito ele de outra maneira mais otimizada. https://github.com/fabianofurtado/random-lottery-numbers Há, basicamente, duas formas de vocês o utilizarem: 1) Através de um arquivo texto contendo as combinações (pode ser gerada no random.org) 2) Através do parâmetro -n onde o sistema utilizará as funções srand() e rand() da libc. Valeu!