Yep, die Dateien sind identisch, nur heißen sie anders. Sind beide von alcohol, also Entwarnung. Grüße

edit: was hat eigentlich der scan mit RootkitRevealer ergeben?

Zitat von ordell1234

Sind beide von alcohol

Woher weißt du, wenn die Dateinamen doch zufällig erzeugt sind?

Ich habe fix ne Testversion von alcohol installiert und den gleichen Treiber zur Prüfung gesendet. MD5 ist identisch.

Alles klar, danke.
Vielleicht sollte ich mir mal Testversionen gängiger Rootkits zulegen.

Vielleicht sollte ich mir mal Testversionen gängiger Rootkits zulegen.

Mach dich zum remote-Admin deiner eigenen Kiste und ein sagenhafter Hauch der Macht umweht dich.

Zitat von Franz1968

Vielleicht sollte ich mir mal Testversionen gängiger Rootkits zulegen.

Soll ich dir zu dem Thema mal eine email schreiben?!

Hi 5ven,

wenn es dich nicht zu sehr stresst, würde ich gerne noch das Ergebnis eines Scans mit Gmer (wie oben beschrieben) sehen. Keine Panik, ich denke nicht, dass er was böses zeigen würde, er würde aber helfen, mit anderen Threads zu vergleichen, in denen vergleichbare Treibedatien auftreten.

Gruß und Dank,
Karl

BS: Win XP Pro, SP2, gmer 1.0.13:

- vor der Installation von alc120% -> nix im log
- nach der Installation von alcohol 120 % -> siehe gmer-alc.txt
- nach der Deinstallation von alcohol -> siehe gmer-no-alc.txt

Der spdt-Treiber wird über die normale Deinstall-routine nicht mit entfernt. Abhilfe schuf die von alkisoft getrennt angebotene Installation/Deinstalltion des spdt-Treibers, danach war GMER wieder blütenweiß.

Der sp**.sys-Treiber gehört ebenfalls zu Alcohol (oder IST der spdt.sys ), liegt in system32\drivers und ändert seinen Namen nach jedem Neustart.

Hoffe es hilft dir.


---------------------
OT:
Karl, mal ne Frage: Im Forum tauchte die Frage auf, was es mit dem Präfix \??\Windows... bei bestimmten Pfadangaben auf sich hat. Nach meiner Wahrnehmung tritt das oft im Zusammenhang mit dem Auslesen von Kernelmodulen auf.

Ein Blick ins Win-Internals-Buch hat folgendes zutage gefördert:

Kapitel 3, Object Manager:
One place in which the executive uses symbolic link objects is in translating MS-DOS-style device names into Windows internal device names. In Windows, a user refers to floppy and hard disk drives using the names A:, B:, C:, and so on and serial ports as COM1, COM2, and so on. The Windows subsystem makes these symbolic link objects protected, global data by placing them in the object manager namespace under the \?? object directory on Windows 2000 and the \Global?? directory on Windows XP and Windows Server 2003.

Session Namespace[..]A user logged on to the console session has access to the global namespace, a namespace that serves as the first instance of the namespace. Additional sessions are given a session-private view of the namespace known as a local namespace. The parts of the namespace that are localized for each session include \DosDevices, \Windows, and \BaseNamedObjects. Making separate copies of the same parts of the namespace is known as instancing the namespace. Instancing \DosDevices makes it possible for each user to have different network drive letters and Windows objects such as serial ports. On Windows 2000, the global \DosDevices directory is named \?? and is the directory to which the \DosDevices symbolic link points, and local \DosDevices directories are identified by the session id for the terminal server session. On Windows XP and later, the global \DosDevices directory is named \Global?? and is the directory to which \DosDevices points, and local \DosDevices directories are identified by the logon session ID.

[..]

All object manager functions related to namespace management are aware of the instanced directories and participate in providing the illusion that nonconsole sessions use the same namespace as the console session. Windows subsystem DLLs prefix names passed by Windows applications that reference objects in \DosDevices with \?? (for example, C:\Windows becomes \??\C:\Windows). When the object manager sees the special \?? prefix, the steps it takes depends on the version of Windows, but it always relies on a field named DeviceMap in the executive process object (EPROCESS, which is described further in Chapter 6) that points to a data structure shared by other processes in the same session.

Quelle: Microsoft® Windows® Internals, Fourth Edition: Microsoft Windows Server™ 2003, Windows XP, and Windows 2000
By Mark E. Russinovich, David A. Solomon

Nun geht mir das deutlich zu sehr in die Tiefen von Windows. Hast du evtl ne Erklärung für Normalsterbliche auf Lager?

Grüße nach Mexico, ordell