XProfan

Infinity-Profan
WinXP, SP3, Core(TM) i7-3770 @ 3.40GHz

- Seite 4 -

Würde ich nicht drauf warten,

hab ihn schon ein paar mal erfolglos gesucht.

Matthias Arlt (22.04.2016)

RGH

Hm...so interessant das zunächst schien mit der XPRC-Ressource...
Ein Packen der Runtime ist dadurch aber wohl unmöglich geworden.

Wieso? Solange die Ressourcen nicht mitgepackt werden, sollte es sogar mit dem fertigen Programm möglich sein. (Testen kann ich es im Moment nicht, da ich keinen EXE-Packer installiert habe.)

Gruß
Roland

XProfan X3
Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Kompilieren Markieren Separieren

RGH

Nun habe ich mir UPX (neueste Version von 2013?) heruntergeladen und probiert:

upx resexplorer.exe --compress-resources=0

Ein mit der neuesten Version von FreeProfan32 kompiliertes Programm (hier: resexplorer.exe) läßt sich problemlos komprimieren.

Die PRFRUN32.EXE vor dem Kompilieren zu komprimieren funktioniert leider nicht.

Gruß
Roland

XProfan X3
Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Matthias
Arlt

Hallo Roland,
Asche auf mein Haupt, genauso ist es auch. Ich hatte erstens die früheren Parameter für UPX verwendet, also auch Ressourcen-Komprimierung. Das war noch so im Kleinhirn verankert. Und zweitens wohl auch zwischendurch mal die 'falsche' Runtime erwischt...
Einige testweise gepatchte Versionen hatte ich zum Vergleich noch aufgehoben und dann wohl durcheinander gebracht...

Also Entwarnung, was das Packen angeht.

Allerdings schlagen nun wieder die API-Funktionen fehl. Bei der fertigen (natürlich ungepackten) Exe verschwindet bei jedem Zugriff die XPRC-Ressource. Die Datei bleibt ansonsten funktionsfähig, verhält sich aber wie eine unverlinkte Runtime. Selbst schon ein FindResource zur Feststellung, ob XPRC überhaupt vorhanden, läuft meist ins Leere.

Ich bin deshalb doch erstmal zur gepatchten Vorgängerversion zurückgekehrt. Das funktionierte ja dann nach den Offset-Korrekturen gut und systemkonform.

WinXP SP2, Win7 - XProfan 10/11/FreeProfan32 - Xpia

Matthias
Arlt

Mein vorläufiges Fazit nach weiteren umfangreichen Tests:

Wenn es möglich ist, würde ich es begrüssen, wenn es bei der bisherigen Form bliebe. Also ohne XPRC als Ressource. Warum:
Bisher muss sich der Anwender, wenn die EXE bearbeitet werden soll, lediglich um die Runtime kümmern. Und ist dabei auch eigentlich keinen Einschränkungen unterworfen. D.h. die Datei verhält sich systemkonform, wie jede EXE, auch für Dritt-Programme.

Bei der Variante mit XPRC-Ressource kann/muss ich zur Ressourcen-Bearbeitung die Runtime ändern, kann diese aber nicht packen. Will man das Ganze packen, ist die verlinkte Runtime zu bearbeiten. Allerdings mit der Einschränkung, die Ressourcen nicht packen zu dürfen. Letzteres kann aber ein ausschlaggebender Grund sein, überhaupt packen zu wollen.

Man muss also letztlich, um im Grunde ein und dasselbe zu erreichen, zweimal "Hand anlegen", einmal vor und einmal nach der Kompilierung. Weil es prinzipbedingt Einschränkungen gibt, die es so vorher nicht gab.

Die EXE verhält sich damit auch aus der "Sicht" von Dritt-Programmen atypisch, sprich unerwartet (oder unkalkulierbar). Das erschwert erheblich z.b. das Schreiben von Programmen, die per API auf den Datei-Inhalt zugreifen. (Die Executable ist ja selbst zuweilen auch Gegenstand der Bearbeitung.)

Das ist insoweit erstmal nur meine subjektive Ansicht. Ich hoffe aber, dass dabei rüber gekommen ist, worum es mir dabei geht.
Aus Anwender-Sicht dürften die (möglichen) Vorteile einer PRC als Ressource doch eher gering sein. Zumindest sehe ich sie momentan nicht. Ob es programmiertechnisch so gewaltige Vorteile bringt, kann ja nur Roland beurteilen...

Gruss Matthias

WinXP SP2, Win7 - XProfan 10/11/FreeProfan32 - Xpia

26.04.2016 ▲

RGH

Beim bisherigen Verfahren kann es aber eigentlich nicht bleiben, weil z.B. ein Entfernen einer Ressource aus einem fertigen Programm, dieses unbrauchbar macht, weil der nicht erwartete "Annhang", nämlich der einfach angehängten Profancode (PRC-Datei), dabei zerstört wird.
Zum anderen macht eine komprimierte Runtime Probleme bei den neuen Ressourcenfunktionen, wie auch beim $RES, mit dem beim Kompilieren Ressourcen eingebunden werden.

Das jetztige Verfahren mit dem Kompilat als Ressource hat den Vorteil, dass alle Ressourcen-Funktionen völlig problemfrei funktionieren, weil es keine "Fremdkörper" (angehängter Programmcode) im fertigen Programm gibt. Es können dem fertigen Programm sogar noch Ressourcen hinzugefügt, geändert oder entfernt werden, auch wenn selbst das nicht mehr nötig ist, da das ja alles schon über $RES erledigt werden kann.

Gruß
Roland

XProfan X3
Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Matthias
Arlt

weil z.B. ein Entfernen einer Ressource aus einem fertigen Programm, dieses unbrauchbar macht, weil der nicht erwartete "Anhang", nämlich der einfach angehängten Profancode (PRC-Datei), dabei zerstört wird.

Aus genau diesem Grund gehe ich bislang folgendermaßen vor:

- Offset an $80/$24 lesen und feststellen, ob PRC vorhanden
- wenn vorhanden, Runtime und PRC temporär separieren (PRC bleibt gleich im RAM)
- Ressourcen-Update per API ausführen (was auch immer...)
- Den nunmehr veränderten Offset an $80/$24 eintragen
- PRC wieder anhängen

Die PRC ist damit in den Update-Vorgang überhaupt nicht involviert. Und was ich dabei mit der temporär separierten Runtime (oder der Nicht-Profandatei) sonst noch anstelle oder auch nicht, steht in meinem Belieben...
Alles in Allem eine schnelle und saubere Sache, die immer problemlos funktioniert(e).

Ich weiss nun natürlich nicht wie die $RES-Funktionen intern umgesetzt sind.

Gruß Matthias

WinXP SP2, Win7 - XProfan 10/11/FreeProfan32 - Xpia

Infinity-Profan
WinXP, SP3, Core(TM) i7-3770 @ 3.40GHz

Gäbe vlt. noch eine Möglichkeit.

Statt die PRC als Res anzuhängen oder (wie bisher) als "blinder Passagier", direkt in den Opcodes-Teil der Exe kopieren so als wäre es auch nativer Code. Wenn ich mich recht erinnere, müsste dafür in der Exe nur etwas Platz geschaffen werden und 1 - 2 Summen im PE-Header angepasst.

Also vlt. mit Delphi oder FreePascal ein Hallo Welt schreiben mit bisl inline-ASM (z.B. 1000 xor eax,eax) und dann nochmal eins mit 2000 xor eax,eax und dann schauen wo die Unterschiede in der Exe-Datei lungern.

Habs sicher wieder mistig erklärt.

Vielleicht wundert sich dann auch UPX über Bytes die keinen Opcodes entsprechen - vielleicht interessiert es UPX aber auch nicht z.B. wenn er eh der Exe einen neuen PE-Overhead verpasst. Das bliebe dann aber auszutesten.

RGH

Der Eintrag an den genannten Offsets wird ab XProfan X3 ja nicht mehr benötigt, da das Kompilat ja nun gesucht wird. Allerdings hatte ich in Version X3 versäumt, das nun sinnfreie Setzen dieses Offsets herauszunehmen. Das wird in der nächsten Version geschehen. Erst dadurch, dass das Kompilat nun gesucht wird, lässt sich nun das fertige Programm komprimieren, ohne dass es seine Lauffähigkeit verliert. (Außerdem fühle ich mich wohler, wenn ich jetzt nicht mehr eine Speicherstelle im Header beschreibe, deren Verwendung nicht dokumentiert ist.)

Gruß
Roland

XProfan X3
Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

RGH

Wie wird $RES intern gehandhabt?

Das macht der Compiler:

Neu:

1. PRFRUN32.EXE wird nach MEINPROGRAMM.EXE kopiert.
2. Die Ressourcen der mit $RES angegebenen *.RES-Dateien werden hinzugefügt, bzw. geändert.
3. Das Kompilat wird als Ressource hinzugefügt. FERTIG!

Bis X2 (Runtime liest Offset):

1. PRFRUN32.EXE wird nach MEINPROGRAMM.EXE kopiert.
2. Das Kompilat wird dazu kopiert (hinten dran gehängt).
3. Das Offset zum Kompilat wird in eine hoffentlich ungenutze Stelle des Headers (4 Byte) eingetragen. FERTIG.

In X3/X3.1 (Runtime sucht Kompilat):

1. PRFRUN32.EXE wird nach MEINPROGRAMM.EXE kopiert.
2. Die Ressourcen der mit $RES angegebenen *.RES-Dateien werden hinzugefügt/geändert.
3. Das Kompilat wird dazu kopiert (hinten dran gehängt).
4. Das Offset zum Kompilat wird nun überflüssigerweise in eine hoffentlich ungenutzte Stelle des Headers (4 Byte) eingetragen. FERTIG.

Bis einschließlich X2.x kann ein fertiges Programm nicht komprimiert werden, auch ein Hinzufügen oder Entfernen von Ressourcen ist nicht möglich.

Ab X3 gibt es aber Funktionen und Befehle, um Ressourcen in Programmen und DLLs zu verändern. Das soll natürlich auch für mit XProfan erstellte Programme möglich sein. Daher wird der Startpunkt des Kompilats nun gesucht. Nebeneffekt: Das fertige Programm ist nun auch komprimierbar.

Ein Problem ist allerdings aufgetaucht: Beim Löschen einer Ressource aus einem fertigen Programm verschwindet das Kompilat. Das da noch etwas hinten dran hängt, ist wohl nicht vorgesehen. Das Problem wird mit dem Kompilat als Ressource sauber gelöst. Es gibt ja keinen Fremdkörper mehr.

Gruß
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Matthias
Arlt

Das Problem wird mit dem Kompilat als Ressource sauber gelöst.

Und genau dies ist eben nicht so:

- Datei funktioniert als fertiges Programm
- res("Change", "TEST.EXE", 2, "TOOLBAR", 0, 0, 0)
- Datei funktioniert immer noch, aber als unverlinkte Runtime, denn:
- Die BITMAP-Ressource "TOOLBAR" ist zwar entfernt, die XPRC aber auch !

Gruß Matthias

WinXP SP2, Win7 - XProfan 10/11/FreeProfan32 - Xpia

RGH

Ich fürchte, Du hast nicht die neueste Version benutzt. Wie auch, da ich sie noch nicht hochgeladen habe. Ich werde das gleich mal nachholen ... jetzt ist die aktuelle Version von FreeProfan32 hochgeladen.

Das Löschen einer Ressource sollte keinesfalls irgendeine andere Ressource betreffen können!

Ich nehme an, bei Deiner Version wurde das Kompilat noch gar nicht als Ressource verlinkt, sondern noch angehängt.

Zumindest habe ich das Ganze mit der soeben hochgeladenen Version noch getestet. Auch nach dem Entfernen der Toolbar bleibt das Programm wie gewohnt lauffähig!

Gruß
Roland

XProfan X3
Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4