Dúvida Curso de Engenharia Reversa - Aula 6

[toto9202]

Em relação `a aula Aula 6 - Executável PE - Seções e endereçamento, por que que ao abrir o crackme.exe no debugger x32dbg, o endereço virtual inicial mostrado foi o 7703746D, e não o 00401000 que foi apresentado na aula?  Por que isso acontece? Como faço essa modificação para que entre automaticamente no 00401000? Precisei executar RUN para que fosse para o endereço 00401000.

Pretendem apresentar situações diversas de reversão tanto no Ollydbg como no IDA Pro?

Muito interessante as aulas. Com boa didática, bom conteúdo e aprofundamento do tema.  Informo que fiz minha assinatura. Seria bom se as aulas fossem maiores,  pelo menos uns 50 minutos.

Grato.

[Leandro Fróes]

Boa tarde @toto9202, tudo bem?

Dê uma olhada neste vídeo aqui. Ele fala justamente sobre o ASLR( o motivo dos endereços serem randômicos a cada execução) e como desabilitar isto.

Sobre os debuggers... não se prende muito nisso não, todos fazem quase a mesma coisa, o que difere são as funcionalidades, mas a engenharia reversa da pra você fazer em todos se souber a base e sim, terão sim desafios, inclusive o último vídeo do CERO é um.

Qualquer dúvida sobre o ASLR, onde este bit fica etc etc só mandar bala aqui.

Abs

 

[Felipe.Silva]

@Leandro Fróes. Posso ter interpretado errado o texto dele, mas eu acho que não era ASLR. Ele disse que quando clicou "RUN" ele foi para o endereço 401000.

Eu não sei o motivo e nem sei do que se trata, mas quando eu abro um executável no EDB ele também executa um código antes do entry point.
Fica na região de memória do ld-2.26.so então eu imagino que seja alguma inicialização do S.O.
Deve ser o mesmo caso no Windows.

Mas como eu já disse eu não sei direito do que se trata. Inclusive eu queria perguntar aqui sobre isso e me esqueci.

[toto9202]

Boa noite Leandro e Felipe.

O vídeo esclareceu o meu problema. Executando o x32dbg, sempre entrava no módulo ntdll (houve variações de endereço em todos sistemas operacionais que testei), porém, em nenhum dos casos, o endereço virtual na memória de início no debugger era o entry point (00401000). Assistindo o vídeo, percebi que neste caminho: Options --> Preferências --> Events --> System Breakpoint, o System Breakpoint estava marcado. Ao desmarcar, o debugger passou a abrir o crackme exatamente no 00401000 (entry point). Não tive problema do ASLR, independente de qual sistema fosse aberto. Nos Ollydbg mais antigos, vários deles modificados, enfrento problemas. Mesmo tendo a opção marcada para iniciar no Entry point of main module, vários deles iniciam na rotina do sistema e boa parte nem consegue executar o código para que a janela seja apresentada.

Valeu!!!

Fábio.

[Fernando Mercês]

Opa!

Da documentação do x64dbg: 

Citar

System Breakpoint

This event happens when the process is being initialized but have not begun to execute user code yet

Ou seja, com a opção de parar no "System Breakpoint" marcada, você cai no código do loader que vai carregar o binário. No Windows o processo começa na CreateProcess() e cia, da kernel32.dll, mas no fim das contas essa família de funções chama a Native API na ntdll.dll e é por isso que o debugger pára nela, mais especificamente na função LdrpInitializeProcess(), já que ela é que vai de fato vai chamar o kernel para criar o processo.

Dá pra ter uma ideia do funcionamento disso vendo o código do Wine ou do ReactOS no ldrinit.c.

No Linux a situação é análoga. O loader fica na ld-*.so e por isso você pára nela. Sendo um pouco mais versátil, dá até pra brincar chamando o loader para carregar um binário:

$ /lib64/ld-linux-x86-64.so.2 /bin/date
Tue Jul 10 12:03:51 EDT 2018

$ man ld.so

Dentre outras situações, esse recurso nos debuggers é útil para vermos códigos que rodem antes do entrypoint, mas vários debuggers modernos já sabem onde esses códigos poderiam estar (TLS callbacks, DLL entry, etc) e permitem parar lá diretamente. Então eu deixo desmarcada por padrão, mas é bom saber que tem. =)