Ergebnis eines Funktionsaufrufs eines anderen Programms verändern

Dalai

Grand Admiral Special
Mitglied seit
14.06.2004
Beiträge
7.420
Renomée
262
Standort
Meiningen, Thüringen
Hallo Leute,

ich hab heute eine Frage an die Programmiercracks unter euch. Ich möchte folgendes erreichen: wenn ein bestimmtes Programm den Ort der Eigenen Dateien abfragt, möchte ich das Ergebnis dessen modifizieren. Dabei sollen aber alle anderen Programme nicht beeinflusst werden, sondern nur dieses eine.

Hintergrund ist, dass es mir inzwischen richtig auf den Sack geht, dass viele Spiele meinen, sich in den Eigenen Dateien niederlassen zu müssen und man bis auf sehr wenige Ausnahmen keine Möglichkeit hat, das zu ändern 8-(. Eigene Dateien gehört mir und NUR MIR!

Klar könnte ich - sofern meine Eigene Dateien-Partition NTFS wäre - Symlinks/Junctions dorthin erstellen, wo ich den Kram gerne hätte. Nur liegen dann eben immernoch die Links dort, die ich dort nicht sehen und haben will.

Ist sowas möglich? Wenn ja, wie müsste ich vorgehen?

MfG Dalai
 
Tja ich mach das anders. Meine eigenen Dateien liegen woanders (überhaupt nirgendwo auf C:, sondern auf D: und E: ), den Ordner "Eigene Dateien" dürfen sich die Spiele nehmen, wie sie lustig sind, ich seh das als Systemordner. Sozusagen des Rechners eigenen Dateien, nicht meine. So muß ich nur ab und zu mit dem Datenvertikutierer durch gehen, wenn es zu sehr zugewuchert ist, ansonsten stören mich die diversen irgendwie angelegten Dateien nicht, weil ich gar nicht hinschaue.
 
Tja ich mach das anders. Meine eigenen Dateien liegen woanders (überhaupt nirgendwo auf C:, sondern auf D: und E: )
Bei mir liegt auch nix auf C:, denn das ist meine Boot-Partition, D: ist Windows-Partition und E: ist Datenpartition, auf die eben auch Eigene Dateien verweist. Es störte mich nicht, wenn die Spiele ihre Daten wie alle anderen Programme in den Anwendungsdaten hinterlegen würden, wo sie IMO hingehören. Eigene Dateien ist ein Verzeichnis für den Benutzer und nicht für Programmdaten.

Ergänzung: Es störte mich auch nicht besonders, wenn alle Spiele in dasselbe Verzeichnis speichern würden, aber leider kocht da jeder Programmierer/Publisher sein eigenes Süppchen und das nervt!

[...] ansonsten stören mich die diversen irgendwie angelegten Dateien nicht, weil ich gar nicht hinschaue.
Mich schon, weil ich eben auf dieser Partition arbeite.

MfG Dalai
 
Zuletzt bearbeitet:
Je nachdem wie das Programm sich den "Eigene Dateien" bzw. Personal Ordner zusammen stickt muss man anders vorgehen.

Vermutlich werden aber die meisten Programm mit
User Shell Folders\Personal Entry arbeiten.
Bei der weiteren Beschreibung User Shell Folders\Personal Entry kann man lesen, dass hierfür die API Funktion SHGetFolderPath() zuständig ist.
Weitere Nachforschungen in der MSDN ergeben, dass SHGetFolderPath veraltet ist. Vermutlich soll man jetzt eher SHGetKnowFolderPath oder IKnownFolder::GetPath verwenden.
Aber egal beide Funktionen liegen in der Shell32.dll.

Mögliche Lösungen die mir jetzt einfallen sind
1. Man könnte also nun temporär die Registry ändern. (Beispiel: sehr komfortabel bei PortableAppsPutty)
2. Man könnte eine wrapper shell32.dll irgendwo in den Pfad legen so dass diese nur beim Start vom Spiel verwendet wird. Diese kann dann die geforderte Änderung des Personal Folders veranlassen und den Rest einfach an das System durch reichen.
 
Ich nehme schon an, dass die fraglichen Programme/Spiele API-Funktionen benutzen, um diese Verzeichnisse zu ermitteln, vermutlich in erster Linie SHGetSpecialFolderLocation und/oder SHGetFolderLocation. MS verweist ja auch immer - zu Recht - darauf, dass man Registry für solche Sachen links liegen lassen und die API-Funktionen vorziehen soll.

1. Man könnte also nun temporär die Registry ändern. (Beispiel: sehr komfortabel bei PortableAppsPutty)
Ich bin mir unsicher, ob das etwas bringt, weil man normalerweise noch irgendeine Funktion rufen muss, damit Windows merkt, dass da etwas geändert wurde und das an die Programme weiterreichen kann. Anyways: das betrifft alle Programme und kommt deshalb nicht wirklich in Frage.

2. Man könnte eine wrapper shell32.dll irgendwo in den Pfad legen so dass diese nur beim Start vom Spiel verwendet wird. Diese kann dann die geforderte Änderung des Personal Folders veranlassen und den Rest einfach an das System durch reichen.
Mmh, interessant. Aber wie stellt man sowas an?

MfG Dalai
 
Ich denke dieser Artikel gibt einiges zu diesem Thema her. Er zeigt aber noch weitere Möglichkeiten. Die von mir genannte ist im Abschnitt "Interception mechanisms" -> "Proxy DLL (Trojan DLL)" - der Weg über die IAT ("Spying by altering of the Import Address Table") wäre auch noch ganz interessant.
Der Artikel ist sehr Umfangreich und bietet so einige einstiegs Möglichkeiten.
Seit Windows Vista (teilweise auch mit WindowsXP SP3)wurde aber einiges an der Sicherheit von Windows geschraubt mit dem bestimmte API´s und DLL´s besonders geschützt sind. Der Artikel ist leider alt und berücksichtigt das nicht.
 
Puh, das ist ne Menge Arbeit, da durchzusteigen, auch wenn die Richtung sicher richtig ist. Bevor ich das gerafft habe, ist wieder Weihnachten (welches Jahr, lass ich mal außen vor ;)). Und vom Kapieren allein ist es ja nicht getan, denn umzusetzen gilt es das ja auch noch...

Daher habe ich mich entschieden, die eh vorhandene Funktionalität meines bevorzugten Dateimanagers Total Commander zu nutzen: die Ignorierliste, mit der man Dateien/Verzeichnisse ausblenden kann. Falls ich doch mal an fragliche Verzecihnisse ran muss, hilft ein Button mit dem Kommando cm_SwitchIgnoreList, der besagte Liste temporär ein-/ausschaltet.

Diese "Lösung" hilft zwar gar nicht gegen die dort liegenden und Speicherplatz belegenden Daten der Spiele, aber es ist innerhalb von Sekunden umgesetzt. Falls jemand noch eine andere einfachere programmiertechnische Lösung hat, immer her damit.

MfG Dalai
 
Du solltest auch noch mal genau angeben für welches konkrete Betriebssystem von Windows du das nun haben möchtest. Das macht bei der Umsetzung nämlich auch einiges aus.
Für WindowsXP mag es da nämlich evtl. schon etwas fertiges geben.

---EDIT: IST NICHT ANWENDBAR FÜR DIESEN FALL---
Was evtl. mal interessant wäre, vermutlich aber zu einem Fehler führen wird.
Wenn du alle benötigten dlls bis auf shell32.dll in ein Verzeichnis kopierst. Dieses (und nur dieses) Verzeichnis dann als dynamisches LoadLibrary Verzeichnis für dein Programm einträgst. Dabei bitte die Anweisungen hier beachten.
---

Ich habe mal diesen Artikel ausprobiert. Dabei habe ich für das Game warzone2100, welches gewöhnlich (ohne Parameter) seine Daten in das "Persönliche" Verzeichnis schreibt einen wrapper für shfolder.dll erstellt.
Trauriger weiße legt er nur kurz zwei Verzeichnisse unter C:\temp (so wollte ich das) an den Rest schreibt er dann wieder in das "Persönliche" Verzeichnis.
Wie ich ich dann weiter herausgefunden habe, liegt das vermutlich daran, dass shell32.dll bereits irgendwo geladen ist und daher meine 2. proxy shell32.dll gar nicht erst geladen bzw. verwendet wird. Andererseits gab es bei der proxy shell32.dll Erstellung einige Probleme die evtl. auch dazu beigetragen haben. In dem Artikel ist am Ende noch eine kurze Diskussion ("Drawbacks") dort wird vermutlich genau das Problem mit zu System nahen dlls beschrieben.
 
Zuletzt bearbeitet:
Du solltest auch noch mal genau angeben für welches konkrete Betriebssystem von Windows du das nun haben möchtest. Das macht bei der Umsetzung nämlich auch einiges aus.
Im Moment Windows XP.

Für WindowsXP mag es da nämlich evtl. schon etwas fertiges geben.
Das wäre schön, aber ich weiß überhaupt nicht, wonach ich suchen soll, um etwas in der Richtung zu finden.

MfG Dalai
 
Ich habe mal diesen Artikel ausprobiert. Dabei habe ich für das Game warzone2100, welches gewöhnlich (ohne Parameter) seine Daten in das "Persönliche" Verzeichnis schreibt einen wrapper für shfolder.dll erstellt.
Trauriger weiße legt er nur kurz zwei Verzeichnisse unter C:\temp (so wollte ich das) an den Rest schreibt er dann wieder in das "Persönliche" Verzeichnis.
Wie ich ich dann weiter herausgefunden habe, liegt das vermutlich daran, dass shell32.dll bereits irgendwo geladen ist und daher meine 2. proxy shell32.dll gar nicht erst geladen bzw. verwendet wird. Andererseits gab es bei der proxy shell32.dll Erstellung einige Probleme die evtl. auch dazu beigetragen haben. In dem Artikel ist am Ende noch eine kurze Diskussion ("Drawbacks") dort wird vermutlich genau das Problem mit zu System nahen dlls beschrieben.
Dieser Beitrag wurde zeitlich falsch eingestellt und kommt hierher.

Ich muss noch dazu sagen ich habe nicht den weg mit dem Umbennenen und modifizieren des Executables mit einem Hexeditor versucht. Sondern die neuen DLLs in das Programm (bzw. CurrentDir) gelegt, damit sie zuerst geladen werden können.
Das Problem mit der shell32.dll könnte man daher vielleicht doch dadurch umgehen, in dem man das executable mit dem Hexeditor verändert und dann eine zB shel42.dll (also so wie im Artikel) lädt. Zum Ausliefern ist so ein Lösung aber nichts. Besser wäre eben der Weg dass man nur die dll´s in das Programmverzeichnis kopiert.
 
Zuletzt bearbeitet:
Ich habe den verlinkten Artikel bzgl. der Proxy DLL jetzt mal nachvollzogen und hatte dabei einige Anlaufschwierigkeiten, weil dumpbin zu Beginn ums Verrecken keinen Output erzeugen wollte, bis ich rausfand, dass ihm eine DLL fehlte, die in einem anderen Verzeichnis von Visual C++ Studio 2008 liegt - MS mal wieder :]...

Nun scheitere ich am Punkt 3 des Artikels: Compile the code. Ich habe gezogen und installiert: Python 2.4.4 und Bakefile 0.2.9 (Version 0.2.2 gibt auch nicht mehr her). Die Meldung bezieht sich auf ein fehlendes wxBase, was ich bisher nicht in der Lage war, zu finden; bzw. nur im Source-Code, aber wenn ich erst etwas kompilieren muss, um etwas kompilieren zu können, nimmt das u.U. kein Ende und ich verliere ganz schnell die Lust...

Sorry, ich kenn mich mit den C(++)-Umgebungen nicht wirklich aus, daher komme ich an der Stelle erstmal nicht weiter. Wie bist du denn vorgegangen?

MfG Dalai
 
Zuletzt bearbeitet:
Ich habe den verlinkten Artikel bzgl. der Proxy DLL jetzt mal nachvollzogen und hatte dabei einige Anlaufschwierigkeiten, weil dumpbin zu Beginn ums Verrecken keinen Output erzeugen wollte, bis ich rausfand, dass ihm eine DLL fehlte, die in einem anderen Verzeichnis von Visual C++ Studio 2008 liegt - MS mal wieder :]...
Also ich verwende 2010 aber auch 2008 macht normal keine Probleme solang man den Visual Studio Command Prompt verwendet. Dann sind in der Regel alle nötigen Pfadangaben vorhanden und die tools funktionieren.

Nun scheitere ich am Punkt 3 des Artikels: Compile the code. Ich habe gezogen und installiert: Python 2.4.4 und Bakefile 0.2.9 (Version 0.2.2 gibt auch nicht mehr her). Die Meldung bezieht sich auf ein fehlendes wxBase, was ich bisher nicht in der Lage war, zu finden; bzw. nur im Source-Code, aber wenn ich erst etwas kompilieren muss, um etwas kompilieren zu können, nimmt das u.U. kein Ende und ich verliere ganz schnell die Lust...
Also ich habe nicht Python 2.4.4 geladen, sondern gleich die neueste stabile Version der Version 2 genommen (also 2.7.x) . Bakefile habe ich zwar geladen und installiert aber mich entschieden das lieber komplett selber mit einem neuen Visual Studio Projekt zu machen.

Ich könnte dir mal das Projekt von Visual Studio 2010 schicken. Hat dann ja keinerlei Abhängigkeiten und sollte so dann auch bei dir funzen. Visual Studio 2008 habe ich leider momentan nicht mehr installiert.

Sorry, ich kenn mich mit den C(++)-Umgebungen nicht wirklich aus, daher komme ich an der Stelle erstmal nicht weiter. Wie bist du denn vorgegangen?

MfG Dalai
Schickst mir ne priv. Mitteilung oder per mail.
 
Also ich verwende 2010 aber auch 2008 macht normal keine Probleme solang man den Visual Studio Command Prompt verwendet.
Ja, OK, dort geht das wohl. Aber da ich keine Ahnung von sowas habe (weil ich sonst mit Delphi arbeite), hab ich eine normale CMD benutzt und dort ließ sich die dumpbin nicht aufrufen. Dies ist aber nötig, damit das Python-Skript arbeitet.

Also ich habe nicht Python 2.4.4 geladen, sondern gleich die neueste stabile Version der Version 2 genommen (also 2.7.x) .
Python 2.6.6 hat irgendwas als deprecated gemeldet in dem Python-Skript und deshalb hab ich's nochmal mit einer älteren Version probiert. Dass es dann immernoch nicht ging, lag an der fehlenden DLL für dumpbin.

[...] aber mich entschieden das lieber komplett selber mit einem neuen Visual Studio Projekt zu machen.
Das dachte ich mir schon. Würde ich auch machen, wenn ich häufiger damit zu tun hätte und weiß, wie's geht.

Ich könnte dir mal das Projekt von Visual Studio 2010 schicken. Hat dann ja keinerlei Abhängigkeiten und sollte so dann auch bei dir funzen.
Das wäre klasse, wobei ich hoffe, dass sich das Ding auch mit VS 2008 sauber öffnen lässt.

MfG Dalai
 
Ich denke dieser Artikel ist wesentlich besser und hat weniger veraltete Tools. Das entsprechende VisualStudio 2008Projekt für wrappit schick ich dir gleich.
 
Ich denke dieser Artikel ist wesentlich besser und hat weniger veraltete Tools.
Hab ich das richtig verstanden, dass es das wrapper.cpp erstmal zu kompilieren gilt, bevor es an die eigentliche Arbeit geht? Wenn dem so ist, komme ich schon dabei nicht weiter. VS 2008 gibt mir diesen Fehler aus:
Code:
------ Neues Erstellen gestartet: Projekt: wrappit, Konfiguration: Debug Win32 ------
Die Zwischen- und Ausgabedateien für das Projekt "wrappit" mit der Konfiguration "Debug|Win32" werden gelöscht.
Kompilieren...
cl : Befehlszeile warning D9028 : Fehler beim minimalen Neukompilieren, normale Erstellung wird durchgeführt.
wrappit.cpp
c:\vc\wrappit\wrappit\wrappit.cpp : fatal error C1902: Fehler im Programmdatenbank-Manager. Überprüfen Sie die Installation.
Das Buildprotokoll wurde unter "file://c:\VC\wrappit\wrappit\Debug\BuildLog.htm" gespeichert.
wrappit - 1 Fehler, 1 Warnung(en)
========== Alles neu erstellen: 0 erfolgreich, Fehler bei 1, 0 übersprungen ==========

Das entsprechende VisualStudio 2008Projekt für wrappit schick ich dir gleich.
Danke, ist angekommen (auch wenn's mein POPFile als Spam markiert hat ;)).

MfG Dalai
 
Zurück
Oben Unten