XProfan

Jörg
Sellmeyer

Es wird Roland sicher helfen, wenn du da einen kleinen lauffähigen (!) Beispielcode postest.

XProfan X3
Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...

10.04.2016 ▲

Kompilieren Markieren Separieren

Matthias
Arlt

Da hast Du natürlich recht... Ich habs mal auf das minimalst mögliche "eingedampft". Mit der Unicode-Variante bei Übergabe von Strings bin ich mir nicht mehr zu 100% sicher (deshalb im Eingangs-Beitrag entfernt).
Hinsichtlich des "Fehl-Verhaltens" macht das erstmal eh' keinen Unterschied.

declare file$,modul&,hFind&,hUpdate&
file$ = Pfad zur FreeProfan-Runtime...
modul& = external("KERNEL32","LoadLibraryExA",addr(file$),0,3)
hFind& = external("KERNEL32","FindResourceExA",modul&,2,"TOOLBAR32",0)
external("KERNEL32","FreeLibrary",modul&)

if hFind&

    print hFind&
    hUpdate& = external("KERNEL32","BeginUpdateResourceA",addr(file$),0)
    print hUpdate&
    print external("KERNEL32","UpdateResourceA",hUpdate&,2,"TOOLBAR32",0,0,0)
    print external("KERNEL32","EndUpdateResourceA",hUpdate&,0)

endif

waitkey

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

10.04.2016 ▲

Matthias
Arlt

Ich habe inzwischen das Problem mal näher untersucht. Mit folgendem Ergebnis:
Der Schreibvorgang findet statt und auch die Einträge im Header werden gesetzt bzw. aktualisiert.
Aber:
Die komplette Ressourcen-Sektion wird um einiges nach vorn verschoben (im konkreten Fall um 312 Byte). Damit stimmt natürlich der Rohdaten-Offset im .rsrc-Header nicht mehr. Oder richtiger, der Offset stimmt schon, was die veränderte Position angeht, nur der davor liegende Teil der Datei ist nunmehr zu kurz. Als Workaround verschiebe ich nun die Sektion durch Einfügen von Null-Bytes wieder komplett um den "Fehlbetrag" nach hinten und trage im Header (.rsrc + 20) wieder den korrekten Offset ein. Wodurch es zu dieser Verschiebung kommt, ist mir allerdings noch ein Rätsel...
An der API kann es nicht liegen, die funktioniert ja bei anderen Dateien (nicht FreeProfan) so wie sie soll.

Gruß Matthias

Nachtrag:
Die anfängliche Annahme, bei "FreePascal- oder Lazarus-Derivaten" die Unicode-Variante der API verwenden zu müssen, hat sich als gegenstandslos erwiesen...

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

19.04.2016 ▲

RGH

Ein erster Versuch hat folgendes ergeben:

XProfan X3 und FreeProfan machen exakt das gleiche. Allerdings reagiert eine XProfan-Runtime auf das Löschen der TOOLBAR32-Ressource aus mir noch unerklärlichen Gründen anders, als eine FreeProfan-Runtime! Aus einer XProfan-Runtime lässt sich die Ressource löschen und sie bleibt funktionsfähig, aus einer FreeProfan-Runtime wohl nicht.

Außerdem musste ich feststellen, dass ein gelinktes XProfan-Profan-Programm beim Löschen der Ressource auch seines Profan-Codes beraubt wird und anschließend wie eine Runtime ohne gelinkten Code funktioniert.

Ich schaue weiter ....

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

19.04.2016 ▲

Matthias
Arlt

Schon seltsam, das Ganze. Immerhin hab ich mich dadurch mal eingehender mit dem Innenaufbau der PE's beschäftigt...

...das ein gelinktes XProfan-Profan-Programm beim Löschen der Ressource auch seines Profan-Codes beraubt wird und anschließend wie eine Runtime ohne gelinkten Code funktioniert.

Das ist in etwa das gleiche Verhalten wie bei der UPX-Problematik, bevor Du die "Packer-Unterstützung" nachgerüstet hattest.

Die Komplett-Verschiebung einer Sektion lässt ja vermuten, daß die Größe oder das Ende des vorherigen Codes irgendwie nicht erkannt wird. Die entsprechenden Infos stehen wiederum in den einzelnen Headern. (ob auch noch an anderer Stelle ???)
Vielleicht trotzdem ein Anhaltspunkt für die weitere Suche. Der Verhaltensunterschied FreeProfan vs. XProfan lässt sich damit aber wohl auch nicht erklären...

Immerhin versetzt mein Workaround die Datei wieder in einen funktionsfähigen Zustand. Bei FreeProfan jedenfalls. Eine aktuelle XProfan-Runtime zum Testen hab ich ja nicht.

Gruß Matthias

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

Kompilieren Markieren Separieren

RGH

Das Problem bei UPX war ein anderes: Da ich ein nachträgliches Ändern der Ressourcen ermöglichen wollte, gibt es keine festdefinierte Adresse in der Runtime mehr, an der das Kompilat zu finden ist, sondern ich suche nach dem Start des Programmes nach dem Header des Kompilates. Da ich mit der Suche aber nicht beim Dateanfang begann, sondern erst kurz vor dem Beginn der Ressourcen im unkomprimierten Programm, lief diese Suche nach der Komprimierung ins Leere. So habe ich dann den Beginn der Suche deutlich früher angesetzt.

BTW: Auch FreeProfan hat die neuen Ressourcen-Funktionen von XProfan X3, so dass sich Dein Programm auf folgende Zeilen reduzieren lässt:

declare file$
file$ = "prfrun32.exe"
print res("Change", file$, 2, "TOOLBAR32",0,0,0)
Print "Fertig!"
waitkey

Leider bleibt das Problem beim Löschen der Ressource bestehen.

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

Ich meinte das auch nur von den Auswirkungen her. Das sich das Problem an sich nicht vergleichen lässt, ist schon klar.

BTW: Auch FreeProfan hat die neuen Ressourcen-Funktionen von XProfan X3, so dass sich Dein Programm auf folgende Zeilen reduzieren lässt:

Auch das ist klar. Mir ging/geht es aber darum, daß der schreibende API-Zugriff fehlschlägt. Und das nicht nur beim Löschen, sondern generell, also auch beim Hinzufügen, Ändern etc.

Die API ist ja sozusagen der kleinste gemeinsame Nenner, der immer zur Verfügung steht, auch wenn keine neuere Profan-Version verwendet wird oder überhaupt kein Zugriff aus Profan heraus erfolgt.
ResourceHacker und Co scheinen da dann auch noch etwas anders vorzugehen oder fangen solche Effekte durch weitere Techniken ab...

Gruß Matthias

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

RGH

FreePascal (Lazarus) scheint einen anderen PE-Header zu verwenden, wie Delphi. Leider habe ich da offensichtlich keinen Einfluss darauf und auch in den Compilereinstellungen nichts dazu gefunden.

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

Den Verdacht mit einem anderen Header-Aufbau hatte ich auch schon, bin aber trotz stundenlanger Suche ebenso wenig fündig geworden.

Nachdem ich herausgefunden habe, was genau da passiert und wie das mit geringem Aufwand wieder hinzubiegen ist, ist es ja kein wirklich gravierendes Problem mehr.

Ärgerlicher ist da fast schon, daß Du auch bei XProfan solch unklare Auffälligkeit entdeckt hast...

Gruß Matthias

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

Michael
W.

Das Kompilat wird gesucht...

Läßt es sich nicht als freie (selbstdefinierte) Ressource über die Ressourcenverwaltung zu fassen bekommen?

Alle Sprachen
System: Windows 8/10, XProfan X4
Programmieren, das spannendste Detektivspiel der Welt.

RGH

Ja, die Idee trage ich auch schon eine Weile mit mir herum und werde es wohl in der nächsten Version von XProfan so halten.

Aber das ist hier ja keine Lösung, da sich die FreeProfan-Runtime (und natürlich auch der Interpreter und vermutlich auch andere mit FreePascal kompilierte Exen) offensichtlich nicht mit den Ressourcen-Funktionen der Windows-API bearbeiten lässt, ohne unbrauchbar zu werden. Bislang habe ich da keine Lösung gefunden.

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