WildBill

GAH. I forgot to put in relocs for the MS10-097 patch. I've uploaded a V2 version and updated the link above, and the file version will bump up one more so you can tell it apart. If you installed V1 of MS10-097, just install the V2 version over it. Sorry for the mix-up

I've finally added patches for MS10-091 and MS10-097 to the patch list. The number of changes in MS10-091 is enormous, so for anyone who wants to port it to other languages I strongly recommend translating the ENU version rather than porting all the changes to a different one. There's a reason why it took me a month to finish it. On the flip side, MS10-097 was really easy and it only took a few hours to make. Next up will be either MS10-099 or MS11-002...I haven't yet decided which. I've taken a look at both, and while MS11-002 is critical I'm not sure yet how to attack it. Each patch file has my notes bundled inside: you can get them by running them with the /x option to extract the contents.

I bundled my notes in my fix for XP. It amounts to a hugely complex and difficult change: ;========================================================================== ; Uninitialized variables fix for XPSP3 MS10-098 patch ;========================================================================== ;========================================================================== ; win32k.sys (SP3GDR) ;========================================================================== ; ------------------------------------------------------------------------- ; xxxSetWindowLong ; ------------------------------------------------------------------------- $BF90AE3D: 33C0 xor eax, eax ; Default to 0 if no match found 90 nop ; ------------------------------------------------------------------------- ; _SetWindowWord ; ------------------------------------------------------------------------- $BF909FF7: 33C0 xor eax, eax ; Default to 0 if no match found 90 nop ; ------------------------------------------------------------------------- ; xxxSetClassData ; ------------------------------------------------------------------------- $BF90AC2C: 33C0 xor eax, eax ; Default to 0 if no match found 90 nop ;========================================================================== ; win32k.sys (SP3QFE) ;========================================================================== ; ------------------------------------------------------------------------- ; xxxSetWindowLong ; ------------------------------------------------------------------------- $BF90AE33: 33C0 xor eax, eax ; Default to 0 if no match found 90 nop ; ------------------------------------------------------------------------- ; _SetWindowWord ; ------------------------------------------------------------------------- $BF909F15: 33C0 xor eax, eax ; Default to 0 if no match found 90 nop ; ------------------------------------------------------------------------- ; xxxSetClassData ; ------------------------------------------------------------------------- $BF90AC06: 33C0 xor eax, eax ; Default to 0 if no match found 90 nop

Just as an FYI, I'm being told that this might be a problem in Vista as well. I don't have Vista and haven't looked into it, but I'm hearing that BSOD's started appearing with MS-073 on Vista and stopped when the hotfix was uninstalled.

Hmm. I've got most of the changes in for MS-091, and I might have found why all the PS fonts show up as invalid when I try the XP driver as-is. I haven't tried patching it yet, but there's a section of code where they do this: and [ebp+###], 0 (local variable) ja ######## (if it takes the jump it means something is invalid) The problem with this is that JA jumps if CF=0 and ZF=0. However, AND **always** sets CF=0 and also sets ZF=0 in this case because the result is 0. The end result: the condition is always true and it always makes the jump. I haven't tried to see what happens if I change the code but as it stands it isn't correct (and I checked the Intel docs to make sure).

Just a little update... I'm presently working on MS-091, the critical font patch. There are an enormous amount of changes, though I'm making steady progress. I tried using the XP driver as-is, but that wouldn't work, so I'm having to upgrade the 2k version. I'll definitely get there, but it's a long slog. I have made a lot of progress on it so far, though, enough that I'm confident that I'll eventually get it done. I also have on my box upgraded versions of win32k.sys and user32.dll. They add support for EngBugCheck, which I had to add when I was trying the XP font driver. They also add support for GetLayeredWindowAttributes, which let me finally run the HP Update program that came with my laptop I'm currently holding off on releasing them until the next time MS patches those files, which if history is any guide, won't be long.

Has anyone notified MS of the problem? Otherwise I'll have to keep issuing fixes every time they change the file...

from 4 to 5 but in MS10-054 you didn't change it. Was it left unchanged for purpose? Or maybe it doesn't matter at all? Also sometimes you delete and sometimes you leave it... does it make any change? Those were oversights on my part. SERVICE_PACK_NUMBER should always be set to 5. I delete all .cat references to keep the patch program from demanding that the update be signed. I guess leaving it in that patch didn't cause any problems.

I'm not really sure where to put this, so I'll just post it here. Apparently the XP MS10-098 and MS10-073 patches were causing BSOD's for some users, and one forum member asked me to make a fix that initializes the variables that I was concerned about (see page 3 for more info). Since applying my revised MS10-098 patch the BSOD's have stopped, so we decided to release it this week if no more problems cropped up. So here is a link to my revised MS10-098 patch for XP. Let's hope that MS fixes it soon... WindowsXP-KB2436673-FIX-x86-ENU.exe Included in the archive is a text file called patches.asm that shows the changes I made. You can get it by extracting everything with the /x option.

I've posted version 0.0.3 of my PE Tool, which should help anyone working on patches. See the top post for an updated link...

I know how to disable automatic updates through the registry (and I tested it), but that's sort of like killing an ant with a thermonuclear device Killing automatic updates entirely also stops updates for Office, etc. Another option would be to let people tell the Automatic Updates service to hide notifications for the older ones that it wants to reinstall. Basically, if you have it set to "notify but do not download", you can open the dialog, go to the details window to show what it wants to install, and uncheck the ones that you want it to hide. It will ask you if you want them to remain hidden, where you would say yes (you can always unhide them from the Automatic Updates control panel applet). To me that's a really kludgy way to do it, but it works. Ideally there would be a way to tell Automatic Updates through the registry that it should not offer those updates. I've spent the last few hours crawling through the assembly code for Automatic Updates and I've done some before-and-after registry comparisons and for the life of me I can't find where that information gets stored. For all I know the per-update hide settings get stored at an MS server somewhere. Anyhow, the patch for MS10-090 is up, and I decided to choose a middle ground...it will set your Automatic Updates to "notify only", which will give you a chance to tell it to not offer the older IE updates. When the icon+balloon appear telling you that an update is available, open it up and do the following: - Select Custom Install (IMPORTANT) - Click Next - Uncheck the IE patch that it offers (e.g. KB982381) - Click Close - When the Hide updates confirmation box pops up, check "Don't notify me about these updates again." - Click Ok. You might get nagged more than once. A minute or so after after I disabled KB982381, it nagged me about an even older update (KB978207). If that happens, turn off notification for that one the same way. After that, Automatic Updates should leave you alone.

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.

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.

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

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.

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

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

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.

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

I've uploaded Daedalus2 0.0.8, which you'll need if you install my unofficial MS10-048 hotfix (which I'll be uplodaing momentarily -- see the Win2k forum for details). In addition to the security patch, my hotfix adds 32-bit icon support to win32k.sys and user32.dll. This will break compatibility with Daedalus 0.0.7, but it also means that Daedalus only has to worry about adding support to image lists which are in comctl32.dll. This version of Daedalus is still compatible with unpatched Windows installations and it checks the file version of user32.dll to decide if it has to add support to user32 as well as comctl32. The link for Daedalus2 0.0.8 is here: http://www.mediafire.com/download.php?d4efbda2zd2ddss

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.

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.

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.