Subclassing einer fremden Application, warum funzt das net ?

**stoxx**

Zitat von Assarbad:

@Hagen: Ali G. wuerde sagen RESTECP

IMO eine sehr elegante Methode. Ich dachte urspruenglich, du woelltest eine Shared Section in der PE erzeugen, was bekanntlich auch moeglich ist. Nur eben nicht in Delphi.
Stell das doch bitte mal in die Codelib
@stoxx: Nimm Hagens Methode. Eleganter als ein Hook ist sie allemal (zumindest auf der NT-Plattform). Allerdings ist Fenster-Hooking als Methode zum Injezieren von DLLs in fremde Prozesse durchaus anerkannt. Also keinerlei Grund dies abzulehnen.

Gruss,

Oliver

Hi Oliver,

Zitat:

@stoxx: Nimm Hagens Methode. Eleganter als ein Hook ist sie allemal

Das würde ich ja auch gern tun, aber komme mit Hagens Erklärungen allein noch nicht so recht weiter.

Wie muss ich nun vorgehen, um die WndProc einer fremden Application zu ersetzen ?
Brauch ich noch eine DLL ?
Muss ich Privilegien unter WinXP beachten ?

Was genau muss ich nun tun, um folgende WndProc einzupflanzen ?

zusammenfalten · markieren

Delphi-Quellcode:

			var

   OldWinProc: Integer;

////////////////////////////////////////////////////////////////////////////////

function NewWinProc(hWnd: HWND; Msg: WORD; wParam: WORD; lParam: LONGINT): LONGINT; stdcall;

begin

   case Msg of

     wm_close : msg := wm_null;

   end; {end of case Msg }

  Result := CallWindowProc(@OldWinProc,hWnd,Msg,wParam,lParam)

end;

kann sich jemand nochmal erbarmen ?
vielen, vielen Dank !

**Motzi**

@Hagen: absolut genial..! Ich hab mir für meinen X-Spy eh auch schon Gedanken wegen Inject-Dlls usw. gemacht, aber wenn es auch ohne geht erleichtert das die Sache natürlich..!

Aber so ganz 100%ig hab ich deine Vorgehensweise (noch) nicht verstanden.. das mit dem dyn. Code beschäftigt mich noch ein bisschen...

Tss tss ... Motzi, jaaanz easy, komm runter

Hagens Code ist elegant, ist aber nicht nicht garantiert, dass er ueberall laeuft. Man sollte also schon wissen was man macht und ihn auf allen OS-Versionen testen. IMO sollte er von Windows NT bis 2003 laufen, aber MS hat keinesfalls jemals behauptet, dass in allen Prozessen die Adressen innerhalb einer MMF gleich sind! Will heissen, wenn irgendwann mal eine MMF nicht innerhalb aller Prozesse an der gleichen Stelle liegen sollte (laesst sich ja anhand der Tatsache, dass dies bei DLLs recht haeufig passiert, beweisen - Stichwort Relocation), dann macht es WUMMM ... und das Programm kackt jaemmerlich ab!

Zugegeben, das passiert "relativ" selten - ABER es passiert!

@Motzi: Den Code solltest du schon 100% kapieren bevor du ihn benutzt. Vorzugsweise noch ein paar Kenntnisse zur NT-Speicherverwaltung ... (oberhalb des MM)

**Motzi**

Zitat von Assarbad:

@Motzi: Den Code solltest du schon 100% kapieren bevor du ihn benutzt. Vorzugsweise noch ein paar Kenntnisse zur NT-Speicherverwaltung ... (oberhalb des MM)

Das ist mir schon klar.. deswegen auch das obige Posting!

Den Code versteh ich soweit schon (also was passiert), aber das "wieso" ist mir noch nicht so ganz klar..

Aber ich werd mich mal ein bisschen damit beschäftigen!

Was die Sachen mit der Speicherverwaltung betrifft so hab ich immer den Richter zur Hand!

Achja, die Sache mit der Relocation - an das hab ich zwar nicht gedacht, aber jetzt wo dus erwähnst isses logisch!

Kurzgeschichte:

Der Speicher in NT ist (oberhalb des MM) in 2 Bereiche aufgeteilt. Einmal der fuer den usermode und einmal der fuer den Kernel. Ich weiss nicht mehr wie rum das nun war, aber gehen wir mal von Hagens Annahme aus $80000000 sei die Grenze. Alles was oberhalb liegt waere dann Kernelspeicher und alles darunter Usermode-Speicher. Bekanntlich duerfen sich Prozesse keinen Speicher teilen, aber der Kernel darf ... daher kommt das mit den Sections (aka MMFs). Die liegen im Kernelspeicher-Bereich, aber es ist eben nicht sicher wie nun das Mapping fuer die einzelnen Prozesse aussieht. Rein theoretisch sollte es immer gleich sein (ich benutze das zB in meinem Hooktut, Hagen in seinem Code und viele andere Leute auch ...) ... aber muss nicht. Fazit, sollte MS das mal aendern, kacken die entsprechenden Progs ab. ABER MS verwendet das sicher selber so oft, dass eine Aenderung fatale Folgen fuer bereits veroeffentlichte Software haben kann.

Um es nochmal zu klaeren. Es gibt quasi 3 Ebenen:
1. physikal. Speicher
2. Speichermanager, welcher den Misch aus Ebene 1 und 3 "sieht" und verwaltet
3. Logischer Speicher, wie ihn jede einzelne Usermode-Anwendung sieht.

PS: Sorry, das ist keine klare Trennung der Begriffe, soll aber auch nur veranschaulichen.

**Chewie**

Darf ich auch mal dazwischenhaken?

Zunächst mal:

Zitat:

Ich weiss nicht mehr wie rum das nun war, aber gehen wir mal von Hagens Annahme aus $80000000 sei die Grenze.

Das sehe ich auch so. Alles darunter ist der Usermode-Speicher, in dem jeder Prozess seinen eigenen Raum hat. Darüber liegt der Kernel-Speicher.

Nur was ich jetzt nicht verstehe: Meines Wissens ist der Kernel-Speicher ja shared. Deshalb funktionieren Filemappings ja auch, es werden Daten an einer Adresse gespeichert, die für alle Prozesse zugänglich sind.
Und wenn ich euch richtig verstanden habe, wollt ihr sagen, dass MS diese Tatsache in Zukunft ändern könnte? Denn das würde ja bedeuten, dass das ganze Konstrukt "MMFs" dann nicht mehr funktionieren würde.

Und nochwas, ich trau mich kaum zu fragen, aber was meinst du in diesem Moment mit "MM"?

Edit: Ach so, klar, der "Memory Manager"

Aber wieso "oberhalb des MM"? Oder spielst du mit dieser Aussage auf dein kleines Schicht-Modell an?

**neolithos**

Ich habe mal in einem klugen Buch geblättert...

Win9x

0x00000000 - 0x00000FFF - 4096 Bytes für MS-DOS und Win16 (kein Zugriff - NULL-Zeiger)
0x00001000 - 0x003FFFFF - 4190208 Bytes für MS-DOS und Win16 (Lese/Schreibzugriff aber Hände weg)
0x00400000 - 0x7FFFFFFF - 2GB Adreßraum für Win32-Prozesse (verwendbar)
0x80000000 - 0xBFFFFFFF - 1GB für speicherbasierte Dateien, Win32-Dll's (verwendbar)
!! Achtung von allen Win32 Prozessen gemeinsam genutzt
0xC0000000 - 0xFFFFFFFF - 1GB für VxD's, MM, FS wird von alles Win32 Prozessen gemeinsam verwendet
(Lese/Schreibzugriff aber Hände weg)

**neolithos**

so nun WinNT/2k/XP

0x00000000 - 0x0000FFFF 64KB für NULL-Zeiger
0x00010000 - 0x7FFEFFFF ca 2GB privater Adressraum für Win32 Prozesse (auch Speicherbasierte Dateien)
0x7FFF0000 - 0x7FFFFFFF 64KB für NULL-Zeiger
0x80000000 - 0xFFFFFFFF 2GB Betriebssystem (keine Zugriffsmöglichkeit)

**Chewie**

Zitat von Assarbad:

Um es nochmal zu klaeren. Es gibt quasi 3 Ebenen:
1. physikal. Speicher
2. Speichermanager, welcher den Misch aus Ebene 1 und 3 "sieht" und verwaltet
3. Logischer Speicher, wie ihn jede einzelne Usermode-Anwendung sieht.

PS: Sorry, das ist keine klare Trennung der Begriffe, soll aber auch nur veranschaulichen.

Ich würde das eher so vereinfachen:

markieren

Code:

			[center]physischer Speicher

|

|[/center]

[center]+----------Memory Manager----------+[/center]

                                 |                                  |

                                 |                                  |

                                  |                                  |

                       getr. Usermode-Speicher            gemeinsamer Kernel-Speicher

Stop stop stop ...

DLLs SIND MMFs! Der Beweis, dass diese in verschiedenen Prozessen auch verschieden gemappt sein koennen, ist das Vorhandensein von Relocations. Dementsprechend funktioniert das Konstrukt an sich schon noch ... ABER ... niemand hat jemals behauptet (ansonsten haette ich gern eine exakte Quelle), dass man mal eben eine MMF mappen und einen View oeffnen kann ... und das dieser Pointer dann ueber Prozessgrenzen hinweg zu sharen ist! Genau das ist aber die Implikation in Hagens Modell. Deshalb sage ich, das es schief gehen KANN!

Der normale und unterstuetzte Weg hingegen ist, dass man, in jedem Prozess in dem man auf eine MMF zugreifen will, einen neuen View zu dieser MMF oeffnet. Ich hoffe das war verstaendlicher.

Naja ... wie du das Modell malst ist eigentlich egal ... Usermode ist boese ... das ist zumindest die erste Lektion des Treiberprogrammierers