Deutsch
Bugs und vermeintliche

FreeProfan Bugs und vermeintliche

FreeProfan32 und API UpdateResource

 
- Seite 1 -



Matthias
Arlt
Bei der Fehlersuche in einem meiner Programme ist mir aufgefallen, dass ein schreibender Zugriff mit "UpdateResource" auf die Runtime (bzw. Interpreter) regelmäßig die Datei unbrauchbar macht. Soweit ich herausgefunden habe, oder dies jedenfalls annehme, wird der Schreibvorgang zwar ausgeführt, aber die Änderung nicht im Header eingetragen... Dies führt dann beim Startversuch der Datei zu unterschiedlichen Fehlermeldungen. Meist "Nur ein Teil der ReadProcessMemory- oder WriteProcessMemory-Anforderung wurde abgeschlossen" oder "Falscher Parameter...".
Es betrifft auch ausschliesslich FreeProfan, die XProfan-Versionen sind von diesem Effekt nicht betroffen.

Gruß Matthias
 
WinXP SP2, Win7 - XProfan 10/11/FreeProfan32 - Xpia
10.04.2016  
 



 
- Seite 4 -


Würde ich nicht drauf warten,

hab ihn schon ein paar mal erfolglos gesucht.
 
22.04.2016  
 




RGH
Matthias Arlt (22.04.2016)
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
22.04.2016  
 




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

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
22.04.2016  
 




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
22.04.2016  
 




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
27.04.2016  
 




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
27.04.2016  
 



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.
 
27.04.2016  
 




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
27.04.2016  
 




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
27.04.2016  
 




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
27.04.2016  
 




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
27.04.2016  
 




Antworten


Thementitel, max. 100 Zeichen.
 

Systemprofile:

Kein Systemprofil angelegt. [anlegen]

XProfan:

 Beitrag  Schrift  Smilies  ▼ 

Bitte anmelden um einen Beitrag zu verfassen.
 

Themenoptionen

66.615 Betrachtungen

Unbenanntvor 0 min.
Sven Bader16.09.2021
Rainer Hoefs12.07.2019
p.specht20.12.2018
Walter23.05.2018
Mehr...

Themeninformationen



Admins  |  AGB  |  Anwendungen  |  Autoren  |  Chat  |  Datenschutz  |  Download  |  Eingangshalle  |  Hilfe  |  Händlerportal  |  Impressum  |  Mart  |  Schnittstellen  |  SDK  |  Services  |  Spiele  |  Suche  |  Support

Ein Projekt aller XProfaner, die es gibt!


Mein XProfan
Private Nachrichten
Eigenes Ablageforum
Themen-Merkliste
Eigene Beiträge
Eigene Themen
Zwischenablage
Abmelden
 Deutsch English Français Español Italia
Übersetzungen

Datenschutz


Wir verwenden Cookies nur als Session-Cookies wegen der technischen Notwendigkeit und bei uns gibt es keine Cookies von Drittanbietern.

Wenn du hier auf unsere Webseite klickst oder navigierst, stimmst du unserer Erfassung von Informationen in unseren Cookies auf XProfan.Net zu.

Weitere Informationen zu unseren Cookies und dazu, wie du die Kontrolle darüber behältst, findest du in unserer nachfolgenden Datenschutzerklärung.


einverstandenDatenschutzerklärung
Ich möchte keinen Cookie