Ir para conteúdo
  • Cadastre-se
Entre para seguir isso  
toto9202

Dúvida Curso de Engenharia Reversa - Aula 6

Posts Recomendados

Postado (editado)

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.

Editado por toto9202

Compartilhar este post


Link para o post
Compartilhar em outros sites

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

 

Compartilhar este post


Link para o post
Compartilhar em outros sites

@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.

806195667_Capturadetelade2018-07-0918-12-14.thumb.png.95ef75c653b0fc065f4c6b7ef9d00b8c.png

  • Curtir 1

Compartilhar este post


Link para o post
Compartilhar em outros sites

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.

Editado por toto9202
  • Curtir 1

Compartilhar este post


Link para o post
Compartilhar em outros sites

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. =)

 

Compartilhar este post


Link para o post
Compartilhar em outros sites

Crie uma conta ou entre para comentar

Você precisar ser um membro para fazer um comentário

Criar uma conta

Crie uma nova conta em nossa comunidade. É fácil!

Crie uma nova conta

Entrar

Já tem uma conta? Faça o login.

Entrar Agora
Entre para seguir isso  

  • Quem Está Navegando   0 membros estão online

    Nenhum usuário registrado visualizando esta página.

×