Jump to content

harkaz

Member
  • Posts

    246
  • Joined

  • Donations

    0.00 USD 
  • Country

    Greece

Everything posted by harkaz

  1. 1. Only the update pack has been fixed so that all uniprocessor HALs are properly used. A further update of the Internet Archive distro includes dump of the RyanVM.net thread, which is about to be shutdown. 2. Yes, but unlike GH0stPak you get seamless integration of all updates for all SP4 components (i.e. dotnets) 3. GH0stPak is unrelated and unnecessary to the integration of post-SP4 update packs. NEWS (March 4th, 2023): Due to announced RyanVM.net shutdown, all XP SP4 material - including dumps of Ryanvm.net thread are available from the alternative download location (official Internet Archive repo): https://archive.org/details/xp-unofficial-sp4-jan2022_20220113 View contents of ryanvm-archive-xpsp4-posts.7z. The SP4 MUI pack can be found only on the Internet Archive, along with everything else.
  2. In the slipstreamed MCE SP4 media, inside file hivesys.inf, search for string "POSReady WPA trick". Remove the registry entry below that. Reinstall Windows (clean) from the latest installation media. This may fix the product key issue. Otherwise, original pidgen.dll must be used from MCE2005 installation media. .NET Framework 4.0 can be unhidden in the sysoc.inf (replace ,hide,7 with ,,7 at the netfx40=... line) so that it can be installed by the Add/Remove Components Wizard if desired. @tpao12 Regarding .NET Framework 4.0 issue, please remove all .NET Frameworks from Add/Remove Components. Restart the system and reinstall .NET Framework 3.5 first, restart, then install .NET Framework 4.0 and reboot again.
  3. Update (January 13, 2022): The update pack and update rollup have been updated to fix a bug with ntoskrnl.exe file (affecting single threaded systems). All files are now available from the Internet Archive: https://archive.org/details/xp-unofficial-sp4-jan2022_20220113
  4. That's normal apart from the freeze. .NET 2.0-3.5 appear due to necessary Windows Installer baseline configuration. Try optimizing the .NET Framework 4.0 (refer to XP SP4 first post at RyanVM.net, see my signature). Otherwise, start from scratch in that order: SP2 -> SP4 directly, no .NET -> Install post-SP4 -> install .NET 3.5 and .NET 1.1 -> reboot -> Install .NET 4.0 -> reboot -> Install all .NET apps -> Optimize .NET Framework 4.0
  5. This is a known issue: for some reason the updated time zone registry entries in the post-sp4 update pack in hivesft.inf cause nlite to crash (an unresolved bug in nLite). As a workaround you can temporarily copy the time zone registry entries from another update pack and replace them in the hivesft.inf file. After nLite is done with the modifications, replace the original registry entries in the hivesft,inf file. The MUI pack has been tested with the XP SP4 v3.1b only. For the post-sp4 update pack level, there are language-specific files such as xpsp4res.dll that may need updating. You can get these files from the latest updates. I have no plans to rebuild the SP4 MUI Pack for the update pack level. SP4 v3.1b (without .NET Framework) is the most stable option for most systems eligible for XP. Microsoft has botched some OS functionality in post-2016 updates (due to lack of extensive testing?) and dropped support for non-SSE2 processors. Yes that message has been disabled by SP4. Version 2014 will not change for historical reasons (XP SP4 was finalized in 2014). After 2016 (XP Embedded SP3 EOL-SP4 v3.1b update level) the quality of POSReady updates was inferior and consequently the update pack may not be stable on some systems. Latest is not always greatest. To get a list of updates: On a system with the post-SP4 update pack - either installed or integrated in the installation media - run qfecheck from the command prompt.
  6. Windows XP SP4 thread (along with a few others) has been mostly archived, but some pages are missing: https://web.archive.org/web/20191105073426/https://ryanvm.net/forum/viewtopic.php?t=10321 We need a full snapshot of the site.
  7. Use the GH0stpak, as described in the RyanVM forum, in order to update your system. The May 2019 update pack is intended for new installations of WIndows XP from updated media.
  8. 1. In a Windows XP environment, extract/copy the contents of XP SP0/SP1/SP2/SP3 original media to an empty folder: C:\XPMEDIA. 2. Run this command from command line: WindowsXP-USP4-v3.1b-x86-ENU.exe /integrate:C:\XPMEDIA 3. As soon as 2 is complete, extract the update pack zip to a blank new folder named C:\updpack 4. Run C:\updpack\slipstream.bat. 5. Paste C:\XPMEDIA to the command line window that appears and press ENTER
  9. UPDATE: SP4 v3 October 2018 MUI Update ISO has been re-uploaded. UPDATE #2: Updated Windows XP Debugging Symbols for May 2019 post-SP4 update pack have been also uploaded. For more information, visit RyanVM.net.
  10. The "Windows XP SP4 MUI October 2018 Update" is the best way to use SP4 in languages other than English (ISO was flagged and no longer available, will re-upload sometime). However, several OS components will not be translated to another language.
  11. Extract zip anywhere you want, then run the .bat file.
  12. UPDATE [June 7, 2019]: Post-SP4 Update Pack released! This final update pack should be applied to Windows XP installation media immediately after slipstreaming SP4 v3.1b to a Windows XP RTM/SP1/SP2/SP3 source. This will update installation media to May 2019, including every single update released until the POSReady 2009 end-of-life in May 2019. Download available at RyanVM.net.
  13. @everyone FYI, new stuff has been released for XP SP4: 1. A SP4 v3.1b installer that does not install .NET Framework unless absolutely necessary (MCE, Tablet PC). 2. Windows XP SP4 Preinstallation Environment and OEM Preinstallation Kit (OPK) with SCSI drivers integrated 3. An updated MUI ISO with fixes and additions. Check my RyanVM thread for details.
  14. UPDATE - 15 OCT 2018: For novice users that do not want to wait for 20-30 minutes after installing XP SP4 AND rebooting For all .NET haters... A NEW RELEASE OF UNOFFICIAL SP4 3.1B WITHOUT .NET FRAMEWORK This release will not install .NET Framework in both live and slipstreamed install, unless: - Media Center Edition is used -> .NET Framework 1.1 SP1 is installed - Tablet PC Edition is used -> .NET Framework 1.0 SP3 is installed Users can still install .NET FWs of their choice from the Add/Remove Components wizard in Control Panel This alternative SP4 release is called: WindowsXP-USP4-v3.1b-NODOTNET-x86-ENU.exe In addition, XP SP4 OEM Preinstallation Kit ISOs with SCSI drivers, and an updated MUI ISO have been released!
  15. Registry settings to import as a .reg file after installing the latest cumulative IE8 update:
  16. You need to manually install the latest cumulative IE8 update and Office updates before scanning for updates. Updates can be downloaded from the Microsoft Update Catalog website (https://catalog.update.microsoft.com). Just search for posready and sort the updates shown in chronological order.
  17. MSI Error 1603: MSI (c) (30:60) [03:46:21:203]: Note: 1: 1708 MSI (c) (30:60) [03:46:21:203]: Product: Java 8 Update 161 -- Installation failed. MSI (c) (30:60) [03:46:21:203]: Windows Installer installed the product. Product Name: Java 8 Update 161. Product Version: 8.0.1610.12. Product Language: 1033. Installation success or error status: 1603. MSI (c) (30:60) [03:46:21:234]: Grabbed execution mutex. MSI (c) (30:60) [03:46:21:234]: Cleaning up uninstalled install packages, if any exist MSI (c) (30:60) [03:46:21:250]: MainEngineThread is returning 1603
  18. Try the offline installer at https://java.com/en/download/manual.jsp UPDATE: Tried that and it's not working. After some quick debugging it seems that there is an access violation exception related to C runtime implementation. ANTIDEBUGGING related stuff. The resource section includes an MSI file, which cannot install for some reason. Using Orca tto see more info.
  19. After applying the convenience rollup to a base SP1 image you will get the ability to run CheckSUR (System Update Readiness Tool) from inside DISM. The command can only be used online and it is the following one: dism /online /cleanup-image /scanhealth You cannot execute this command offline (on an install.wim image file), if that's what you're talking about.
  20. 1. The update.ses manifest file In a few big updates (like service packs) one may notice the presence of an update.ses file. The purpose of this file is to control package target installation state in different servicing stack conditions. For example, you could define a different behaviour when the servicing stack is of a different version, when the update is deployed online or offline. Ses stands for 'session'. This file controls the CBS session manager. Update.ses is digitally signed by the update.cat file. The same file is used to sign update.mum. Example from Windows 7 SP1: <?xml version="1.0" encoding="UTF-8"?> <Session version="1.0"> <Tasks operationMode="OnlineInstall"> ;Actions to take when installing online. <Phase servicingStack="6.1.7601.17514"> ;Prerequisite servicing stack version for update installation. ;Define target state for the specified package. See DISMAPI Documentation for supported installation states. <package id="Package_for_KB976902~31bf3856ad364e35~amd64~~6.1.1.17514" targetState="Installed"/> </Phase> <Phase exclusive="AllowPending"> <package id="Windows7SP1-KB976933~31bf3856ad364e35~amd64~~6.1.1.17514" targetState="Installed"/> </Phase> </Tasks> <Tasks operationMode="OnlineUninstall"> ;Actions to take when update is being uninstalled. <Phase exclusive="AllowPending"> <package id="Windows7SP1-KB976933~31bf3856ad364e35~amd64~~6.1.1.17514" targetState="Absent"/> </Phase> </Tasks> <Tasks operationMode="OfflineInstall"> <Phase> <package id="Windows7SP1-KB976933~31bf3856ad364e35~amd64~~6.1.1.17514" targetState="Absent"/> </Phase> </Tasks> <Tasks operationMode="OfflineUninstall"> <Phase> <package id="Windows7SP1-KB976933~31bf3856ad364e35~amd64~~6.1.1.17514" targetState="Absent"/> </Phase> </Tasks> </Session> 2. It is not essential to have a package container manifest (_manifest_.cix.xml) if there are no deltas in the update package. If there is no point in creating deltas (e.g. IE11 install package), because this will not save any disk space, then there is no need for adding such a manifest. The payload (files) each MANIFEST file copies to the system is stored in a FOLDER that has exactly the same name as its respective manifest: For example, all files copied by amd64_aagwrapper_31bf3856ad364e35_6.1.7601.17514_none_dd3e751b9f413882.manifest are stored in the directory amd64_aagwrapper_31bf3856ad364e35_6.1.7601.17514_none_dd3e751b9f413882 inside the update package root directory. In this case the sourceName in the MANIFEST file has to be defined explicitly: <file name="agilevpn.sys" destinationPath="$(runtime.drivers)\" sourceName="agilevpn.sys" sourcePath=".\" importPath="$(build.nttree)\"> <securityDescriptor name="WRP_FILE_DEFAULT_SDDL" /> <asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2"><dsig:Transforms xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" /></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha256" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" /><dsig:DigestValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">YscNoSf0j3lviJe7+iOrbrCAzJI/Dwkd+jhKk/XJDKE=</dsig:DigestValue></asmv2:hash></file>
  21. More details about the MUM/ Manifest connection: Some MUM files in the MUM chain may contain references similar to these: ;Create an 'update': a top-level 'bundle' to connect MUM with MANIFEST. <update description="wvpchbus_inf" displayName="wvpchbus_inf" name="INF_wvpchbus"> <applicable disposition="detect"> <detectUpdate> <parent name="wvpchbus_inf"/> ;No prerequisites </detectUpdate> </applicable> <component> <assemblyIdentity buildType="release" language="sv-SE" name="wvpchbus.inf-LanguagePack" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" version="7.1.7600.16393" versionScope="nonSxS"/> </component> </update> This section is responsible for linking the component (MANIFEST) named amd64_wvpchbus.inf-languagepack_31bf3856ad364e35_7.1.7600.16393_sv-se_e01330253ba0e3cd.manifest with the specific MUM file. So, apart from the CAT connection, there is also a link inside the MUM itself. The specified MANIFEST file, in turn, is a trigger for another MANIFEST file, referenced as dependency: <?xml version="1.0" encoding="utf-8" standalone="yes"?> <?Copyright (c) Microsoft Corporation. All rights reserved.?> <assembly xmlns="urn:schemas-microsoft-com:asm.v3" copyright="Copyright (c) Microsoft Corporation. All Rights Reserved." manifestVersion="1.0"> <assemblyIdentity buildType="release" language="sv-SE" name="wvpchbus.inf-LanguagePack" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" version="7.1.7600.16393" versionScope="nonSxS"/> <deployment/> <dependency discoverable="no"> <dependentAssembly dependencyType="install"> <assemblyIdentity buildType="release" language="sv-SE" name="wvpchbus.inf.Resources" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" version="7.1.7600.16393" versionScope="nonSxS"/> </dependentAssembly> </dependency> <rescache xmlns="urn:schemas-microsoft-com:rescache.v1"/> </assembly> This dependency contains everything we've seen previously (file copying, driver install, etc.). Everything is triggered from a single MUM file. It seems it's rather complicated after all. I'll continue to search for patterns in Windows Update packages and report anything significant here.
  22. Windows Update package structure - Part 3: The MUM chaos As if the complexity of the manifest files was not enough, here comes the part that links the manifest files together: component-based servicing. Each manifest is named with the same name as its respective component-file folder in WinSxS. For example, a file named like aa.manifest means that all of its files are copied to winsxs\aa. The packages allow top-level interaction with servicing stack and Windows Update. The servicing stack creates a registry link between each package and components. The way it performs this link is not yet obvious to me. I suspect that the key to the connection is CAT files: (See post #5 below to learn how MUM and MANIFEST files are linked). There exists 1 CAT file for each MUM file. Each CAT must at least contain the hash of each respective mum and have the same file name with it. However, some CAT files include more than one hashes. These correspond to the copied files and the MANIFEST files. A manifest file is thus linked to a MUM file, via its unique catalog file. Update.mum should start like: <?xml version="1.0" encoding="UTF-8"?> ;General, top-level info about the update package (useful for DISM, etc.) <assembly manifestVersion="1.0" description="Windows Virtual PC" displayName="Windows Virtual PC (KB958559)" company="Microsoft Corporation" copyright="Microsoft Corporation" supportInformation="http://support.microsoft.com/kb/958559" xmlns="urn:schemas-microsoft-com:asm.v3"> ;Microsoft-Windows-VirtualPC-Package-TopLevel-MergedCab is the name of the package ;BuildType set to release in most packages ;Be careful of the publicKeyToken. ;DEFINITION of the update.mum package info. Be careful of the MergedCab designation in various update.mum packages. <assemblyIdentity buildType="release" language="neutral" name="Microsoft-Windows-VirtualPC-Package-TopLevel-MergedCab" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" version="7.1.7600.16393"/> ;Package identifier is the KB number. Applicability evaluation controls the Windows Update detection system. ;Sometimes the Permanence=Permanent designation is present, indicating that the update package will be marked as non-removable. ;This XML section means that servicing stack will start processing the update.mum package prerequisites and install other packages. <package identifier="KB958559" applicabilityEvaluation="deep" releaseType="Update" [Permanence="Permanent"]> <parent> ;Check for the presence of prerequisite parent packages. <assemblyIdentity name="Microsoft-Windows-UltimateEdition" version="6.1.7600.16385" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" buildType="release"></assemblyIdentity> ;....Add more prerequisites here </parent> ;Specify the MUM packages this MUM will install: <update name="Microsoft-Windows-VirtualPC-Package-TopLevel"> <package integrate="hidden"> ;Invisible to package manager (DISM) ;Specifies the MUM info (name, processor, publicKeyToken, version) of the package to install ; Now servicing stack will recursively process that MUM file, etc. <assemblyIdentity buildType="release" language="neutral" name="Microsoft-Windows-VirtualPC-Package-TopLevel" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" version="7.1.7600.16393"/> </package> </update> <update name="Microsoft-Windows-vpc-Package-SP1-Restore-Wrapper"> ;Usually a top level optional component package is followed by a respective 'wrapper' <package integrate="hidden"> <assemblyIdentity language="neutral" name="Microsoft-Windows-vpc-Package-SP1-Restore-Wrapper" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" version="6.1.1.17514"/> </package> </update> </package> </assembly> Sometimes MUM files do other stuff like driver installation: <update name="vpcuxd_inf" restart="required"> <applicable disposition="staged"> ; Indicates that servicing stack should stage the driver update and add it to the pending.xml tasks list. <updateDriver elevate="install"> ;In this example, the update that will be processed is not a MUM but a driver INF file (a driver package) ;PublicKeyToken is vital because it identifies the signer. ;Defines the driver update package info for the pending.xml <assemblyIdentity buildType="release" language="neutral" name="vpcuxd.inf" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" type="driverUpdate" version="7.1.7600.16393" versionScope="nonSxS"/> </updateDriver> </applicable> <driver inf="vpcuxd.inf" ranking="normal"> <assemblyIdentity buildType="release" language="neutral" name="vpcuxd.inf" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" type="driverUpdate" version="7.1.7600.16393" versionScope="nonSxS"/> </driver> </update> This completes my presentation of Windows Update packages, at least for now. It would be useful to start working on an update package creator, that will empower advanced users to install whatever they want, however they want.
  23. It's not just the ID of the first delta, it changes throughout the xml file. I will closely examine this. In most cases it is the ID of the previous delta in the XML. This is not the case with some language-specific resource files, however. MSU is an MsZIP archive containing 4 files: a txt, an xml, the wsusscan.cab and the main cab file. We use the term update referring to both the MSU and Main CAB file. The update package per se is the Main CAB file, while the MSU is its Windows Update bundle. Anyway, let's return to the package analysis. After specifiying everything, the package container manifest ends like: </Files></Container> Now, how are all the files copied and how are windows update registry entries added? The .mum and .manifest files do this. Instead of having a single update.inf it's now much more complicated. Example of a .manifest file (with comments): <?xml version="1.0" encoding="UTF-8"?> ;Introduction <assembly xmlns="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0" copyright="Copyright (c) Microsoft Corporation. All Rights Reserved."> ;Specify assembly identity as the name of its winsxs folder: Architecture_Name_PublicKeyToken_version_locale ;IMPORTANT: You cannot change the CAT signature vendor like I did in XP USP4! You must use MS-provided CAT files to install file with the same publickeytoken. <assemblyIdentity name="vpcusb.inf.Resources" version="7.1.7600.16393" processorArchitecture="amd64" language="da-DK" buildType="release" publicKeyToken="31bf3856ad364e35" versionScope="nonSxS" /> ;XML section for file copying: ;file name destinationPath sourcename and sourcepath importPath ;file name: target file name in winsxs ;destinationPath: directory to update with the file. We've lost the simplicity of the LDIDs in INF files. Special directories are designated by $(runtime.xxx) string. ;Examples: $(runtime.drivers), $(runtime.help), $(runtime.system32) More examples could be added here. ;sourcename and sourcepath: Undocumented, use only if there is a different file name definition in package container XML. ;importpath: Undocumented, reverse engineering required to properly understand this. Probably $(build.nttree) represents a temporary location where the delta files are extracted along with the other stuff. ;destinationPath <file name="vpcusb.inf_loc" destinationPath="$(runtime.system32)\DriverStore\da-DK\" sourceName="" sourcePath=".\" importPath="$(build.nttree)\loc\da-dk\mui_infs\vpc\"> ;Security desciptor for SFC. Some reverse engineering will be required for further options. <securityDescriptor name="WRP_FILE_DEFAULT_SDDL" /> ;Verification hashes - section start. <asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2"> <dsig:Transforms xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"> <dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" /> </dsig:Transforms> ;Uses SHA256 for validation. ;Also must be CAT signed with MS certificate. <dsig:DigestMethod xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Algorithm="http://www.w3.org/2000/09/xmldsig#sha256" /> ;BASE64 digest value (SHA256 algorithm) <dsig:DigestValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">xVT51HPqzn0ICbhyK392n198mRihDDTh5yd3muBYZrA=</dsig:DigestValue> </asmv2:hash> </file> ;Specify file info for validation (copy of the previous line) <file name="vpcusb.sys.mui" destinationPath="$(runtime.drivers)\da-DK\" sourceName="" sourcePath=".\" importPath="$(build.nttree)\loc\da-dk\vpc\"> <securityDescriptor name="WRP_FILE_DEFAULT_SDDL" /> <asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2"> <dsig:Transforms xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"> <dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" /> </dsig:Transforms> <dsig:DigestMethod xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" Algorithm="http://www.w3.org/2000/09/xmldsig#sha256" /> <dsig:DigestValue xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">2cJBTne143cft9wMNmJ3b+AEwdV3Tk70cNB59wx71pM=</dsig:DigestValue> </asmv2:hash> </file> ;ACL codes for the winsxs assembly as a whole- Do not touch these ;Operationhint set to "replace" to replace any existing ACL. <trustInfo> ;Designates start of trust info specification section. <security> <accessControl> <securityDescriptorDefinitions> <securityDescriptorDefinition name="WRP_FILE_DEFAULT_SDDL" sddl="O:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464G:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464D:P(A;;FA;;;S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464)(A;;GRGX;;;BA)(A;;GRGX;;;SY)(A;;GRGX;;;BU)S:(AU;FASA;0x000D0116;;;WD)" operationHint="replace" /> </securityDescriptorDefinitions> </accessControl> </security> </trustInfo> <rescache xmlns="urn:schemas-microsoft-com:rescache.v1" /> </assembly> Other sections you could find in manifests: - Service creation (as you know drivers are services): <memberships> <categoryMembership> <id name="Microsoft.Windows.Categories.Services" version="6.1.7600.16393" publicKeyToken="31bf3856ad364e35" typeName="Service" /> <categoryInstance> ;Specify data for service creation (it's should be rather straightforward) <serviceData name="vpcvmm" displayName="@%SystemRoot%\system32\drivers\vpcvmm.sys,-100" errorControl="normal" imagePath="system32\drivers\vpcvmm.sys" start="system" type="kernelDriver" description="@%SystemRoot%\system32\drivers\vpcvmm.sys,-101" startAfterInstall="asynchronous" /> </categoryInstance> </categoryMembership> <categoryMembership> ;Store it as boot critical service. <id name="Microsoft.Windows.Categories" version="1.0.0.0" publicKeyToken="365143bb27e7ac8b" typeName="BootCritical" /> </categoryMembership> </memberships> - Registry (it is straightforward) ;In INF language: HKLM, "SOFTWARE\Microsoft\Assistance\Client\1.0\Namespaces\Windows\en-US\Titles","virtualpc",0,"" ;(Yeah I love Windows XP) <registryKeys> <registryKey keyName="HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Assistance\Client\1.0\Namespaces\Windows\en-US\Titles" owner="false"> <registryValue name="virtualpc" valueType="REG_SZ" value="" operationHint="replace" owner="true" /> <securityDescriptor name="WRP_REGKEY_DEFAULT_SDDL" /> ;Undocumented; reversing required. </registryKey> </registryKeys> To be continued... P.S. For practice, try analyzing the manifests in Windows 7 SP1. Together we'll discover more stuff, more quickly.
  24. It will be rather difficult without some kind of automation. I'd recommend trying to create customized patches rather than a unofficial sp2; there is no point of doing such a thing in modern Windows actually. First of all, Windows 6.x and later updates are deployed in .cab format. Inside the cab file there must be a file named: _manifest_.cix.xml Take a look inside this file with IE preferably: It starts with something like: <?xml version="1.0" encoding="UTF-8"?> <Container name="windows6.1-kb958559-x64-refreshpkg.cab" type="CAB" length="19070059" version="1" xmlns="urn:ContainerIndex"><Description/> Container Name: The name of the CAB file. type="CAB" The type of the file that contains the updates (Set to CAB). length: Length of the update package in bytes Each file is then registered in another XML section called <Files>. Two primary examples: <File length="1872" name="x86_microsoft-windows-virtualpc-additions_31bf3856ad364e35_7.1.7600.16393_none_fa50c45d13592d39.manifest" attr="32" time="128981427337272897" id="1143"><Delta><Source type="RAW" name="x86_microsoft-windows-virtualpc-additions_31bf3856ad364e35_7.1.7600.16393_none_fa50c45d13592d39.manifest"/></Delta></File> <File length="5888" name="amd64_wvpchbus.inf_31bf3856ad364e35_7.1.7601.17514_none_435a07889c1e3a43\wvpchbus.inf" attr="32" time="129347010400000000" id="1116"><Delta><Source type="PA30" name="0"/></Delta></File> <File length="5888" name="amd64_wvpchbus.inf_31bf3856ad364e35_7.1.7600.16393_none_411c23409f399fec\wvpchbus.inf" attr="32" time="128981427800274961" id="1115"><Delta><Source type="PA30" name="1"/><Basis file="1116"/></Delta></File> File length: Target file size, in bytes name: Target file name + extension attr : Decimal code of the file attributes, as defined here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365535(v=vs.85).aspx Source type: RAW or PA30. RAW means that no delta-compression is implemented. PA30 means that the file in the cab file is a delta. Time: A 64-bit time stamp. Shows Win32 FILETIME values count 100-nanosecond intervals since January 1, 1600 UTC. More info: https://blogs.msdn.microsoft.com/oldnewthing/20030905-02/?p=42653 ID: A number identifying the source file in the update package (it is just an index number). name: An index value for the PA30. 0 means first delta, 1 second delta to process and so on. Respective deltas are named the same way in the cab file. <Basis file="1116"/> Not sure what this means, some more research required. To be continued.
  25. @jaclaz I see your point. I have some ethical concerns about current Rebase users, however. It wouldn't make me look good if I gave Rebase for free right now, when they've paid a few bucks for it just a few weeks ago. There are 3 and a half years till Windows 7 support ends. On the other hand, you're right that a few people might be really interested in Rebase if they discover it within the following months. For these few potential buyers, I am sure a private arrangement regarding pricing/support/intended use of the program could be reached.
×
×
  • Create New...