• Announcements

    • xper

      MSFN Sponsorship and AdBlockers!   07/10/2016

      Dear members, MSFN is made available via subscriptions, donations and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, become a site sponsor and ads will be disabled automatically and by subscribing you get other sponsor benefits.
WildBill

PE Tool for creating patches

695 posts in this topic

@WildBill:

It's a known fact that all official MS cumulative security updates to IE6SP1 (except a couple of rather old ones) work OK in Win 9x/ME

So I suggested testing your unofficial KB2360131 in the proper thread named (somewhat misleading) Latest MS IE6 Security Update Breaks Windows 98?, and bingo! Your update was tested and found to work, too! So, in fact, for the IE6 updates, you now have a somewhat wider user base.

However, while testing the update, Dave-H found out the puzzling fact that the modded mshtmled.dll v. 6.0.2800.1107 file you included in the unofficial update seems to be, in fact, based in the original IE6SP1's v. 6.0.2800.1106, instead of being based in the much newer v. 6.0.2800.1501 or, preferably, the 6.0.2800.1502 (the qfe branch file), both from KB896156... Have you perhaps missed it?

Well, in any case, this post is not only to discuss this point, but also to invite you to join us in discussing those updates in the above mentioned thread.

Keep on the great work, you do rock! :thumbup

As an afterthought, I'd very much appreciate if you could port your mods also to the qfe branch of MSHTML.DLL (i.e.: v. 6.0.2800.1650, thus creating v. 6.0.2800.1652) since it appears to me, on closer inspection, that your modded file is derived from v. 6.0.2800.1649 (i. e.: the gdr branch) of MSHTML.DLL. Some users, like myself, do always prefer qfe branch files (except, of course, when the gdr works but the qfe doesn't, although it never happened to me). Browseui.dll and Shdocvw.dll from both branches are identical, so, for those two, no extra effort is required.

0

Share this post


Link to post
Share on other sites

Can these files be slipstreamed with hfslip?

I don't see why not. They work like any other MS hotfix.

As for mshtmled.dll, for some reason the newest version must not have been on my PC. I guess I'll have to reapply the patch to the newest one, though I might wait for the next IE patch first. I'm currently working on the RPC patch (the remote execution one) and it's a real bear. I might release my PE tool tonight even though it's not completely bug-free because the backlog is such that I really need help. Keeping up with these patches has taken me away from all other projects and I just can't let them languish for much longer.

0

Share this post


Link to post
Share on other sites

But what about MS10-074, WildBill? Can't you at least make an attempt to make an unofficial MS10-074 MFC patch for Win2000? Otherwise, I will find someone else who can since it's so easy to make one and it only involves just the updated MFC*.DLL files from the XP version of MS10-074.

You can do MS10-083 later on. Priority should be MS10-074, I think; and many applications depend on those MFC*.DLL files.

Edited by erpdude8
0

Share this post


Link to post
Share on other sites

I installed all these new updates today. Everything went OK; however, when I opened the "Add and remove programmes" window in the control panel after installing I got a message: "Program error. mshta.exe has generated errors and will be closed by Windows. An error log is being created." The "Add and remove programs" window was shut down.

I carried out a fresh install of W2000 and after installing all official updates through Windows Automatic Updates I started installing the new updates individually, then checking if the "Add and remove programs" window could be opened normally. Apart from the official updates, only an nVidia driver, the monitor driver and the motherboard drivers had been installed- no other software at all. KB2079403, KB2115168, KB2121546 and KB2124261 caused no errors, but when KB2183461 was installed the problem recurred.

Will carry out a total reinstall tomorrow, skipping KB2183461 to see if this update causes the problem. Hope this helps.

By the way, where can I find the error log? So far I haven't been able to find it!

0

Share this post


Link to post
Share on other sites

Installing KB2360131 results in the same "Program error" as above when starting "Add and remove programs" in Control Panel.

0

Share this post


Link to post
Share on other sites

I've uploaded the first version of my PE Tool and updated the top post. This tool is for people who understand PE files to a degree (read: it's easy to screw up an executable if you don't know what you're doing). Hopefully, though, it will make it easier for other people to create patches.

0

Share this post


Link to post
Share on other sites
but when KB2183461 was installed the problem recurred.

Will carry out a total reinstall tomorrow, skipping KB2183461 to see if this update causes the problem.

Installing KB2360131 results in the same "Program error" as above when starting "Add and remove programs" in Control Panel.

KB2360131? Wasn't it KB2183461? dubbio.gif

@WildBill: Thanks for the release. You rock! :thumbup

0

Share this post


Link to post
Share on other sites

Good catch. I had applied a patch in 2183461 (MS10-053) in the wrong place. I just released V2 versions of MS10-053 and MS10-071 and updated the links above. If you have 071 installed then you only need to apply the V2 patch for that one: I had to release both because the same file was patched in both (mshtml.dll). I also updated my notes for MS10-053 to reflect the correct code.

0

Share this post


Link to post
Share on other sites

Daft question, no doubt....... but would it be possible to use these (and future) updates as a basis for making updates for other languages, or is the code completely different?

0

Share this post


Link to post
Share on other sites

I can't say for certain, but I would expect the code to be very similar, though the locations might vary. I've found from looking at blackwingcat's patches that the code in question was identical between ENU and JPN, though the addresses did differ.

0

Share this post


Link to post
Share on other sites

Can you make a KB955704 exFAT patch?

0

Share this post


Link to post
Share on other sites

A new version of my PE Tool is now up: please see the top post for an updated download link. By the way, has anyone tried making any patches from it yet?

I've also posted a patch to MS10-083. This one really has me scratching my head -- it works just fine, but I'm not entirely sure that it even applies to Win2k. Still, there are other benefits (see the beginning of my notes for details).

;==========================================================================
; MS10-083 patches ported to Windows 2000 SP4
;
; The patches to WordPad looked nasty enough that I decided to try getting
; the XP WordPad to run as-is on 2k. This meant having to enhance
; shlwapi.dll a little (see below). The patch also involves ole32.dll, and
; the differences between 2k and XP are so huge that I opted to patch the
; 2k version of ole32.dll instead.
;
; The XP WordPad looks for a newer version of the richedit control, which
; is in msftedit.dll, so that's included.
;
; Making all these changes gets the XP WordPad running on 2k as-is, and
; according to Dependency Walker there shouldn't be any surprises.
;
; All this said, now that I've crawled through all this and made the
; changes, I'm not sure that this security update even applies to 2k.
; Everything seems to revolve around registry settings that tell an app
; if a DLL is safe to load, and the update.inf part of the patch installs
; a handful of new registry settings. It would be nice if someone who
; understands COM on XP can explain what this is supposed to fix. Still,
; the enhancement to shlwapi and the fact that we're now synchronized with
; XP's WordPad should provide some value nonetheless.
;
; The patch says to include xpsp4res.dll, though I have no idea what it does.
; I think it supplies a popup dialog. I'd be lying if I said I understood
; what's going on here from a big-picture perspective.
;==========================================================================

;==========================================================================
; shlwapi.dll
;
; The XP WordPad requires SHRegGetValueW from shlwapi.dll, which 2k doesn't
; have. Managed to add it with the subroutines that it requires and added
; it to the export list. Since I had to add all this, decided to also
; add (and export) SHRegGetValueA for good measure.
;==========================================================================

; -------------------------------------------------------------------------
; RestrictBootMode
;
; Copied mostly as-is, though rearranged to eliminate fragmentation
; -------------------------------------------------------------------------

$70ACEC80:

; -------------------------------------------------------------------------
; RestrictRegType
;
; Copied mostly as-is, though condensed to use all "short" jumps
; -------------------------------------------------------------------------

$70ACECD4:

; -------------------------------------------------------------------------
; FixRegDataW
; -------------------------------------------------------------------------

$70ACE47C:

; -------------------------------------------------------------------------
; NullTerminateRegSzStringW
; -------------------------------------------------------------------------

$70ACED78:

; -------------------------------------------------------------------------
; NullTerminateRegExpandSzStringW
; -------------------------------------------------------------------------

$70ACE000:

; -------------------------------------------------------------------------
; NullTerminateRegMultiSzStringW
; -------------------------------------------------------------------------

$70ACE330:

; -------------------------------------------------------------------------
; SHRegQueryValueW
; -------------------------------------------------------------------------

$70ACE7BC:

; -------------------------------------------------------------------------
; SHRegQueryValueA
; -------------------------------------------------------------------------

$70ACE900:

; -------------------------------------------------------------------------
; ___report_gsfailure
; -------------------------------------------------------------------------

$70ACE674:

$70ACE5F4: ___security_cookie
$70ACE5F8: ___security_cookie_complement

$70A7D3E0: aKernel32_dll_0

$70ACE604: aSetUnhandledExceptionFilter
$70ACE620: aUnhandledExceptionFilter
$70ACE639: aTerminateProcess

; -------------------------------------------------------------------------
; __security_check_cookie
; -------------------------------------------------------------------------

$70ACE7A0:

; -------------------------------------------------------------------------
; FixRegDataA
; -------------------------------------------------------------------------

$70ACE53C:

; -------------------------------------------------------------------------
; NullTerminateRegSzStringA
; -------------------------------------------------------------------------

$70ACEDE8:

; -------------------------------------------------------------------------
; NullTerminateRegExpandSzStringA
; -------------------------------------------------------------------------

$70ACE1C0:

; -------------------------------------------------------------------------
; NullTerminateRegMultiSzStringA
; -------------------------------------------------------------------------

$70ACE3E8:

; -------------------------------------------------------------------------
; SHRegGetValueW
;
; Exported entry 743 in XP
; -------------------------------------------------------------------------

$70ACE9FC:

$70ACEB78: aShreggetvaluew

; -------------------------------------------------------------------------
; SHRegGetValueA
;
; Exported entry 742 in XP
; -------------------------------------------------------------------------

$70ACEBB8:

$70ACEB98: aShreggetvaluea

; -------------------------------------------------------------------------
; ZeroDataOnFailure
; -------------------------------------------------------------------------

$70ACE9C4:

; -------------------------------------------------------------------------
; RestrictArguments
; -------------------------------------------------------------------------

$70ACE980:

; -------------------------------------------------------------------------
; GetProcPtrA
;
; My own routine for getting a proc address
; -------------------------------------------------------------------------

$70ACE650:

8BFF mov edi, edi
55 push ebp
8BEC mov ebp, esp
FF7508 push dword ptr [ebp+8] ; Module name
FF156412A770 call [$70A71264] ; GetModuleHandleA
85C0 test eax, eax
740A jz $yy
FF750C push dword ptr [ebp+$C] ; Proc name
50 push eax ; Module handle
FF151814A770 call [$70A71418] ; GetProcAddress

$yy:

89EC mov esp, ebp
5D pop ebp
C3 ret



;==========================================================================
; ole32.dll
;==========================================================================

$7CF02000: ___security_cookie
$7CF02004: ___security_cookie_complement
$7CF0202C: aSetUnhandledExceptionFilter
$7CF0204C: wKernel32_dll

; -------------------------------------------------------------------------
; __security_check_cookie
; -------------------------------------------------------------------------

$7CF02010:

; -------------------------------------------------------------------------
; GetProcPtrW
;
; My own routine for getting a proc address
; -------------------------------------------------------------------------

$7CF0206C:

8BFF mov edi, edi
55 push ebp
8BEC mov ebp, esp
FF7508 push dword ptr [ebp+8] ; Module name
FF159C12E27C call [$7CE2129C] ; GetModuleHandleW -- ole32 doesn't import GetModuleHandleA
85C0 test eax, eax
740A jz $7CF02088
FF750C push dword ptr [ebp+$C] ; Proc name
50 push eax ; Module handle
FF153012E27C call [$7CE21230] ; GetProcAddress

$yy:

89EC mov esp, ebp
5D pop ebp
C3 ret

; -------------------------------------------------------------------------
; ___report_gsfailure
;
; Adapted it slightly because we need to use GetProcPtrW to get the address
; to SetUnhandledExceptionFilter
; -------------------------------------------------------------------------

$7CF02090:

; -------------------------------------------------------------------------
; CComRegCatalog::GetProcessInfo
; -------------------------------------------------------------------------

$7CE94E15:

6A72 push 72h ; Allocating room for one more member variable

; -------------------------------------------------------------------------
; CComProcessInfo::CComProcessInfo
; -------------------------------------------------------------------------

$7CE97928:

E98BA80600 jmp $7CF021B8
90 nop

$7CF0219C:

unicode <AppIDFlags>, 0


$7CF021B8:

C7450C04000000 mov [ebp+$C], 4 ; cbData
33C0 xor eax, eax
894368 mov [ebx+$68], eax ; Initialize our new member variable to 0
8D450C lea eax, [ebp+$C] ; cbData
50 push eax
8D85F0FDFFFF lea eax, [ebp-$210] ; Src
50 push eax
8938 mov [eax], edi
8D45F8 lea eax, [ebp-8] ; Type
50 push eax
57 push edi ; 0
689C21F07C push $7CF0219C ; Offset of unicode AppIDFlags string -- needs reloc
FF152810E27C call [$7CE21028] ; RegQueryValueExW -- needs reloc
85C0 test eax, eax
7515 jnz $vv
837DF804 cmp [ebp-8], 4 ; Type
750F jnz $vv
837D0C04 cmp [ebp+$C], 4 ; cbData
7509 jnz $vv
8B85F0FDFFFF mov eax, [ebp-$210] ; Src
894368 mov [ebx+68h], eax

$vv:

8D4350 lea eax, [ebx+50h]
50 push eax
6A01 push 1
E92957F9FF jmp $7CE9792E

; -------------------------------------------------------------------------
; wCreateObject
;
; Copied new one as-is; only had to fix jumps and addresses and add relocs
; (verified that it's compatible except for the extra parameter that it takes)
; -------------------------------------------------------------------------

$7CF02208:

; -------------------------------------------------------------------------

; Change the original to act as a wrapper that pushes an extra 0 on the stack
; and calls the new one above

$7CEA59FE:

8BFF mov edi, edi
55 push ebp
8BEC mov ebp. esp
6A00 push 0 ; Extra argument
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]
E8E0C70500 call $7CF02208 ; See above
C9 leave
C22800 ret $28


; -------------------------------------------------------------------------
; OleLoadWithoutBinding
;
; Making a copy of the original (from Win2k) and modifying it to accept an
; extra parameter which it will pass to our new wCreateObject. Like above,
; we'll then convert the original to a wrapper that will pass 0 as the
; extra argument.
; -------------------------------------------------------------------------

$7CF024E4: ; Modified copy goes here

$7CEA5540: ; The original was here

8BFF mov edi, edi
55 push ebp
8BEC mov ebp. esp
6A00 push 0 ; Extra argument
FF7518 push [ebp+$18]
FF7514 push [ebp+$14]
FF7510 push [ebp+$10]
FF750C push [ebp+$C]
FF7508 push [ebp+$8]
E889CF0500 call $7CF024E4 ; See above
C9 leave
C21400 ret $14

$7CF02570: aDllVerifyCLSIDIsSafeToLoad

; -------------------------------------------------------------------------
; OleLoad
;
; A little extra code that gets a proc pointer which we push as an extra argument
; to a call to our new OleLoadWithoutBinding
; -------------------------------------------------------------------------

$7CE58F36:

jmp $7CF02590 ; Jump to our new version

$7CF02590: ; New one is here, copied as-is with addresses fixed up

; -------------------------------------------------------------------------
; CComProcessInfo::GetSaferTrustLevel
; -------------------------------------------------------------------------

$7CF025E4:

B805400080 mov eax, $80004005 ; Signals that it's untrusted
C20800 ret 8

; -------------------------------------------------------------------------
; CComProcessInfo::GetAppIDFlags
; -------------------------------------------------------------------------

$7CF025F0:

8BFF mov edi, edi
55 push ebp
8BEC mov ebp. esp
8B4508 mov eax, [ebp+8] ; arg_0
8B4068 mov eax, [eax+$68] ; We put the AppID flags here
8B4D0C mov ecx, [ebp+$C] ; arg_4
8901 mov [ecx], eax
33C0 xor eax, eax
5D pop ebp
C20800 ret 8

$7CF0260C: _IID_IComProcessInfo2

$7CF0261C: _IID_IComProcessInfo3

; Moving a Unicode string to make roon for more entries in the IComProcessInfo
; VMT array. This will let us support IComProcessInfo3, which can return AppID
; flags.

$7CF02634: aRegistryMach_0

$7CE97E69:

mov [ebp-4], $7CF02634 ; New string location

$7CE25DA0:

0DAFE77C dd $7CE7AF0D ; Offset CServerSecurity::Cancel
E425F07C dd $7CF025E4 ; Offset CComProcessInfo::GetSaferTrustLevel
F025F07C dd $7CF025F0 ; Offset CComProcessInfo::GetAppIDFlags

; -------------------------------------------------------------------------
; CComProcessInfo::QueryInterface
;
; The new code to retrieve the AppID flags won't ever get invoked unless
; we signal that it's available. This means responding that we implement
; IID_IComProcessInfo3 (and IID_IComProcessInfo2 by inclusion). The easiest
; way to do this is to just copy the entire QueryInterface routine and
; redirect the old one to this one and fix up addresses, etc.
; -------------------------------------------------------------------------

$7CF02660: ; New one goes here

$7CE97A02: ; Original was here

E959AC0600 jmp $7CF02660
90 nop

; -------------------------------------------------------------------------
; OleLoadFromStream
;
; Extra code that does a similar check to the patches above
; -------------------------------------------------------------------------

$7CE60C25:

sub esp, $24 ; Add room for a GUID

$7CE60C5B:

E9981A0A00 jmp $7CF026F8
90 nop

$7CF026F8:

8BF0 mov esi, eax
85F6 test esi, esi
7465 jz $nn6
50 push eax
FF159C12E27C call [$7CE2129C] ; GetModuleHandleW
85C0 test eax, eax
745A jz $nn6
687025F07C push $7CF02570 ; offset aDllVerifyCLSIDIsSafeToLoad
50 push eax
FF153012E27C call [$7CE21230] ; GetProcAddress
85C0 test eax, eax
744A jz $nn6
33C9 xor ecx, ecx ; Zero out our new GUID
894DDC mov [ebp-$24], ecx
894DE0 mov [ebp-$20], ecx
894DE4 mov [ebp-$1C], ecx
894DE8 mov [ebp-$18], ecx
8D4DDC lea ecx, [ebp-$24] ; Our new GUID
51 push ecx
8D4DEC lea ecx, [ebp-$14] ; pclsid
51 push ecx
FFD0 call eax
8BF0 mov esi, eax
81FE05000780 cmp esi, $80070005
7528 jnz $nn6
6A04 push 4
59 pop ecx
56 push esi
57 push edi
8D7DDC lea edi, [ebp-$24] ; Our new GUID
BE5844E37C mov esi, $7CE34458 ; offset GUID_NULL
33C0 xor eax, eax
F3A7 repe cmpsd
740E jz $rr3
8D75DC lea esi, [ebp-$24] ; Our new GUID
8D7DEC lea edi, [ebp-$14] ; pclsid
A5 movsd
A5 movsd
A5 movsd
A5 movsd
5F pop edi
5E pop esi
EB07 jmp $nn6

$rr3:

5F pop edi
5E pop esi
E963E5F5FF jmp $7CE60CC6


$nn6:

E9F9E4F5FF jmp $7CE60C61

0

Share this post


Link to post
Share on other sites

@WildBill:

It's a known fact that all official MS cumulative security updates to IE6SP1 (except a couple of rather old ones) work OK in Win 9x/ME

So I suggested testing your unofficial KB2360131 in the proper thread named (somewhat misleading) Latest MS IE6 Security Update Breaks Windows 98?, and bingo! Your update was tested and found to work, too! So, in fact, for the IE6 updates, you now have a somewhat wider user base.

However, while testing the update, Dave-H found out the puzzling fact that the modded mshtmled.dll v. 6.0.2800.1107 file you included in the unofficial update seems to be, in fact, based in the original IE6SP1's v. 6.0.2800.1106, instead of being based in the much newer v. 6.0.2800.1501 or, preferably, the 6.0.2800.1502 (the qfe branch file), both from KB896156... Have you perhaps missed it?

Well, in any case, this post is not only to discuss this point, but also to invite you to join us in discussing those updates in the above mentioned thread.

Keep on the great work, you do rock! :thumbup

As an afterthought, I'd very much appreciate if you could port your mods also to the qfe branch of MSHTML.DLL (i.e.: v. 6.0.2800.1650, thus creating v. 6.0.2800.1652) since it appears to me, on closer inspection, that your modded file is derived from v. 6.0.2800.1649 (i. e.: the gdr branch) of MSHTML.DLL. Some users, like myself, do always prefer qfe branch files (except, of course, when the gdr works but the qfe doesn't, although it never happened to me). Browseui.dll and Shdocvw.dll from both branches are identical, so, for those two, no extra effort is required.

I followed the link but there doesn't seem to be a way to download a version for Win2k :blink:

0

Share this post


Link to post
Share on other sites

Of course there is one! Just click here, and follow the instructions (of the offered alternatives, select the middle one, which is for IE6 sp1), and they'll send it to you.

0

Share this post


Link to post
Share on other sites

Ok, I'll look at it when I get a chance. In the meantime, I've posted an update for MS10-074. It's the MFC library update and uses the new files as-is. While it was easy to put together, i wanted to take some time to make sure that they were compatible with 2k instead of just blindly posting it. I've made some comparisons with the 2k version and also compared the original XPSP3 version with the ones in 2k and XPSP2. The original XPSP3 one turned out to be identical to the one in XPSP2, which was a good sign of compatibility. I didn't see any glaring issues with my brief assembler comparison with the 2k one, and Dependency Walker didn't spot any problems. The update also seems to run fine in my VM, so I guess it's okay. I now have it installed in my main OS installation and I'm seeing no problems.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

Wow! Thanks a lot, WildBill, you do rock! :thumbup

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)... :wacko:

0

Share this post


Link to post
Share on other sites

Hi WildBill.

Have you tried to use my security patch ? (It doesn't include ole32.dll)

MS10-083

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)

Edited by blackwingcat
0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

Thanks I've been waiting.

Edited by PROBLEMCHYLD
0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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 :lol:

;==========================================================================
; 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

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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...

0

Share this post


Link to post
Share on other sites

It figures :rolleyes:

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.

Edited by WildBill
0

Share this post


Link to post
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.