Mal comecei a leitura do meu mais novo “mother-fucker” livro e já encontrei a solução para nunca mais viver o terror que vivi quando tive que testar minha engenharia reversa do artigo sobre o Houaiss. Se trata de uma simples questão que não sei por que não sigo todas as vezes religiosamente: configure seus símbolos corretamente.
Esse é o primeiro ponto abordado pelo autor, por se tratar de algo que, caso não seja bem feito, pode dar dores de cabeça piores do que o próprio problema que originou a sessão de debugging. Por isso eu repito:
Configure Seus Símbolos Corretamente
Vamos acompanhar alguns momentos de tortura alheia?
Era uma vez
Tudo aconteceu quando inesperadamente perdi metade do artigo que estava escrevendo para explicar o processo de engenharia reversa no dicionário Houaiss. Tive que refazer todos os meus testes que havia feito no laptop. Como a preguiça é a mãe de todas as descobertas, não estava com ele ligado no momento do “reteste” e por isso acabei usando a máquina desktop, mesmo.
A análise inicial consistia simplesmente em verificar as entradas e saídas da função ReadFile, na esperança de entender a formatação interna do dicionário. Repetindo a seqüência:
windbg -pn houaiss2.exe
0:001> bp kernel32!ReadFile "dd @$csp L6" $$ Dando uma olhada nos parâmetros
g
0012fa70 0040a7a9 00000200 <font color="#ff0000">08bbf1d0 00000200</font>
0012fa80 0012fa88 00000000
eax=0012fa88 ebx=00000200 ecx=00000200 edx=08bbf1d0 esi=08bbf1d0 edi=00000200
eip=7c80180e esp=0012fa70 ebp=0012facc iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
kernel32!ReadFile:
7c80180e 6a20 push 20h
$$ O buffer de saída é <font color="#ff0000">08bbf1d0 </font>
$$ O número de bytes lidos é <font color="#ff0000">200</font>
0:000> db 08bbf1d0 L80
08bbf1d0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
08bbf1e0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
08bbf1f0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
08bbf200 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
08bbf210 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
08bbf220 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
08bbf230 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
08bbf240 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0:000> bp /1 @$ra "db 08bbf1d0 L80"
0:000> g
08bbf1d0 2a 70 72 6f 67 72 61 6d-61 2d 66 6f 6e 74 65 0d <font color="#ff0000">*programa-fonte.</font>
08bbf1e0 0a 43 73 2e 6d 2e 0d 0a-64 7b 5c 69 20 73 58 58 <font color="#ff0000">.Cs.m...d{\i sXX</font>
08bbf1f0 7d 0d 0a 54 69 6e 66 0d-0a 3a 70 72 6f 67 72 61 <font color="#ff0000">}..Tinf..:progra</font>
08bbf200 6d 61 20 64 65 20 63 6f-6d 70 75 74 61 64 6f 72 <font color="#ff0000">ma de computador</font>
08bbf210 20 65 6d 20 73 75 61 20-66 6f 72 6d 61 20 6f 72 <font color="#ff0000"> em sua forma or</font>
08bbf220 69 67 69 6e 61 6c 2c 20-61 6e 6f 74 61 64 6f 20 <font color="#ff0000">iginal, anotado</font>
08bbf230 70 65 6c 6f 20 70 72 6f-67 72 61 6d 61 64 6f 72 <font color="#ff0000">pelo programador</font>
08bbf240 20 65 6d 20 75 6d 61 20-6c 69 6e 67 75 61 67 65 <font color="#ff0000"> em uma linguage</font>
0:000> $$
0:000> $$ Tudo legível? Mas já? Ai, meu Deus, alguém chama uma benzedeira!
0:000> $$
Se notarmos no artigo anterior, veremos que o conteúdo do arquivo lido não é em texto claro, sendo necessário passar por mais algumas instruções assembly para descobrir a função responsável por embaralhar o conteúdo na memória. Contudo, ao rodar esses comandos novamente, eis que a saída do ReadFile já vem toda legível, como se o dicionário não estivesse mais encriptado.
A leitura foi feita e o texto direto do arquivo veio em claro? O que está acontecendo? Quando abro pelo comando type ele aparece todo obscuro…
Sim, alguma coisa não-trivial acaba de acontecer. Testei esse procedimento no laptop e no desktop, sendo que esse problema aconteceu apenas no desktop. Dessa vez a curiosidade falou mais alto que a preguiça, e tive que abrir as duas máquinas e comparar os resultados.
Rastreando o problema do endereço de retorno diferente
Depois de um pouco de cabeçadas rastreando o assembly executado, descobri que o ponto onde o breakpoint havia parado não era o retorno da chamada a ReadFile. Isso eu não vou demonstrar aqui pois se trata de raciocínio de passo-a-passo no assembly até descobrir a diferença. É enfadonho e sujeito a erros. Sugiro que tente um dia desses. Para mim, o resultado lógico de tudo isso é a saída que segue:
0012fa70 0040a7a9 00000200 <font color="#ff0000">08bbf1d0 00000200</font>
0012fa80 0012fa88 00000000
eax=0012fa88 ebx=00000200 ecx=00000200 edx=08bbf1d0 esi=08bbf1d0 edi=00000200
eip=7c80180e esp=0012fa70 ebp=0012facc iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
kernel32!ReadFile:
7c80180e 6a20 push 20h
0:000> ? <font color="#ff0000">poi(esp)</font>
Evaluate expression: 4237225 = <font color="#ff0000">0040a7a9</font>
0:000> ? <font color="#ff6600">@$ra</font>
Evaluate expression: 4959640 = <font color="#ff6600">004bad98</font>
0:000> ? <font color="#ff0000">poi(@$csp)</font>
Evaluate expression: 4237225 = <font color="#ff0000">0040a7a9 </font>
Como podemos ver pelos comandos acima, o pseudo-registrador $ra não está mostrando o valor corretamente!
Primeiro passo lógico: o seu é o mesmo que o meu?
A primeira coisa que se faz numa hora dessas é comparar as versões dos componentes do depurador de ambos os ambientes. Para isso usamos o comando version.
0:000> version <font color="#ff6600">$$ desktop</font>
Windows XP Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt, suite: SingleUserTS
kernel32.dll version:
Debug session time: Tue Feb 26 19:51:58.295 2008 (GMT-3)
System Uptime: 0 days 1:14:07.857
Process Uptime: 0 days 0:31:52.840
Kernel time: 0 days 0:00:01.482
User time: 0 days 0:00:02.723
Live user mode: <Local>
command line: '"C:\Tools\DbgTools\windbg.exe" -pn houaiss2.exe' Debugger Process 0xEC4
dbgeng: image <font color="#ff6600">6.6.0007.5</font>, built Sat Jul 08 17:12:40 2006
[path: C:\Tools\DbgTools\dbgeng.dll]
dbghelp: image <font color="#ff6600">6.6.0007.5</font>, built Sat Jul 08 17:11:32 2006
[path: C:\Tools\DbgTools\dbghelp.dll]
DIA version: 60516
Extension DLL search Path:
C:\Tools\DbgTools\winext;C:\Tools\DbgTools\winext\arcade;(...)
Extension DLL chain:
dbghelp: image 6.6.0007.5, API 6.0.6, built Sat Jul 08 17:11:32 2006
[path: C:\Tools\DbgTools\dbghelp.dll]
ext: image 6.6.0007.5, API 1.0.0, built Sat Jul 08 17:10:52 2006
[path: C:\Tools\DbgTools\winext\ext.dll]
exts: image 6.6.0007.5, API 1.0.0, built Sat Jul 08 17:10:48 2006
[path: C:\Tools\DbgTools\WINXP\exts.dll]
uext: image 6.6.0007.5, API 1.0.0, built Sat Jul 08 17:11:02 2006
[path: C:\Tools\DbgTools\winext\uext.dll]
ntsdexts: image 6.0.5457.0, API 1.0.0, built Sat Jul 08 17:29:38 2006
[path: C:\Tools\DbgTools\WINXP\ntsdexts.dll]
0:000> version <font color="#ff6600">$$ laptop</font>
Windows XP Version 2600 (Service Pack 2) UP Free x86 compatible
Product: WinNt, suite: SingleUserTS Personal
kernel32.dll version:
Debug session time: Tue Feb 26 20:54:39.718 2008 (GMT-3)
System Uptime: 9 days 10:26:39.289
Process Uptime: 0 days 0:00:56.359
Kernel time: 0 days 0:00:00.406
User time: 0 days 0:00:01.078
Live user mode: <Local>
command line: '"C:\Tools\DbgTools\windbg.exe" -pn houaiss2.exe' Debugger Process 0x864
dbgeng: image <font color="#ff6600">6.8.0004.0</font>, built Thu Sep 27 18:28:09 2007
[path: C:\Tools\DbgTools\dbgeng.dll]
dbghelp: image <font color="#ff6600">6.8.0004.0</font>, built Thu Sep 27 18:27:05 2007
[path: C:\Tools\DbgTools\dbghelp.dll]
DIA version: 20119
Extension DLL search Path:
C:\Tools\DbgTools\WINXP;C:\Tools\DbgTools\winext;C:\(...)
Extension DLL chain:
dbghelp: image 6.8.0004.0, API 7.0.6, built Thu Sep 27 18:27:05 2007
[path: C:\Tools\DbgTools\dbghelp.dll]
ext: image 6.8.0004.0, API 1.0.0, built Thu Sep 27 18:26:59 2007
[path: C:\Tools\DbgTools\winext\ext.dll]
exts: image 6.8.0004.0, API 1.0.0, built Thu Sep 27 18:26:28 2007
[path: C:\Tools\DbgTools\WINXP\exts.dll]
uext: image 6.8.0004.0, API 1.0.0, built Thu Sep 27 18:26:45 2007
[path: C:\Tools\DbgTools\winext\uext.dll]
ntsdexts: image 7.0.6440.1, API 1.0.0, built Thu Sep 27 18:45:23 2007
[path: C:\Tools\DbgTools\WINXP\ntsdexts.dll]
OK. A versão instalada no desktop é bem antiga. Pode ser um indício. Fiz então a atualização e comparei novamente a saída de version.
Tudo igual.
Segundo passo lógico: prove ou refute seu raciocínio
Decidi então usar aquela lógica cética que é desenvolvida por quem costuma depurar coisas sinistras e esotéricas por anos e anos e não duvida de mais nada, mas também acredita piamente que tudo tem um motivo. Se não está aparente, basta descobri-lo. E foi o que eu fiz. Gerei dois _dumps _distintos, um no laptop e outro no desktop. Ambos estavam com os ponteiros de instrução apontados exatamente para a entrada da função ReadFile, início de todo esse problema. Copiei o dump do desktop para o laptop e vice-versa.
Abri o dump do desktop no laptop: tudo funcionando. Abri o dump do _laptop _no desktop: mesmo erro.
Conclusão óbvia: é algo relacionado com o WinDbg no desktop, uma vez que o estado da pilha que era mostrado corretamente no _laptop _em ambos os dumps falhava duplamente na máquina desktop.
Próxima tentativa intuitiva: verificar o _path _dos símbolos:
.sympath
Symbol search path is: <empty>
Isso com certeza não cheira bem. Ainda mais porque do outro lado do hemisfério, meu laptop estava configurado com toda a rigidez que um laptop de WinDbgeiro deve ter:
0:000> .sympath
Symbol search path is: SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols
E aí estava uma diferença plausível. Consertados os diretórios de símbolos, tudo voltou ao normal.
Moral da história
Procure primeiro verificar as coisas mais simples. Depois você tenta consertar o universo. Mas, primeiro, antes de tudo, veja se o cabo de rede está conectado. Ou no nosso cado de debugueiro:
Configure Seus Símbolos Corretamente
Wanderley Caloni 2008-03-12