WildBill

PE Tool for creating patches

695 posts in this topic

Billtodd -

It fixes the MS10-046 security vulnerability relating to LNK files.

0

Share this post


Link to post
Share on other sites

Billtodd -

It fixes the MS10-046 security vulnerability relating to LNK files.

Thanks for the speedy response. I understand what 2286198 does, it's just not clear to me that this also addresses what 967715 fixes (i.e., that the assertion that the former supersedes the latter is correct: that assertion appears in bristols' Win2K SP4 update list, so - as I said - forgive me if this is not the right place to ask about it).

- bill

0

Share this post


Link to post
Share on other sites

Almost there :) Here's another one that changes how it tries to load the bootskin image from disk to use a lot less stack space. Even if you have bootskins off it was still allocating a lot of stack space and maybe that was a problem.

Windows2000-KB2393802-v1-early-c5j-x86-ENU.exe

Unfortunately there's no difference with c5i :(

billtodd,

2286198 does supersede 967715. If you look at the file version of Shell32.dll, you'll see that the one from 967715 is 5.0.3900.7155 and the one from 2286198 is 5.0.3900.7158. Basically newer versions are based on older ones so the changes done to Shell32.dll by 967715 are also present in 2286198. Now, file version is not everything. There are also changes done to the registry. If you check update.inf files of both of these updates it'll be clear that they both add the same things to the registry.

However, you do have the point here because indeed there are two mistakes on bristols' page.

1. 967715 is superseded by 2286198. <- Correct.

2286198 is said to be superseded by 2479628 so 2479628 should supersede both 967715 & 2286198. <- False

Actually the current version of 2479628 does not supersede 2286198. The shell32.dll file is newer but the registry changes added in both 967715 & 2286198 are not present in 2479628! I prepared a corrected version of it.

Windows2000-UU-KBz2479628-v9-x86-ENU.exe

Now it really supersedes 967715 & 2286198.

2. 2079403 is said to supersede 955069. In reality it does not. The problem is the same as above - the registry changes done by 955069 are not present in 2079403.

Here is a fixed version:

Windows2000-UU-KBz2079403-v2-x86-Global.exe

I prepared also an another additional update:

MS10-005: Vulnerability in Microsoft Paint could allow remote code execution

Windows2000-UU-KB978706-v2-x86-ENU.exe

Windows2000-UU-KB978706-v2-x86-PLK.exe

This is MS Paint from Windows XP. It has an advantage over the one from Windows 2000 that you can save files as jpg, png, etc. while in the original one only bmp is available.


  • mspaint.exe 5.1.2600.5918

I have decided to add -UU- for "Unofficial Updates" and "-HBR-" for hotfixes (by request) to filenames from now on so it should be much easier to know what kind of an update it is.

I hope everything is clear now :)

EDIT

I've changed the filename of KB978706 to KB978706-v2 in order to distinguish it from the original KB978706. You must not use both official KB978706 and unofficial KB978706-v2 when slipstreaming in HFSLIP because the newer paint.exe won't be copied in such a case.

Edited by tomasz86
0

Share this post


Link to post
Share on other sites

Thanks for such a clear and complete explanation. The main reason I questioned whether 2286198 actually superseded 967715 was because the Microsoft 'replaces' information for the former did not appear to recognize that it superseded the latter (nor did the descriptions of the problems addressed appear similar). I would have taken a closer look at what was going on had I not assumed that the question could be answered off the top of someone's head, so apologies (and further appreciation) if you had to do more than that.

It surprised me that 2286198 was itself superseded without any mention in its own slot - perhaps because it (and similarly 2296011 and two other unofficial updates that apparently didn't supersede earlier official updates) was superseded only by an IE-specific update rather than by a system update. Just tracking what replaces what must be non-trivial, and since it shouldn't do any harm to apply earlier updates unnecessarily I guess the only real reason to try to avoid that may be the size limitations of a CD (though perhaps not even that, given how the CD is likely created).

Edit: I've wondered whether the HFSLIP command file keyed off alphabetical order to make sure that newer files in SOURCESS weren't overwritten by older ones, but I guess your new naming conventions make it clear that it doesn't.

Edited by billtodd
0

Share this post


Link to post
Share on other sites

KB2479628 isn't an IE-specific update per se. It was just that initially there were problems when it was installed in an IE5 system. That's why separate versions were created and bristols still keeps them on his page. Starting from 2479628-v8 there are no problems regardless whether you use IE5 or IE6. Only if you happen to use IE6+FDV fileset, you must use HFSLIP 1.7.10 beta J v5 or newer to get this update slipstreamed correctly.

Actually it may cause problems (in some cases) if you have both newer and superseded updates in HF folder. As for newer files, there are no problems because HFSLIP always slipstreams only the newest ones (=newest by their date, not version) but it may be problematic when both updates change the same registry entries. In such a case the newer one must be processed after the older. That's why I add the "z" after KB in KB2* to ensure that they are listed after the older ones starting with KB8* or KB9*.

I used to keep both superseded official updates and newer unofficial ones in my HF folder but recently I've removed all the superseded ones to prevent any potential errors from happening. Actually I have two separate HFSLIP folders now - one with official updates only and the other one with unofficial ones included (and superseded official updates removed). Thanks to that I can easily check and compare them anytime I want.

Edited by tomasz86
0

Share this post


Link to post
Share on other sites

WildBill,

I've been having some problems with my computer and don't have access to my 2K system at the moment :(

I'll try to test your patch as soon as possible.

0

Share this post


Link to post
Share on other sites

I've just tested it but still no difference unfortunately :(

0

Share this post


Link to post
Share on other sites

I've found one more mistake on britols' page and this one I'd call critical.

2511455 is said to supersede 980232 but it does not because there's no rdbss.sys in it. If you slipstream 2511455 and don't include 980232 at the same time, you'll get a BSOD during Windows setup.

I prepared a fixed version where I added the rdbss.sys from 980232:

Windows2000-UU-KBz2511455-v2-x86-Global.exe

0

Share this post


Link to post
Share on other sites

Thanks tomasz86.

Aside from rdbss.sys, did you add anything else to 2511455?

If not, I guess it's OK to continue using 980232 together with the existing 2511455 by WildBill. Is that right?

0

Share this post


Link to post
Share on other sites

No, the only thing I added was rdbss.sys :) It's different in case of 2479628 & 2079403 where changes are related strictly to the registry.

Of course you can use both 980232 & 2511455. It's just (in my opinion) that the fewer updates, the better ;)

0

Share this post


Link to post
Share on other sites
the fewer updates, the better

Sure, but that's not the only consideration.

Thanks tomasz86.

Edited by bristols
0

Share this post


Link to post
Share on other sites

I've removed KB908536.

Uxtheme.dll seems to cause problems with .NET Framework based applications. I tried both versions - one from OldCigarette and the other one from BlackWingCat but unfortunately it's always the same. There's an error when trying to launch .NET based programs.

0

Share this post


Link to post
Share on other sites

I added two updates:

Windows2000-UU-MSRDP7-x86-ENU.exe <- MS Remote Desktop 7.0 (quite experimental but works)

Windows2000-UU-WIC-x86-Global.exe <- Windows Imaging Component (WIC)

Both of them rely on DLLs coming from either BlackWingCat's KDW or directly from Windows XP.

I'd also like to add one important information. Starting from this moment I'm going to test updates only in a system with (at least) BlackWingCat's kernel v5 installed. They may work without the kernel but don't have to. I'm sorry to say it but I just haven't got the time to test them in a configuration without unofficial kernel installed :(

The kernel is also required for applications written in Visual Studio 2010 so I think using it is just inevitable.

Edited by tomasz86
0

Share this post


Link to post
Share on other sites

I added:

OnePiece_Microsoft.NET_Framework_v3.5.30729.3644.4_True_AddOn_ENU_W2K.7z

This is modified version of OnePiece's .NET 3.5 True AddOn for XP/2K3. I fixed the dependencies to make it work smoothly in Windows 2000. The files used to fix them come either from BlackWingCat's KDW or directly from Windows XP. You must install OnePiece's .NET 2.0 True AddOn together with one!! When slipstreaming in HFSLIP, both of them should go to HFAAO folder.

Edited by tomasz86
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.