Jump to content

PE Tool for creating patches


WildBill

Recommended Posts


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 by MacLover
Link to comment
Share on other sites

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 by WildBill
Link to comment
Share on other sites

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 by WildBill
Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 6 months later...

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 by blackwingcat
Link to comment
Share on other sites

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 by WildBill
Link to comment
Share on other sites

  • 3 weeks later...

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.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...