Einen prozess in anderen Desktop befördern ohne switch!

[Neotracer64]

Ich möchte eine andere Anwendung starten, aber in einem anderen Desktop ohne selbst dahinzuswitchen!
Alle Beispiele, die ich gefunden habe, können nur das eigene Programm auf einen neuen Desktop befördern.

Also habe ich versucht Code in diesen Prozess zu injezieren und darin habe ich folgendes getan:

Delphi-Quellcode:

Desktop:= CreateDesktop('Neu', nil, nil, DF_ALLOWOTHERACCOUNTHOOK, GENERIC_ALL, nil);
SetThreadDesktop(Desktop);

Jedoch startet sich das Programm normal im Standard-Desktop. (Ja die injektion war erfolgreich, getestet mit einer Messagebox)

Dann habe ich etwas anderes versucht. Ich habe mir überlegt, dass ein Programm, dass schon im anderen Desktop läuft und selbst ein anderen Prozess startet, dass dieser dann auch auf dem neuen Desktop startet.... Fehlanzeige

Mir gehen so langsam die Ideen aus. Habt ihr ne Idee? Oder ist es zwingend notwendig das programm zu patchen?

[RavenIV]

schau dir mal in der Delphi-hilfe TScreen und vor allem TScreen.Monitors an.
Könnte sein, dass dies dir weiterhilft.

[NicoDE]

Ein Thread kann den Desktop mittels SetThreadDesktop nur wechseln, wenn er keine Referenzen auf seinen aktuellen Desktop hält (üblicherweise Fenster-Handle).
Insofern dürfte es schwierig werden Anwendungen auf einen anderen Desktop zu 'verschieben'.

Zitat:

Zitat von MSDN

The SetThreadDesktop function will fail if the calling thread has any windows or hooks on its current desktop (unless the hDesktop parameter is a handle to the current desktop).

[Neotracer64]

thx 4 answer.

Ergo heisst das, ich muss den SetThreadDesktop-Aufruf in die Executable patchen, bevor die ganzen Referenzen entstehen, nicht wahr?
Ich glaube ich hänge einfach eine Sektion ran, jumpe am Anfang hin,,tätige dort die notwendigen Api-Aufrufe und springe dann wieder zurück.
Ich werde verlauten lassen ob es funktioniert hat.

[Neotracer64]

Patchen hat geklappt.
Ich hab jetzt nicht extra eine Section rangehängt, da noch genug platz in der code-Section war.

Hier der ASM-Code den ich direkt mit Ollydbg reingeschrieben habe.
Am OEP der Executable hab ich einen Jump auf 0140B8D0 gemacht. Und dort erstmal die Register gesichert.
Der Code von 0140B919 bis 0140B91C ist das, was ich am OEP überschrieben habe.
Ich gebe zu, dass ich etwas umstänlich war und 2x GetModuleHandle aufgreufen habe, aber ich habe es halt on-the-fly implementiert.

Wenn ihr es bei einem programm nachmachen wollt, müsst ihr natürlich die Adressen fixen ;)

Delphi-Quellcode:

0140B8D0   > \60                PUSHAD
0140B8D1   .  9C                PUSHFD
0140B8D2   .  68 25B94001       PUSH _patch.0140B925                            ; /pModule = "user32.dll"
0140B8D7   .  FF15 18C04001     CALL DWORD PTR DS:[<&KERNEL32.GetModuleHandleA>]  ; \GetModuleHandleA
0140B8DD   .  68 30B94001       PUSH _patch.0140B930                            ; /ProcNameOrOrdinal = "CreateDesktopA"
0140B8E2   .  50                PUSH EAX                                          ; |hModule
0140B8E3   .  FF15 48C04001     CALL DWORD PTR DS:[<&KERNEL32.GetProcAddress>]    ; \GetProcAddress
0140B8E9   .  6A 00             PUSH 0
0140B8EB   .  68 00000010       PUSH 10000000
0140B8F0   .  6A 01             PUSH 1
0140B8F2   .  6A 00             PUSH 0
0140B8F4   .  6A 00             PUSH 0
0140B8F6   .  68 F03F5103       PUSH _patch.03513FF0
0140B8FB   .  FFD0              CALL EAX
0140B8FD   .  50                PUSH EAX
0140B8FE   .  68 25B94001       PUSH _patch.0140B925                            ; /pModule = "user32.dll"
0140B903   .  FF15 18C04001     CALL DWORD PTR DS:[<&KERNEL32.GetModuleHandleA>]  ; \GetModuleHandleA
0140B909   .  68 3FB94001       PUSH _patch.0140B93F                            ; /ProcNameOrOrdinal = "SetThreadDesktop"
0140B90E   .  50                PUSH EAX                                          ; |hModule
0140B90F   .  FF15 48C04001     CALL DWORD PTR DS:[<&KERNEL32.GetProcAddress>]    ; \GetProcAddress
0140B915   .  FFD0              CALL EAX
0140B917   .  9D                POPFD
0140B918   .  61                POPAD
0140B919   .  55                PUSH EBP
0140B91A   .  8BEC              MOV EBP,ESP
0140B91C   .  6A FF             PUSH -1
0140B91E   .^ E9 F37EFFFF       JMP _patch.01403816
0140B923      00                DB 00
0140B924      00                DB 00
0140B925   .  75 73 65 72 33 32>ASCII "user32.dll",0                              ;  user32.dll
0140B930   .  43 72 65 61 74 65>ASCII "CreateDesktopA",0                          ;  CreateDesktopA
0140B93F   .  53 65 74 54 68 72>ASCII "SetThreadDesktop"
0140B94F   .  00                ASCII 0

[Luckie]

Und wozu ist das jetzt gut? Wozu braucht man so was? :gruebel:

[NicoDE]

Ich frage mich ohnehin, warum er den Zieldesktop nicht 'einfach' in die TStartupInfo bei CreateProcess schreibt...
(bzw GetStartupInfo() verwendet um die Struktur zu initialisieren)

[Neotracer64]

Was ist wenn die Ziel-Executable GetStartUpInfo nicht callt?
Ich hab keinen Einfluss (also closed-source) auf die Programme, die ich auf dem anderen Desktop starten will und deswegen dachte ich jetz Patchen sei die einzige Möglichkeit.

[NicoDE]

Zitat:

Zitat von Neotracer64

Ich hab keinen Einfluss (also closed-source) auf die Programme, die ich auf dem anderen Desktop starten will und deswegen dachte ich jetz Patchen sei die einzige Möglichkeit.

Ich dachte du startest die Programme immer selbst... dann kannst du bei CreateProcess auch angeben, in welchem Desktop das Programm ausgeführt werden soll.

[mh166]

Wobei ich aber beim patchen von fremder Software vorsichtig wäre... Wenn dus nur für dich nutzt, dann wirds da vermutlich nich viel Probs geben. Aber letztendlich könnte es vom rein rechtlichen Standpunkt her sicher problematisch sein, oder täusch ich mich da (nur mal der Neugierde halber. :))?

mfg, mh166

[Neotracer64]

Zitat:

Ich dachte du startest die Programme immer selbst... dann kannst du bei CreateProcess auch angeben, in welchem Desktop das Programm ausgeführt werden soll.

Achso. Und ich war in dem Glauben, dass der Prozess, den ich starte "GetStartupInfo" am Anfang des Programms aufrufen muss um die TStartupInfo auch verarbeiten zu können.

[FreewareFire]

Hallo zusammen!

Ich habe da ein kleines Problem... Wie verschiebe Ich meine Anwendung auf den aktiven Desktop? Alle bisherigen versuche das Programm auf den neuen Desktop zu setzen sind fehl geschlagen.

Also ich habe mein Programm das einen neuen Desktop anlegt... jetzt soll das Programm auch auf den neuen Desktop wechseln... Ich möchte aber nicht mit CreateProcess eine neue Instanz starten müssen. Ich möchte das Fenster einfach mit auf den Desktop verschieben. Aber wie?

Das Problem bei mir ist, dass nicht einmal das Beispiel (glaube von Luckie ist es) richtig zum laufen bekomme... Er erstellt zwar den neuen Desktop, switcht auch, aber er zeigt die MessageBox nicht auf dem neuen, sondern auf dem Default Desktop an! Ich suche jetzt seit 3 Tagen nach einer Lösung...

Bitte helft mir weiter!

Vielen Dank


Ralf

[SirThornberry]

wenn du dir die bisherigen Beiträge duchgelesen hättest wüsstest du das dies nicht geht. Man kann einen Thread nur in einen anderen Desktop befördern wenn dieser keine referenzen (Fenster-Handles etc.) auf seinen aktuellen Desktop hat. Daraus folgt das ein Fenster somit auch nicht auf einen anderen Desktop verschoben werden kann. Nächstes mal bitte erst das bereits gepostete lesen damit wir nicht 5 mal die gleiche Frage innerhalb eines Themas schreiben müssen.

[FreewareFire]

Danke für die schnelle Antwort... Das ist ja wohl sinnlos? Hättest du Dir mein Posting vorher mal richtig durchgelesen, wüsstest du, dass Ich bereits seit 3 Tagen nach einer Antwort suche... Und da werde Ich sicher nicht zum Spaß die Frage hier stellen... Ergo gelesen... Aber egal - und wenn du das erste Posting liest, stellst du fest, sofern Ich das richtig verstehe, da eben das eigene Programm sehr wohl switchen kann - siehe Angabe mit Beispielen die das wohl können... zum anderen gibt es Posts, in denen das wohl geht, allerdings nonVCL Versionen... Und es gibt einige Tools, die das letztlich auch machen (siehe Dexpot)... Tja, und jetzt? Wer also was weiß, Bitte postet doch mal was... auch Links sind Willkommen!


Vielen Dank an alle D-Praxis Leser!

[NicoDE]

Dann werde konkreter, beschreibe wie du was versucht hast und an welchem konkreten Problem du scheiterst (Fehlercode einer API, etc).

[SirThornberry]

auch das eigene Programm kann keine Programme auf einen anderen Desktop befördern wenn der Thread referenzen auf den aktuellen Desktop hält (auch NonVCL nicht). Das Program Dexpot und viele andere auch arbeiten nicht mit Desktops sondern verstecken lediglich die Programme. Wenn du zum Beispiel ICQ auf einem anderen desktop hast und ICQ ein neues Fenster öffnet erscheint dieses egal auf welchem Desktop du dich befindest eben weil es keine richtigen Desktops sind sondern nur die Fenster ausgeblendet werden.

Man muss sich also entscheiden ob man mit richtigen Desktops arbeiten will (und somit die Programme auch in Ihrem desktop verbleiben) oder mit "virtuellen" Desktops und akzeptieren das es zu unerwünschten Effekten kommt weil die Fenster einfach nur ausgeblendet werden.

[FreewareFire]

Ok, dass war das was ich wissen wollte - dachte Dexpot usw. nutzen auch CreateDesktop und Co.

Allerdings habe Ich da eine Idee gehabt: Klonen!? Also den Prozess klonen - dazu habe Ich in der MSDN das hier gefunden:

DuplicateHandle

Duplicates an object handle.
BOOL DuplicateHandle(
HANDLE hSourceProcessHandle,
HANDLE hSourceHandle,
HANDLE hTargetProcessHandle,
LPHANDLE lpTargetHandle,
DWORD dwDesiredAccess,
BOOL bInheritHandle,
DWORD dwOptions
);

hier der Link!

MSDN für DuplicateHandle

Wäre das evtl. eine Lösung? Allerdings krieg ich kein Beispiel hin. Vielleicht kann jemand mal ein kleines Prog basteln, dass ein duplikat der Anwendung erstellt...? Verstehe Ich doch richtig, dass diese Funktion diesen zweck erfüllen soll, oder? Irgendwo in den dwOptions oder so kann man glaube Ich den Desktop mit angeben!!! Dann würde er die Kopie ja im Desktop öffnen, oder?

Danke euch!

[Olli]

Zitat:

Zitat von SirThornberry

Man muss sich also entscheiden ob man mit richtigen Desktops arbeiten will (und somit die Programme auch in Ihrem desktop verbleiben) oder mit "virtuellen" Desktops und akzeptieren das es zu unerwünschten Effekten kommt weil die Fenster einfach nur ausgeblendet werden.

Echte machen ja auch dann erst richtig Sinn, wenn sie mit anderen Credentials laufen ... :stupid:

[Vjay]

@FreewareFire: Ich beschränke mich mal auf ein einfaches "nein".

Warum sollten die anderen Desktopmanager so ein kompliziertes Versteckspiel verwenden, wenn es doch so einfach wäre?

Zitat:

The DuplicateHandle function duplicates an object handle.

Und nur das, nicht den Prozess oder sonstwas.

[FreewareFire]

Ok, Danke - wollte ja nur helfen... Schließlich ist das ja ein weit verbreitetes Problem...

Evtl. kommt irgendwann eine Lösung - Cya!

[Olli]

Zitat:

Zitat von FreewareFire

Ok, Danke - wollte ja nur helfen... Schließlich ist das ja ein weit verbreitetes Problem...

Du hast nur die Daten mit dem Zeiger auf die Daten verwechselt. Denn nicht das Objekt wird kopiert, sondern es wird nur eine neue Referenz auf das gleiche Objekt erzeugt.