Assembly: [Løst]Klarer du å løse denne oppgaven?

[fenderebest]

Bare for artig har jeg bestemt meg for å vise litt hvordan man kan feilsøke et systemkræsj i Windows XP ved å bruke en debugger, (I dette tilfellet Windbg) og også se om noen andre muligens klarer å finne ut hva som er problemet.

Uansett, systmet bugchecket med en 0XA bugcheck (IRQL NOT LESS OR EQUAL) og jeg huket på en debugger og dumpet ut stakken for den tråden som forårsaket problemet:

 

kd> kv

ChildEBP RetAddr Args to Child

f8959e08 804dbda3 badb0d00 00000000 82266008 nt!KiTrap0E+0x233 (FPO: [0,0] TrapFrame @ f8959e08)

f8959e98 804dc4a8 f8959fc0 0000003e f8959fc0 nt!KiWaitTest+0x30 (FPO: [Non-Fpo])

f8959fa4 804dc378 18d1bda0 00000000 ffdff000 nt!KiTimerListExpire+0x7a (FPO: [Non-Fpo])

f8959fd0 804dbbd4 8055a020 00000000 0000103d nt!KiTimerExpiration+0xaf (FPO: [Non-Fpo])

f8959ff4 804db89e baeead54 00000000 00000000 nt!KiRetireDpcList+0x46 (FPO: [0,0,0])

f8959ff8 baeead54 00000000 00000000 00000000 nt!KiDispatchInterrupt+0x2a (FPO: [uses EBP] [0,0,1])

WARNING: Frame IP not in any known module. Following frames may be wrong.804db89e 00000000 00000009 bb835675 00000128 0xbaeead54

 

Når et unntak eller et avbrudd forekommer lager Windows et såkalt trap frame som det lagrer på kernel-siden av stakken, dette trap framet inneholder trådens nåværende kontekst, som vi ser har vi en trap frame adresse på stakken. La oss derfor undersøke denne:

 

kd> .trap f8959e08

ErrCode = 00000000

eax=00000000 ebx=81fd9fe8 ecx=f8959e88 edx=00000000 esi=81fd9fe0 edi=81fda008 eip=804dbda3 esp=f8959e7c ebp=f8959e98 iopl=0 nv up ei pl nz ac pe cycs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010217

nt!KiWaitTest+0x30:804dbda3 6683781601 cmp word ptr [eax+16h],1 ds:0023:00000016=????

 

Dette er da altså den instruksjonen som feilet, kan noen se hvorfor?

Her følger en komplett deassembling av funksjonen KiWaitTest+0x30:

 

kd> uf nt!KiWaitTest+0x30

nt!KiWaitTest:

804dbd7b 8bff mov edi,edi

804dbd7d 55 push ebp

804dbd7e 8bec mov ebp,esp

804dbd80 83ec10 sub esp,10h

804dbd83 53 push ebx

804dbd84 56 push esi

804dbd85 8bf1 mov esi,ecx

804dbd87 837e0400 cmp dword ptr [esi+4],0

804dbd8b 8d4df0 lea ecx,[ebp-10h]

804dbd8e 8d5e08 lea ebx,[esi+8]

804dbd91 8b03 mov eax,dword ptr [ebx]

804dbd93 8955f8 mov dword ptr [ebp-8],edx

804dbd96 894df4 mov dword ptr [ebp-0Ch],ecx

804dbd99 894df0 mov dword ptr [ebp-10h],ecx

804dbd9c 7e5f jle nt!KiWaitTest+0xd7 (804dbdfd)

 

nt!KiWaitTest+0x27:

804dbd9e 57 push edi

 

nt!KiWaitTest+0x28:

804dbd9f 3bc3 cmp eax,ebx

804dbda1 744f je nt!KiWaitTest+0xb7 (804dbdf2)

 

nt!KiWaitTest+0x30:

804dbda3 6683781601 cmp word ptr [eax+16h],1

 

Gitt denne informasjonen hva ville vært interessant å undersøkt videre for å prøve å finne ut hva som forårsaket problemet?

 

Skal bli artig og se om noen finner løsningen, lykke til! Om ikke poster jeg svaret om 2 uker.

[Goophy]

eax-krøllet ligger her: 804dbd91 8b03 mov eax,dword ptr [ebx]

 

Finn ut hva som ligger i ebx.

Da får du en adresse du kan søke opp pool-tagen til og finne driveren som er faulty.

[fenderebest]

Fantastisk! En løsning så raskt-jeg får virkelig begynne å lage vanskeligere oppgaver. Som du sier blir EAX satt ved instruksjonen:

804dbd91 8b03 mov eax,dword ptr [ebx]

Hva ligger i EBX?

 

kd> dd ebx

81fd9fe8 00000000 00000000 18d1af90 00000000

81fd9ff8 f8959fc0 f8959fc0 81fda008 00000000

81fda008 01000013 00000000 00000000 f8370f1a

81fda018 81fd9fe0 00000000 00000000 00000000

81fda028 bad67b5a 81fd7000 820e5ad0 00000000

81fda038 000a0008 00000001 81fda040 81fda040

81fda048 00000000 00000000 00000000 00000000

81fda058 81fda060 00000000 01000013 ffdff980

 

Jo ganske riktig, her ser man hvordan EAX ble nullet ut.

Deretter aktiverer man såkalt pool tagging-en funksjon som gjør at alle pool-allokasjoner blir tagget med den systemdriveren som gjorde dem. Altså får hver enkelt enhetsdriver en unik tag.

Antagelsen er da at minneområdet 81fd9fe8 er blitt korrupt, ved å bruke !pool kommandoen kan man undersøke tag'en for å finne ut hvem som gjorde allokeringen.

 

kd> !pool 81fd9fe8

Pool page 81fd9fe8 region is Nonpaged pool

*81fd7000 : large page allocation, Tag is NALW, size is 0x5000 bytes

Owning component : Unknown (update pooltag.txt)

 

Pool-tag'en er ukjent mao er det ingen windows komponent-men man kan videre bruke feks strings- et verktøy som lar seg søke etter tekststrenger i feks driverfiler

 

 

Og vips så ser man at drivertagen tilhører wlcom51b.sys. som er da en miniportdriver for et wlan-kort.

 

kd> lm kv m wlcom51b

start end module name

bad5e000 bad8ac00 wlcom51b (deferred)

Image path: \SystemRoot\system32\DRIVERS\wlcom51b.sys

Image name: wlcom51b.sys

Timestamp: Fri Oct 22 15:59:55 2004 (4179125B)

CheckSum: 00033C12

ImageSize: 0002CC00

Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0

 

Videre analyse viser at driveren er nok så gammel og en oppdatering løste problemet!

Endret 24. mars 2009 av fenderebest

[Marvil]

Hei!

 

Emnetittelen i denne tråden er lite beskrivende for trådens innhold og det er derfor ingen god emnetittel. Jo bedre og mer beskrivende emnetittelen er, jo lettere er det for andre å skjønne trådens innhold og det vil være lettere å treffe den riktige forumbrukeren med det rette svaret. Ber deg derfor om å endre emnetittel. Vennligst forsøk å ha dette i tankene neste gang du starter en tråd, og orienter deg om hva vår nettikette sier om dårlig bruk av emnetitler.

 

Husk at en god emnetittel skal beskrive eller oppsummere hvilket problem du har - ikke at du har et problem. En god emnetittel skal heller ikke kun bestå av et produktnavn.

 

Bruk -knappen i første post for å endre emnetittelen.

 

(Dette innlegget vil bli fjernet ved endring av emnetittel. Ikke kommenter dette innlegget, men gjerne dette innlegget når tittelen er endret, så vil det bli fjernet..)

[Techster]

eax-krøllet ligger her: 804dbd91 8b03 mov eax,dword ptr [ebx]

 

Finn ut hva som ligger i ebx.

Da får du en adresse du kan søke opp pool-tagen til og finne driveren som er faulty.

 

Hvordan fant du det ut?

[Techster]

Fantastisk! En løsning så raskt-jeg får virkelig begynne å lage vanskeligere oppgaver. Som du sier blir EAX satt ved instruksjonen:

804dbd91 8b03 mov eax,dword ptr [ebx]

Hva ligger i EBX?

 

kd> dd ebx

81fd9fe8 00000000 00000000 18d1af90 00000000

81fd9ff8 f8959fc0 f8959fc0 81fda008 00000000

81fda008 01000013 00000000 00000000 f8370f1a

81fda018 81fd9fe0 00000000 00000000 00000000

81fda028 bad67b5a 81fd7000 820e5ad0 00000000

81fda038 000a0008 00000001 81fda040 81fda040

81fda048 00000000 00000000 00000000 00000000

81fda058 81fda060 00000000 01000013 ffdff980

 

Jo ganske riktig, her ser man hvordan EAX ble nullet ut.

Deretter aktiverer man såkalt pool tagging-en funksjon som gjør at alle pool-allokasjoner blir tagget med den systemdriveren som gjorde dem. Altså får hver enkelt enhetsdriver en unik tag.

Antagelsen er da at minneområdet 81fd9fe8 er blitt korrupt, ved å bruke !pool kommandoen kan man undersøke tag'en for å finne ut hvem som gjorde allokeringen.

 

kd> !pool 81fd9fe8

Pool page 81fd9fe8 region is Nonpaged pool

*81fd7000 : large page allocation, Tag is NALW, size is 0x5000 bytes

Owning component : Unknown (update pooltag.txt)

 

Pool-tag'en er ukjent mao er det ingen windows komponent-men man kan videre bruke feks strings- et verktøy som lar seg søke etter tekststrenger i feks driverfiler

 

 

Og vips så ser man at drivertagen tilhører wlcom51b.sys. som er da en miniportdriver for et wlan-kort.

 

kd> lm kv m wlcom51b

start end module name

bad5e000 bad8ac00 wlcom51b (deferred)

Image path: \SystemRoot\system32\DRIVERS\wlcom51b.sys

Image name: wlcom51b.sys

Timestamp: Fri Oct 22 15:59:55 2004 (4179125B)

CheckSum: 00033C12

ImageSize: 0002CC00

Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0

 

Videre analyse viser at driveren er nok så gammel og en oppdatering løste problemet!

 

Hvordan ser du at eax blir nullet ut her?

[fenderebest]

Instruksjonen

mov eax,dword ptr [ebx]

 

Vil jo overføre verdien som ebx peker til inn i registret eax.

Man dumper derfor ut minneområdet som ebx peker til og får dette:

kd> dd ebx

81fd9fe8 00000000 00000000 18d1af90 00000000

81fd9ff8 f8959fc0 f8959fc0 81fda008 00000000

81fda008 01000013 00000000 00000000 f8370f1a

81fda018 81fd9fe0 00000000 00000000 00000000

81fda028 bad67b5a 81fd7000 820e5ad0 00000000

81fda038 000a0008 00000001 81fda040 81fda040

81fda048 00000000 00000000 00000000 00000000

81fda058 81fda060 00000000 01000013 ffdff980

 

Som du ser er de første 32 bitene bare 0. Dermed ble eax satt til 0 ved denne instruksjonen.

 

Siden en senere instruksjon ( Som var den som feilet) refererer minneaddressen i eax

nt!KiWaitTest+0x30:804dbda3 6683781601 cmp word ptr [eax+16h],1 ds:0023:00000016=????.

 

Referer man til addresse 00000016 i minnet som er en ugydlig minneaddresse da dette er et minneområde i Windows som er et reservert nullpekerminne. Dermed er det rimelig å anta at verdien hentet fra Ebx er ugydlig og dermed er minnet ugyldig.

[Techster]

Ok. Ser sammenhengen.