| |
| |
|
| - page 1 - |
|
 | Ausgelesen avec ModHunter sous Windows98:
Version Windows: 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 qui ici comme Memory-Module Dinge wohl Treiber son  . |
|
| |
| |
| |
|
| |
| |
| - page 2 - |
|
|
| | je peux pour alle Detektive ici la fois ModHunter de meiner Page d'accueil empfehlen. ModHunter ist spitze et taugt pas seulement zum Scannen pour Trojanern! |
|
| |
| |
| |
|
|
Nico
Madysa | | Ähm, Andreas, je veux mich pas avec dir anlegen, mais je peux den ModHunter pas trouver. qui Zip de deiner HP contient ne DLL, un Video, une HLP, une CNT et ne GID, mais aucun EXE. |
|
| |
| |
| |
|
|
| | Tricolore justement encore einmal heruntergeladen - chez mir ist qui EXE là. peux cela la fois quelqu'un anders nochmal vérifier? |
|
| |
| |
| |
|
|
Nico
Madysa | Aargh, je nehm alles zurück. je hab qui EXE beim dans-une-Extra-Dossier-Déplacer übersehen, là qui Explorer qui EXE juste eingeordnet hat, sorry!  |
|
| |
| |
| |
|
|
| So, lieu maintenant la fois folgende Behauptung sur:
1.) Speicherbereiche au-dessus de de 2GB verhalten sich sous Wiondows95/98/ME genauso comment sous NT-basierenden System.
a) Virtuelle Adressen dans unterschiedlichen Prozessen verweisen sur qui gleichen realen Speicheradressen.
b) qui grenier wird dans jeden Prozess gleichermaßen gemappt. Wird un Speicherbereich dans einem Prozess zugewiesen, erscheint cette aussi dans allen anderen Prozessen.
cela bedeutet: Wird dans DLL sous Windows95/98/ME de einem Prozess dans Speicherbereiche au-dessus de de 2GB geladen, sommes en Exportfunktionen pas seulement im aktuellen Prozess, mais aussi dans allen anderen laufenden Prozessen sur Call aufrufbar, quoique là ne...aucune Handle sur qui DLL besteht.
=>
sous NT-basierenden Systemen gilt pour Speicherbereiche au-dessus de de 2GB:
Alle là durchgeführten Schreibaktionen erscheinen aussi im virtuellen Adressbereich aller anderen Prozesse des Systems.
So richtig? |
|
| |
| |
| |
|
|
Nico
Madysa | | Moment, est cela, si je Arbeitsspeicher sur 2 GB habe, peux je sous certain Bedingungen une DLL appel, oghne vous ouvert trop avons? |
|
| |
| |
| |
|
|
 | | non cela hat rien avec qui Taille des physikalisch zur Disposition stehenden Rams trop 1faire. |
|
| |
| |
| |
|
|
| allô Nico...
la fois entier simple:
Windows verschafft chaque Prozess quasi une eigenen Speicherbereich avec einer Taille de dans qui règle 4GB. qui obere Bereich cet virtuellen Mémoire wird vom Betriebsystem genutzt (dorthin volonté zum Beispiel Treiber geladen); qui User hat normalement keinen Zugriff puis, avec cela cela Betriebsystem sûrement fonctionne.
qui untere Bereich ist dem User zugänglich (Module magasin, Variablen grenier etc.) et peux ausgelesen et bearbeitet volonté.
sous Windows95/98/ME sommes 3GB dem User zugänglich, sous NT basierenden Systemen (NT/2000/XP/Vue) dans qui règle 2GB.
Läd eh bien Windows sous Windows95/98/ME un Modul dans cette Bereich de 1GB Taille, qui dem User là plus zusteht comme sous NT, steht cela geladene Modul (DLL) aussi den Prozessen zur Disposition, qui vous gar pas geladen avons!
qui état des choses ist extrem simple sur ModHunter et TNT nachzuvollziehen - witzige Geschichte  . |
|
| |
| |
| |
|
|
| si je droite habe, pourrait là aussi qui größte Fehlerquelle de Windows95/98/ME liegen.
.
écrit un Prozesse versehentlich dans cette Bereich, serait ca ensuite aussi sous Umständen zum Absturz ou bien hängen des WindowsExplores et avec cela des Betriebsystems mener . |
|
| |
| |
| |
|
|
Nico
Madysa | OK, merci pour qui Erläuterung.
P.S.: à cause de deiner Anfrage im RGH-Forum: chez mir fonctionne qui Code sans Probleme par, quoi deine Vermutung zustätzlich stützen pourrait. |
|
| |
| |
| |
|
|
| la fois zum Abschluss ici qui Beweis, dass cela wirklich so ist. seulement Windows95/98/ME!
Code 1:
qui im Downlod enthaldene Code Modul magasin.prf enthalt qui de mir quelque chose modifizierte Include de Sebastian König MemoryModule.Inc . Modifiziert habe je ici qui Funktion LoadLibraryM et habe là sous anderem den undokumentierten Flag $8000000, den es seulement sous Windows95/98/ME gibt, eingefügt. cette Flag bewirkt, cela qui Virtuelle grenier pour cela Modul im Bereich entre 2GB et 3GB bereitgestellt wird.
Code 2:
qui Code qui DLL, qui de Code 1 geladen volonté soll (Testmodul.dll), findet on dans qui Dossier Testmodul.prf . ici wird simple une variable um 1 augmenté et qui Wert dans qui Dossier C:TEST.INI gespeichert, si le Funktion _increase@0 aufgerufen wird..
Code 3:
qui Code Increase_Variable.prf :
dans cela Inputfeld muss ici qui Adresse qui Funktion _increase@0 eingegeben volonté. après erfolgt simple un Call sur cet Adresse.
Voila: Variable augmenté sich, quoique Code 3 qui DLL Testmodul.dll gar pas läd!
... et qui augmenté sich naturellement aussi, si Increase_Variable.prf avec cette Adresse aufgerufen wird et Modul magasin.prf pas fonctionne.
Fazit:
1.) Le meilleur Possibilité, um dans un Windows9x/ME System une DLL trop injecter, ist sur un Memory-Modul cela dans denSpeicherbereich entre 2GB et 3GB geladen wird.
2.) une dans cette Bereich geladene DLL taucht mitsammt ihrem Datenbereich oui c'est ca so dans chaque anderen Prozess sur, ist là mais unsichtbar, là ne...aucune Handle sur cet DLL besteht.
3.) dans Speicherbereiche de 2GB jusqu'à 3GB volonté sous Windows9x/ME dans qui règle wichtige Systemdlls et Systemstrukturen (wohl aussi qui TEBs) geladen. écrit un fehlerhaftes Programme dans cet Bereiche, sommes lourd Systemabstürze vorprogrammiert!
sous NT-basierenden Systemen wird cette Bereich komplett de Treibern genutzt - d.h. qui User peux pas dans cet Bereiche écrivons - quoi cela System ingesammt stabiler pouvoir.
4.) qui User peux sous Windows9x/ME chez VIrtualAlloc chez paramètre 3 den Flag $8000000 verwenden, um données speziell dans cette geteilten Speicherbereich trop magasin. |
 |
| |
| |
| |
|
|
Frank
Abbing | Alles intéressant, mais malheureusement Schnee de gestern. cet Betriebssysteme riechen bereits quelque chose streng...  |
|
| |
| |
| |
|
(1.110)
Deutsch
English
Français
Español
Italia