Frontpage
Forums
Tutorials
Members
Calendar
Subscription
Donate
Links
Contact 
Help
I've uploaded a V3 of MS10-071 that uses the newest mshtmled.dll for 2k. It's based on the QFE version, but for good measure I compared the QFE and GDR versions and they're identical save for internal build timestamps. Anyhow, now it has the latest and greatest version inside.
PE Tool for creating patches
WildBill's post-EOL patches for Windows 2000 are here.
Rate Topic:
#41
- Senior Member
-
- Group: Developers
- Posts: 671
- Joined: 09-August 05
- OS:none specified
-
Country:
Posted 24 November 2010 - 10:44 PM
Back to top
#42
- Adiuvat plus qui nihil obstat
-
- Group: Super Moderator
- Posts: 4,860
- Joined: 07-April 07
- OS:98SE
-
Country:
Posted 25 November 2010 - 12:54 PM
Wow! Thanks a lot, WildBill, you do rock! 
BTW, I hadn't compared the QFE and GDR binaries, in this case. But, in fact this may happen, since all MS says about QFE is that they *may* contain additional fixes (however, when they don't, they ought to have the same version number as the corresponding GDR file -- and that usually happens -- but not here)...
BTW, I hadn't compared the QFE and GDR binaries, in this case. But, in fact this may happen, since all MS says about QFE is that they *may* contain additional fixes (however, when they don't, they ought to have the same version number as the corresponding GDR file -- and that usually happens -- but not here)...
#43
- Senior Member
-
- Group: Members
- Posts: 579
- Joined: 31-May 08
- OS:Windows 2000 Professional
-
Country:
Posted 29 November 2010 - 11:50 PM
Hi WildBill.
Have you tried to use my security patch ? (It doesn't include ole32.dll)
MS10-083
And PE Tool 0.0.2 has a critical bug.
*Add Exported function.
*select the added cell.
*Add Exported function name.
*save.
*theb function export table is broken !
(I tried with kernel32.dll)
Have you tried to use my security patch ? (It doesn't include ole32.dll)
MS10-083
WildBill, on 01 November 2010 - 11:29 PM, said:
I'm taking a look at MS10-083, but I'd like to see if I can take a different tack. The patch involves changes to ole32.dll and wordpad.exe. When I try to run the XP WordPad it says that it can't find a routine in shlwapi that XP has but 2k presumably doesn't. It might be possible to add the necessary routines to the 2k version so the XP WordPad can be used as-is. I don't know if this is possible or worth it, but I'm looking into it.
And PE Tool 0.0.2 has a critical bug.
*Add Exported function.
*select the added cell.
*Add Exported function name.
*save.
*theb function export table is broken !
(I tried with kernel32.dll)
This post has been edited by blackwingcat: 30 November 2010 - 02:50 AM
#44
- Senior Member
-
- Group: Developers
- Posts: 671
- Joined: 09-August 05
- OS:none specified
-
Country:
Posted 13 December 2010 - 07:47 AM
Tomorrow a raft of patches comes out, so I figure I'd write an update of what I'm working on. I'm testing a patch for MS10-048 that also adds some 32-bit icon support to 2k (you'll still need Daedalus to for full support, in fact I'll have to release a new one because the update breaks compatibility somewhat, but Daedalus won't have to interfere as much now). I'm analyzing MS10-073 at the moment, which was one of the holes that Stuxnet exploited. After that I plan to look at what's new this month.
#45
- The Resurrector for old Windows OS
-
- Group: Members
- Posts: 2,464
- Joined: 07-October 05
- OS:98SE
-
Country:
Posted 13 December 2010 - 08:18 AM
Thanks I've been waiting.
This post has been edited by PROBLEMCHYLD: 03 January 2011 - 04:53 PM
#46
Posted 13 December 2010 - 03:25 PM
A minor suggestion: when installing the v2/v3 improved updates for KB2183461 and KB2360131 I noticed that in "Add/remove programmes: Currently installed programmes " the updates are simply listed as KB2183461/KB2360131 without -v2 or -v3. Could the version number be included in future updates where applicable (if that is possible)? This would eliminate confusion as to whether the latest version of an update is installed or not.
#47
- Senior Member
-
- Group: Developers
- Posts: 671
- Joined: 09-August 05
- OS:none specified
-
Country:
Posted 14 December 2010 - 08:14 PM
I've posted my patch for MS10-048 above (see the first page for the download link, as usual). in addition to the security patches to win32k.sys, this one has a bonus -- I've ported 32-bit icon support to win32k.sys and user32.dll. This doesn't update comctl32.dll though, so you'll still need Daedalus2. In fact, this breaks compatibility with Daedalus2 0.0.7, and I've posted Daedalus2 0.0.8 in the Customizing Windows forum section.
So why did I bother? Eventually I'd like to patch comctl32.dll, and then Daedalus will no longer be needed. In the meantime, Daedalus2 will be able to be a lot less intrusive since it won't have to worry about adding compatibility to user32.dll. Consider this update the first step of getting native 32-bit icon support. Even without Daedalus2 installed, 32-bit icons will work under certain circumstances -- basically, any time an image list isn't involved. One way you can test it is to right-click on a 32-bit icon and look at the Properties page -- while it might not render correctly on the desktop without Daedalus2 (since the desktop uses an image list), it will render correctly on the properties page (since an image list isn't involved).
Here are my notes, as usual. I was toying with the idea of embedding them in the hotfix instead (so you could get them by extracting it with the /x option), but I forgot to do it this time
So why did I bother? Eventually I'd like to patch comctl32.dll, and then Daedalus will no longer be needed. In the meantime, Daedalus2 will be able to be a lot less intrusive since it won't have to worry about adding compatibility to user32.dll. Consider this update the first step of getting native 32-bit icon support. Even without Daedalus2 installed, 32-bit icons will work under certain circumstances -- basically, any time an image list isn't involved. One way you can test it is to right-click on a 32-bit icon and look at the Properties page -- while it might not render correctly on the desktop without Daedalus2 (since the desktop uses an image list), it will render correctly on the properties page (since an image list isn't involved).
Here are my notes, as usual. I was toying with the idea of embedding them in the hotfix instead (so you could get them by extracting it with the /x option), but I forgot to do it this time
;==========================================================================
; MS10-048 patches ported to Windows 2000 SP4
;
; The actual security patches are pretty minimal -- however, I'm using the
; opportunity to add 32-bit icon support to Win2k. Once the patch is
; applied the OS will be able to properly load and render 32-bit icons,
; with ONE exception -- image lists, which are handled in comctl32.dll.
; A new (less intrusive) version of Daedalus can fill that capability gap
; for the time being. These patches will still improve compatibility with
; 32-bit icons and should fix problems that Daedalus doesn't cover.
;==========================================================================
;==========================================================================
; win32k.sys
;==========================================================================
; Combined .data and .kbdfall sections so we could add a .patch section
; -------------------------------------------------------------------------
; PostMessage
;
; Patch for MS10-048. Seems to block certain power-related messages.
; I'm not sure that Win2k sends all of these but XP does and it's safer to
; just block them all the way that the patch calls for.
; -------------------------------------------------------------------------
$A00091E6:
E915B21700 jmp $A0184400
909090909090909090 nop (9)
$A0184400:
81F919020000 cmp ecx, $219
750A jnz $A0184412
F6451180 test byte ptr [ebp+$11], $80 ; wParam +1
0F85E24DE8FF jnz $A00091F4
$A0184412:
83F94C cmp ecx, $4C
0F85DE4DE8FF jnz $A00091F9
837D1004 cmp [ebp+$10], 4 ; wParam
0F84704EE8FF jz $A0009295
837D100D cmp [ebp+$10], $D ; wParam
0F84664EE8FF jz $A0009295
837D100C cmp [ebp+$10], $C ; wParam
0F845C4EE8FF jz $A0009295
E9BB4DE8FF jmp $A00091F9
; -------------------------------------------------------------------------
; PostThreadMessage
;
; Similar to above -- blocking certain power-related messages. The idea
; seems to be that these messages should ONLY be sent internally by the
; kernel and never sent from user space (or accepted from user space). I
; only wish I knew what these messages did...
; -------------------------------------------------------------------------
$A0054545:
E9FAFE1200 jmp $A0184444
909090909090909090 nop (9)
$A0184444:
81FB19020000 cmp ebx, $219
750A jnz $A0184456
F6451180 test byte ptr [ebp+$11], $80 ; wParam +1
0F85FD00EDFF jnz $A0054553
$A0184456:
83FB4C cmp ebx, $4C
0F85F900EDFF jnz $A0054558
837D1004 cmp [ebp+$10], 4 ; wParam
0F84A401EDFF jz $A005460D
837D100D cmp [ebp+$10], $D ; wParam
0F849A01EDFF jz $A005460D
837D100C cmp [ebp+$10], $C ; wParam
0F849001EDFF jz $A005460D
E9D600EDFF jmp $A0054558
; -------------------------------------------------------------------------
; xxxDispatchMessage
;
; More message blocking.
; -------------------------------------------------------------------------
$A000D5AC:
E9D76E1700 jmp $A0184488
9090909090909090 nop (8)
$A0184488:
3D19020000 cmp eax, $219
750A jnz $A018449A
F6460980 test byte ptr [esi+9], $80 ; wParam +1
0F852091E8FF jnz $A000D5B9
$A018449A:
83F84C cmp eax, $4C
0F851C91E8FF jnz $A000D5BE
8B4E08 mov ecx, [esi+8] ; wParam
83F904 cmp ecx, 4
0F841691E8FF jz $A000D5C4
83F90D cmp ecx, $D
0F840D91E8FF jz $A000D5C4
83F90C cmp ecx, $C
0F840491E8FF jz $A000D5C4
E9F990E8FF jmp $A000D5BE
; -------------------------------------------------------------------------
; xxxSendMessageCallback
;
; And again...
; -------------------------------------------------------------------------
$A001FBF4:
E9D3481600 jmp $A01844CC
909090909090909090 nop (9)
$A01844CC:
81FB19020000 cmp ebx, $219
750A jnz $A01844DE
F6451180 test byte ptr [ebp+$11], $80 ; wParam +1
0F8524B7E9FF jnz $A001FC02
$A0184456:
83FB4C cmp ebx, $4C
0F8520B7E9FF jnz $A001FC07
837D1004 cmp [ebp+$10], 4 ; wParam
0F841CB7E9FF jz $A001FC0D
837D100D cmp [ebp+$10], $D ; wParam
0F8412B7E9FF jz $A001FC0D
837D100C cmp [ebp+$10], $C ; wParam
0F8408B7E9FF jz $A001FC0D
E9FDB6E9FF jmp $A001FC07
; -------------------------------------------------------------------------
; _IsPseudoPwnd@4
;
; Direct copy -- seems to be a helper routine that 2k inlines instead.
; This is used by the patch to xxxCreateWindowEx, but after analyzing it
; I'm not sure that the patch to xxxCreateWindowEx applies to 2k. Decided
; to leave xxxCreateWindowEx alone.
; -------------------------------------------------------------------------
$A0184510:
; -------------------------------------------------------------------------
; NtUserfnINDEVICECHANGE
;
; The change to $A0062647 is the only real change in functionality. The rest
; is just improved overflow checking.
; -------------------------------------------------------------------------
$A0062622: 83EC48 sub esp, $48 ; extra dword
$A0062647: 0F841D000000 jz $A006266A ; Set an error if null was passed in arg 4
$A0062693: E9B02A1200 jmp $A0185148
909090909090 nop (6)
$A0185148: 8D45A8 lea eax, [ebp-$58]
50 push eax
6A02 push 2
57 push edi
E88CFFFFFF call $A01850E0 ; ULongAdd
85C0 test eax, eax
0F8C0ED5EDFF jl $A006266A ; set error on overflow
6A01 push 1
6855736476 push $76647355
FF75A8 push [ebp-$58]
E933D5EDFF jmp $A006269E
$A006276F: E9F7291200 jmp $A018516B
909090909090909090 nop (9)
$A018516B: 83FF10 cmp edi, $10
0F820DD6EDFF jb $A0062781 ; error: too small
8D45A8 lea eax, [ebp-$58]
50 push eax
6A01 push 1
8D430C lea eax, [ebx+$C]
50 push eax
E8931BEBFF call $A0036D16 ; wcslen
59 pop ecx
50 push eax
E856FFFFFF call $A01850E0 ; ULongAdd
85C0 test eax, eax
0F8CEFD5EDFF jl $A0062781 ; set error on overflow
8D45A8 lea eax, [ebp-$58]
50 push eax
6A02 push 2
FF75A8 push [ebp-$58]
E88EFFFFFF call $A018512E ; ULongMult
85C0 test eax, eax
0F8CD9D5EDFF jl $A0062781 ; set error on overflow
8D45A8 lea eax, [ebp-$58]
50 push eax
6A0C push $C
FF75A8 push [ebp-$58]
E82AFFFFFF call $A01850E0 ; ULongAdd
85C0 test eax, eax
0F8CC3D5EDFF jl $A0062781 ; set error on overflow
8B45A8 mov eax, [ebp-$58]
E9B7D5EDFF jmp $A006277D
$A006275C: E9652A1200 jmp $A01851C6
9090909090909090909090 nop (11)
$A01851C6: 83FF20 cmp edi, $20
0F82B2D5EDFF jb $A0062781 ; error: too small
8D45A8 lea eax, [ebp-$58]
50 push eax
6A01 push 1
8D431C lea eax, [ebx+$1C]
50 push eax
E8381BEBFF call $A0036D16 ; wcslen
59 pop ecx
50 push eax
E8FBFEFFFF call $A01850E0 ; ULongAdd
85C0 test eax, eax
0F8C94D5EDFF jl $A0062781 ; set error on overflow
8D45A8 lea eax, [ebp-$58]
50 push eax
6A02 push 2
FF75A8 push [ebp-$58]
E833FFFFFF call $A018512E ; ULongMult
85C0 test eax, eax
0F8C7ED5EDFF jl $A0062781 ; set error on overflow
8D45A8 lea eax, [ebp-$58]
50 push eax
6A1C push $1C
FF75A8 push [ebp-$58]
E8CFFEFFFF call $A01850E0 ; ULongAdd
85C0 test eax, eax
0F8C68D5EDFF jl $A0062781 ; set error on overflow
8B45A8 mov eax, [ebp-$58]
E95CD5EDFF jmp $A006277D
$A0062739: jmp $A0185221
9090 nop (2)
$A0185221: 8D55A8 lea edx, [ebp-$58]
52 push edx
50 push eax ; Contains dword at [ebx+$24]
6A28 push $28
E8B3FEFFFF call $A01850E0 ; ULongAdd
85C0 test eax, eax
0F8C4CD5EDFF jl $A0062781 ; set error on overflow
397DA8 cmp [ebp-$58], edi
0F8743D5EDFF ja $A0062781 ; set error on overflow
8B4324 mov eax, [ebx+$24]
8D441828 lea eax, [eax+ebx+$28]
8D4B28 lea ecx, [ebx+$28]
3BC1 cmp eax, ecx
0F8231D5EDFF jb $A0062781 ; set error on overflow
8D4DA8 lea ecx, [ebp-$58]
51 push ecx
6A01 push 1
50 push eax
E8BA1AEBFF call $A0036D16 ; wcslen
59 pop ecx
50 push eax
E87DFEFFFF call $A01850E0 ; ULongAdd
85C0 test eax, eax
0F8C16D5EDFF jl $A0062781 ; set error on overflow
8D45A8 lea eax, [ebp-$58]
50 push eax
6A02 push 2
FF75A8 push [ebp-$58]
E8B5FEFFFF call $A018512E ; ULongMult
85C0 test eax, eax
0F8C00D5EDFF jl $A0062781 ; set error on overflow
8D45A8 lea eax, [ebp-$58]
50 push eax
6A28 push $28
FF75A8 push [ebp-$58]
E851FEFFFF call $A01850E0 ; ULongAdd
85C0 test eax, eax
0F8CEAD4EDFF jl $A0062781 ; set error on overflow
8D45A8 lea eax, [ebp-$58]
50 push eax
FF7324 push [ebx+$24]
FF75A8 push [ebp-$58]
E83AFEFFFF call $A01850E0 ; ULongAdd
85C0 test eax, eax
0F8CD3D4EDFF jl $A0062781 ; set error on overflow
8B45A8 mov eax, [ebp-$58]
E9C7D4EDFF jmp $A006277D
; -------------------------------------------------------------------------
; ULongAdd
;
; Direct copy
; -------------------------------------------------------------------------
$A01850E0:
; -------------------------------------------------------------------------
; ULongLongToULong
;
; Direct copy
; -------------------------------------------------------------------------
$A0185106:
; -------------------------------------------------------------------------
; ULongMult
; -------------------------------------------------------------------------
$A018512E:
; -------------------------------------------------------------------------
; xxxRealDrawMenuItem
;
; Range validation patch.
; -------------------------------------------------------------------------
$A00AAA31: E982A80D00 jmp $A01852B8
90909090 nop (4)
$A01852B8: 83F908 cmp ecx, 8
7213 jb $A01852D0
83F90B cmp ecx, $B
770E ja $A01852D0
8D414F lea eax, [ecx+$4F]
8B0D88C417A0 mov ecx, [$A017C488] ; _gpsi -- needs reloc
E96A57F2FF jmp $A00AAA3A
$A01852D0:
33C0 xor eax, eax
E9B75CF2FF jmp $A00AAF8E
; -------------------------------------------------------------------------
; Everything below this point has nothing to do with the security patch.
; This is a target of opportunity -- icon support is spread primarily
; between win32k.sys and user32.dll, so this is a great opportunity to add
; 32-bit icon support. The one exception is that image lists are in
; comctl32.dll. For now, will release a new version of Daedalus that will be
; backward-compatible but also support Win2k after this patch is applied.
; The new version of Daedalus will check the version of user32.dll to know
; how to start up. When this patch is applied, Daedalus will only have to
; deal with capability gaps in comctl32.dll (and will therefore be a lot
; less intrusive).
; -------------------------------------------------------------------------
; -------------------------------------------------------------------------
; CreateEmptyCursorObject
;
; In 2k/XP, icons are stored in win32k using this structure:
;
; ICON
; base dd ; Seems to have to do with a master icon linked list
; field_4 dd
; field_8 dd
; field_C dd ; Seems to have to do with process information
; next dd ; Seems to have to do with a master icon linked list
; lpModuleName dd ; Points to a unicode string (module name?)
; lpResName dd ; Points to a unicode string (resource name?)
; atom dw
; type dw
; flags dd
; xHotSpot dw ; For cursors -- win32k usees the same struct for icons and cursors
; yHotSpot dw ; For cursors -- win32k usees the same struct for icons and cursors
; hbmMask dd ; HBITMAP
; hbmColor dd ; HBITMAP
; field_30 dd ; Seems to only have to do with animated cursors
; field_34 dd ; Seems to only have to do with animated cursors
; field_38 dd ; Seems to only have to do with animated cursors
; field_3C dd ; Seems to only have to do with animated cursors
; field_40 dd ; Seems to only have to do with animated cursors
; hbmAlpha dd ; HBITMAP <-- XP ONLY! This field is NOT in 2k at all!
; bpp dd
; width dd
; height dd ; Icons typically have the height = color.height + mask.height, i.e. double normal height
; END
;
; In XP there is an extra dword between field_40 and bpp -- hbmAlpha.
; hbmAlpha is an HBITMAP that points to an image that is created ONLY when
; a 32-bit icon is loaded (otherwise it contains 0). The image is similar
; to hbmColor but the RGB values are premultiplied against the alpha values
; because AlphaBlend() expects them to be that way.
;
; To minimize the risk of breaking 2k code I'm appending hbmAlpha to the end
; of the structure instead. In any case, though, there are a lot of changes
; below for accommodating the larger structure. When examinimg XP code,
; it's important to remember that offsets at or above $44 are different
; (there are always offset differences when comparing XP and 2k code, though).
;
; There are two other structures that similarly have an extra field in XP:
;
; ICONDATA
; hbmMask dd ; HBITMAP
; hbmColor dd ; HBITMAP
; width dd
; height dd
; hbmAlpha dd ; HBITMAP <-- XP ONLY! This field is NOT in 2k at all!
; END
;
; CURSORICONDATA
; lpModuleName dd ; Points to a unicode string (module name?)
; lpResName dd ; Points to a unicode string (resource name?)
; type dw ; Note that the order is switched relative to ICON
; atom dw ; Note that the order is switched relative to ICON
; flags dd
; xHotSpot dw ; For cursors -- win32k usees the same struct for icons and cursors
; yHotSpot dw ; For cursors -- win32k usees the same struct for icons and cursors
; hbmMask dd ; HBITMAP
; hbmColor dd ; HBITMAP
; field_1C dd ; Seems to only have to do with animated cursors
; field_20 dd ; Seems to only have to do with animated cursors
; field_24 dd ; Seems to only have to do with animated cursors
; field_28 dd ; Seems to only have to do with animated cursors
; field_2C dd ; Seems to only have to do with animated cursors
; hbmAlpha dd ; HBITMAP <-- XP ONLY! This field is NOT in 2k at all!
; bpp dd
; width dd
; height dd
; field_40 dd
; field_44 dd
; field_48 dd
; field_4C dd
; field_50 dd
; field_54 dd
; END
;
; Some of these structures are present in win32k.sys and some are in user32.dll.
; As such, the patches below are a matched set -- you can't just upgrade one
; file without also upgrading the other.
;
; In this routine we're allocating an extra dword for the ICON structure.
; -------------------------------------------------------------------------
$A00393EA:
6A54 push $54 ; Allocate an extra dword
; -------------------------------------------------------------------------
; DestroyCursor
;
; Have to destroy hbmAlpha as well as the other images.
; -------------------------------------------------------------------------
$A0039114:
E9FBBE1400 jmp $A0185014
$A0185014:
8B4650 mov eax, [esi+50h] ; ICON.hbmAlpha
85C0 test eax, eax
740E jz $A0185029
50 push eax
E8ED67E8FF call $A000B80E ; GreDeleteObject
FF760C push dword ptr [esi+0Ch]
E8EC63F7FF call $A00FB415 ; GreDecQuotaCount
$A0185029:
8B4630 mov eax, [esi+30h]
85C0 test eax, eax
E9E640EBFF jmp $A0039119
; -------------------------------------------------------------------------
; SetCursorContents
;
; Copy hbmAlpha as well as the other images.
; -------------------------------------------------------------------------
$A009DE42:
E985710E00 jmp $A0184FCC
90 nop
$A0184FCC:
89702C mov [eax+2Ch], esi ; ICON.hbmColor
89512C mov [ecx+2Ch], edx ; ICON.hbmColor
8B7150 mov esi, [ecx+50h] ; ICON.hbmAlpha
8B5050 mov edx, [eax+50h] ; ICON.hbmAlpha
897050 mov [eax+50h], esi ; ICON.hbmAlpha
895150 mov [ecx+50h], edx ; ICON.hbmAlpha
jmp $A009DE48
; -------------------------------------------------------------------------
; NtUserSetCursorIconData
;
; Have to shift a bunch of stack variables around to accommodate the
; larger CURSORICONDATA struct. Have to be VERY careful here because
; there are some UNICODE_STRING structures on the stack as well -- if those
; are to be moved, each must be moved as a unit or we'll crash.
; -------------------------------------------------------------------------
$A007907A: 81EC88000000 sub esp, $88
$A0079095: 898574FFFFFF mov [ebp-$8C], eax
$A007909F: 218570FFFFFF and [ebp-$90], eax
$A00790BC: 899568FFFFFF mov [ebp-$98], edx
$A00790C9: 899568FFFFFF mov [ebp-$98], edx
$A00790D2: 898D6CFFFFFF mov [ebp-$94], ecx
$A00790E7: 89B560FFFFFF mov [ebp-$A0], esi
$A00790F4: 89B560FFFFFF mov [ebp-$A0], esi
$A00790FD: 89BD64FFFFFF mov [ebp-$9C], edi
$A0079118: 663B956AFFFFFF cmp dx, [ebp-$96]
$A0079169: 6A16 push $16
$A007916C: 8DBD78FFFFFF lea edi, [ebp-$88]
$A0079174: F6458408 test [ebp-$7C], 8
$A007917A: 8B75B4 mov esi, [ebp-$4C]
$A0079182: 8B4DB8 mov ecx, [ebp-$48]
$A0079196: 8B55C4 mov edx, [ebp-$3C]
$A00791A0: 3955C0 cmp [ebp-$40], edx
$A00791B6: 8B4DBC mov ecx, [ebp-$44]
$A00791D8: 8D8578FFFFFF lea eax, [ebp-$88]
$A00791E7: FFB574FFFFFF push [ebp-$8C]
$A00791F2: 898570FFFFFF mov [ebp-$90], eax
$A0079201: 83A570FFFFFF00 and [ebp-$90], 0
$A0079211: 8B8570FFFFFF mov eax, [ebp-$90]
; -------------------------------------------------------------------------
; SetCursorIconData
; -------------------------------------------------------------------------
$A0039362: 6A0C push $0C
$A0039367: E97BBC1400 jmp $A0184FE7
$A0184FE7:
FF732C push dword ptr [ebx+2Ch] ; ICON.hbmColor
E811F9FFFF call $A0184900 ; ProcessAlphaBitmap
894350 mov [ebx+50h], eax ; ICON.hbmAlpha
85C0 test eax, eax
7410 jz $A0185006
6A00 push 0
50 push eax
E87264E9FF call $A001B470 ; GreSetBitmapOwner
FF75D0 push [ebp-$30] ; var_30
E8FF63F7FF call $A00FB405 ; GreIncQuotaCount
$A0185006:
6A00 push 0
FF7328 push dword ptr [ebx+28h] ; ICON.hbmMask
E95C43EBFF jmp $A003936C
; -------------------------------------------------------------------------
; ProcessAlphaBitmap
;
; New routine -- this creates hbmAlpha if the icon is 32-bit.
; -------------------------------------------------------------------------
$A0184900:
; -------------------------------------------------------------------------
; GreCreateDIBitmapReal
;
; ProcessAlphaBitmap relies on an extra piece of information from
; GreCreateDIBitmapReal, and hence the XP version of GreCreateDIBitmapReal
; takes an extra argument. The change to GreCreateDIBitmapReal is pretty
; minimal, but it means that we have to accommodate the extra argument.
; Lucked out in that in XP, all other calls to GreCreateDIBitmapReal push
; 0 as the extra argument (it's a pointer to a DWORD), so we can get away
; with copying the 2k version, upgrading it, and changing the original
; to a wrapper that pushes 0 as the extra argument (ProcessAlphaBitmap will
; call the upgraded one instead). Decided to do it this way to minimize
; the risk of breaking any existing 2k code.
; -------------------------------------------------------------------------
$A01054C6:
8BFF mov edi, edi
55 push ebp
8BEC mov ebp, esp
6A00 push 0 ; The extra argument
FF7534 push [ebp+$34]
FF7530 push [ebp+$30]
FF752C push [ebp+$2C]
FF7528 push [ebp+$28]
FF7524 push [ebp+$24]
FF7520 push [ebp+$20]
FF751C push [ebp+$1C]
FF7518 push [ebp+$18]
FF7514 push [ebp+$14]
FF7510 push [ebp+$10]
FF750C push [ebp+$C]
FF7508 push [ebp+8]
call $A0184A84
C9 leave
C23000 ret $30
$A0184A84:
; -------------------------------------------------------------------------
; BltIcon
;
; Copied the XP version and put in a JMP at the start of the 2k version to it.
; The rest of the 2k version is now dead code (read: usable space for any other
; code we need in the future).
; -------------------------------------------------------------------------
$A001F092:
E9FE541600 jmp $A0184595
909090 nop (3)
$A0184595:
; -------------------------------------------------------------------------
; DrawIconEx
;
; Copied the XP version and put in a JMP at the start of the 2k version to it.
; The rest of the 2k version is now dead code (read: usable space for any other
; code we need in the future).
; -------------------------------------------------------------------------
$A001F6FA:
E9AD4F1600 jmp $A01846AC
90 nop
$A01846AC:
; -------------------------------------------------------------------------
; NtUserDrawIconEx
; -------------------------------------------------------------------------
$A00482BE: 6A14 push $14 ; ICONDATA is bigger
$A00482CF: E964CD1300 jmp $A0185038
$A00482D4: 90 nop
$A0185038:
8B462C mov eax, [esi+$2C] ; ICON.hbmColor
894704 mov [edi+4], eax ; ICONDATA.hbmColor
8B4650 mov eax, [esi+$50] ; ICON.hbmAlpha
894710 mov [edi+$10], eax ; ICONDATA.hbmAlpha
E98C32ECFF jmp $A00482D5
; -------------------------------------------------------------------------
; __InternalGetIconInfo@24
; -------------------------------------------------------------------------
$A0042C28: 83EC3C sub esp, $3C
$A0042C84: E9C3231400 jmp $A018504C
$A018504C:
837E4420 cmp dword ptr [esi+$44], $20 ; ICON.bpp
755F jnz $A01850B1
6A0B push $0B
59 pop ecx
33C0 xor eax, eax
8D7DAC lea edi, [ebp-$54]
F3AB rep stosd
53 push ebx
33DB xor ebx, ebx
C745AC28000000 mov [ebp-$54], $28 ; size of BITMAPINFOHEADER structure: 40 bytes
8B4648 mov eax, [esi+$48] ; ICON.width
8945B0 mov [ebp-$50], eax ; biWidth
8B464C mov eax, [esi+$4C] ; ICON.height (normally contains the height for 2 images in icon files)
D1E8 shr eax, 1 ; Make it for one image only
8945B4 mov [ebp-$4C], eax ; biHeight
66C745B80100 mov word ptr [ebp-$48], 1 ; biPlanes
66C745BA2000 mov word ptr [ebp-$46], $20 ; biBitCount
895DBC mov [ebp-$44], ebx ; biCompression
895DC0 mov [ebp-$40], ebx ; biSizeImage
895DCC mov [ebp-$34], ebx ; biClrUsed
895DD0 mov [ebp-$30], ebx ; biClrImportant
53 push ebx
53 push ebx
53 push ebx
53 push ebx
53 push ebx
53 push ebx
53 push ebx
6A2C push $2C
53 push ebx
8D45AC lea eax, [ebp-$54]
50 push eax
53 push ebx
53 push ebx
A1BCC317A0 mov eax, _gpDispInfo ; needs reloc
FF7010 push dword ptr [eax+$10]
E8DBF9FFFF call $A0184A84 ; GreCreateDIBitmapReal_new
5B pop ebx
33FF xor edi, edi
E9E9DBEBFF jmp $A0042C9A
$A01850B1:
8B464C mov eax, [esi+$4C] ; ICON.height
D1E8 shr eax, 1
E9CEDBEBFF jmp $A0042C89
; -------------------------------------------------------------------------
; DrawCaptionIcon
; -------------------------------------------------------------------------
$A0023C49: E972141600 jmp $A01850C0
$A0023C4E: 90 nop
$A01850C0:
8B7510 mov esi, [ebp+$10] ; Icon data
817E5000000000 cmp dword ptr [esi+$50], 0 ; ICON.hbmAlpha
0F8572ECE9FF jnz $A0023D42
8B4D18 mov ecx, [ebp+$18]
83E110 and ecx, $10
E974EBE9FF jmp $A0023C4F
;==========================================================================
; user32.dll
;
; The patches to this are only for adding 32-bit icon support. Because
; adding support involves growing structures that are used in user32.dll and
; win32k.sys, the files have to be patched and updated together.
;==========================================================================
; -------------------------------------------------------------------------
; DrawIconEx
;
; Replaced with the XP version. Placed the XP version in a different place
; and put in a JMP to it from the 2k routine. I could possibly do without
; this by changing all references to the routine -- the only reason that I
; didn't is because this routine has an export table entry.
;
; Erased the rest of the 2k version and used the space to hold other
; routines we need to get 32-bit icons working.
; -------------------------------------------------------------------------
$77E2583A:
E90DD30300 jmp $77E62B4C
90 nop
$77E62B4C:
; -------------------------------------------------------------------------
; CreateIconIndirect
;
; Shifting some stack variables around to accommodate the larger
; CURSORICONDATA struct.
; -------------------------------------------------------------------------
$77E39FA2: 81EC94000000 sub esp, 94h
$77E39FF7: 6A16 push $16 ; Requires win32k upgrade
$77E3A092: E9AD8D0200 jmp $77E62E44
$77E3A097: 90 nop
$77E62E44:
FF730C push dword ptr [ebx+$C]
89856CFFFFFF mov [ebp-$94], eax
E94672FDFF jmp $77E3A098
$77E3A0C3: E98A8D0200 jmp $77E62E52
$77E3A0C8: 90 nop
$77E62E52:
FFB56CFFFFFF push [ebp-$94]
FF7308 push [ebp+8]
E96972FDFF jmp $77E3A0C9
$77E3A01D: jmp $77E62EA4
$77E3A022: 909090 nop (3)
$77E62EA4:
8B4D90 mov ecx, [ebp-$70]
66837D8001 cmp word ptr [ebp-$80], 1
750E jnz $77E62EBC
66837D8220 cmp word ptr [ebp-$7E], $20
7507 jnz $77E62EBC
6800080000 push $800 ; Set this bit if 32-bit icon
EB01 jmp $77E62EBD
$77E62EB9:
56 push esi
$77E62EBA:
0FB75580 movzx edx, [ebp-$80]
E95F71FDFF jmp $77E3A025
; -------------------------------------------------------------------------
; CreateAniIcon
;
; All stack variables move by 4 to accommodate the larger CURSORICONDATA struct.
; -------------------------------------------------------------------------
$77E3B144: 83EC58 sub esp, $58
$77E3B15E: 6A16 push $16
$77E3B163: 8D7DA8 lea edi, [ebp-$58]
$77E3B198: 895DEC mov [ebp-$14], ebx
$77E3B19E: 894DF4 mov [ebp-$C], ecx
$77E3B1A1: 8975E4 mov [ebp-$1C], esi
$77E3B1AA: 894DF0 mov [ebp-$10], ecx
$77E3B1B1: 66894DB0 mov [ebp-$50], cx
$77E3B1BA: 897DE8 mov [ebp-$18], edi
$77E3B1BD: C745B408000000 mov [ebp-$4C], 8
$77E3B1C4: C745AC7830E677 mov [ebp-$54], $77E63078 ; offset _szUSER32
$77E3B1CB: 894DA8 mov [ebp-$58], ecx
$77E3B230: 8D45A8 lea eax, [ebp-$58]
; -------------------------------------------------------------------------
; CopyIcoCur
;
;
; Need to shift some stack variables around to accommodate a larger
; CURSORICONDATA struct. This is complicated by the fact that there are
; other structures on the stack as well so we have to be careful to move any
; other structures as a unit. In this case, we're moving an ICONSEARCHREC
; out of the way.
; -------------------------------------------------------------------------
$77E21350: 81ECC0040000 sub esp, $4C0
$77E2138C: 8D8548FDFFFF lea eax, [ebp-$2B8] ; WCHAR array (string)
$77E21397: 8D8540FBFFFF lea eax, [ebp-$4C0] ; WCHAR array (string)
$77E21441: E9A21A0400 jmp $77E62EE8
90 nop
$77E62EE8:
898554FFFFFF mov [ebp-$AC], eax ; iconSearchRec.type
8B45F4 mov eax, [ebp-$C]
898560FFFFFF mov [ebp-$A0], eax ; iconSearchRec.bpp
8D8550FFFFFF lea eax, [ebp-$B0] ; iconSearchRec
50 push eax
668B45D8 mov ax, [ebp-$28]
FF75D0 push [ebp-$30]
898D50FFFFFF mov [ebp-$B0], ecx ; iconSearchRec.hIcon
66F7D8 neg ax
1BC0 sbb eax, eax
89BD58FFFFFF mov [ebp-$A8], edi ; iconSearchRec.width
2345DC and eax, [ebp-$24]
89B55CFFFFFF mov [ebp-$A4], esi ; iconSearchRec.height
E942E5FBFF jmp $77E21466
$77E215B1: 6A16 push $16
; -------------------------------------------------------------------------
; CreateCursor
;
; All stack variables move by 4 to accommodate the larger CURSORICONDATA struct.
; -------------------------------------------------------------------------
$77E3F163: 83EC58 sub esp, $58
$77E3F183: 6A16 push $16
$77E3F188: 8D7DA8 lea edi, [ebp-$58]
$77E3F196: 8945DC mov [ebp-$24], eax
$77E3F199: 8D45A8 lea eax, [ebp-$58]
$77E3F1A1: 66895DB8 mov [ebp-$48], bx
$77E3F1A5: 668955BA mov [ebp-$46], dx
$77E3F1A9: 8975E0 mov [ebp-$20], esi
; -------------------------------------------------------------------------
; CreateIcon
;
; All stack variables move by 4 to accommodate the larger CURSORICONDATA struct.
; -------------------------------------------------------------------------
$77E3F1BF: 83EC58 sub esp, $58
$77E3F1C4: 6A16 push $16
$77E3F1C9: 8D7DA8 lea edi, [ebp-$58]
$77E3F1E1: 668945B8 mov [ebp-$48], ax
$77E3F1EA: 894DDC mov [ebp-$24], ecx
$77E3F1EF: 668945BA mov [ebp-$46], ax
$77E3F1F3: 8975E0 mov [ebp-$20], esi
$77E3F200: 8D45A8 lea eax, [ebp-$58]
; -------------------------------------------------------------------------
; ConvertDIBIcon
;
; Have to accommodate a larger CURSORICONDATA struct. Lucked out in that
; there is only one DWORD in the way which we can move, but it also means that
; anything above where we put it also has to shift up by a dword.
; -------------------------------------------------------------------------
$77E3F390: 81EC64020000 sub esp, $264 ; Extra DWORD on the stack
$77E3F39F: 8955A4 mov [ebp-$5C], edx ; Moving pbmi out of the way
$77E3F3B0: 6A16 push $16
$77E3F3DE: 8D4DA4 lea ecx, [ebp-$5C] ; Moving pbmi
$77E3F421: 8D8D9CFDFFFF lea ecx, [ebp-$264] ; Filename moves up
$77E3F433: 8D859CFDFFFF lea eax, [ebp-$264] ; Filename moves up
$77E3F43F: 8B4DA4 mov ecx, [ebp-$5C] ; Moving pbmi
$77E3F4EA: 8B45A4 mov eax, [ebp-$5C] ; Moving pbmi
$77E3F517: FF75A4 push [ebp-$5C] ; Moving pbmi
$77E3F534: FF75A4 push [ebp-$5C] ; Moving pbmi
$77E3F3D4: E9A73A0200 jmp $77E62E80
$77E3F3D9: 90 nop
$77E62E80:
6683780C01 cmp word ptr [eax+$C], 1 ; planes
750E jnz $77E62E95
6683780E20 cmp word ptr [eax+$E], $20 ; bitcount
7507 jnz $77E62E95
814D2000080000 or [ebp+20], $800 ; Set this bit if 32-bit icon
$77E62E95:
8D4D08 lea ecx, [ebp+8]
8B751C mov esi, [ebp+$1C]
E93AC5FDFF jmp $77E3F3DA
; -------------------------------------------------------------------------
; ConvertDIBBitmap
;
; Patched to match the XP version so 32-bit icons can work.
; -------------------------------------------------------------------------
$77E1F2B8: E9093C0400 jmp $77E62EC6
$77E1F2BD: 90909090 nop (4)
$77E62EC6:
F6C508 test ch, 8
740E jz $77E62ED9
8A5E0C mov bl, [esi+$C] ; planes
8A460E mov al, [esi+$E] ; bitcount
83E101 and ecx, 1
E9EEC3FBFF jmp $77E1F2C7
$77E62ED9:
83E101 and ecx, 1
8A984C0E0000 mov bl, [eax+$0E4C]
E9DAC3FBFF jmp $77E1F2C1
$77E1F2E5:
8930 mov [eax], esi
EB15 jmp $77E1F2FE
; -------------------------------------------------------------------------
; ReadIconGuts
;
; Replaced in-place with the XP version (which is physically smaller). The
; XP version supports 32-bit icons.
; -------------------------------------------------------------------------
$77E3AF35:
; -------------------------------------------------------------------------
; ChangeDibColors
;
; Patched to match the XP version so 32-bit icons can work.
; -------------------------------------------------------------------------
$77E21226: E9391C0400 jmp $77E62E64
90 nop
$77E62E64: 66C7460E0100 mov word ptr [esi+$E], 1
83661000 and dword ptr [esi+$10], 0
E935E3FBFF jmp $77E2122C
; -------------------------------------------------------------------------
; GetBestImage
;
; This is only called from one place. Added the XP version elsewhere and
; changed the call. The 2k version is now dead code.
; -------------------------------------------------------------------------
$77E21051:
; -------------------------------------------------------------------------
; MatchImage
;
; Originally patched it but eventually replaced it with the XP version.
; This routine is now dead code.
; -------------------------------------------------------------------------
$77E20FBB: E9681F0400 jmp $77E62F28
90 nop
$77E62F28:
0FB65002 movzx edx, byte ptr [eax+2] ; colorCount
85D2 test edx, edx
750B jnz $77E62F3B
51 push ecx
0FB74806 movzx ecx, word ptr [eax+6] ; bitCount
83CA01 or edx, 1
D3E2 shl edx, cl
59 pop ecx
$77E62F3B:
E986E0FBFF jmp $77E20FC6
; -------------------------------------------------------------------------
; GetResourceBpp
;
; Used by GetBestImage_new and MatchImage_new.
; -------------------------------------------------------------------------
$77E62F40:
; -------------------------------------------------------------------------
; GetBestImage_new
;
; XP replacement for GetBestImage that supports 32-bit images.
; -------------------------------------------------------------------------
$77E2583F:
; -------------------------------------------------------------------------
; MyAbs_new
;
; Used by MatchImage_new. The old one was used only by the original
; MatchImage and is now dead code.
; -------------------------------------------------------------------------
$77E258E4:
; -------------------------------------------------------------------------
; MatchImage_new
;
; Used by GetBestImage_new. The old one was used only by the original
; MatchImage and is now dead code.
; -------------------------------------------------------------------------
$77E25902:
; -------------------------------------------------------------------------
; RtlGetIdFromDirectory
;
; This is the only routine that calls GetBestImage. Changed the call to
; use the XP version instead. Both versions take the same arguments and
; return the same info so this was painless.
; -------------------------------------------------------------------------
$77E211D7: E863460000 call GetBestImage_new
#48
- Senior Member
-
- Group: Developers
- Posts: 671
- Joined: 09-August 05
- OS:none specified
-
Country:
Posted 18 December 2010 - 05:32 PM
I'm partway through building the patch for MS10-073, but parts of the MS patch DO NOT LOOK RIGHT AT ALL. I would swear that the patches to xxxSetWindowLong(), _SetWindowWord(), and xxxSetClassData() result in indeterminate behavior -- the variables they use as default values in their extra validation code are not initialized if they go through the entire class atom list and don't find a match. The code in NtUserRegisterClassExWOW() is similar -- it has the same extra validation code, but initializes the default value to 0. I'm going to assume that this should be the case in the other three routines, but this worries me. If someone has a contact at MS, I'd advise giving them a heads-up.
I checked MS10-098 since that also patches win32k.sys to see if they fixed it, but the code is the same. I think they missed it, and it looks like a real vulnerability to me.
I checked MS10-098 since that also patches win32k.sys to see if they fixed it, but the code is the same. I think they missed it, and it looks like a real vulnerability to me.
#49
- Adiuvat plus qui nihil obstat
-
- Group: Super Moderator
- Posts: 4,860
- Joined: 07-April 07
- OS:98SE
-
Country:
Posted 20 December 2010 - 08:53 AM
MS 10-073 may be blorked, in any case, even if I'm one ot the rare users who actually had an issue with it. Read this thread, please. In any case, since the issue was solved in the next release of win32k.sys, which is in MS 10-098, I suggest you skip MS 10-073 entirely and move on to MS 10-098. However, even that one may not provide adequate security, from your preliminary analysis, which is worrisome...
#50
- Senior Member
-
- Group: Developers
- Posts: 671
- Joined: 09-August 05
- OS:none specified
-
Country:
Posted 20 December 2010 - 06:23 PM
It figures 
I've completed the MS10-073 patch and also built a patch for MS10-084 (which was trivial). MS10-073 is working fine in my VM and on my PC, but I'm analyzing MS10-098 to see what's involved. So far I'm only seeing changes to how cursors are destroyed, which has nothing to do with the changes in MS10-073. I haven't finished my analysis, yet, though.
I've completed the MS10-073 patch and also built a patch for MS10-084 (which was trivial). MS10-073 is working fine in my VM and on my PC, but I'm analyzing MS10-098 to see what's involved. So far I'm only seeing changes to how cursors are destroyed, which has nothing to do with the changes in MS10-073. I haven't finished my analysis, yet, though.
This post has been edited by WildBill: 20 December 2010 - 06:23 PM
#51
- Senior Member
-
- Group: Developers
- Posts: 671
- Joined: 09-August 05
- OS:none specified
-
Country:
Posted 21 December 2010 - 01:38 PM
I've finished analyzing MS10-098, and I don't think it actually fixes any problems with MS10-073, unless by coincidence. There doesn't seem to be anything in common between the two, but since the problem with 073 involves uninitialized stack variables I can see how changing the code could happen to change what's on the stack at the time. I still think the XP patches are broken. As for the 2k patch, I'm initializing the default value to 0 so this isn't an issue.
I'm satisfied that I can release my 073 and 084 patches for 2k and work on the 098 patch afterward, so I'll post what I have shortly.
I'm satisfied that I can release my 073 and 084 patches for 2k and work on the 098 patch afterward, so I'll post what I have shortly.
#52
- Senior Member
-
- Group: Developers
- Posts: 671
- Joined: 09-August 05
- OS:none specified
-
Country:
Posted 21 December 2010 - 01:44 PM
Patches for MS10-073 and MS10-084 are up...notes below:
;==========================================================================
; MS10-073 patches ported to Windows 2000 SP4
;==========================================================================
;==========================================================================
; win32k.sys
;==========================================================================
; -------------------------------------------------------------------------
; xxxSwitchWndProc
; -------------------------------------------------------------------------
$A008489D: E9360A1000 jmp $A01852D8
90 nop
$A01852D8: 0F8553F6EFFF jnz $A0084931
39BE98000000 cmp [esi+$98], edi ; Offset is $A4 in XP
0F85F7F5EFFF jnz $A00848E1
E9B4F5EFFF jmp $A00848A3
; -------------------------------------------------------------------------
; xxxMenuWindowProc
; -------------------------------------------------------------------------
$A0030CA6: E945461500 jmp $A01852F0
90909090 nop (4)
$A01852F0: 817D0C81000000 cmp [ebp+$C], $81 ; message
0F85B2B9EAFF jnz $A0030CAF
33D2 xor edx, edx
399798000000 cmp [edi+$98], edx ; Offset is $A4 in XP
0F84B2B9EAFF jz $A0030CBD
33C0 xor eax, eax
E959BAEAFF jmp $A0030D6B
; -------------------------------------------------------------------------
; xxxKENLSProcs
; -------------------------------------------------------------------------
$A00951CD: jmp $A0185314
909090 nop (3)
$A0185314: 38907CFFFFFF cmp [eax-$84], dl
0F85B5FEF0FF jnz $A00951D5
80B87DFFFFFF03 cmp byte ptr [eax-$83], 3
0F83A8FEF0FF jnb $A00951D5
E9B5FEF0FF jmp $A00951E7
; -------------------------------------------------------------------------
; GenerateNlsVkKey
;
; Range validation patch.
;
; Put a complete replacement at $A001F098, which was freed up when BltIcon
; was moved. There are three calls to the original that will be pointed to
; the new one. Then will NOP out the original one at $A0095089.
; -------------------------------------------------------------------------
$A0095103: E8909FF8FF call $A001F098 ; GenerateNlsVkKey_new
$A0095161: E8329FF8FF call $A001F098 ; GenerateNlsVkKey_new
$A0095195: E8FE9EF8FF call $A001F098 ; GenerateNlsVkKey_new
; -------------------------------------------------------------------------
; GenerateNlsVkAltKey
;
; Range validation patch.
;
; Put a complete replacement at $A001F0D8, which was freed up when BltIcon
; was moved. There are two calls to the original that will be pointed to
; the new one. Then will NOP out the original one at $A00950AD.
; -------------------------------------------------------------------------
$A009515A: E8799FF8FF call $A001F0D8 ; GenerateNlsVkAltKey_new
$A0095187: E84C9FF8FF call $A001F0D8 ; GenerateNlsVkAltKey_new
; -------------------------------------------------------------------------
; xxxDesktopThread
;
; I don't think this applies to 2k. It seems to deal with the menu window
; for the desktop and the 2k code doesn't seem to create such a window.
; -------------------------------------------------------------------------
; -------------------------------------------------------------------------
; xxxCreateDesktop
;
; I don't think this applies to 2k. It seems to deal with the menu window
; for the desktop and the 2k code doesn't seem to create such a window.
; -------------------------------------------------------------------------
; -------------------------------------------------------------------------
; xxxSetWindowLong
; -------------------------------------------------------------------------
$A001D572: 742D jz $A001D5A1
$A001D584: 741B jz $A001D5A1
$A001D58A: 7515 jnz $A001D5A1
$A001D8EB: E8101E0000 call $A001F700 ; xxxSetWindowLongExtraVerify
$A001F700: ; Placed a copy of the 2k xxxSetWindowLong here but modified
; it to include the extra verification in the XP patch. This
; way we can avoid having to modify every call to it to pass
; an extra parameter.
; -------------------------------------------------------------------------
; SetupClassAtoms
; -------------------------------------------------------------------------
; Need to make room for some writable data. Found a pair of tables that EngDitherColor
; reads from but never writes to. Moving them to the .patch section to make room.
$A0185334: ; Put dither tables here
$A00C116C: 0FB688335318A0 movzx ecx, [eax+$A0185333] ; Index is 1-based, so back up the address by 1 (original code is the same way)
$A00C1173: 0FB6B0735318A0 movzx esi, [eax+$A0185373] ; Index is 1-based, so back up the address by 1 (original code is the same way)
$A0171D30: ; Put the initialized data we need for SetupClassAtoms here
$A007D4AE: E90B7F1000 jmp $A01853BE
9090 nop (2)
$A01853BE: 66890D38C517A0 mov [$A017C538], cx ; _gatomLastPinned
8B0D88C417A0 mov ecx, [$A017C488] ; _gpsi
668B91C0010000 mov dx, [ecx+$1C0]
668915301D17A0 mov [$A0171D30], dx
668B91C6010000 mov dx, [ecx+$1C6]
668915381D17A0 mov [$A0171D38], dx
668B91C4010000 mov dx, [ecx+$1C4]
668915401D17A0 mov [$A0171D40], dx
668B91A8010000 mov dx, [ecx+$1A8]
668915481D17A0 mov [$A0171D48], dx
668B91CA010000 mov dx, [ecx+$1CA]
668915501D17A0 mov [$A0171D50], dx
668B91B0010000 mov dx, [ecx+$1B0]
668915581D17A0 mov [$A0171D58], dx
E99180EFFF jmp $A007D4B5
; -------------------------------------------------------------------------
; SetWindowWord
; -------------------------------------------------------------------------
$A004A077: E9ACB31300 jmp $A0185428
9090 nop(2)
$A0185428: 8B5660 mov edx, [esi+$60] ; WND.pcls (at $64 in XP)
F6421302 test byte ptr [edx+$13], 2 ; CLS.flags.hi (at $17 in XP)
7437 jz $A0185468
33C9 xor ecx, ecx ; index starts at 0
668B5204 mov dx, [edx+4] ; atomClassName
$A0185437: 663B14CD301D17A0 cmp dx, [ecx*8+$A0171D30] ; _gSafeBufferClasses.atom
740A jz $A018544B ; Found a match?
41 inc ecx
83F906 cmp ecx, 6 ; 6 atoms to check
7CF0 jl $A0185437
33D2 xor edx, edx ; No match -- default size = 0 -- NOT INITIALIZED IN XP CODE!!!
EB07 jmp $A0185452
$A018544B: 8B14CD341D17A0 mov edx, [ecx*8+$A0171D34] ; _gSafeBufferClasses.limit
$A0185452: 39D0 cmp eax, edx ; Compare index with limit
7D12 jge $A0185468
83F904 cmp ecx, 4 ; Only get in here if we found an atom match
0F85034BECFF jnz $A0049F62 ; Error -- invalid value
83F81E cmp eax, $1E
0F87FA4AECFF ja $A0049F62 ; Error -- invalid value
$A0185468: 8D8C3098000000 lea ecx, [eax+esi+98h] ; hProcess
E90A4CECFF jmp $A004A07E ; Continue setting the value
; -------------------------------------------------------------------------
; NtUserRegisterClassExWOW
; -------------------------------------------------------------------------
$A007A2D0: jmp $A0185478
9090 nop (2)
$A0185478: 8B45D4 mov eax, [ebp-$2C] ; wcx.lpszClassName
F7C00000FFFF test eax, $FFFF0000 ; Is it an atom?
7406 jz $A0185489
50 push eax
E8808FE9FF call $A001E409 ; UserFindAtom
$A0185489: 33D2 xor edx, edx ; No match -- default size = 0
6685C0 test ax, ax
7428 jz $A01854B8
33C9 xor ecx, ecx ; index starts at 0
$A0185492: 663B04CD301D17A0 cmp ax, [ecx*8+$A0171D30] ; _gSafeBufferClasses.atom
740A jz $A01854A6 ; Found a match?
41 inc ecx
83F906 cmp ecx, 6 ; 6 atoms to check
7CF0 jl $A0185492
33D2 xor edx, edx ; No match -- default size = 0
EB12 jmp $A01854B8
$A01854A6: 0FB714CD321D17A0 movzx edx, word ptr [ecx*8+$A0171D32] ; _gSafeBufferClasses.flags
095518 or [ebp+$18], edx ; Flags
8B14CD341D17A0 mov edx, [ecx*8+$A0171D34] ; _gSafeBufferClasses.limit
$A01854B8: F6451904 test byte ptr [ebp+$19], 4 ; Flags.hi
740C jz $A01854CA
3955BC cmp [ebp-$44], edx ; wcx.cbWndExtra
7D07 jge $A01854CA
6A05 push 5
E9204EEFFF jmp $A007A2EA ; Error
$A01854CA: 57 push edi
FF7518 push [ebp+$18] ; Flags
FF7514 push [ebp+$14] ; fnID
E9014EEFFF jmp $A007A2D7
; -------------------------------------------------------------------------
; LW_RegisterWindows
; -------------------------------------------------------------------------
$A01854E0: ; New, larger register table put here (an extra flags field in each record)
$A01855E8: ; New version of LW_RegisterWindows goes here (original will be erased)
$A007E5F9: E82B701000 call $A0185629 ; LW_RegisterWindows_new
$A007E679: E8AB6F1000 call $A0185629 ; LW_RegisterWindows_new
; -------------------------------------------------------------------------
; xxxSetClassData
; -------------------------------------------------------------------------
$A00971F5: E9D6E40E00 jmp $A01856D0
$A01856D0: 83FAF8 cmp edx, $FFFFFFF8
0F848E1BF1FF jz $A0097267
F6461304 test byte ptr [esi+$13], 4 ; CLS.flags.hi (at $17 in XP)
7438 jz $A0185717
83FAEE cmp edx, $FFFFFFEE
7533 jnz $A0185717
33C0 xor eax, eax
668B4E04 mov cx, [esi+4] ; CLS.atom
$A01856EA: 663B0CC5301D17A0 cmp cx, [eax*8+$A0171D30] ; _gSafeBufferClasses.atom
740A jz $A01856FE
40 inc eax
83F806 cmp eax, 6
7CF0 jl $A01856EA
33C0 xor eax, eax
EB07 jmp $A0185705
$A01856FE: 8B04C5341D17A0 mov eax, [eax*8+$A0171D34] ; _gSafeBufferClasses.limit
$A0185705: 8B7D10 mov edi, [ebp+$10] ; dwNewLong
3BF8 cmp edi, eax
0F8DEA1AF1FF jge $A00971FA
6A05 push 5
E9141CF1FF jmp $A009732B
$A0185717: 8B7D10 mov edi, [ebp+$10] ; dwNewLong
E9DB1AF1FF jmp $A00971FA
; -------------------------------------------------------------------------
; xxxMNOpenHierarchy
;
; I don't think this applies to 2k. It seems to do with alternate menu window
; creation logic that 2k doesn't have. Looked for similar code in the 2k
; routine and it properly checks for null pointers.
; -------------------------------------------------------------------------
;==========================================================================
; MS10-084 patches ported to Windows 2000 SP4
;==========================================================================
;==========================================================================
; rpcrt4.dll
;==========================================================================
; -------------------------------------------------------------------------
; LRPC_SASSOCIATION__BindBack
; -------------------------------------------------------------------------
$77D5A301: 81ECF0000000 sub esp, $F0
$77D5A3BF: E9284E0300 jmp $77D8F1EC
909090 nop (3)
$77D8F1EC: 8D8514FFFFFF lea eax, [ebp-$EC]
50 push eax
83A510FFFFFF00 and [ebp-$F0], 0
8D8510FFFFFF lea eax, [ebp-$F0]
50 push eax
E9C1B1FCFF jmp $77D5A3C7
; -------------------------------------------------------------------------
$77D5A400: E9014E0300 jmp $77D8F206
$77D8F206: 81BD10FFFFFF00010000 cmp [ebp-$F0], $100
59 pop ecx
0F87EEB1FCFF ja $77D5A405
3BFE cmp edi, esi
0F8CE6B1FCFF jl $77D5A405
E9E6B1FCFF jmp $77D5A40A
#53
- Senior Member
-
- Group: Developers
- Posts: 671
- Joined: 09-August 05
- OS:none specified
-
Country:
Posted 24 December 2010 - 03:21 PM
A Win2k patch for MS10-096 is up 
This one was really easy -- I analyzed the files and you can use the XP one as-is, so I only had to rebuild the installer. I'm currently testing a patch for MS10-098, and I've partially analyzed MS10-099.
Merry Christmas, everyone
This one was really easy -- I analyzed the files and you can use the XP one as-is, so I only had to rebuild the installer. I'm currently testing a patch for MS10-098, and I've partially analyzed MS10-099.Merry Christmas, everyone
#54
Posted 26 December 2010 - 08:52 AM
So if I want to build, say, a Dutch W2000 patch for MS10-096 all I would have to do is download the Dutch XP patch, then extract the contents and repack? And are the packing tools readily available, and which do I need?
#55
- Senior Member
-
- Group: Members
- Posts: 579
- Joined: 31-May 08
- OS:Windows 2000 Professional
-
Country:
Posted 26 December 2010 - 10:56 PM
Hi, WildBill.
I already have released MS10-099 for Windows 2000.
(MS10-096 is Japanese only)
* I renewaled MS10-099-v2 on 24th Jan.
Sincerely.
I already have released MS10-099 for Windows 2000.
(MS10-096 is Japanese only)
* I renewaled MS10-099-v2 on 24th Jan.
Sincerely.
WildBill, on 24 December 2010 - 03:21 PM, said:
A Win2k patch for MS10-096 is up This one was really easy -- I analyzed the files and you can use the XP one as-is, so I only had to rebuild the installer. I'm currently testing a patch for MS10-098, and I've partially analyzed MS10-099.
Merry Christmas, everyone
This one was really easy -- I analyzed the files and you can use the XP one as-is, so I only had to rebuild the installer. I'm currently testing a patch for MS10-098, and I've partially analyzed MS10-099.Merry Christmas, everyone
This post has been edited by blackwingcat: 25 January 2011 - 12:09 AM
#56
- Senior Member
-
- Group: Developers
- Posts: 671
- Joined: 09-August 05
- OS:none specified
-
Country:
Posted 27 December 2010 - 06:53 PM
Dagwood, on 26 December 2010 - 08:52 AM, said:
So if I want to build, say, a Dutch W2000 patch for MS10-096 all I would have to do is download the Dutch XP patch, then extract the contents and repack? And are the packing tools readily available, and which do I need?
It should work, though repacking isn't a one-step process. Look at this thread for moe info on repacking. Basically it boils down to these steps:
1. Remove the .cat files because you won't be able to sign the update.
2. Copy one of the .inf file (e.g. update_SP3GDR.inf) to update.inf).
3. Delete the XP-specific .inf files: update_SP3GDR.inf, update_SP3QFE.inf, updatebr.inf, and branches.inf.
4. Patch update.inf to remove all references to the .cat files you deleted.
5. Change all references to "XP" in update.inf to "2000". I usually also put "Unofficial" before the title but that isn't necessary.
6. Delete the SP3GDR and SP3QFE folders and put your patch file in the folder above the update folder.
7. Remove all references to the SP3GDR or SP3QFE folders in update.inf, since your source files aren't in one of those subdirectories.
8. In update.inf, make the following changes:
[Version]
NtBuildToUpdate=2195
NtMajorVersionToUpdate=5
NtMinorVersionToUpdate=0
MaxNtBuildToUpdate=2195
MaxNtMajorVersionToUpdate=5
MaxNtMinorVersionToUpdate=0
MinNtServicePackVersion=1024
MaxNtServicePackVersion=1024
ThisServicePackVersion=1280
[Strings]
SERVICE_PACK_NUMBER = 5
9. Normally you'd have to patch update.ver with a new MD5 sum and file size, but since the file isn't changing in this case you don't have to do that.
10. Patch update.ver to remove the references to the SP3GDR and SP3QFE subdirectories and make sure that there is only one entry (the one that you're using --so if it came from the SP3GDR folder then keep that entry, otherwise keep the other one).
11. Replace update\update.exe with one from any of the releases I uploaded -- mine will let you install an unsigned update, the one from MS won't.
12. Compress your files:
cabarc -m LZX:21 -p -r N ..\outfile.cab *.*
13. Patch the created .cab file so that it knows to execute update.exe. You'll need a hex editor for this (e.g. xvi32). Look for the update\update.exe entry toward the beginning of the file. Before it there should be a 20h byte. Change that to 60h which will flag it as an auto-execute file.
14. Prepend the MSCF.sfx file before the .cab file to make an installer:
copy /b MSCF.sfx + outfile.cab outfile.exe
15. Rename outfile.exe to something appropriate to the patch and language:
ren outfile.exe Windows2000-KB######-x86-XXX.exe
It's a pain, but once you do it a few times it becomes second nature. You can unpack any of my patches with the /x option to see an example. One caveat, though: patching win32k.sys on 2000 requires a very different .inf file than patching it on XP does.
This post has been edited by WildBill: 27 December 2010 - 06:55 PM
#57
- Senior Member
-
- Group: Developers
- Posts: 671
- Joined: 09-August 05
- OS:none specified
-
Country:
Posted 27 December 2010 - 07:01 PM
I've tested my MS10-098 patch for a few days and I haven't run into any problems, so I've posted it (look in the usual place for it). I'm currently analyzing the IE patch in MS10-090, which is never an easy proposition....
This post has been edited by WildBill: 27 December 2010 - 07:01 PM
#58
- Member
-
- Group: Members
- Posts: 204
- Joined: 28-October 08
- OS:98SE
-
Country:
Posted 30 December 2010 - 12:50 PM
Just checking... doesn't KB2436673 (MS10-098) supersede KB981957 (MS10-073)?
Thank you so much for all the hard work, effort, and time obviously required to develop these updates!
Thank you so much for all the hard work, effort, and time obviously required to develop these updates!
#59
- Senior Member
-
- Group: Developers
- Posts: 671
- Joined: 09-August 05
- OS:none specified
-
Country:
Posted 30 December 2010 - 02:14 PM
Prozactive, on 30 December 2010 - 12:50 PM, said:
Just checking... doesn't KB2436673 (MS10-098) supersede KB981957 (MS10-073)?
Thank you so much for all the hard work, effort, and time obviously required to develop these updates!
Thank you so much for all the hard work, effort, and time obviously required to develop these updates!
Yes, though the update.inf isn't cumulative, so skipping MS10-073 could wind up leaving out some important registry settings.
Thanks for the kudos. This is consuming 100% of my free time, so I'd really appreciate it if some kind person could also make some patches.
In other news, I'm presently testing a patch for MS10-090.
#60
- Senior Member
-
- Group: Developers
- Posts: 671
- Joined: 09-August 05
- OS:none specified
-
Country:
Posted 31 December 2010 - 06:59 PM
Happy New Year, everyone!
I've found a bug in my MS10-083 patch and uploaded a V2 version. The download link above has been updated as well as the file name. I've also included my patches.asm file in the archive, which you can extract with the /x option.
My MS10-090 patch is ready, except for one problem -- I can't seem to get Automatic Updates to leave the registry changes alone. It keeps wanting to reinstall KB982381 -- MS10-090 changes a few registry values that were set in KB982381, and this seems to be making Automatic Updates unhappy. I'm not crazy about the idea of disabling Automatic Updates, but I also need a way to stop it from the endless nagging. Does anyone have any info on how to make it happy? I've already tried increasing the installed IE version registry setting from 6,0,2800,2006 to 6,0,2800,2007, but that didn't help.
If and when MS10-090 is posted, it should be truly cumulative -- I've merged in all the INF changes from KB982381, MS10-053, and MS10-071, and it contains all files from the last pre-EOL update as well as anything changed post-EOL. It also contains the registry changes in KB2467659 and has some extra XP API's in shlwapi.dll.
I've found a bug in my MS10-083 patch and uploaded a V2 version. The download link above has been updated as well as the file name. I've also included my patches.asm file in the archive, which you can extract with the /x option.
My MS10-090 patch is ready, except for one problem -- I can't seem to get Automatic Updates to leave the registry changes alone. It keeps wanting to reinstall KB982381 -- MS10-090 changes a few registry values that were set in KB982381, and this seems to be making Automatic Updates unhappy. I'm not crazy about the idea of disabling Automatic Updates, but I also need a way to stop it from the endless nagging. Does anyone have any info on how to make it happy? I've already tried increasing the installed IE version registry setting from 6,0,2800,2006 to 6,0,2800,2007, but that didn't help.
If and when MS10-090 is posted, it should be truly cumulative -- I've merged in all the INF changes from KB982381, MS10-053, and MS10-071, and it contains all files from the last pre-EOL update as well as anything changed post-EOL. It also contains the registry changes in KB2467659 and has some extra XP API's in shlwapi.dll.
This post has been edited by WildBill: 31 December 2010 - 07:02 PM
- ← Windows 2000 Overclock 5.2GHz
- Windows NT4 / 2000 / 2003
- Win2K Server reinstall, Windows Update issues →
