Rootkit verschiebt Windows in virtuelle Maschine

Rootkit verschiebt Windows in virtuelle Maschine (40 Beiträge, 391 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

http://www.heise.de/newsticker/meldung/79676

Auf dem Ende Oktober stattfindenden, von Microsoft initiierten Hackertreffen BlueHat soll ein weiteres Virtual Machine Rootkit vorgestellt werden, das in der Lage ist, Windows zur Laufzeit in eine virtuelle Maschine (VM) zu verschieben. Das Vitriol getaufte Rootkit nutzt dazu Intels Virtualization Technology (VT-x, ehemals Vanderpool). Anders als bei Software-Virtualisierungstechniken bieten auf Hardware beruhende Virtualisierungslösungen direkte Unterstützung durch den Prozessor.

Das in eine VM verschobene Windows oder Linux hat anschließend keinerlei Möglichkeiten mehr, das Rootkit zu erkennen, da es außerhalb seines Wahrnehmungshorizontes läuft. Virenscanner und Rootkit-Schnüffler haben so ebenfalls keine Chance mehr, das System zu schützen. Auch Vistas neue Kernelschutzfunktionen für 64-Bit-Systeme PatchGuard und Treibersignierung wären dann nutzlos. Vitriol wurde vom Sicherheitsspezialisten Dino Dai Zovi entwickelt und bereits auf der vergangenen Black-Hat-Konferenz vorgestellt (Link zu PDF-Dokument) – allerdings nicht vorgeführt. Joanna Rutkowska hingegen hatte auf der Black-Hat einen Prototyp ihres Blue Pill genannten VM-Rootkit in der Praxis gezeigt. Blue Pill nutzt AMDs Virtualisierungslösung SVM/Pacifica, um Windows während des Betriebs einen Hypervisor unterzuschieben. Auch Microsoft untersucht mit seinem Proof-of-Concept-Rootkit SubVirt die Auswirkung von VM-Rootkits.

Zur BlueHat werden nur ausgewählte Sicherheitsspezialisten eingeladen, um mit Microsoft über Schwachstellen zu diskutieren. Auf der vergangenen BlueHat waren unter anderen David Litchfield, Halvar Flake, HD Moore und Alexander Kornbrust unter den Vortragenden zu finden.

Siehe dazu auch:

Rootkit infiltriert Beta-Version von Windows Vista, Meldung auf heise Security
Microsoft demonstriert Virtualisierungs-Rootkit, Meldung auf heise Security
(dab/c't)

Genial. Genial einfach (zumindest vom Prinzip her)

Die Frage ist - das Host-System kann dann ja prinzipiell auf jeden Speicherbereich zugreifen - inwiefern dieser geschützt ist.

"Guido, da ist eine echte Michaele Schuhmacher Ferrari in meine Laden. Eine echte Ferrari. Zwick mich, Guido, zwick mich. Das hier, ist die glorioseste Tag von meine Leben."

Im Prinzip nur so weit wie das Host System dies wünscht, logischerweise.

Als System hast Du zwangsläufig vollständige Kontrolle über Deinen Ram. Daß ein Programm das innerhalb des Systems läuft nicht darüber verfügen darf kannst Du bestimmen, als Programm kannst Du aber nicht verhindern daß das System in Deinem Adressraum rumpfuscht.

________________________________________________________________________
There's a typo in the Bible.
It should read "The geek shall inherit the earth".

Sprich, der Host kann im Prinzip tun und machen was er will.

"Guido, da ist eine echte Michaele Schuhmacher Ferrari in meine Laden. Eine echte Ferrari. Zwick mich, Guido, zwick mich. Das hier, ist die glorioseste Tag von meine Leben."

Latürnich. Er muß schließlich den Speicher des Guest-Systems verwalten, entsprechend hat er auch darauf Zugriff.

________________________________________________________________________
There's a typo in the Bible.
It should read "The geek shall inherit the earth".

Inwiefern ermöglicht Windows dass das möglich ist? Wo genau liegt da der Unterschied zu einem Unixoiden?

Ich kann ein Unixoid ja auch innerhalb einer virtuellen Umgebung laufen lassen.

"Guido, da ist eine echte Michaele Schuhmacher Ferrari in meine Laden. Eine echte Ferrari. Zwick mich, Guido, zwick mich. Das hier, ist die glorioseste Tag von meine Leben."

Ömm... im Prinzip gibt's da keinen Unterschied. Höchstens die Möglichkeit daß das Linux in der virtuellen Umgebung ggf. nicht läuft weil die notwendigen Treiber im Kernel nicht vorhanden sind.

________________________________________________________________________
There's a typo in the Bible.
It should read "The geek shall inherit the earth".

Na dann hab ich das eh richtig verstanden .. Danke

"Guido, da ist eine echte Michaele Schuhmacher Ferrari in meine Laden. Eine echte Ferrari. Zwick mich, Guido, zwick mich. Das hier, ist die glorioseste Tag von meine Leben."

Das hat nix mit dem System zu tun das in der VM läuft (vorausgesetzt es "kann" mit der vorgegaukelten Hardware, allerdings geh ich mal davon aus, daß ein Trojaner schon so programmiert wird, daß er sein Zielsystem laufen lassen kann). Fakt ist, das System hat die Oberhoheit über den Speicher, und Du kannst ihm diese Hoheit nicht entziehen.

De facto ist es so, daß das Gastsystem als "Programm" in der VM läuft. Und als solches hat es sich zwangsläufig dem Hostsystem unterzuordnen.

________________________________________________________________________
There's a typo in the Bible.
It should read "The geek shall inherit the earth".

Jaja. Wie die Virtualisierung im Prinzip funktioniert ist mir klar. Ich wollt eher darauf hinaus, ob ein derartiger "hack" auch bei einem Unixoiden möglich wäre.

Ein "laufendes" System zu verschieben hat schon was

"Guido, da ist eine echte Michaele Schuhmacher Ferrari in meine Laden. Eine echte Ferrari. Zwick mich, Guido, zwick mich. Das hier, ist die glorioseste Tag von meine Leben."

Hmm... also ich würde hergehen, die Bootmaschinerie entsprechend ummodeln und dann das System gepflegt abballern, damit ein Neustart ausgeführt wird.

________________________________________________________________________
There's a typo in the Bible.
It should read "The geek shall inherit the earth".

Reboot is fad ... da oben steht "zur Laufzeit" .. ohne dass es ein Benutzer merkt ... DAS hat was ..

"Guido, da ist eine echte Michaele Schuhmacher Ferrari in meine Laden. Eine echte Ferrari. Zwick mich, Guido, zwick mich. Das hier, ist die glorioseste Tag von meine Leben."

völlig richtig. Vor allem bei selbstcompilierten Kernel ohne Module wird sich so ein Rootkit schwer tun.

Remember what the dormouse said: Feed your head!

Nicht zwingend...

Denn im Prinzip könnte der Hypervisor-prozeß ja alle Zugriffe vom Linux-Kernel "abfangen" und selbst genauso durchführen.

Der Hypervisor könnte also dieselbe HW-Plattform anbieten, auf der er eh rennt - alleine ein bißchen Memory müßte er abzwacken.

Performancetechnisch würdest du das kaum merken, da Prozessoren bei HW-Zugriff eh nur mit warten auf die HW beschäftigt sind... Und er hat es einfacher, weil er ja nur ein Guest-OS laufen hat und daher kein/kaum Ressourcenscheduling durchführen muß.

Ach ja, eines noch zur HW...
Unter XEN als HV kannst mit VT ein ungepatchtes XP installieren und laufen lassen - und unter Win merkst es net.... war mal auf Heise.

Ich frage mich aber nur, wie man das nutzen will - also welcher Vermehrungs- bzw. Fernsteuerungscode im Hypervisor dort laufen sollte.

Des weiteren ist mir einfach net bekannt, ob sich Hypervisoren kaskadiren lassen...
Also angenommen, ich hab schon einen Hypervisor laufen (Sobald ich einen VT/Pazifica-Prozzi habe, kommt sicher sofort XEN drauf) - dann wird's wohl net klappen (weil ja der laufende Hypervisor kaum die Hypervisor-calls zuläßt).

VT an sich finde ich jedenfalls saugeil - ich freue mich schon total drauf.
OS hochziehen ohne downtime ? Oder gar wechseln von IIS auf LAPP ? Lösbar...

Einfach in einem neuen Guest alles vorbereiten, den booten (produktivsystem bleibt up) - und wenn grad keine Session offen ist einfach switchen... Noch besser bei einem DB-Servercluster. Einfach neuen Guest mit höherer DB-Version starten, in den Cluster stellen, "original"-DB aus dem Cluster entfernen - und du hast hochmigiriert ohne daß benutzer eine einzige Session verlieren (nicht einmal unkommitierte)... *FREU*

Naja das komplette "Abfangen" eines Systems seh ich schon als etwas problematisch an.
Klar ist irgendwann greift der Kernel direkt auf die Hardware zu. Nur wie fängst direkte HW-Zugriffe effektiv ab ? Ich nehm an dieses Rootkit fängt die mov's einfach ab und gibt diese weiter an die direkte Hardware. Die weiteren Zugriffe zu blocken ist ja kein Problem, vor allem nicht an den Kernel, da es ein leichtes Spiel ist (DOS-Viren lassen grüßen) die IRQ-Tabelle zu manipulieren.

IMO ist es nicht möglich eine komplette virtuelle Plattform ohne dementspr. Performanceeinbußen anzubieten => Du mußt ja auch die dementspr. Speicheradressen dem System zur Verfügung stellen auf die dann die HW-Zugriffe "gemapt" werden. Wär's nur eine reine IRQ Sache, wärs um einiges einfacher.

Remember what the dormouse said: Feed your head!

Klar ist irgendwann greift der Kernel direkt auf die Hardware zu.

Und hier beginnt dein Denkfehler

Ich kenne es nur aus der Hostebene - und vermute, daß VT da ähnlich rennt.

Stelle es Dir vor wie den Unterschied zwischen Real-Mode und Protected Mode... Und DOS damals.
REAL-Mode Programme glauben, daß sie direkt auf der HW laufen - und lösen Exceptions im Protected Mode aus, der das ganze mapped.

Aktuelle Intel-OSsen (Linux, Windows, MacOS) sind nun [noch] nicht VT-aware - und merken genausowenig wie realmode-Proggys damals, daß sie eben nicht direkt auf die HW zugreifen.

Der Witz dabei ist nun auch, daß [vermutlich, VT habe ich mir im Detail noch nicht angesehen, da ich leider so eine Maschine net hab - schluchz] ja nur ein zusätzlicher Indirektionsgrad dazukommt...

Indirektionsgrade waren früher teuer (man sah richtig, wie mein 386er langsamer wurde, wenn qemm gestartet wurde) - aber heute nix kosten... denn ob die CPU nun 100 Taktzyklen vershißed beim Memory-Zugriff oder 105 - bleibt gleich.

Und... Solange nur ein Guest am laufen ist, braucht der Hypervisor mal gar nix abfangen sondern kann alles durchlassen - bis eben auf die paar KB Ram, die er selbst braucht.

Oder anders:
Wenn du Windows in einer VM laufen hast - brauchst virtuelle NW-Treiber, ...
Windows unter XEN mit VT braucht genau die HW-Treiber der HW, die du hast...

Einige HW-VT-Lösungen (AIXen) gehen ja dorthin, daß du eben keine virtuellen LW und so hast, sondern sagst "Der erste SCSI-Controller gehört Guest1, der 2. Guest2, ..."

Und sowas kostet - vermutlich - echt null cpu..

Naja irgendwann MUSS der Kernel direkt auf die Hardware zugreifen, sonst ist kein Betrieb möglich... bei manchen Linux-Treibern (ich red hier nur von Linux, Win kenn ich ned so genau) wird sogar explizit auf Adressen geschrieben, siehe parport_pc.c (als einfaches Beispiel). Und hier beginnt genau das beschrieben Problem: Eine VM müsste quasi diese ganzen Adressen mappen, wohlwissentlich das es nicht wirklich eine 100% Darstellung erreichen kann, bzw. diese nur mit performanceverlusten, die merkbar wären.. wie gesagt, wärs nur IRQ-Basierend wärs easy.. soviel ich weiss, geht das unter Windows ähnlich ???

Alle DOS-Programme fahren direkt auf die Hardware, das hat nix mit den Modis zu tun in denen du die CPU versetzt...deswegen teilw. auch die Probleme sobald ein älteres DOS-Programm auf z.B. die serielle hinfährt..kannst heute vergessen da das explizit der Kernel machen muß um ggf. Fehler der HW-nahen Programmierung abzufangen..

Remember what the dormouse said: Feed your head!

Hmmm...

AFAIK (ist laaaaange her) konntest über 3 Arten mit HW reden:
1.) IRQ
2.) Schreiben in Speicherstellen

Beides läßt sich leicht vom OS handeln - wird ja auch so gemacht.
Ein IO an Speicherstelle 1234 geht mal runter zur LDT/GDT - und wird auf eine physikalische Adresse gemappt. Jede Speicherseite hat nun ein "präsent"-Bit... Und wenn die Seite nicht präsent ist, wird eine Exception ausgelöst (um zB die Seite vom Swap einzulesen)..

DOS-Programme unter Linux oder Windows laufen mal genauso ab wie bisher - sie bleiben im Real-Mode und wollen zB via Adresse 0x220 mit dem Soundblaster kommunizieren...

Das OS (Windows/Linux) markieren die Seite für den Prozeß (LocalDescriptorTable) als net präsent - und fangen so die Exception ab und können das Verhalten emulieren.

Dadurch reden Dos-Proggies unter Win2k /nie/ direkt mit der HW - auch wenn sie es glauben - weil sie net ProtectedMode-Aware sind.

Ein HV hats nun einfach, wenn er nur einen einzigen Guest supporten muß - er kann alle Zugriffe (egal ob PCI-Bus, ,....) einfach zulassen und muß nur sich selbst (also 20k Ram oder so) schützen.

Dadurch kostet das ziemlich genau 0 Performance... Vermutlich

konntest über 3 Arten mit HW reden:
1.) IRQ
2.) Schreiben in Speicherstellen

Jein, Du konntest Hardware via Speicherstellen schreiben ansprechen, die meisten IRQ's die es damals gab, waren allerdgins Servicedienste von MSDOS. Man erinnere sich an das bekannte mov al,04h int21h

Soviel ich jetzt noch weiß gabs überhaupt damals nur 3 oder 4 NMI..
Tastatur, Div by Zero, und ein HW-Timer... wobei ich mir ned sicher bin ob der Timer ned doch eine SW gschicht von DOS war..

Ports ham aber nix mit Speicheradressen zu tun, sondern liegen auf einem anderen Bus.

Ja das natürlich, das ja schon von der CPU her so implementiert das Du Pages direkt als RM geflaggte Speicherteile an RM-Proggies weitergibst. Aber perv. hat ja gemeint das ein komplettes OS da hineingehoben wird, das stell ich mir dann nimmer sooo easy vor.. da das OS ja sich selbst in den PM stellt, auf die das Rootkit selbst afaik nicht zugreifen dürfte..
Wenn jetzt $0000:0000 - $0000:00FF protected ist, kann das Teil schon wieder Nüsse machen, da es nedmal die IRQ's verbiegen kann...

Remember what the dormouse said: Feed your head!

Jein, Du konntest Hardware via Speicherstellen schreiben ansprechen, die meisten IRQ's die es damals gab, waren allerdgins Servicedienste von MSDOS. Man erinnere sich an das bekannte mov al,04h int21h

Ist so net ganz richtig, denke ich (aber ist mir auch zu lange her).
Einerseits blendete sich viel HW in die Speicherbereiche ein - Damals war ja VGA-Assemblercoden noch was "for real men"

.

Zweitens kommunizierst viel mit HW per IRQ (bzw. die HW liefert so die Rückmeldung). Beispiel LPT - du kannst wahlweise pollen oder eben auf interrupt-requests antworten..

Bei den Interrupts fällt mir mal der kaskadierte 2er/9er ein, VGA hatte einen, Ide-Controller, Soundblaster...
Das war doch die "schöne" Zeit mit Interruptkonflikten der HW, ...

Div By Zero hingegen löste IMHO eine Exception aus - die was anderes als ein Interrupt ist.. (Auch wenn sie implizit einen Auslöst). Exceptions gab's doch ein paar, oder ? Waren da nicht zusätzlich zu "DIVISION BY ZERO" "Single-Step-Debugmodus", FPU-Exception, Alignment-Fehler, .. ?

Jop genau, die berühmte $A000:0000

)

Des stimmt schon, aber guck Dir diese Teile mal im Vergleich zu dem schier riesigen MSDOS-Service-Aufgebot an (http://www.cs.cmu.edu/afs/cs/user/ralf/pub/WWW/files.html )

Jein das war auch eher selten: Oft hast z.B. gesagt mov ax, 400fh (40 = Main 0f = service) int xxh. Returnwerte wurden da defaultmässig (so die MSDOS Programmers ToDo) auf DX returned, da das DX von Intel/MS explizit als Datenregister genutzt worden ist, entweder via normales Statusbyte/word oder halt durch eine absolut Adresse.

Div by Zero war Int 00h

http://en.wikipedia.org/wiki/BIOS_call ... schauderlich heute das anzusehn ..

Naja Exceptions.. mhh.. also die Exception war das Du halt den interrupt verbiegen konntest auf deine eigene Exception-Routine (sonst wären die ja nie abzufangen gewesen).

Remember what the dormouse said: Feed your head!

Nun denn...

Erstmals mußt zwischen software- und hardware-Interrupts unterscheiden...
Hardware-Interrupts kamen damals (vor APIC) eben via dem Interrupt-Controller, der nur 8 Steuerleitungen hatte.
Drum waren ja (außer bei den allerallerersten) 2 Interrupt-Controller Kaskadiert - Steuerleitung 2 kam zu Interrupt 9.

Software-Interrupts sind von der Logik her nix anderes als seeehr bequeme JumpToSubroutine, was insbesondere wegen der Segmentregistergschichten (*grusel*) auf Intel wichtig war.

HW-Interrupts gab es daher von 1-15
- 1-6 und 8 war vom ersten
- 9-15 vom zweiten

Div-by-Zero war eben kein "NORMALER" int00h...
Stattdessen wurde von der Logik INT00 verwendet um Exceptions zu "transportieren".
Sie sind aber komplett was anderes und verhalten sich anders.als alle anderen HW-Interrupts.

Beispiel:
Du hattest ja das Interrupt-Enable-Flag (Das natürlich nur für HW-Interrupts galt, da das System ja sonst sinnlos wäre). Exceptions (die ja auch durch HW getriggert werden wie zB wrong alignment, FPU-Error, ...) kamen aber als Exception und Exceptions funktionierten immer, egal welchen wert das Interrupt-Enable-Bit hatte.

Beleg:
ftp://download.intel.com/design/Pentium4/manuals/25366821.pdf

Und ad Dos-Interrupts...

Sag mal, warst du Real-Mode-Coder ? *mitDemFingerZeig-und-Haha-Ruf*

Dos und Protected Mode war net so "kompatibel"

Jo des schon klar, des haben wir aber in unserem Eingangsposting schon gehabt mit SW<->HW Interupts

Auch des is klar, statt eines jsr wird halt der PC auf die Adresse von dem dementspr. IRQ gelesen und gesetzt...

Jo des kann ich ja auf alles anwenden, ob da Int00 "geraised" wurde oder ob der User Print Screen drückt, das alles läuft auf dieser einfachen Sache raus, PC -> Stack => Adresse holen -> PC => abarbeiten => Stack -> PC, und da wars egal welcher IRQ raised..

Des schon sicher richtig, ändert aber nix daran das die IRQ's alle auf demselben Prinzip gearbeitet haben, und die das (endlich mal) konsequent durchgezogen wurde..

Jop... hab aber hauptsächlich HW-nahe Sachen gemacht, hauptsächlich GFX-Sachen, da iss der Protected Mode so uninteressant wie nur irgendwas, auch wenn ichs gelernt hab den anzusprechen..

Remember what the dormouse said: Feed your head!

Jop... hab aber hauptsächlich HW-nahe Sachen gemacht, hauptsächlich GFX-Sachen, da iss der Protected Mode so uninteressant wie nur irgendwas, auch wenn ichs gelernt hab den anzusprechen..

War schon klar, daß es da um Hardwarenahes ging - denn sonst macht Asse ja kaum Sinn (bzw. sonst würde man sicher alles in damals Pascal, C oder eventuell schon C++ schreiben und nur die kritischen Sachen in Asse)... Denn die immerhin 5-10fache Speed des Original-PCs gegenüber einem C=64 zeigte schon, daß man dann auch mit dem Performanceverlust von 5-10 bei den damalig kaum optimierenden Compilern leben konnte...

Wobei gerade bei Graphic- und Datengschichterln war ich begeistert vom Protected Mode...
Denn die 64K_Segmentschiebereien waren echt (zumindest in meiner Sicht) massivst gschißn.
Ich habe mich damals aber nur auf Standard-VGA, Standard-Herkules (die genialste Monitor-Karten-Kombi überhaupt) und die Vesa-Modi verlassen... Soweit ich mich erinnere letztendlich nur auf Standard-VGA (Mode 10 oder 13 läutet bei mir im Hinterkopf - so wie bei Dir Int00

)

Ach ja, 2 Off-Topic-Fragen:
1.) mein alter Herkules-Monitor hat ein durchlaufendes Bild - kennst jemand in Wien, der das im Pfusch richten kann ? Drehen an den Schrauben hinten brachte nix - und die GraKa ist fix in meinen Server eingebaut (der immer up ist), also müßte der selbst noch so ein Teil haben zum Testen...

2.) [nur Interessehalber]:
Ich hatte unter Linux auf tty13-16 meine Herkules-Graka - und auf 1-12 meine Matrox Millenium.
Wenn ich nun auf tty13 arbeitete (also MDA/Herkules) und auf Ctrl-F7 tippte (für X) - so stellte X scheinbar meinen Herkules-Monitor auf schwarzes Bild). Wenn ich "nur so" wechselte (also zB von tty1 auf tty13), gab es das Problem net... Ich habe echt gegraben und damals keine Konfig von X gefunden, die das verhindert... Wie wäre das gegangen (nicht mehr so relevant, weil derzeit kein X am Server).
Müßig zu erwähnen, daß das natürlich wieder ein reines Linux-Problem ist, denn unter WinXP habe ich NULL/NADA/KEINE Herkules-GraKa-Probleme

Naja war damals ned wirklich interessant für die Sachen. Code ging sich in 64kb ja locker aus, und der Mode 13( 320x200x256 Cols 8Bits/Pixel) war ja wie geschaffen dafür

.

Das aber heute auch noch so. Schau dir z.b. die gängigen Compiler von Visual Studio bishinzu GCC an, was die für Crap an Code erzeugen.. für ein kleines if (x < 0) printf ("smaller\"); else printf ("larger\n"); wird ein Code erzeugt der schon 20x durch die Abarbeitung springt und damit den Code ENORM verlangsamt (brauch ja jetzt wohl ned ausführen was bei einem jne/jle branch passiert

). Ich mach ja heute auch noch ab und an sowas, mach das auch noch alles unter Assembler, find das ganz nah an der CPU sein echt genialst..

1.) Ich kann mal schaun ob ich Kontakt zu einem Ex-Mitarbeiter bekomm der hat bei meiner Exfirma Monitor repariert.. aber kanns ned versprechen..

Hast auf beiden Karten einen XServer laufen gehabt ? Weil da kannst explizit den Bus einstellen den er nutzen soll...

Remember what the dormouse said: Feed your head!

Periodisch hatte ich auf beiden X...

Spiele am Herkules unter X waren superlustig... wirklich extreme Schlieren wegen der Nachleuchtzeit - aber das allerallerangenehmste Arbeiten weil so ein ruhiges Bild...

Und auch die alten borland-Tools damals... Superst. Debugsession am Herkules, Programmablauf unter VGA... Feinst.

Uff ne sorry das eine Konfig die hatte ich auch noch nie..

Also ich habs bei mir mit einer TVOut Karte so:

- Desktop wird mit FullX gestartet (WM etc.)
- TVOut X wird seperat gestartet mit MiniX Config also nur das Proggy zum abspielen von Videos.

Da kannst direkt festlegen was er wo ansprechen soll in der Config.. aber k.a. ob das für Deine Anwendung auch richtig klappt.

Remember what the dormouse said: Feed your head!

Nun ja, da hast ja was ganz was anderes....

Denn vielleicht macht(e) X das ja per default auf allen Grakas, daß es mal im Textmodus auf schwarz stellte...
und du hingegen hattest auf der TV-Karte wohl kaum einen getty laufen, nehme ich an ... Kann sein, daß es auch am Getty lag... aber eh nicht mehr relevant

Mhhh nein das natürlich nicht, das wurde alles von X aus dann geregelt, das noch mit NVidia Treibern also hat ned wirklich was mit der Config von Dir zu tun. Die restlichen Kisten haben nedmal eine GraKa (vnc/ssh rulez)... bin da leider der Falsche

Remember what the dormouse said: Feed your head!

Was ist eine Virtual Machine? (:

Das wirst auch du herausfinden können (ob ich da mal nicht täusche). Wikipedia, Google, etc. geben dir sicher gerne Auskunft.

http://de.wikipedia.org/wiki/Virtuelle_Maschine

Remember what the dormouse said: Feed your head!

Nur gut das ich AMD verwende und keine Intel Hardware.

(sigkilled v1.8 (Wed Oct 18 19:57:00 2006): gesperrte externe URL gefunden)

amd hat doch auch so eine virtualisierungstechnologie, warts ab

________________
Mein Notebook:
Maxdata Pro 8100X

Nur gut das ich AMD verwende und keine Intel Hardware.

Und? Dann komme ich statt durch Tor "I" eben durch Tor "A". Das war's dann aber auch schon.

Du kannst aber natürlich gerne vorsintflutliche Hardware einsetzen (so etwa 386 bis Pentium Schnee), dann bist Du zwar arbeitsunfähig, aber vor dieser Malware sicher. (Dafür quälen Dich dann wieder die Viren der Urzeit. )

GrummelGrumpf

24.10.2006, 11:50 Uhr - Editiert von GrummelGrumpf, alte Version: hier

Und? Dann komme ich statt durch Tor "I" eben durch Tor "A". Das war's dann
aber auch schon.

Plonk das schnell bevor es der phj liest.

lG Mike
Das Ende des GHF naht... *klick*

Du kannst aber natürlich gerne vorsintflutliche Hardware einsetzen (so etwa 386 bis Pentium Schnee), dann bist Du zwar arbeitsunfähig, aber vor dieser Malware sicher. (Dafür quälen Dich dann wieder die Viren der Urzeit

LOOOOOL.... Ein Jurassic-Park-Gschichterl ?

Aber im Ernst... Gibt es besagte Viren noch ? Und... Ist ein normaler Pentium4 (also ohne VT) echt schon so Urzeitmäßig ????

LOOOOOL.... Ein Jurassic-Park-Gschichterl ?

Ganz genau.

Gibt es besagte Viren noch ?

Ja, tatsächlich. Ich staune auch immer wieder, was sich an Methusalems auf ungeschützen PCs finden lässt.

Und... Ist ein normaler Pentium4 (also ohne VT) echt schon so Urzeitmäßig ????

Erstens "Ja." und zweitens meinte ich eher Pentium I und II...

GrummelGrumpf

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung