Blocked hotfixes, a workaround

CrashControl · Post by **CrashControl** » Sat Jun 25, 2011 2:36 pm

5eraph wrote:Updated to 2009-12_1. Please read the Changelog for full details.

As those of you who have downloaded some of the latest x64 hotfixes from Microsoft may have noticed, Microsoft has begun to use "WindowsServer2003" in place of "WindowsServer2003.WindowsXP" in the file names for certain updates. In addition, Microsoft has begun to use the following code in update_SP2QFE.inf:
Code: Select all
[Prerequisite]
    Condition=AndOp,Prereq.[color=white]XPAMDInstallBlock[/color].Section
..

[Prereq.XPAMDInstallBlock.Section]
    PresentOp=CheckReg,HKLM,"SYSTEM\CurrentControlSet\Control\ProductOptions",ProductType,0x00000000
    EqualOp=CheckReg,HKLM,"SYSTEM\CurrentControlSet\Control\ProductOptions",ProductType,0x00000000,==,"ServerNT"
    Display_String="%WrongProductMessage%"
This code cannot be altered to force the installer to work with XP x64 without breaking the signature for the INF. Nor can one change the protected registry value without hacking Windows, which we will not discuss here as it borders on piracy. However, some of these updates seem to be intended for XP x64 despite being blocked by the installer. Here is an incomplete list:
KB974927-v2, KB975928-v2, KB977073 and KB977534.
Microsoft's use of the above code seems to be arbitrary and incorrect in the cases of the updates listed, and perhaps other cases. Therefore, I have decided to include blocked updates in the update pack.

Hi 5eraph,

First, thank you (and others who contributed) for the comprehensive list of hotfixes maintained in the first post of this thread. Downloading the hotfixes (i.e., those that can't be downloaded automatically) from Microsoft and thehotfixshare.net one-by-one took forever!.

(I wanted the packages for my own installation/integration solutions)

I know the post I'm replying to specifically is dated but having just dealt with this annoying problem myself I wanted to discuss this. I don't want to clutter this thread so perhaps a new one should be created for related issues.

Concerning the blocking of hotfixes, the workaround I used for local installation was to first extract the hotfix into its own directory and then patch the update.exe binary to ignore the "prerequisite" section in the .inf file. All that involves is replacing the appropriate section name in the binary with a dummy value (of equal byte length) that won't be present. Backup the patched update.exe to some other directory so that next time you can just copy over the extracted update.exe with it.

Someone described in a blog (I'll try to dig up the URL if anyone wants it) patching the update.exe to allow modification of the .inf file, but I didn't want to break the signatures of any signed files.

Code: Select all

fc /b update.orig.exe  update.exe
00016A90: 50 44
00016A91: 72 75
00016A92: 65 6D
00016A93: 52 6D
00016A94: 65 79
00016A95: 71 53
00016A96: 75 65
00016A97: 69 63
00016A98: 73 74
00016A9A: 74 6F
00016A9B: 65 6E
00016AA0: 50 44
00016AA2: 72 75
00016AA4: 65 6D
00016AA6: 52 6D
00016AA8: 65 79
00016AAA: 71 53
00016AAC: 75 65
00016AAE: 69 63
00016AB0: 73 74
00016AB4: 74 6F
00016AB6: 65 6E

Odd that even the packaged hotfix says that it applies to XP64 in the version info section. It's sad that end-users should be forced to patch MS "fixes" to fix bugs in *their* software.

Post by **5eraph** » Sat Jun 25, 2011 6:32 pm

Very interesting workaround. Thank you for sharing, and welcome to the forum.

And you're right, this topic deserves its own thread.

EDIT 1: 2014/05/14
The following x64 patched file was created from the directions given by CrashControl above.

EDIT 2: 2014/09/08
Added an x86 version intended for POSReady 2009 and WEPOS update packages. Same patch, different location in the file (starting at 0x1CB90).

EDIT 3: 2015/04/07
Added SFXCAB Substitute by RAX Software and directions for using it to repackage an update. Please read the new warning in the TXT files. I won't be held responsible for carelessness.

Download:

Link: Patched_update.exe.7z
Size: 960 KB
MD5: 19d8a10fcdeeb8297345ef4defd88b89

yumeyao · Post by **yumeyao** » Sat Jun 25, 2011 8:30 pm

breaking update.exe and update.inf's signatures doesn't harm *anything*. The installation resule is transparent for both the OS and the user.

Post by **5eraph** » Sat Jun 25, 2011 8:50 pm

I could not force updates to install by modifying only the INF.

yumeyao · Post by **yumeyao** » Sat Jun 25, 2011 8:57 pm

as described above, just patch update.exe.

A patched file can be extracted from my WIC/XPS installers.

OnePiece Alb · Post by **OnePiece Alb** » Sat Jun 25, 2011 9:27 pm

I used almost 1 year ago with great success (update.exe also worked with modified inf)
http://www.remkoweijnen.nl/blog/2009/05 ... -hotfixes/
http://www.remkoweijnen.nl/blog/2009/07 ... otfixes-2/
I tried some tests on DirId which uses update.exe

however very interesting and the way to find the hex to edit

very ultile understand how to modify other files as SYSSETUP.dll and many other files, even though I know Microsoft does not use more certain structure in recent dll (to easily find the hex)

sorry for my English

Ciao a tutti.

Post by **5eraph** » Mon Feb 13, 2012 10:00 pm

Further discussion can be found on MSFN.

ricktendo64 · Post by **ricktendo64** » Thu Feb 16, 2012 2:34 pm

Can the setup from a .net4 patch be modded to ignore digital signature as well?

http://www.mediafire.com/?omrjgqn58hubbee

PJAmerica · Post by **PJAmerica** » Mon Apr 06, 2015 6:17 am

5eraph wrote:Download:
File: Patched_update.exe.7z

Is there an way to compress this so as to make it like a normal EXE installer?

Post by **5eraph** » Mon Apr 06, 2015 10:42 am

Yes there is, PJAmerica:

harkaz wrote:A technical note: @tomasz86: Cabarc failed BIG TIME creating the cab today. I used this excellent tool (and XVI32) to create the SFX EXE: http://www.softpedia.com/progDownload/S ... 31564.html.
It will work only in English, but I think it's easy to change the sfx header for a different langugae. It compresses all files without problems, and that's what matters (cabarc wouldn't compress after some point).

I've used the following SFXCAB Substitute command lines successfully:

x86:

SFXCAB.exe WindowsXP-KB3049874-x86-Embedded-ENU.exe target -r:update/update.exe -ipd -iswu

x64:

SFXCAB.exe WindowsServer2003-KB3049874-x64-ENU.exe target -r:update\update.exe

Tried using a source folder with spaces wrapped in quotes, like "A3049874-TimeZone replaces A3039024", but SFXCAB always fails with the following error:

Unknown command r

ERROR: Cabinet creation failed.

Use a source folder such as "target" to avoid this error.

To my knowledge, no x64 update package has ever used IPD compression; therefore, I don't use that switch in the x64 command line. The "-iswu" switch is specific to IPD compression and is not necessary for x64 packages.

PJAmerica · Post by **PJAmerica** » Mon Apr 06, 2015 11:14 am

I appreciate the follow up but I didn't understand a word of it.

Post by **5eraph** » Mon Apr 06, 2015 11:17 am

Have you extracted an update package and replaced the "update.exe" file? I'd like to help, but I don't know what you've accomplished so far.

PJAmerica · Post by **PJAmerica** » Mon Apr 06, 2015 12:01 pm

5eraph wrote:Have you extracted an update package and replaced the "update.exe" file? I'd like to help, but I don't know what you've accomplished so far.

Yes, I have that down pat. I have the target folder an everything. I just want to create actual EXE files of the patches once they are done. So I can add them to a clean install on the fly or via nlite at a later date. The more detailed and direct the directions the better. Or even if someone would do it for me that would be great. I can patch them all for someone. I wouldn't mind learning if it's not over my head.

Edit: These are for a 32-bit XP Home Edition. I am using the ones from Onepiece's box archive for English language.

Post by **5eraph** » Mon Apr 06, 2015 3:02 pm

It's fairly simple to do.

Download and extract SFXCAB Substitute.
Copy "SFXCAB.exe" to the directory that contains "target".
Open a CMD prompt and navigate to "SFXCAB.exe".
Type the following command line for x86 packages in the CMD window:
SFXCAB.exe KB3049874.exe target -r:update/update.exe -ipd -iswu
Replace "KB3049874.exe" above with whatever file name you want.
PROFIT.

PJAmerica · Post by **PJAmerica** » Mon Apr 06, 2015 4:23 pm

You have to forgive me but I am entirely ignorant to this stuff.

The "target" folder is on my desktop. Do I just copy "SFXCAB.exe" to inside the target folder?

How do I navigate to "SFXCAB.exe" once I have opened a CMD prompt and how do I open a CMD prompt for this? Just type? CMD in run box?

Post by **5eraph** » Mon Apr 06, 2015 5:12 pm

If "target" is on your desktop then copy "SFXCAB.exe" to your desktop. Yes, you can type CMD in the Run box. Then type the following into the CMD box:

cd desktop
SFXCAB.exe KB3049874.exe target -r:update/update.exe -ipd -iswu

The finished file, "KB3049874.exe" or whatever you want to name it, should then appear on your desktop.

Post by **5eraph** » Mon Apr 06, 2015 10:26 pm

The archive containing the patched update.exe files has been updated. Now that the tool and the directions are readily available to repackage updates with these patched files, I feel that I must post this warning from the TXT files in the archive:

DISTRIBUTING REPACKAGED UPDATE PACKAGE EXECUTABLES THAT CONTAIN THESE PATCHED update.exe FILES IS STRONGLY DISCOURAGED. Allow me to explain...

The update.exe files in this archive are patched to bypass the [Prerequisite] section of an update package's INF file. This allows a POSReady 2009 update with restricting prerequisites to install on 32-bit versions of Windows XP. And it allows a Windows 2003 x64 update with restricting prerequisites to install on Windows XP x64.

Because the [Prerequisite] section is bypassed, EXTRA CARE must be taken when installing updates using these patched update.exe files. This INF section can be used for more than just checking the operating system version. It may also be used to check software component versions. THIS FUNCTIONALITY WILL BE BROKEN.

For example, an update for IE8 that includes one of these patched update.exe files WILL NOT verify the current IE version before replacing files. Existing IE6 and IE7 files will be incorrectly replaced by IE8 files. THIS MAY CAUSE SYSTEM INSTABILITY OR A SYSTEM CRASH.

For this reason, DISTRIBUTING REPACKAGED UPDATE PACKAGE EXECUTABLES THAT CONTAIN THESE PATCHED update.exe FILES MUST BE STRONGLY DISCOURAGED.

In most cases I wouldn't have an issue. But special cases exist that could wreak havoc--like Internet Explorer updates, which are all too common. I need to cover my ass.

PJAmerica · Post by **PJAmerica** » Tue Apr 07, 2015 12:28 am

5eraph wrote:The archive containing the patched update.exe files has been updated. Now that the tool and the directions are readily available to repackage updates with these patched files, I feel that I must post this warning from the TXT files in the archive:

DISTRIBUTING REPACKAGED UPDATE PACKAGE EXECUTABLES THAT CONTAIN THESE PATCHED update.exe FILES IS STRONGLY DISCOURAGED. Allow me to explain...

The update.exe files in this archive are patched to bypass the [Prerequisite] section of an update package's INF file. This allows a POSReady 2009 update with restricting prerequisites to install on 32-bit versions of Windows XP. And it allows a Windows 2003 x64 update with restricting prerequisites to install on Windows XP x64.

Because the [Prerequisite] section is bypassed, EXTRA CARE must be taken when installing updates using these patched update.exe files. This INF section can be used for more than just checking the operating system version. It may also be used to check software component versions. THIS FUNCTIONALITY WILL BE BROKEN.

For example, an update for IE8 that includes one of these patched update.exe files WILL NOT verify the current IE version before replacing files. Existing IE6 and IE7 files will be incorrectly replaced by IE8 files. THIS MAY CAUSE SYSTEM INSTABILITY OR A SYSTEM CRASH.

For this reason, DISTRIBUTING REPACKAGED UPDATE PACKAGE EXECUTABLES THAT CONTAIN THESE PATCHED update.exe FILES MUST BE STRONGLY DISCOURAGED.
In most cases I wouldn't have an issue. But special cases exist that could wreak havoc--like Internet Explorer updates, which are all too common. I need to cover my ass.

I don't blame you at all. I am very cautious myself and was leery for a good while. I have spent months, days and weeks testing these thing in variation for adverse effects on my machine. due dilligence is required.

PJAmerica · Post by **PJAmerica** » Tue Apr 07, 2015 12:44 am

5eraph wrote:If "target" is on your desktop then copy "SFXCAB.exe" to your desktop. Yes, you can type CMD in the Run box. Then type the following into the CMD box:

cd desktop
SFXCAB.exe KB3049874.exe target -r:update/update.exe -ipd -iswu
The finished file, "KB3049874.exe" or whatever you want to name it, should then appear on your desktop.

You sir are my Windows XP savior. Thank you for enabling me to do this for myself. I appreciate the time and patience.

Post by **5eraph** » Tue Apr 07, 2015 3:00 am

Glad I could help.

PJAmerica · Post by **PJAmerica** » Wed Apr 08, 2015 7:26 am

For some reason, no matter what I do, KB3035132 turns out corrupted when I do the process with SFXCAB.exe. I tried Onepiece's copy of KB3035132 from the Box Link. I downloaded it from the Catalog even. What is wrong with this thing? Any insights?

Post by **5eraph** » Wed Apr 08, 2015 1:02 pm

Can't pin down exactly why it fails. The long directory tree within the update seems to cause trouble when SFXCAB is run from a location with a long path. I did, however, get the following command line to work from the desktop:

sfxcab KB3035132.exe target -r:update/update.exe -ipd -iswu -basisexe:spmsg.dll

The new EXE is a bit larger than the original. But it extracts and installs properly in my VM.

PJAmerica · Post by **PJAmerica** » Thu Apr 09, 2015 10:56 am

5eraph wrote:Can't pin down exactly why it fails. The long directory tree within the update seems to cause trouble when SFXCAB is run from a location with a long path. I did, however, get the following command line to work from the desktop:

sfxcab KB3035132.exe target -r:update/update.exe -ipd -iswu -basisexe:spmsg.dll
The new EXE is a bit larger than the original. But it extracts and installs properly in my VM.

I run everything from desktop as the directions prescribed. So that can't be it. Odd.

bphlpt · Post by **bphlpt** » Thu Apr 09, 2015 3:06 pm

Since 5eraph has identified that there is an issue when a long path is involved, and perhaps with spaces involved, you might try re-running your test where everything you need has been re-located to somewhere with a short, simple path, such as "C:\tst\". By the way, it is usually not recommended to run things from the desktop. It used to be that many scripts and programs would have problems with a long path with spaces. Not as much anymore, but I would still always suggest a short, simple path, when possible. Just my two cents.

Cheers and Regards

PJAmerica · Post by **PJAmerica** » Thu Apr 09, 2015 3:44 pm

bphlpt wrote:Since 5eraph has identified that there is an issue when a long path is involved, and perhaps with spaces involved, you might try re-running your test where everything you need has been re-located to somewhere with a short, simple path, such as "C:\tst". By the way, it is usually not recommended to run things from the desktop. It used to be that many scripts and programs would have problems with a long path with spaces. Not as much anymore, but I would still always suggest a short, simple path, when possible. Just my two cents.

Cheers and Regards

I did that indeed before posting. I alter the path shorter and the exe file to a shorter name. Until he provided the that command though, nothing worked. Just odd outcome.

Post by **5eraph** » Thu Apr 09, 2015 3:45 pm

Glad you got it to work, PJAmerica.

While I agree with you about the desktop, bphlpt, it seems that the number of people familiar with directory structures and command lines is dropping sharply. DOS is a distant memory. In my opinion, walking someone through a series of commands is safer from the desktop than the root of a drive, where one bad keystroke could still nuke an operating system.

PJAmerica · Post by **PJAmerica** » Thu Apr 09, 2015 4:03 pm

5eraph wrote:Glad you got it to work, PJAmerica.

While I agree with you about the desktop, bphlpt, it seems that the number of people familiar with directory structures and command lines is dropping sharply. DOS is a distant memory. In my opinion, walking someone through a series of commands is safer from the desktop than the root of a drive, where one bad keystroke could still nuke an operating system.

Yeah, I experienced that way back in the day when learning DOS. Hence I am gun shy and not all too familiar after 20+ years. I like to keep it safe and keep it off the shelf and vanilla.