Subclassing einer fremden Application, warum funzt das net ?

[stoxx]

Hallo !

Ich wollte die WndProc einer fremden Application subclassen, aber irgendwie funzt das net.
Also die neu definierte NewWinProc wird niemals aufgerufen.
Es passiert einfach gar nix ..!
Wo liegt der Fehler ?

Danke !

Delphi-Quellcode:

var
   OldWinProc: Integer;

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

function NewWinProc(hWnd: HWND; Msg: WORD; wParam: WORD; lParam: LONGINT): 
LONGINT;
var
   MessageProcessed: Boolean;
begin
   MessageProcessed := False;
  // case Msg of

  // end; {end of case Msg }
   if not MessageProcessed then
      Result := CallWindowProc(@OldWinProc,hWnd,Msg,wParam,lParam)
   else
      Result := 0;
end;

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

procedure SubClassWin(hWnd: HWND);
begin
   OldWinProc := SetWindowLong(hWnd,GWL_WNDPROC,integer(@NewWinProc));
end;

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

procedure UnSubClassWin(hWnd: HWND);
begin
   SetWindowLong(hWnd,GWL_WNDPROC,OldWinProc);
end;

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

procedure TForm1.Button1Click(Sender: TObject);
var h : hwnd;
begin

h := findwindow('notepad', nil);
if h > 0 then subclasswin(h);

end;

[Luckie]

Der Fehler liegt darin, dass das nicht geht. Zu mindest wohl nicht so einfach. Warum es nicht geht und wie man es amcht, kann ich dir leider auch nicht sagen.

[Chewie]

IM PSDK klingt es so, als würde es unter Win9x gehen:

Zitat:

Zitat von PSDK

GWL_WNDPROC
Sets a new address for the window procedure.

Windows NT/2000/XP: You cannot change this attribute if the window does not belong to the same process as the calling thread.

Für mich bedeutet das, dass das Subclassen fremder Fenster bei NTff nicht geht, wohl aber bei Win9x.

Bei NTff müsste es eigentlich irgendwie über VirtualAllocateEc und Read/WriteProcessMemoyr gehen. Man müsste den Aufruf von SetWindowLong irgendwie in den fremden Prozess kriegen und die eigene WindowProc ebenfalls (natürlich auch die Wiederherstellung der Original-Fenterprozedur). Dann müsste es eigentlich funktionieren, denn es würde die Bedingung "belongs to the same process as the calling thread" gelten.
So, wie du jetzt Code in einen fremden Prozess kopierst, kann dir (hoffentlich) Luckie sagen (oder er kann mir erklären, wieso das, was ich geschrieben hab, nicht funktioniert :wink: ). Oder schau dir mal LuckieDips (auf http://www.luckie-online.de) an, da wird auch sowas ähnliches gemacht.

[Luckie]

Die Dips haben nichts mit Subclassing am Hut und mit Read- / WriteProcessMemory liest man nur Speicher aus und damit dürfte man auf dem falschen Weg sein.

[Chewie]

Aber soweit ich das kopiert hab, kopiert man doch irgendwie ausführbaren Code in einen fremden Prozess, oder?

[Luckie]

Nein Speicher.

[Chewie]

Liegt der Code nicht auch im Speicher? Ich meinte, sollte es nicht möglich sein, den Speicher, in dem sich der Code befindet, in den fremden Prozess zu kopieren?

[Luckie]

Klar tut er das. Nur ist es ein Unterschied, ob es Programmcode ist oder ob es Daten (Variablen) sind.

[kiar]

deine alte poc musst du als pointer in den var parameter aufnehmen . in der initialization musst du deiner alten proc nil zuweisen und deine neue procedure musst mit stdcall aufgerufen werden.

so zumindest schreibt es kosch in seinem buch

raik

[DaFox]

Hi,

Zitat:

Zitat von Chewie

Für mich bedeutet das, dass das Subclassen fremder Fenster bei NTff nicht geht, wohl aber bei Win9x.

Geht schon, du musst aber Deinen Code (also zumindest die neue WndProc) in den Addressraum Deiner Zielanwendung injizieren.

Einfachste Möglichkeit:
- DLL mit Hook um in den anderen Adressraum zu gelangen
- SetWindowLong()/SetClassLong() um WndProc umzubiegen (siehe oben)
- MMF zur "Interprocess Communication"

Gruß,
Markus

[Motzi]

Du kannst auf die WndProc von Fenstern aus anderen Prozessen von deinem Prozessraum aus nicht zugreifen (nicht einmal lesen)! Aber selbst wenn du sie ändern könntest würde dir das nicht viel bringen, da deine neue WndProc in dem Adressraum deines Progs liegt, aber die Adresse deiner WndProc im Adressraum des anderen Prozesses nicht gültig ist! -> du musst den Code irgendwie in den anderen Adressraum bekommen - Stichwort: Inject-Dlls - ist aber ein recht heikles und kompliziertes Thema!

[stoxx]

[quote="Chewie"]IM PSDK klingt es so, als würde es unter Win9x gehen:

Zitat:

Zitat von PSDK

GWL_WNDPROC
Sets a new address for the window procedure.

Windows NT/2000/XP: You cannot change this attribute if the window does not belong to the same process as the calling thread.

Für mich bedeutet das, dass das Subclassen fremder Fenster bei NTff nicht geht, wohl aber bei Win9x.

Hallo Chewie,

Du könntest Recht haben.

denn der Aufruf

OldWinProc := SetWindowLong(hWnd,GWL_WNDPROC,integer(@NewWinProc ));

liefert schon Null zurück.

ob man die Prozesse mit AttachThreadInput irgndwie verbinden kann ?

[stoxx]

Zitat:

Geht schon, du musst aber Deinen Code (also zumindest die neue WndProc) in den Addressraum Deiner Zielanwendung injizieren.

hihi .. ich glaub das übersteigt im Moment meine Kenntnisse ..
hast Du sowas schonmal gemacht ? .. oder war das nur eine Idee wie es gehen könnte und Du das nur irgendwo gehört hast ?

[Luckie]

http://www.luckie-online.de/tutorials/assarbad/
Das Hook-Tutorial, da geht es auch um IPC und Inject DLL's.

[negaH]

Es müsste auch über shared Speicher funktionieren. Man alloziert also einen Speicherbereich oberhalb $80000000, also mit CreateFileMapping(). Dann kopiert man seinen Fensterprocedure code da rein. Und arbeitet mit SetWindowLong(). Ob nun NT abbrüft ob SetWindowLong() die entsprechenden Privilegien benötigt weis ich aber nicht.

Gruß Hagen

[Chewie]

Zitat:

Zitat von negaH

Ob nun NT abbrüft ob SetWindowLong() die entsprechenden Privilegien benötigt weis ich aber nicht.

Meiner Ansicht nach, ja:

Zitat:

Windows NT/2000/XP: You cannot change this attribute if the window does not belong to the same process as the calling thread.

Es geht also (zunächst) gar nicht darum, ob der fremde Prozess jetzt auf die neue WndProc zugreifen kann oder nicht, sondern darum, ob man das Attribut "Fensterprozedur" eines Fenster ändern kann - und laut dieser Aussage darf man das nicht.

Bleibt halt: Aufruf von SetWindowLong via DLL-Inject in dem fremden Prozess rein und die WndProc in eine MMF auslagern, damit beide Prozesse Zugriff drauf haben.

[jbg]

Zitat:

Zitat von negaH

Man alloziert also einen Speicherbereich oberhalb $80000000, also mit CreateFileMapping(). Dann kopiert man seinen Fensterprocedure code da rein.

Klingt einfach. Es fehlt aber eine entscheidende Kleinigkeit: Wo kommt die Delphi RTL her, die von der injezierten WndProc aufgerufen wird?

Eine gute Lektüre zu dem Thema gibt es hier

[stoxx]

Hallo halli, dies ist ein ernsthaftes Sicherheitsloch. Ich bin zwar nicht stoxx, aber ist ja auch egal ;) ... er hat mich gebeten hier mal zu antworten und offensichtlich den Link inklusive der SessionID reinkopiert. Jetzt schreibe ich als er. Und jetzt ratet mal wer ich bin ;)

Wärbunk: http://assarbad.info

Vielleicht solltet ihr (i.e. Daniel und Gerome) das nochmal überprüfen ;)

Bis zur Antwort aus meinem Kontext verbleibe ich ... Assa

[Assarbad]

Jaja, "cannot change" ist uns als DLL ja pupegal, da wir ja zu JEDEM Prozess gehören in dem wir laufen. Außerdem wissen wir schonmal, daß der Zielprozeß ein Fenster besitzt. Wie bringen wie also unsere DLL in den fremden Prozeß? Na? Dreimal dürft ihr raten!

Ein Fensterhook, na klar ... und schwupp ist unsere DLL in jeder Anwendung drin die ein Fenster hat.

Naja und der Rest ist bekanntlich Formsache. Also, nicht rumlamentieren ... weitermachen ;) *g*

@stoxx, nix für ungut. Sorry für das schreiben in deinem Kontext. Das ging offensichtlich, weil du mir einen Link inklusive aktiver SessionID geschickt hast. Habe die Mods bereits unterrichtet.

Zusammengefaßt: Hagen schlug vor, die Fensterproc in den Bereich zu legen, in dem auch MMFs liegen.
@Hagen: Deine Idee ist tatsächlich nicht so abwegig. Aber wie bringst du das dem Delphi-Linker bei?

@jbg: Mit dem Zeugs von madshi wäre ich vorsichtig ... :-/ ... zumindest vor einiger Zeit funktionierte das nicht so, daß ich es in einem Programm in einer Produktivumgebung nutzen würde!

[toms]

Hier mal ein paar Links um eine DLL zu injecten:

Inject DLL by Aphex (works under 95/98/NT/2K/XP) + Beispiel 1, Beispiel 2

Inject DLL using Madshi components by Kaiser

Elirt 1.01
(VirtualAllocEx, VirtualFreeExe, OpenThread and CreateRemoteThread for Windows 95,98,ME,NT,2000,XP,2003)

Inject DLL by Rezmond

[Assarbad]

Aahhhhhhhhhhhhhhhhh :evil:

Nochmal ... auch wenn das alles hübsch und schön ist, nämlich hübsch doof und schön dämlich ;) ... warum wollt ihr immer mit dem Kopf durch die Wand? Die ganzen tollen API-Hooks laufen nur, wenn man auch entsprechende Privs auf dem System hat. Das Debug-Priv ist meist Minimum. Oder man läßt sich einmalig irgendwelchen Code vom Admin im System implantieren ... aber mal ehrlich: Fensterhooks bieten genau das was stoxx will. Sie ermöglichen es einer DLL im Kontext eines beliebigen Prozesses mit Fenster zu laufen und den Rest (Subclassing) bekommt man noch gratis drauf.

Aber vielleicht denke ich auch nur falsch, wenn ein 50-Zeiler das erledigen kann und ich doch einen so schönen 500-Zeiler nehmen könnte ... nehmen wir doch einfach den 500-Zeiler. Vielleicht schaffen wir dann auch die gleiche relative Fehlerquote. Absolut wären das dann immerhin 10mal soviele Fehler.

Als Nachtrag: Hagens Idee finde ich noch am charmantesten. Allerdings ist mir nicht bekannt, daß dies auch nur annähernd mit Delphi realisierbar ist. In C sind das nur ein paar kleine Kommandos an den Linker und die Section der PE ist shared ...

[Assarbad]

@toms: Also die Sachen von Aphex fand ich schon immer ganz nett, aber dieses "Rootkit" ( http://www.virustrading.com/positron...t_root_kit.rar ) ist einfach nur lächerlich. Da hat wohl jemand nicht den Sinn hinter "Rootkit" verstanden. Das ist, glaube ich, das erste Rootkit welches mir unterkommt, das im Usermode arbeitet *ROFL*

Ich kann gar nicht soviel fressen wie ich kotzen möchte ...:

Zitat:

Zitat von LOM

//This code was contributed by Aphex ;)
//to be completely honest im not 100% sure how it works, but for the next
//source code release - ill look into it!

Zitat:

Zitat von LOM

If you dont want to see 'bandwidth exceeded' messages when you try to download files or access this site, then help support me and donate 20$ in the donations section.

Zitat:

Zitat von LOM

Next Application that will be released when donations reach 50 sales : Webcam Addict.
This application won't be released until I reach 50 donations.

Zitat:

Zitat von LOM

Following Application after : LOM Security Analysis Rootkit.

... im Usermode ... *muhahahaha*

Zitat:

Zitat von LOM

You can start supporting the community as the authors have supported you by contributing 35$ (this is not even the price of a computer game, and you will be truly getting something worthwhile that no-one else would provide, in uniqueness and technologically?) here :

Also "unique" sind seine Sachen wirklich ;) ... aber IMO nicht so, wie er sich das denkt *g*

[jbg]

Zitat:

Zitat von Assarbad

@jbg: Mit dem Zeugs von madshi wäre ich vorsichtig ... :-/ ... zumindest vor einiger Zeit funktionierte das nicht so, daß ich es in einem Programm in einer Produktivumgebung nutzen würde!

Wer sagt, dass ich dessen Code benutze? Mir ging es bei dem Link mehr um das Hintergrundwissen, dass auf dieser Seite bereitgestellt wird. Mit diesem Wissen konnte ich dann schon mein eigenes Testprojekt schreiben, ohne je den Code von madshi angeschaut zu haben (den gibt es sowieso nicht zum Download).

[Assarbad]

*g* Irrtum ... der Code ist schließlich in den Units enthalten ;)

Aber ich verstehe schon was du meinst ;) so gesehen möchte ich noch auf Microsoft Research Detours verweisen :-)
BTW: Ich hatte ja garnicht behauptet, daß du es benutzt. Wollte nur auf die Unzulänglichkeiten aufmerksam machen.

[stoxx]

Hi zusammen !

Zitat:

Es müsste auch über shared Speicher funktionieren. Man alloziert also einen Speicherbereich oberhalb $80000000, also mit CreateFileMapping(). Dann kopiert man seinen Fensterprocedure code da rein. Und arbeitet mit SetWindowLong(). Ob nun NT abbrüft ob SetWindowLong() die entsprechenden Privilegien benötigt weis ich aber nicht.

geht denn das nun oder nicht ?
wenn ja, wie ? :-)

hmmm .. irgendwie seh ich noch nicht so recht den zusammenhang ..

[Assarbad]

Also stoxx ... wie oben schon erwähnt. Warum willst du mit dem Kopf durch die Wand?

Du hast bereits einen Hook. Jetzt darf dieser Hook nur nicht mehr Filtern, sondern muß eben nur durchlassen. Als nächstes schreibst du die Subclassing-Routine und fügst die in den Prozess ein, in dem sie sein soll. Voila, es ist angerichtet.

[stoxx]

Hallo zusammen,

also mir gefällt die Idee mit dem injecten einer DLL recht gut.
Vielen Dank nochmal an alle !

@Assa .. das mit dem Hook gefällt mir irgendwie nicht, wäre ja dann doppelt gemoppelt.
Einmal gehen alle Messages durch den Hook und zum zweiten mal in der eigenen neuen Wndproc.

Jetzt aber nochmal konkrekt die Frage.
Ich möchte zwei fremde Applicationen subclassen.
Ich habe jetzt eine DLL (in meinem Programmverzeichnis)
In diese wird die neue wndprog mit setWindowLong umgeleitet
Dann Injecte ich sie den zwei Prozessen.
Ist die vorgehensweise richtig ?

Aber wie kann ich die beiden "Daten" der zweimal geladenen Dll unterschieden jetzt ?
Habe noch keine konkrete vorstellung von dem ganzen.

[negaH]

Zitat:

Aber wie bringst du das dem Delphi-Linker bei?

@Assarbad: die neue Fensterprocedure in dem MMF nutzt keinerlei Delphi RTL, ist so codiert das sie an jede Stelle des Speichers verschoben werden kann, hat also keine relativen Adressen auf Importe in unseren Prozess oder Sprünge an Adressen in unserem Prozess, und alle nötigen Importe auf die Kernel32.dll werden entweder in einer eigenen "Import" tabelle gemacht oder eben dynamisch.

Also, man würde in das MMF eine Datenstruktur ablegen wie

Delphi-Quellcode:

type
  PHookData = ^THookData;
  THookData = packed record
    AssemblerHook: array[] of Byte;

    LoadLibrary: function(FileName: PChar): hModule; stdcall;
    GetProcAddress: function(Lib: hModule; Name: PChar): Pointer; stdcall;
    Name: array[0..MAX_PATH -1] of Char;
    OtherData: Integer; 
.. usw. usw.
//    Code: array[0..0] of Byte; 
  end;

Nun wird das MMF erzeugt und obige Datenstruktur an erster Position initialisiert. Dahinter steht der Code der nur auf diese PHookData zugreift.
Der Code könnte so aussehen:

Delphi-Quellcode:

function MyWndProc(..., HookData: PHookData): Integer; stdcall;
var
  Module: hModule;
begin
  Lib := HookData.LoadLibrary(HookData.Name);
  ...
  HookData.FreeLibrary(Lib);
end;

In den ersten Bytes von HookData steht dynamischer Code

Delphi-Quellcode:

asm
      POP  ECX                       // hole Return Address
      CALL @@1                       // ermittle HookData Address
@@1:  POP  EAX                       // EAX = @@@1 
      SUB  EAX,3                     // EAX = @POP ECX = HookData                 
      PUSH EAX                       // erster Param unserer WindowProc 
      PUSH ECX                       // return address 
      ADD  EAX,SizeOf THookData      // Sprung zu WindowProc(HookData, ....)
      JMP  EAX
end;

D.h. im MMF steht als erstes eine HookData Struktur, danach unser PASCAL Code.
Wir initialisieren das MMF, setzten AssemblerHook auf obigen Assembler, initialisieren die Importe und kopieren unseren PASCAL Code an Code.

Danach ist die Adresse des MMFs die Adresse unserer neuen WindowProc().

Gruß Hagen

[negaH]

Übrigens, diese Technik kann in jeden beliebigen Prozess Code injezieren. D.h. das MMF kann auch dem Ziel-Prozess zugeordnet werden, oder besser noch einfach nur global für alle Prozesse gültig sein.

Nimmt man nun die Remote Thread funktionen und setzt deren Thread funktion auf eine so wie oben erzeugt "Funktion" dann könnte diese Funktion das Fenster subclassen IM Zielprozess. Somit wäre es nicht nötig eine Debug/Hook DLL zu injezieren.

Gruß Hagen

[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

[stoxx]

Zitat:

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 ?

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... :gruebel:

[Assarbad]

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:

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! ;)

[Assarbad]

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" :wall:

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:

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:

Code:

[center]physischer Speicher
|
|[/center]
[center]+----------Memory Manager----------+[/center]
                                 |                                  |
                                 |                                  |
                                  |                                  |
                       getr. Usermode-Speicher            gemeinsamer Kernel-Speicher

[Assarbad]

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 :)