Another odd one…

 

More than a bit this time…

 

Here is something to think about – and I don’t know why we don’t catch this. Maybe someone else has ideas.

 

Machine was crashing  every time we tried to do the same action – in this case it was a dcpromo.  So each time at the same spot during dcpromo , LSASS would crash.

 

 

Question for any fellow MS Bloggers - Is it OK for me to post a stack using public symbols? 

 

I want to walk folks all the way thru my thought process but have snipped it so I dont get in trouble.... So I also changed the mem locations and call   ( not sure why since anyone with internet access has the symbols ) but I am paranoid. Maybe some kinda security risk? That's another post, why am I paranoid? Am I too paranoid? Ultra paranoid? Crazy?

 

Anyway - here was where we were crashing each time.

 

0:025> r

eax=00000000 ebx=00000000 ecx=00001a67 edx=6c82ed54 esi=00000000 edi=00000004

eip=6216de22 esp=01b6f874 ebp=01b6fb2c iopl=0         nv up ei pl zr na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246

foomod!foofunc1:

6216de22 0000            add     byte ptr [eax],al          ds:0023:00000000=??

 

 

 

Whats going on here? This isn’t how it should look...

 

0:025> u eip

6216de22 0000            add     byte ptr [eax],al

6216de24 0000            add     byte ptr [eax],al

6216de26 0000            add     byte ptr [eax],al

6216de28 0000            add     byte ptr [eax],al

6216de2a 0000            add     byte ptr [eax],al

6216de2c 0000            add     byte ptr [eax],al

6216de2e 0000            add     byte ptr [eax],al

6216de30 0000            add     byte ptr [eax],al

6216de32 0000            add     byte ptr [eax],al

6216de34 0000            add     byte ptr [eax],al

6216de36 0000            add     byte ptr [eax],al

6216de38 0000            add     byte ptr [eax],al

6216de3a 0000            add     byte ptr [eax],al

6216de3c 0000            add     byte ptr [eax],al

6216de3e 0000            add     byte ptr [eax],al

6216de40 0000            add     byte ptr [eax],al

 

 

All of the code section around here have been zero’d out.

 

0:025> dc 6216dbf0 

 

6216dbf0  0203ffff bd890009 ffffff4c 89d4458d  ........L....E..

6216dc00  00000000 00000000 00000000 00000000  ................

6216dc10  00000000 00000000 00000000 00000000  ................

6216dc20  00000000 00000000 00000000 00000000  ................

6216dc30  00000000 00000000 00000000 00000000  ................

6216dc40  00000000 00000000 00000000 00000000  ................

 

 

< more 0’s snipped >

 

6216e1b0  00000000 00000000 00000000 00000000  ................

6216e1c0  00000000 00000000 00000000 00000000  ................

6216e1d0  00000000 00000000 00000000 00000000  ................

6216e1e0  00000000 00000000 00000000 00000000  ................

6216e1f0  00000000 00000000 00000000 00000000  ................

6216e200  6e696268 00000000 00001000 00000000  hbin............

 

 

 

 

Customer’s File:

 MD4:  13A867915743BB72EC65DA678BC8AFE3

 MD5:  C5CD5F76E85213C1F2077F3742F2B283

 SHA:  529F8F1C8AF1A4D20BCB853DDE38E61F098EEFBA

 SHA1:  529F8F1C8AF1A4D20BCB853DDE38E61F098EEFBA

 

 

My File – same version etc… ( even if it doesnt look like it )

 MD4:  77D807C081B591950CC27DDF38017284

 MD5:  E7996A8BDCF6D05D435A5E86F54D5E67

 SHA:  0B5BB92B3BA96F2194BA959031267CB4B2401C6A

 SHA1:  0B5BB92B3BA96F2194BA959031267CB4B2401C6A

 

Obviously different.

 

This is similar to my other post about “every little bit counts” but in this case we have a whole chunk which is different, and I suspect if I had looked at other areas I would find the similar corruption.

 

The customer’s version of  samsrv.dll  in his \dllcache  was correct and we replaced it from there.  But the question I have is, “Why didn’t the windows file protection dealy thingy pick this up?”

 

Anyone?

 

Spat