Trace into no ollydbg

[gzn]

E aí galera, mais uma vez estou aqui!

Fui ver um vídeo do Mercês sobre Ollydbg no YouTube (do canal mente binária) e acabei que baixando ontem o Ollydbg. Coloquei ele para rodar no wine (estou usando uma distro chamada kubuntu).

Fui fazer um simples teste com o Ollydbg analisando um binário de nome rtrace.exe seguindo o tutorial neste endereço. Estou confuso: quando eu logo o trace into em um arquivo não consigo ver que a execução passou pelo endereço 4011A3 (onde tem um CMP EAX, 3). Porém, quando eu coloco um ponto de parada nesse endereço ele para ali! Ué, o trace into não guarda todas as instruções executadas? Por que o caminho não está coincidindo? Eu devo estar cometendo alguma bobeira... rs

Obs.:

Ollydbg que eu usei foi: http://www.ollydbg.de/odbg201.zip

O binário que eu examinei foi o seguinte: http://www.ollydbg.de/tut_rtr.zip (tá dentro desse zip com o nome rtrace.exe)

A versão do wine: wine-1.8.7 (Ubuntu 1.8.7-1ubuntu1)

Eu fiz um vídeo agora pra vocês verem o que fiz de errado: https://drive.google.com/open?id=0B1q3ErJCNtmTTWx4dGpONjdVcEk (se você baixar fica com resolução melhor do que assistir online)

[Fernando Mercês]

Que pergunta boa. :-)

Quando você rodou o Run Trace o Olly logo reclamou que não conseguiu acessar o endereço 00000000 de memória que naturalmente é inválido pro programa mesmo. E no teu log do do Run Trace ele mostrou o motivo (00:34s do vídeo): a função GetProcAddress() chamada em 406E1D retornou NULL (EAX=0). Então em 406E28 que tem um CALL EAX resultou no endereço 00000000 sendo colocado em EIP e a execução foi pra lá. Como este endereço é inválido, o Run Trace parou e o programa pausou. Logo, não chegou no CMP que você queria e por isso não está no log.

A questão é: por que quando o Olly estava instrumentando (protocolando) as instruções com o Run Trace aconteceu isso e quando você simplesmente colocou um BP na instrução que você queria e mandou rodar deu tudo certo? É difícil dizer mas o Run Trace é uma operação custosa que eu jamais rodaria no Olly sobre o Wine. Eu rodei aqui numa VM (só patcheei esse loop que tem um milhão de iterações - mudei pra 10) e a instrução CMP em 4011A3 foi protocolada normalmente. Não tive o problema com a GetProcAddress() em 406E1D. Fiz um vídeo também pra ficar melhor de entender.

Tenta numa VM e avisa aí no que deu. ;-)

Abraço!

[gzn]

Nossa, muito obrigado pela resposta Fernando Mercês.

Citar

[...] Run Trace é uma operação custosa [...]

Pois é, sobre o run trace ser uma operação custosa eu vi mesmo no tutorial alertando, mas achei que mesmo demorando ele ia protocolar. Era esperado o mesmo comportamento de execução tanto no Windows quanto no Wine.

Citar

Tenta numa VM e avisa aí no que deu. ;-)

Eu fiz um teste no Windows deu tudo certo, protocolou como esperado .

Ah! Falando sobre a operação ser custosa durante o run trace, lá no tutorial diz que a gente pode pular certos códigos que não tem saltos para código externo:

Citar

Note that sequence is quasi-linear, i.e. has no jumps to outside. From the pop-up menu, choose "Run trace|Skip selection when tracing -- Tutorial Run Trace, Oleh Yuschuk

Só que nessa versão do olly (2.01) quando eu clico com botão direito na janela CPU (onde tem o disassembly)  sobre a seleção não acho essa opção...

Eu pesquisei na internet e vi que o método é diferente e parece menos prática... https://reverseengineering.stackexchange.com/a/8292

 

 

[Fernando Mercês]

Em 10/2/2017 em 19:03, gzn disse:

Só que nessa versão do olly (2.01) quando eu clico com botão direito na janela CPU (onde tem o disassembly)  sobre a seleção não acho essa opção...

Sim, uma pena que esta versão não tenha sido acabada e por isso algumas opções que havia na v1 simplesmente não existem na v2, como este caso da exclusão. Como o Olly tem a opção de incluir apenas um range de EIP específico, o cara aí no StackExchange fez duas faixas, excluindo as instruções que ele não queria, o que de fato não é nada prático. Outra opção é usar o Olly v1 mesmo.

Abraço!

[gzn]

Outra ideia que tive e fiz também é pausar a execução durante um run trace into demorado e colocar um bp depois do trecho que demora muito e depois continuar. Dessa forma ele vai e para no bp e depois disso é só apertar para fazer o run trace into de novo. Isso se o trecho for executado uma única vez rs, do contrario a gente ia te que ficar perdendo tempo fazendo esse processo manualmente rs (bem, eu soube que todo depurador geralmente tem uma API para automação, quem sabe não seria por aí rs).

Mercês, devido a essas carências no Olly 2.01 eu descobri outro depurador chamado x64dbg. Ele parece fantástico, parece ter muito mais coisa do que no Olly (inclusive um decompilador interessante chamado snowman). Baixei ele ontem e testei, porém to apanhando aqui:

1º Tentei achar uma forma de salvar as configurações do "Trace into", mas toda vez tem que preencher o diálogo lá (a gente aperta Ctrl+Alt+F7 e tem que faze tudo de novo)...

2º Tentei achar um Hit trace com frequencia de execução, igual ao que o Olly faz na coluna "Back" da janela "Run trace."...