PE Tool for creating patches

[WildBill]

Ouch. There definitely is a bug there. I'll work on fixing it this weekend.

[WildBill]

It turned out to be pretty easy to fix, so KB2508429 v13 is now up. Please let me know how it turns out!

[MacLover]

Still the same bluescreen (If it helps, Windows shows a "Restoring Network Connections" dialog (for VMware shared folders) right before the BSOD.)

[WildBill]

A-ha. There were actually two bugs in the code; EAX was incorrect, but EDX was also incorrect. I fixed the EAX one but not the other. I'll post another update as soon as I fix this one.

[WildBill]

Another easy fix, and it's posted; I'd be very surprised if you still get STOP errors with KB2508429 v14, at least in the same place...

[MacLover]

Still the same BSOD.

EDIT: On a whim, I decided to try regular safe mode and it works fine as well.

EDIT2: If I disable VMware shared folders, the system boots fine.

Edited January 25, 2014 by MacLover

[WildBill]

Are the details from the BSOD the same? I'm wondering if the bug is not in srv.sys.

[MacLover]

Same details. On the other hand, if I disable Shared Folders before booting up and logging in then re-enable it after I've logged in and try to access the network drive, Explorer crashes.

EDIT: here are some logs from Dr. Watson:

explorer.txt

winlogon.txt

Edited January 26, 2014 by MacLover

[WildBill]

It looks like the exception occurred somewhere in kernel32.DefineDosDeviceW (address 0x7C5B3DE3). I'll look into it some more during the week, but from what I can see so far it happened when it called CsrFreeCaptureBuffer, which led to RtlZeroHeap, which led to the exception. Maybe it was a bad pointer?

Edited January 27, 2014 by WildBill

[WildBill]

I did some more investigating, and this is something that I'm really going to need help with. The fault during the call to DefineDosDeviceW is really occurring, but it's also a red herring. What's really happening is heap corruption. The stack back trace doesn't have all of the symbols in ntdll that I've figured out by reverse engineering. The actual call hierarchy is like this:

ntdll!RtlpCoalesceFreeBlocks

ntdll!RtlFreeHeap

ntdll!CsrFreeCaptureBuffer

kernel32!DefineDosDeviceW

winlogon!Logoff

I'm attaching a .dbg file for ntdll that I've generated from my .map file that has lots more symbol info, but the real issue is there is a bug somewhere in the kernel32 rewrite that's corrupting the application heap. I've suspected this for some time but haven't been able to track it down. I *really* need help on this one.

ntdll_info.zip

Edited January 28, 2014 by WildBill

[Dubby]

Hmmm... I was able to boots just fine even with vmware shared folder enabled using kernel rewrite v.4 ... I'm also have full acces into it...

It's a vanilla system with usp 5.1 if I'm not mistaken..

Sent from my GT-I8190 using Tapatalk

[hansonsux]

I installed the patch for the .lnk vauln and my system still fails the suckme test.

System is sp4 and up to July 2010, nothing special.

[blackwingcat]

Hi.

 

I found a few bug .

And I think that it will return only eprocess ImageFilename. (without any path)

 L00537A7F:  		sub	edx,00000002h  		jz 	L00537A8D  		mov	al,[ecx]  		mov	[edi],ax  		inc	edi  		inc	edi<----------------- inc ecx ?<----------------- inc ecx ?  		jmp	L00537A7F L00537A8D:  		xor	eax,eax  		mov	[edi],ax  		pop	edx  		test	ebx,ebx  		jz 	L00537A99  		mov	[ebx],edx L00537A99:  		pop	ecx  		call	ObfDereferenceObject  		or	dword ptr [ebp-04h],FFFFFFFFh  		xor	eax,eax  		jmp	L00537AB2 L00537AA7:  		pop	ecx  		call	ObfDereferenceObject  		mov	eax,C0000004h L00537AB2:  		jmp	L004DF924

  		mov	eax,ds:[FFDFF020h]  		mov	ecx,[eax+000004BCh]  		xor	ecx,[eax+00000450h]  		xor	ecx,[ebp-44h]  		xor	ecx,[ebp-48h]  		xor	eax,eax  		<- Does "lock" need  on multi cpu kernel ?  		cmpxchg	[edi],ecx  		push	00000004h  		pop	edx  		jmp	L00537997

Windows2000-KB2393802-v20-x86-ENU.exe

ntoskrnl/ntkrnlpa/ntkrnlmp/ntkrpamp.exe

PsGetCurrentProcess
PsGetCurrentThread
PsGetCurrentProcessSessionId
NtQueryInformationProcess: added support for PROCESSINFOCLASS.ProcessImageFileName (0x1B), required by psapi additions below

 

 

P.S.

 

I fixed it such.

  		mov	[edi],eax  		add	edi,00000004h  		xor	eax,eax  		sub	edx,00000002h*  		push	edx*  		push	ecx*  		nop*  		push	00000000h*  		push	00000020h*  		push	edi*  		call	RtlMultiByteToUnicodeN*  		nop*  		nop*  		nop  		pop	edx  		test	ebx,ebx  		jz 	L00537A99  		mov	[ebx],edx L00537A99:

Edited August 27, 2014 by blackwingcat

[WildBill]

Thanks! I'll integrate it into the next patch. I'm currently testing a win32k/user32 update that adds support for the raw-input API for mouse and keyboard devices. The changes are pretty intrusive so I want to really thoroughly test it before releasing it. Since win32k.sys is contained in both KB2393802 and KB2479628, I'm leaning pretty heavily on combining the two patches and coming up with some other designation for it. I also found at least two potential crash bugs in win32k.sys that the update fixes.

Edited August 28, 2014 by WildBill

[WildBill]

I'm putting together a patched called KB2479629 that combines KB2479628 and KB2393802. It incorporates fixes to the bug that blackwingcat found, the win32k.sys raw-input API, and I think a few other things (I'll have to go back and see what else I added). KB2479629 isn't used by MS so it should be safe to use.