| |
| |
|
 | 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  . |
|
| |
| |
| |
|
|
| | Das Modul mit der Adresse -1341456384 sieht aus wie die nvdd32.dll - und die dürfte zu meiner Grafikkarte gehören . |
|
| |
| |
| |
|
|
| Und Adresse -1074921472 scheint zu einer 20kB großen NTDLL.DLL zu passen, die sich in meinem Windows Systemordner befindet. Scheinen alles Windows-System-DLls zu sein.
Woher kommen diese DLLs und wie wurden die geladen? Warum sind die unsichtbar, wenn man die DLLs über die ToolHelp Funktionen listet??? |
|
| |
| |
| |
|
|
| | Hat jemand anderes von euch mal irgenwas geschrieben, was Module eines Prozesses mit den ToolHelp Funktionen (CreateToolhelp32Snapshot /Module32First/Module32Next) listet, damit ich damit mal testen kann, ob dieser Code alle Module anzeigt???? |
|
| |
| |
| |
|
|
| Vielleicht hat ja mal jemand Lust, das oben angesprochene unter Windows2000/XP zu bauen? Ich habe im Augenblick den Eindruck, Microsoft versteckt dort absichtlich etwas, um bestimmte Sachverhalte vor dem User und dem Programmierer zu verschleiern.  |
|
| |
| |
| |
|
|
| Nö Andreas,  da wird nichts versteckt oder verschleiert - aber ich habe jetzt eine Vermutung, woher diese Module kommen und wie sie geladen werden. Schreibe noch Code, um das zu beweisen oder zu widerlegen. |
|
| |
| |
| |
|
|
| Bingo!
Hier ist Code:
KompilierenMarkierenSeparierenDEF @GetModuleHandle(1) !KERNEL32,GetModuleHandleA
DEF @GetProcAddress(2) !KERNEL32,GetProcAddress
Declare Module2$,Module$,HModule&,Funktion&,Funktion$,Zero&,FileInfoSize&
LET Module$=VERSION
LET Module2$=$SYSPATH+KERNEL32.DLL
LET FUNKTION$=GetFileVersionInfoSizeA
Windowstyle 31
Windowtitle Call ohne Handle!
Window 0,0-640,440
Print Handle der Version.dll vor dem Laden: +@str$(@GetModuleHandle(@addr(Module$)))
Print
LET HModule&=@UseDll(VERSION)
Print Handle der geladenen Version.dll: +@str$(@GetModuleHandle(@addr(Module$)))
Print
LET FUNKTION&=@GetProcAddress(HModule&,@addr(Funktion$))
Print Funktionsadresse von +FUNKTION$+: +@str$(FUNKTION&)
LET FileInfoSize&=@Call(FUNKTION&,@ADDR(Module2$),@ADDR(Zero&))
Print FileInfoSize von Kernel32.dll vor dem Entladen: +@str$(FileInfoSize&)
Freedll HModule&
Print Handle der Version.dll nach dem Entladen: +@str$(@GetModuleHandle(@addr(Module$)))
Clear FileInfoSize&
$B Vor Call
LET FileInfoSize&=@Call(FUNKTION&,@ADDR(Module2$),@ADDR(Zero&))
$B Nach Call
Print
Print FileInfoSize von Kernel32.dll nach dem Entladen: +@str$(FileInfoSize&)
Print Handle der Version.dll nach dem Call: +@str$(@GetModuleHandle(@addr(Module$)))
Print
While 1
Waitinput
wend
Dieser Code dürfte auf allen NT basierenden Systemen (NT/2000/XP) abstürzen, auf allen nicht-NT basierenden Systemen (95/98/ME) aber funktionieren.
Wenn das irgendwo unter 95/98/ME nicht funktionieren sollte, bräuchte ich mal das zurückgegeben Handle der geladenen Version.dll .
Wo hauts hin, wo nicht??? |
|
| |
| |
| |
|
|
| Behauptung füt Windows95/98/ME:
Solange irgendein Prozess läuft, der die Version.dll über LoadLibrary (...) geladen hat, läuft der obige Code - hat kein Prozess die Version.dll geladen, stürzt der Code ab. |
|
| |
| |
| |
|
|
Frank
Abbing | | Stimmt, schmiert ab unter XP... |
|
| |
| |
| |
|
|
 | Das lässt weit blicken... nonNTs sind quasi gefährlich  |
|
| |
| |
| |
|
|
| iF
Das lässt weit blicken... nonNTs sind quasi gefährlich
Das ist sowieso der Fall, da absolut nichts abgesichert ist. Hier geht es mir aber eher um die Speicherverwaltung und um einen Sachverhalt, der unter NT-Systemen unsichtbar ist, da da das dort nur Treiber betrifft (oder betreffen kann).
Es geht hier auch nur um ganz bestimmte Module und nicht um alle! |
|
| |
| |
| |
|
|
| Bin ich mal gespannt was Du als unser Windows-Detektiv hier herausbekommst.  |
|
| |
| |
| |
|
(1.112)
Deutsch
English
Français
Español
Italia