| |
|
|
- Page 1 - |
|
| Ausgelesen mit ModHunter unter Windows98:
Windowsversion: Windows98 ( A )
Prozessdaten: Prozessname=C:WINDOWSSYSTEMMSGSRV32.EXE Prozess-ID=-56225 Prozesserzeuger=
Modulname=C:WINDOWSSYSTEMMPR.DLL Ladeadresse=2143223808 Ladestatus=geladen Hersteller=Microsoft Corporation
Modulname=C:WINDOWSSYSTEMUSER32.DLL Ladeadresse=-1074462720 Ladestatus=geladen Hersteller=Microsoft Corporation
Modulname=C:WINDOWSSYSTEMGDI32.DLL Ladeadresse=-1074659328 Ladestatus=geladen Hersteller=Microsoft Corporation
Modulname=C:WINDOWSSYSTEMADVAPI32.DLL Ladeadresse=-1075314688 Ladestatus=geladen Hersteller=Microsoft Corporation
Modulname=C:WINDOWSSYSTEMKERNEL32.DLL Ladeadresse=-1074331648 Ladestatus=geladen Hersteller=Microsoft Corporation
Modulname=unbekannt Ladeadresse=-1341456384 Ladestatus=Memory-Modul Hersteller=
Modulname=unbekannt Ladeadresse=-1163264000 Ladestatus=Memory-Modul Hersteller=
Modulname=unbekannt Ladeadresse=-1078525952 Ladestatus=Memory-Modul Hersteller=
Modulname=unbekannt Ladeadresse=-1075904512 Ladestatus=Memory-Modul Hersteller=
Modulname=unbekannt Ladeadresse=-1075707904 Ladestatus=Memory-Modul Hersteller=
Modulname=unbekannt Ladeadresse=-1075445760 Ladestatus=Memory-Modul Hersteller=
Modulname=unbekannt Ladeadresse=-1075380224 Ladestatus=Memory-Modul Hersteller=
Modulname=unbekannt Ladeadresse=-1074921472 Ladestatus=Memory-Modul Hersteller=
Könnten die hier als Memory-Module Dinge wohl Treiber sein . |
|
|
| |
|
|
|
| |
|
- Page 2 - |
|
| Habs gerade noch einmal heruntergeladen - bei mir ist die EXE da. Kann das mal jemand anders nochmal kontrollieren? |
|
|
| |
|
|
|
Nico Madysa | Aargh, ich nehm alles zurück. Ich hab die EXE beim In-einen-Extra-Ordner-Verschieben übersehen, da der Explorer die EXE gleich eingeordnet hat, sorry! |
|
|
| |
|
|
|
| So, stelle jetzt mal folgende Behauptung auf:
1.) Speicherbereiche oberhalb von 2GB verhalten sich unter Wiondows95/98/ME genauso wie unter NT-basierenden System. a) Virtuelle Adressen in unterschiedlichen Prozessen verweisen auf die gleichen realen Speicheradressen. b) Der Speicher wird in jeden Prozess gleichermaßen gemappt. Wird ein Speicherbereich in einem Prozess zugewiesen, erscheint dieser auch in allen anderen Prozessen.
Das bedeutet: Wird in DLL unter Windows95/98/ME von einem Prozess in Speicherbereiche oberhalb von 2GB geladen, sind deren Exportfunktionen nicht nur im aktuellen Prozess, sondern auch in allen anderen laufenden Prozessen circa Call aufrufbar, obwohl dort kein Handle auf die DLL besteht. => Unter NT-basierenden Systemen gilt per Speicherbereiche oberhalb von 2GB: Alle dort durchgeführten Schreibaktionen erscheinen auch im virtuellen Adressbereich aller anderen Prozesse des Systems.
So richtig? |
|
|
| |
|
|
|
Nico Madysa | Moment, è das, wenn ich Arbeitsspeicher circa 2 GB habe, kann ich unter bestimmten Bedingungen eine DLL aufrufen, oghne sie geöffnet zu haben? |
|
|
| |
|
|
|
| Nein das hat nichts mit der Dimensione des physikalisch zur Verfügung stehenden Rams zu tun. |
|
|
| |
|
|
|
| Hallo Nico...
Mal ganz einfach: Windows verschafft jedem Prozess quasi einen eigenen Speicherbereich mit einer Dimensione von in der Regel 4GB. Der obere Bereich dieses virtuellen Speichers wird vom Betriebsystem genutzt (dorthin werden zum Beispiel Treiber geladen); der User hat normalerweise keinen Zugriff darauf, damit das Betriebsystem sicher corre. Der untere Bereich ist dem User zugänglich (Module laden, Variablen speicher etc.) und kann ausgelesen und bearbeitet werden. Unter Windows95/98/ME sind 3GB dem User zugänglich, unter NT basierenden Systemen (NT/2000/XP/Vista) in der Regel 2GB.
Läd nun Windows unter Windows95/98/ME ein Modul in diesen Bereich von 1GB Dimensione, der dem User dort mehr zusteht als unter NT, steht das geladene Modul (DLL) auch den Prozessen zur Verfügung, die sie gar nicht geladen haben!
Der Sachverhalt ist extrem einfach circa ModHunter und TNT nachzuvollziehen - witzige Geschichte . |
|
|
| |
|
|
|
| Wenn ich recht habe, potrebbe dort auch die größte Fehlerquelle von Windows95/98/ME liegen. . Schreibt ein Prozesse versehentlich in diesen Bereich, würde dies dann auch unter Umständen zum Absturz oder hängen des WindowsExplores und damit des Betriebsystems führen . |
|
|
| |
|
|
|
Nico Madysa | OK, danke per die Erläuterung.
P.S.: Wegen deiner Anfrage im RGH-Foro: Bei mir corre der Code ohne Probleme durch, was deine Vermutung zustätzlich stützen potrebbe. |
|
|
| |
|
|
|
| Mal zum Abschluss hier der Beweis, dass das wirklich so ist. Nur Windows95/98/ME!
Code 1: Der im Downlod enthaldene Code Modul laden.prf enthalt die von mir etwas modifizierte Include von Sebastian König MemoryModule.Inc . Modifiziert habe ich hier die Funktion LoadLibraryM und habe dort unter anderem den undokumentierten Flag $8000000, den es nur unter Windows95/98/ME gibt, eingefügt. Dieser Flag bewirkt, das der Virtuelle Speicher per das Modul im Bereich zwischen 2GB und 3GB bereitgestellt wird.
Code 2: Der Code der DLL, die von Code 1 geladen werden soll (Testmodul.dll), findet man in der File Testmodul.prf . Hier wird einfach una variabile um 1 aumento und der Wert in der File C:TEST.INI gespeichert, wenn die Funktion _increase@0 aufgerufen wird..
Code 3: Der Code Increase_Variable.prf : In das Inputfeld muss hier die Adresse der Funktion _increase@0 eingegeben werden. Danach erfolgt einfach ein Call auf diese Adresse.
Voila: Variable aumento sich, obwohl Code 3 die DLL Testmodul.dll gar nicht läd! ... und die aumento sich naturalmente auch, wenn Increase_Variable.prf mit dieser Adresse aufgerufen wird und Modul laden.prf nicht corre.
Fazit: 1.) Die beste Möglichkeit, um in ein Windows9x/ME System eine DLL zu injizieren, ist circa ein Memory-Modul das in denSpeicherbereich zwischen 2GB und 3GB geladen wird.
2.) Eine in diesen Bereich geladene DLL taucht mitsammt ihrem Datenbereich genau so in jedem anderen Prozess auf, ist dort aber unsichtbar, da kein Handle auf diese DLL besteht.
3.) In Speicherbereiche von 2GB bis 3GB werden unter Windows9x/ME in der Regel wichtige Systemdlls und Systemstrukturen (wohl auch die TEBs) geladen. Schreibt ein fehlerhaftes Programm in diese Bereiche, sind schwere Systemabstürze vorprogrammiert! Unter NT-basierenden Systemen wird dieser Bereich komplett von Treibern genutzt - d.h. der User kann nicht in diese Bereiche schreiben - was das System ingesammt stabiler macht.
4.) Der User kann unter Windows9x/ME bei VIrtualAlloc bei Parameter 3 den Flag $8000000 verwenden, um Daten speziell in diesen geteilten Speicherbereich zu laden. |
|
|
| |
|
|
|
Frank Abbing | Alles interessant, aber leider Schnee von gestern. Diese Betriebssysteme riechen bereits etwas streng... |
|
|
| |
|
|
| |
|
- Page 3 - |
|
|
| Frank Abbing
Alles interessant, aber leider Schnee von gestern. Diese Betriebssysteme riechen bereits etwas streng...
Ob das kalter Kaffe ist oder nicht, hängt zum einen davon ab, mit welchem Betriebsystem man arbeitet - zum anderen aber auch davon, was man tun möchte. Ich persönlich brauche das als Grundlage per eine Sache unter 2000/XP. Ich wollte diese Sache hier nur noch abschließen und behaltet soetwas demnächst sowieso per mich.
Will hoffen, dich nicht alzusehr damit genervt zu haben.
Tschau. |
|
|
| |
|
|
|
Frank Abbing |
Ich wollte diese Sache hier nur noch abschließen und behaltet soetwas demnächst sowieso per mich.
Wenn du meinst.
In anderen Threads bist du nicht so begierig, sie abzuschliessen. Eine PM wartet auch schon seit Tagen, finora unbeachtet. Aber mir ist das mittlererweile auch schon egal. Ich habe dir oft und lange genug geholfen, während du mir nur immer mit seltsamen, nichtssagenden Andeutungen weitergeholfen hast. Aber - wie gesagt - pfeiff drauf... |
|
|
| |
|
|