Einer fremden *.exe Daten voranstellen ?

rüdiger

Nimm doch einfach die Datei und pack die als Resource in deine Anwendung und entpacke diese dann einfach temporär.

Ok das ist mal eine gute Idee kingruedi! Das mit dem Schreiben
in eine Datei hat mich jetzt schon einige Zeit in Google & Co.
gekostet. Ich will jetzt einfach wissen wie das geht
Hat das noch nie jemand von euch versucht ? Das mit Assembler
wäre nötig damit man ggf. mit einem Hex-Editor arbeiten kann, oder ?

SirLant

Mit entsprechenden Kentnissen, sollte es kein Problem sein, einfach in der Initialisierung dein Programm vor dem Start des eigentlichen Programmes zu laden.
Aber ohne Assemblerkentnisse wird das wohl nix.

Ich denke mit Assembler wäre das jawohl super aufwendig.
Man muss ja am Anfang zumindest ein CALL Deine_Funktion
aufrufen und somit wären alle absoluten Sprungadressen
anschliessend falsch.

Jockel

Kompliziert kompliziert... hätte ich nicht gedacht

LUZA

also, zum entpacken von resourcen

http://www.c-plusplus.net/forum/viewtopic.php?t=89120&highlight=

Spacelord

Was genau möchtest du denn machen bevor der fremde Prozess ausgeführt wird?
Zum einen schreibst du dass du den fremden Prozess anhalten möchtest bis dein Code ausgeführt ist und auf der anderen Seite sagst du dass der Code ausgeführt werden soll bevor der fremde Prozess mit der Ausführung seines Codes beginnt.Wenn dein Code vor dem des fremden Prozesses ausgeführt wird gibt es nichts zum anhalten.
Der Ablauf ist ganz grob etwa folgender:
-der Lader des Betriebssystems blendet die Exe in den virtuellen Adressraum der Anwendung ein und erstellt einen primären Thread.
-Dieser primäre Thread schaut im Importabschnitt nach den Abhängigkeiten und lädt die entsprechenden Dll´s.
-Jetzt werden erst dir Dll-Main Funktionen der Dll´s ausgeführt
-und erst jetzt fängt der fremde Prozess mit der Ausführung seiner main,WinMain oder was auch immer an.
Besonders interessant für dich halte ich den Punkt dass die DllMain Funktionen
auf jeden Fall vor dem Start des eigentlichen Exe Codes ausgeführt werden.
Vielleicht wäre ne Dll doch die bessere Alternative?
Sofern die fremde Anwendung die User32.dll lädt(und das tun alle GUI Anwendungen) lädt,ist die Injektion deiner(imaginären ) Dll trivial(Registryeintrag).
Da deine Dll dann aber in jeden Prozess geladen wird,der die User32.dll lädt, ist die ganze Nummer natülich ne Performancebremse.Wie stark sich das auswirkt kann ich dir allerdings nicht sagen weil ich es selber noch nicht gemacht hab.
Auf jeden Fall müsstest du dann in der DllMain als allererstes testen ob du dich in der richtigen Anwendung befindest und ansonsten die Dll wieder entladen.
Wäre meiner Meinung nach immer noch der einfachste,wenn auch nicht schönste Weg.

MfG Spacelord

Hallo Spacelord,

das mit der DLL ist ja evtl doch ganz interessant.
Also mit "anhalten" meine ich, dass ich das fremde
Programm oder besser das Dialogfeld sperre.
So, dass man darin nicht anklicken kann, ehe man
in meinem kleinen Dialog die Bedingungen akzeptiert
hat. Ist dies erfolgt, wird die Hauptanwendung freigegeben.
Falls nicht akzeptiert wird, sende ich die Message zum
schließen des Hauptprogrammes.

Wenn ich das nun richtig verstehe, suche ich mir eine
System-DLL und baue dort eine Überprüfung ein, ob z.B.
der Prozess meiner fremden Hauptanwendung aktiv ist.
Wenn ja, sperre ich den Dialog und führe meinen Code
aus.

Kein Problem, bis auf dass ich bisher max eine eigene
kleine DLL erstellt habe und nicht wirklich einen Plan
davon habe, wie ich in die user32 z.B. nun meinen Code
einbauen kann

@LUZA
Das mit dem einfügen einer Datei in meine eigene Anwendung kenne ich bereits,
aber thx.
Da hätte ich nur das Problem, dass man wenn erstmal das Programm irgendwo auf
Platte ist es jederzeit ohne meine Abfrage starten kann.
Doch mein "Akzeptieren"-Dialog sollte möglichst bei jedem Start der
Anwendung erfolgen. Und um dann wieder diese externe zu überwachen muss ich
praktisch meine eigene Anwendung irgendwo im Autostart verstecken.
Das wollte ich möglichst nicht.

Spacelord

Nene,es ist ja noch viel einfacher du musst an der User32.dll garnichts machen.
Es ist lediglich Voraussetzung dass der fremde Prozess diese in seinen Adressraum einblendet(und wenn er einen Dialog hat tut er das).
In der Registry gibt es nen Schlüssel HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\App_InitDLLs und wenn du da nen Eintrag mit dem Pfad deiner Dll machst wird diese automatisch mit in den Adressraum eingeblendet.

Ach ja,da gibt es ja auch noch Win98/ME( ich tendiere dazu diese zu ignorieren ) da funktioniert die Geschichte nicht.

MfG Spacelord

Spacelord

Also ich hab das vorhin mal getestet und muss hier mal eine massive Warnung abgeben.
Solange der Code in der DllMain Funktion nicht 100%ig den Prozess identifiziert
für den der Code gedacht ist darf in dem Code auf gar keinen Fall irgendwas sein das in irgendeiner Form blockiert!!! Keine MessageBox keine Wait-Funktion
usw.
Das finstere ist nämlich dass der Code auch für Systemprozesse ausgeführt wird bevor(!!) Windows überhaupt richtig hochgefahren ist.Wenn der Code dann blockiert(in meinem Fall war es ne einfache MessageBox,die aber logischerweise noch garnicht angezeigt wurde und wahrscheinlich zu diesem Zeitpunkt noch gänzlich unbekannt war) fährt Windows überhaupt nicht mehr hoch(ständige Neustarts).
Im Nachhinein war es irgendwie logisch.....
Also da ist schon eine gewisse Vorsicht geboten dass man mit seinem Code keine Systemprozesse erwischt die vor dem eigentlichen Systenstart ausgeführt werden!!!!

Aber ansonsten klappts

MfG Spacelord

otze

Nachdem ich nun meinen PC wieder formatiert habe....
Ok Ok, kleiner Scherz

Hab den Registrykey gefunden. Ich könnte da also "c:\demo\akzept.dll"
eintragen um die DLL zu initialisieren richtig ?!

Aber was meinst du mit den Prozess 100%ig identifizieren ?
Wie soll ich das machen ? Mir ist zwar bekannt wie ich laufende
Prozesse ermitteln kann, aber wie steuere ich denn da einen Zugriff
auf diese DLL ? Bzw. ich soll ja verhindern, dass andere Anwendungen
wegen meiner akzept.dll abschmieren/diese nutzen. Richtig ?

Oder hab ich dich falsch verstanden. Meintest du meinen Code zum
sperren der externen exe ? Das ist klar, da arbeite ich ja mit FindWindow.
Dann sollte es doch problemlos klappen oder ?

Spacelord

Mit FindWindow wirst du nichts anfangen können weil der Dll Code ja wie gesagt vor dem Exe Code ausgeführt wird.Zu diesem Zeitpunkt gibt es noch kein Fenster.
Aber du kannst mit GetModuleFileName den Namen der Exe herausfinden.
Ist es der Prozess den du "modifizieren" willst kannst du deinen Code ausführen und ansonsten machst du als erstes mal besser nichts.
Später könntest du dann versuchen die Dll aus den Prozessen für die sie nicht gedacht ist wieder zu entladen(aber wie gesagt es ist ja absolut undefiniert was da während des Bootens passiert!).Eventuell stehen dir zu eines frühem Zeitpunkt des Bootens Funktionen,wie GetModuleFileName noch garnicht zur Verfügung?

Also du solltest bevor du damit anfängst auf jeden Fall ne Startdiskette anlegen.Wenn du dann in die Misere kommst ist es damit getan die Dll zu löschen.Dann fährt die Kiste auch wieder hoch.
Ich hatte vorhin mit XP Schwein dass ich noch ne olle Startdiskette von ME hier rumfliegen hatte....

MfG Spacelord

Chris1986

Ok, habs eben auch mal getestet, aber mit SetCursorPos(300,300) gleich
beim Start der DLL.
Es funktioniert wie beschrieben wunderbar.

Hast du eine Ahnung, ob das sehr auf die Systemleistung geht, wenn ich
da eine Schleife einbaue, die prüft ob die Exe geladen ist ?
Mit Sicherheit ist das keine schöne Lösung. Und zunächst muss ich
ja noch immer die DLL irgendwie auf den PC bekommen und in die Registry schreiben.

Ach, wenn das noch jemand hier probieren sollte. Nicht vergessen zu prüfen
ob bereits etwas in den Registrykey AppInit_Dlls geschrieben wurde.
Sonst löscht man das ja ggf. versehentlich mit dem eigenen Eintrag raus.