| |
| |
|
| - 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 - |
|
|
| | Ich kann per alle Detektive hier mal ModHunter von meiner Homepage empfehlen. ModHunter ist spitze und taugt nicht nur zum Scannen nach Trojanern! |
|
| |
| |
| |
|
|
Nico
Madysa | | Ähm, Andreas, ich will mich nicht mit dir anlegen, aber ich kann den ModHunter nicht finden. Die Zip von deiner HP enthält ne DLL, ein Video, eine HLP, eine CNT und ne GID, aber keine EXE. |
|
| |
| |
| |
|
|
| | 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...  |
|
| |
| |
| |
|
(1.109)
Deutsch
English
Français
Español
Italia