[Blockierte Grafik: http://wp.xin.at/wp-content/uploads/2014/05/hackxp-logo.png]
Gekürzte Fassung. [Originalversion].
Für Schnellentschlossene:
Wer nachfolgende Hacks nicht selbst durchführen, sondern modifizierte Backports wie unmodifizierte Updates von mir beziehen möchte, kann [hier vorbeischauen], wo die Updates und einige Links+Infos dazu bereitstehen.
Hintergrundinformationen und gescheitertes:
Microsoft mag die offizielle Unterstützung für Windows XP zwar eingestellt haben, aber dennoch ist nicht von der Hand zu weisen, daß Windows XP Pro x64 Edition eine breite Codebasis mit Server 2003 x64 teilt, welcher noch in den Genuß von Updates bis in den Juli 2015 kommen darf.
Um zu verhindern, daß Benutzer einfach Server 2003 Updates recyclen um XP x64 auf aktuellem Stand zu halten, wurde eine Modifikation in den INF Dateien der Updates eingebracht:
[Prereq.XPAMDInstallBlock.Section] PresentOp=CheckReg,HKLM,"SYSTEM\CurrentControlSet\Control\ProductOptions",ProductType,0x00000000 NotEqualOp=CheckReg,HKLM,"SYSTEM\CurrentControlSet\Control\ProductOptions",ProductType,0x00000000 Display_String="%WrongProductMessage%"
Mit folgendem als Resultat:
[Blockierte Grafik: http://wp.xin.at/wp-content/upl…stall-error.png]
Der Versuch, ein Update zu installieren, das zwar für XP x64 gebaut wurde, aber per INF geblockt ist.
Entpackt man ein solches Update mit 7zip oder WinRAR und ändert die INF Datei ab, wird die Installation aber verweigert, weil die INF Dateien durch kryptographische Signaturen in den beiliegenden Katalogdateien (*.cat) gesichert sind. Ändert man die betreffende INF Datei einfach ab, quittiert der Updater ebenso den Dienst, da die Signaturverifikation fehlschlagen muß:
[Blockierte Grafik: http://wp.xin.at/wp-content/upl…l-inf-error.png]
Ein ändern der INF Datei führt nur zu neuen Problemen. Soweit hat Microsoft leider schon noch mitgedacht.
Es gilt also, den im Updatearchiv befindliche Patcher update.exe zu fixen.
http://wp.xin.at/wp-content/uploads/2014/05/IDA_1.png http://wp.xin.at/wp-content/uploads/2014/05/IDA_2.png
Links zu sehen die verantwortliche Funktion IsInfFileTrusted im Disassembler IDA. Rechts ein Versuch, Binärcode durch Patchassembly zu erzeugen. Ein Einfplegen von Binärode, der dafür sorgen sollte, daß die Funktion immer True zurückgibt so wie [hier in einem Patch für Server 2003 32-Bit zu sehen] ist mir aber nicht gelungen. Viel zuwenig Skill. (Klicken zum Vergrößern)
Wie es richtig gemacht wird:
Nachdem mein Disassembler + Hex Editor Abenteuer also gescheitert ist, fand ich die finale Lösung [hier] in RyanVMs Forum. Wieder handelt es sich um einen Binärpatch von update.exe. Hier die Änderungen mit Offsets, altem Wert und neuem Wert:
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
Alles anzeigen
Man öffne also die Datei update.exe mit einem Hex Editor und springe zu Offset 0x00016A90 bzw. $16A90, wo man dann das hier zu sehen bekommt (die zu ändernden Teile sind hier schon markiert):
http://wp.xin.at/wp-content/uploads/2014/05/XVI32_01.png
Update.exe Version 6.3.4.1, unverändert. (Klicken zum Vergrößern)
Und jetzt ändern wir die PreRequisite Strings so ab, daß da einfach irgendein Unsinn steht, der nicht erkannt werden kann:
http://wp.xin.at/wp-content/uploads/2014/05/XVI32_02.png
Strings durch Blödsinn ausgetauscht. Und speichern! (Klicken zum Vergrößern)
Nun kann man die Datei update.exe ausführen, und das ganze wird auch funktionieren:
http://wp.xin.at/wp-content/uploads/2014/05/install.png http://wp.xin.at/wp-content/uploads/2014/05/install-done.png
Installation des Updates mittels hacked update.exe. (Klicken zum Vergrößern!)
Daß das ganze auch tatsächlich klappt, läßt sich dadurch verifizieren, daß man die Dateiversionen vor der Installation und nach der Installation und ggf. Reboot prüft, in diesem Fall handelt es sich dabei nur um eine Bibliothek, und zwar die shlwapi.dll:
http://wp.xin.at/wp-content/upl…wapi-before.png http://wp.xin.at/wp-content/upl…lwapi-after.png
Erfolg! (Klicken zum Vergrößern)
Natürlich könnte man die Dateien aus den entpackten Updates von Microsoft auch einfach händisch über die bestehenden kopieren, wo möglich. Das ist allerdings alles andere als sauber, weswegen ich eine bessere Lösung angestrebt habe, bei der die Updates auch deinstallierbar bleiben und sauber im System registriert sind. Maßgeblich für den Erfolg war weit weniger mein Disassembly, als die Arbeit der User aus dem RyanVM Forum, allen voran des Users 5eraph.
Wenn man all das hier nicht selber machen möchte, kann man auch einfach [5eraphs eigene Updatesammlung] für Windows XP Pro x64 Edition verwenden, die immer noch gewartet und mit Server 2003 Updates wie hier gezeigt verstärkt wird. Dann muß man auch nicht selbst mit einem Hexeditor hantieren (was ich aber wohl weiterhin so machen werde).
Betroffen sind übrigens nicht alle Updates, da sich Internet Explorer Patches und Updates für .Net bislang scheinbar ganz normal installieren lassen. Dort wo das Problem allerdings auftritt, läßt es sich auch fixen!
Ein schönes weiteres Jahr mit quasi-Support für Windows XP x64 wünsche ich. Und nein, ich übernehme keine Garantien. 5eraph übrigens wohl auch nicht.
(Sollte dieser Beitrag im News Forum als unpassend angesehen werden, könnte er vielleicht in den Softwarebereich verschoben werden. Ich war mir mit der Positionierung nicht ganz sicher.)
Besonderer Dank muß 5eraph gelten, sowie dem Hoster RyanVM und zur Ehrerbietung vor klarem Skill dem Windows Hacker Remko Weijnen!
http://creativecommons.org/licenses/by-nc…0/at/deed.de_AT
Alle Informationen in diesem Beitrag von Michael Lackner stehen unter einer [Creative Commons Namensnennung-NichtKommerziell-Weitergabe unter gleichen Bedingungen 3.0 Österreich Lizenz].