Windows Vista build 5000 (vbl core.040808-2000)

From BetaWiki
Jump to navigation Jump to search

6.0.5000.vbl_core.040808-2000
Build of Windows Vista
6.0.5000.vbl_core.040808-2000
OS family
Architecturex86
Compiled2004-08-08
Timebomb2005-08-03 (+360 days)
Works in
About
WindowsVista-6.0.5000-040808-About.png
SKUs
Professional

Windows Longhorn build 5000 (vbl core) (with a buildtag of 5000.vbl_core.040808-2000) is a build of Windows Vista. On 2020-01-23, this build was listed on a thread by UX.Unleaked blog founder Grabberslasher to be released to the BetaArchive FTP, and was released in the third set of 33 other Longhorn builds on 2020-01-26, alongside build 4048, other compiles of this build, and build 5001.[1]

This build by default has a severe bug where it appears to hang as soon as Windows switches to graphical mode, ending up with a light blue or black screen, making this build technically uninstallable via normal means.

What is failing?[edit | edit source]

Module name: win32k.sys

Reason (tl;dr): An empty variable which gets win32k to throwing "Access Violation" exception internally and failing without any notice.

It all started when Windows loads, shows the background and just sits right there; no cursor, no watermark, keyboard interrupts were also stuck/unregistered. First checks showed that kernel idle loop is running fine and processing interrupts. There were no exceptions or bugchecks logged into windows debugger (windbg), hence the next check was to set breakpoints on nt!ExRaiseStatus and nt!ExRaiseAccessViolation, which apparently was what win32k is calling and leaving the function it was in. According to the following stack it's either being called at win32k!EngFreeModule+0x5c9 (the preceding instruction), or the called function has called it:

f75d6d24 nt!ExRaiseAccessViolation
f75d6d48 win32k!EngFreeModule+0x5ce
f75d6d50 win32k!EngFreeModule+0x4b5
f75d6da0 nt!KeReleaseInStackQueuedSpinLockFromDpcLevel+0xb14
f75d6da4 ntdll+0x18c3c
f75d6da8 0x75a69626

Checking the code, it is calling the function located at win32k!EngMulDiv+0x29c0:

win32k!EngFreeModule+0x5b1:
bf8a0581 e84a5effff      call    win32k!EngMultiByteToUnicodeN+0x4310 (bf8963d0)
bf8a0586 893530079cbf    mov     dword ptr [win32k!HT_Get8BPPMaskPalette+0x30bb0 (bf9c0730)],esi
bf8a058c 8935cc219cbf    mov     dword ptr [win32k!HT_Get8BPPMaskPalette+0x3264c (bf9c21cc)],esi
bf8a0592 ff1500119abf    call    dword ptr [win32k!HT_Get8BPPMaskPalette+0x11580 (bf9a1100)]
bf8a0598 50              push    eax
bf8a0599 e8e280f8ff      call    win32k!EngMulDiv+0x29c0 (bf828680)
bf8a059e 8bd8            mov     ebx,eax   <-- The return address in the stack, second frame (win32k!EngFreeModule+0x5ce)
bf8a05a0 3bdf            cmp     ebx,edi

Inside that procedure, with a line-by-line tracing we found where it ended up calling ExRaiseAccessViolation in the following part:

win32k!EngMulDiv+0x2b62:
bf828822 3b0d9c219cbf    cmp     ecx,dword ptr [win32k!HT_Get8BPPMaskPalette+0x3261c (bf9c219c)] ds:0023:bf9c219c=00000000

win32k!EngMulDiv+0x2b68:
bf828828 0f8721fcffff    ja      win32k!EngMulDiv+0x278f (bf82844f)      [br=1]

win32k!EngMulDiv+0x278f:
bf82844f ff1580109abf    call    dword ptr [win32k!HT_Get8BPPMaskPalette+0x11500 (bf9a1080)] ds:0023:bf9a1080={nt!ExRaiseAccessViolation (809849aa)}

Now, comparing it to 5000.0.080409, we can notice the content of win32k!HT_Get8BPPMaskPalette+0x3261c (bf9c219c) is 7fff0000 instead of 00000000. It's now believed that we pinpointed the location of the failure, and with additional comparison against 040808's win32k.sys we found where that address is being filled up:

How to fix[edit | edit source]

  1. Replace win32k.sys with 040809's, as comparing it against 040808 turns up this only change and it will operate just as it was patched.
  2. Using WinDBG: once you break into the session, type
    ba e1 bf9c73b3 "r eax=7fff0000;e bf9c219c 00 00 ff 7f;gc"
    and it will adjust the content of that address and continue.

Gallery[edit | edit source]

References[edit | edit source]