Jump to content

POSReady 2009 updates ported to Windows XP SP3 ENU


glnz

Recommended Posts


eGo®Z

Microsoft wants Subsequent addition of March patch day a new update for KB3013455 and KB3037639, for operating systems have had problems with the font smoothing. I had heard so on a Microsoft blog, where many angry users writing down their frustrations. Whether then a new version number is relevant? See this only as a last resort.

Edited by heinoganda
Link to comment
Share on other sites

March patch day a new update for KB3013455 and KB3037639

Whether then a new version number is relevant?

No, not relevant until then.

Contrary nice, helps to avoid confusion in the meantime.

There is a unicode string ".6712"

gsar -b "-s:x2E:x00:x36:x00:x37:x00:x31:x00:x32:x00"

String at different offset per language, gsar can change this string too. Report later.

Link to comment
Share on other sites

Microsoft wants Subsequent addition of March patch day a new update for KB3013455 and KB3037639, for operating systems have had problems with the font smoothing. I had heard so on a Microsoft blog, where many angry users writing down their frustrations. Whether then a new version number is relevant? See this only as a last resort.

Changing version number with the highest one will protect you from an occasional reinstalling of the original KB3013455 in a future. So if Microsoft will release in march a new KB with the same file version number, you will need just uninstall your patched KB.

 

By the way about last digital group in update.ver file. On the ryanvm.net forum i've found the message from harkaz where he wrout that it is CRC-32 hash sum. But how it can be caculated? Anyways it is not CRC-32 (ISO) or CRC-32B with Normal hash sum generator type - that's for sure.

Link to comment
Share on other sites

 

@ jaclaz

 

Here a batch for hexalter and PEChecksum: 

 

Yep. :)

 

JFYI, this would do as well:

hexalter.exe win32k.sys 0x55D20=0xF7,0x04,0x00,0x00 0x55D2B=0x17,0x7E,0xFF,0xFF

 

(everything should be as simple as possible, but not simpler ;))

 

jaclaz

Link to comment
Share on other sites

To patch KB3013455 win32k.sys, set version string .6713 and adjust PE checksum.

hexalter.exe win32k.sys 0x55D20=0xF7,0x04,0x00,0x00 0x55D2B=0x17,0x7E,0xFF,0xFFgsar.exe -o -s":x2E:x00:x36:x00:x37:x00:x31:x00:x32:x00" -r":x2E:x00:x36:x00:x37:x00:x31:x00:x33:x00" win32k.sysgsar.exe -o -s":x01:x00:x05:x00:x38:x1A:x28:x0A" -r":x01:x00:x05:x00:x39:x1A:x28:x0A" win32k.sysPEChecksum.exe win32k.sys
Link to comment
Share on other sites

UPDATE [22/5/2014]: Sebijk reported that a simple registry tweak is enough for WU to show the latest POSReady updates on Windows XP. This method has been tested and works on any XP build.

 

Add the following registry keys (INF Format):

 

HKLM,"System\CurrentControlSet\Control\WindowsEmbedded\ProductVersion","FeaturePackVersion",0x00000000,"SP3"

HKLM,"SYSTEM\WPA\WEPOS","Installed",0x10001,0

HKLM,"SYSTEM\WPA\WES","Installed",0x10001,0

HKLM,"SYSTEM\WPA\POSReady","Installed",0x10001,1

 

and restart the computer. Then run WU to get the latest updates.

 

here is another way of doing it.. create a reg-file with the data, below, and "merge" it into your registry:

Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINE\SYSTEM\WPA\PosReady]"Installed"=dword:00000001

reference:

 

http://news.softpedia.com/news/How-to-Update-Windows-XP-after-End-of-Support-443631.shtml

 

using the reg-file, as described above, has worked for me..

 

p.s. when creating a reg-file, i always leave a blank line at the end of the code.. when using "regedit" to export a regkey, it always leaves a blank line at the end of the code, so that is the way that i do it too..

Edited by redwolfe_98
Link to comment
Share on other sites

I think I have found a difference:

 

The order of command execution is reversed.

 

2uig1ol.jpg

harkaz, i appreciate the work that you have done.. i installed your "FIX" for the MS15-010/3013455 update, which, incidentally, took a leap of faith, since it is a modified "windows" file and it also requires installing a "certificate" for it..

 

with all of the talk about komodia's installing certificates etc, and with "privdog", and everything else associated with that, when you talk about installing a certificate (not to mention installing a modified windows file), it is concerning:

 

http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/

 

http://www.pcworld.com/article/2887632/secure-advertising-tool-privdog-compromises-https-security.html

 

i would like to know how to remove your certificate that i installed, in case i ever want to.. does it have a name? to remove the certificate, would you simply delete the "HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCertificates\Root\Certificates\F2C90A445A5E0F0F79AEDEB694D50B9656B24A71" regkey, or would deleting that regkey cause problems with other certificates?

 

i just wanted to mention something.. looking at the screenshot that you posted, you say that "the order of command execution is reversed", but there seems to be more to it..

 

in your screenshot, in the code in the window on the left, it has a "@sc1_InitializeTwilightcontours@12" while the code in the window on the right doesn't, at least that is the way that it looks to me.. maybe you already noticed that, or maybe i am confused and that actually was the point that you were making.. :)

 

regarding the MS15-010/3013455 update, from what you have posted, it seems that the "win32k.sys" file that was installed by the 3013455 update was flawed, and that the 3037639 update, which was meant to fix the font problem, simply tweaks windows in order to allow it to use the flawed win32k.sys file, but without the font-problems.. tweaking windows to where it can use a flawed win32k.sys file (but without the font problems) doesn't sound good to me..

 

from reading some of the other posts here, it seems that some people opted to tweak the win32k.sys file themselves.. i suppose that they also had to use their own certificates in order for windows to allow the modified win32k.sys file to be installed and to run..

 

for the record, i don't know anything about "coding" software.. i am not an "expert".. i am just a regular home-computer-user..

Edited by redwolfe_98
Link to comment
Share on other sites

 

here is another way of doing it.. create a reg-file with the data, below, and "merge" it into your registry:

 

Sure :), that is actually the "original" way, exactly as posted by Sebijk

https://www.sebijk.com/community/board9-community/board5-pc/2984-xp-updates-weiterbeziehen/

In the very early days of this thing, the entries for all the four "still supported products" were added, while soon after it was found out how only the PosReady was needed and enough.

See also:

http://www.msfn.org/board/topic/171814-posready-2009-updates-ported-to-windows-xp-sp3-enu/page-3#entry1078506

 

jaclaz

Link to comment
Share on other sites

 

I think I have found a difference:

 

The order of command execution is reversed.

 

2uig1ol.jpg

harkaz, i appreciate the work that you have done.. i installed your "FIX" for the MS15-010/3013455 update, which, incidentally, took a leap of faith, since it is a modified "windows" file and it also requires installing a "certificate" for it..

 

with all of the talk about komodia's installing certificates etc, and with "privdog", and everything else associated with that, when you talk about installing a certificate (not to mention installing a modified windows file), it is concerning:

 

http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/

 

http://www.pcworld.com/article/2887632/secure-advertising-tool-privdog-compromises-https-security.html

 

i would like to know how to remove your certificate that i installed, in case i ever want to.. does it have a name? to remove the certificate, would you simply delete the "HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCertificates\Root\Certificates\F2C90A445A5E0F0F79AEDEB694D50B9656B24A71" regkey, or would deleting that regkey cause problems with other certificates?

 

i just wanted to mention something.. looking at the screenshot that you posted, you say that "the order of command execution is reversed", but there seems to be more to it..

 

in your screenshot, in the code in the window on the left, it has a "@sc1_InitializeTwilightcontours@12" while the code in the window on the right doesn't, at least that is the way that it looks to me.. maybe you already noticed that, or maybe i am confused and that actually was the point that you were making.. :)

 

regarding the MS15-010/3013455 update, from what you have posted, it seems that the "win32k.sys" file that was installed by the 3013455 update was flawed, and that the 3037639 update, which was meant to fix the font problem, simply tweaks windows in order to allow it to use the flawed win32k.sys file, but without the font-problems.. tweaking windows to where it can use a flawed win32k.sys file (but without the font problems) doesn't sound good to me..

 

from reading some of the other posts here, it seems that some people opted to tweak the win32k.sys file themselves.. i suppose that they also had to use their own certificates in order for windows to allow the modified win32k.sys file to be installed and to run..

 

for the record, i don't know anything about "coding" software.. i am not an "expert".. i am just a regular home-computer-user..

 

nope, I just modified win32.sys and replace them(in both dllcache and system32) on-the-fly right after installing original KB3013455 patch.

So no cert. are needed.

Link to comment
Share on other sites

 

I think I have found a difference:

 

The order of command execution is reversed.

 

2uig1ol.jpg

harkaz, i appreciate the work that you have done.. i installed your "FIX" for the MS15-010/3013455 update, which, incidentally, took a leap of faith, since it is a modified "windows" file and it also requires installing a "certificate" for it..

 

with all of the talk about komodia's installing certificates etc, and with "privdog", and everything else associated with that, when you talk about installing a certificate (not to mention installing a modified windows file), it is concerning:

 

http://arstechnica.com/security/2015/02/lenovo-pcs-ship-with-man-in-the-middle-adware-that-breaks-https-connections/

 

http://www.pcworld.com/article/2887632/secure-advertising-tool-privdog-compromises-https-security.html

 

i would like to know how to remove your certificate that i installed, in case i ever want to.. does it have a name? to remove the certificate, would you simply delete the "HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCertificates\Root\Certificates\F2C90A445A5E0F0F79AEDEB694D50B9656B24A71" regkey, or would deleting that regkey cause problems with other certificates?

 

i just wanted to mention something.. looking at the screenshot that you posted, you say that "the order of command execution is reversed", but there seems to be more to it..

 

in your screenshot, in the code in the window on the left, it has a "@sc1_InitializeTwilightcontours@12" while the code in the window on the right doesn't, at least that is the way that it looks to me.. maybe you already noticed that, or maybe i am confused and that actually was the point that you were making.. :)

 

regarding the MS15-010/3013455 update, from what you have posted, it seems that the "win32k.sys" file that was installed by the 3013455 update was flawed, and that the 3037639 update, which was meant to fix the font problem, simply tweaks windows in order to allow it to use the flawed win32k.sys file, but without the font-problems.. tweaking windows to where it can use a flawed win32k.sys file (but without the font problems) doesn't sound good to me..

 

from reading some of the other posts here, it seems that some people opted to tweak the win32k.sys file themselves.. i suppose that they also had to use their own certificates in order for windows to allow the modified win32k.sys file to be installed and to run..

 

for the record, i don't know anything about "coding" software.. i am not an "expert".. i am just a regular home-computer-user..

 

 

1. You will found the @sc1_InitializeTwilightcontours@12 if you follow the jmp instruction

 

2. I have done statistical analysis of the differences between the 2 MS patches (Server 2003) and I have found an equivalent patch for the NT5.1 win32k.sys. (It's not the same because the Server 2003 corrective patch is done via a function chunk, while my patch is simply a reversal of the function execution order). So crafting the patch is something more than intuition.

 

3. Deleting HKEY_LOCAL_MACHINE\Software\Microsoft\SystemCertificates\Root\Certificates\F2C90A445A5E0F0F79AEDEB694D50B9656B24A71 is enough to remove my CA from your system. All files signed with certificates chained to this CA will become untrusted.

 

4. It is possible to perform SSL hijacking by creating certificates signed with my certificate authority (provided you have the encryption keys of the CA, which you don't). Only if I decided/managed to inject a virus in your system would this be possible.

Edited by harkaz
Link to comment
Share on other sites

By the way, i have to add my one cent to "update.ver" file patching. It has the structure, as it described below:

[sourceFileInfo]

sp3qfe\win32k.sys=D34BA6467C2109D604646747AB33D3AC,000500010A281A4D,1890432,SP3QFE,7B2FBF88

|----------- MD5 -------------| |-- Version --| |--bytes--| |--Branch--| |--Unknown--|

========

In our case Version is 5.1.2600.6733, so it can be decoded in this way:

0x0005 - 5

0x0001 - 1

0x0A28 - 2600

0x1A4D - 6733

 

PS: What means the last group of digits i dont know. If anyone knows, so describe it here, please.

 

By the way about last digital group in update.ver file. On the ryanvm.net forum i've found the message from harkaz where he wrout that it is CRC-32 hash sum. But how it can be caculated? Anyways it is not CRC-32 (ISO) or CRC-32B with Normal hash sum generator type - that's for sure.

 

Hmm... The file win32k.sys from Harkaz has:

CRC-32 = 9C109679                (http://hash.online-convert.com/crc32-generator)

CRC-32B = A761AAA6            (http://hash.online-convert.com/crc32b-generator)

However, the last digital group in the update.ver file from Harkaz is 7B2FBF88.

 

How is this discrepancy to be understood?

Link to comment
Share on other sites

@egrabrych It turns out that the update installation program does not check the CRC32, but it needs these 8 digits to be there to recognise update.ver as valid. It checks MD5 and file size.

Link to comment
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.
×
×
  • Create New...