• Content count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About WildBill

Contact Methods

  • Website URL

Profile Information

  • OS
    none specified
  • Country

Recent Profile Visitors

593 profile views
  1. I've posted the newest version of my kernel32.dll rewrite, including source: http://www.mediafire.com/download/4ovx3tv1o85cc9m/Windows2000-kernel32-rewrite-v5.zip I can't say it's bug-free, so test with extreme caution, but I don't know of any bugs in it.
  2. Yes, it's fixed in KB2508429 v17, which has srv.sys 5.0.2195.7371. I just double-checked the file in IDA and it's fixed. On another note, I'm still plugging away with my kernel32.dll rewrite. I had thought it was ready, but I found a bug when I run Seven File Replacer -- the GUI doesn't render properly. I've been slowly verifying the routines that it calls, but Seven File Replacer is a hideously complex program for some reason, so it's been really hard to track down. EDIT: I had a bout of insomnia and decided to work on verifying some more routines in my rewrite. What a relief -- I finally tracked that bug down! memset() in the original kernel32 is **evil**.
  3. That's just bizarre. I scanned it on my end with Avast and it's clean, so I deleted it from MediaFire and I'm re-uploading it. I'll update the link once it completes. Hmm. It still thinks it's infected, so I rebuilt the .exe and I'm reposting it. For some reason the new one is different from the original. I have no idea why.
  4. I've got a couple new versions posted up on the master list: Windows2000-KB2508429-v17-x86-ENU.exe iphlpapi.dll if_indextoname Windows2000-KB2479629-v3-x86-ENU.exe (There was no v2, that was internal and only added IsProcessInJob) kernel32.dll IsProcessInJob GetNumaHighestNodeNumber GetNumaProcessorNode GetNumaNodeProcessorMask GetNumaProcessorMap GetNumaAvailableMemory GetNumaAvailableMemoryNode GetLogicalProcessorInformation ntdll.dll NtIsProcessInJob ZwIsProcessInJob ntoskrnl.exe/ntkrnlpa.exe/ntkrnlpa.exe/ntkrpamp.exe Added support to NtQuerySystemInformation for new kernel32 API calls
  5. Thanks! I'm almost fully recovered; I had a bout of anemia a couple weeks ago, and I've been cooking steaks every night to try to get my numbers back up. I'll be seeing the doc tomorrow, but I anticipate that I should be back to work on Monday. I've started looking at the requested routines, and it looks like I only need to add CreateActCtxW (as the patch versions I have here already contain the other routines). That one will be tricky because I've found that putting in stub versions causes some applications to act wonky (because they expect them to actually work). I once took a stab ad making fully functional versions of the activation context API (which MS calls the Fusion API), but it's far from trivial. Still, taking another look never hurts.
  6. Funny that you mention those, since I'm testing an update here that adds the first two (GetNumaHighestNodeNumber and GetLogicalProcessorInformation). Unfortunately health issues intervened and I'm currently recovering from gall bladder surgery. When I get back on my feet so to speak I'll try to remember to look at the rest of those.
  7. It's been a long while since I mentioned it, but I've quietly been working on a total rewrite of kernel32.dll in C. It took forever, but I've finally squashed enough of the bugs such that it's booting in a VM without exhibiting any errors. Once I synchronize it with the current kernel32.dll in my patches, I'll be releasing a new version of the rewrite with full source.
  8. For what it's worth, here is the MS page on bugcheck 0x7F: https://msdn.microsoft.com/en-us/library/windows/hardware/ff559244%28v=vs.85%29.aspx It sounds like a diff of the working and failing drivers might be in order, but blackwingcat is right -- the crash dump should help a lot.
  9. New update: KB2508429 v16 (apparently I never uploaded v15, oh well...). There are three new functions for advapi32 since v14: RegSaveKeyExA RegSaveKeyExW EnumerateTraceGuids
  10. I've been sitting on the update so I could test it thoroughly, but I just posted KB2479629. It combines KB2479628 and KB2393802, rendering them obsolete. It also adds some new stuff: ntoskrnl/ntkrnlpa/ntkrnlmp/ntkrpamp.exe The fix for the NTQueryInformationProcess bug that blackwingcat found. setupapi.dll Added SetupUninstallOEMInfW user32.dll Added true implementations for the following (for mouse and keyboard support only, not other USB devices) DefRawInputProc GetRawInputBuffer GetRawInputData GetRawInputDeviceInfoA GetRawInputDeviceInfoW GetRawInputDeviceList GetRegisteredRawInputDevices RegisterRawInputDevices win32k.sys Kernel-side implementation of the raw-input API that user32.dll invokes (where the real work is). wtsapi32.dll Added stubs for WTSRegisterSessionNotification and WTSUnRegisterSessionNotification
  11. 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.
  12. 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.
  13. 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
  14. 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?
  15. Are the details from the BSOD the same? I'm wondering if the bug is not in srv.sys.