Software PC Phone Home - wie kann die funktionieren?

[Stefan]

Hallo,
ich bin heute auf http://www.chip.de/news_stories/news_stories_8771062.html gestoßen. Der Hersteller schreibt, dass sich (zumindest die kostenpflichtige Version) nicht durch Formatierung/fdisk entfernen lassen soll. Wie kann das funktionieren? Kann das überhaupt gehen? Wenn die Platte in einen anderen Computer eingebaut wird (ok, bei Notebooks nicht so einfach, aber laut Hersteller ist das Programm nicht nur für Notebooks) oder von Diskette gebootet wird (mal vorausgesetzt, dass das nicht irgendwie per BIOS gesperrt ist) lässt sich doch alles platt machen oder etwa nicht?

[Henryk Plötz]

Moin,

ich bin heute auf http://www.chip.de/news_stories/news_stories_8771062.html gestoßen. Der Hersteller schreibt, dass sich (zumindest die kostenpflichtige Version) nicht durch Formatierung/fdisk entfernen lassen soll. Wie kann das funktionieren?

Naja, etwas das sich in den Bootsektor schreibt, könnte eine einfache Festplattenformatierung überleben, beim Neupartitionieren bin ich mir nicht sicher, und ein einfaches   fdisk /mbr   putzt es in jedem Fall weg. Oder man könnte bei bestimmten Modellen vielleicht auch ein eigenes Programm im evt. vorhandenen Flash-BIOS unterbringen. In jedem Fall hätte das Programm dann aber keine Kontrolle mehr über die Internetverbindung sobald erst mal das Betriebssystem geladen ist.

Kann das überhaupt gehen?

Nein. Das klingt für mich nach snake oil.

Die Leute verspielen ihre potentielle Glaubwürdigkeit schon im Ansatz, indem sie die 'Ortung' per IP-Addresse vornehmen wollen.

--
Henryk Plötz
Grüße aus Berlin

[Slyh]

Hallo,

Naja, etwas das sich in den Bootsektor schreibt, könnte eine einfache Festplattenformatierung überleben,

Wenn ich das Prinzip des Bootsektors richtig verstanden habe, kann dort
nur ein sehr kleines Programm (512 Bytes?) abgelegt werden, das dann
die zum Betriebssystem-Start notwendigen Dateien lädt.
Ein ausgewachsens Windows-Programm kann dort also wohl nicht abgelegt werden.
Dieses müßte sich trotzdem noch an einer (festen?) Stelle auf der Festplatte
befinden.
Beim Formatieren - spätestens aber beim Partitionieren - wäre dieses dann
aber verloren. Ein Überschreiben des MBR - wie du ja schon sagtest - wäre
wohl auch recht effektiv was das Entfernen des Programms angeht. :-)

Daß da etwas im Flash-BIOS gespeichert wird, halte ich für höchst unwahrscheinlich.
Schon alleine deshalb, weil das Beschreiben des Flash von Hersteller zu Hersteller
und BIOS-Version zu BIOS-Version unterschiedlich funktioniert. Außerdem
wird der BIOS-Hersteller sicherlich auch keinen teuren Platz im Flash-Speicher
zu verschenken haben...

Gruß
Slyh

[Philipp Hasenfratz]

Halihallo

Naja, etwas das sich in den Bootsektor schreibt, könnte eine einfache Festplattenformatierung überleben,

Wenn ich das Prinzip des Bootsektors richtig verstanden habe, kann dort
nur ein sehr kleines Programm (512 Bytes?) abgelegt werden, das dann
die zum Betriebssystem-Start notwendigen Dateien lädt.

Ja, das stimmt. Programme im Bootsektor werden auch meistens nur dazu verwendet, um dann die System-Komponenten zu laden (primitiv gesagt eine Linksammlung, was als nächstes geschehen soll)... Wenn das genannte Programm wirklich so funktioniert, müssten noch zahlreiche andere Dateien irgendwo auf der Festplatte liegen (512 Bytes reichen nur für kleine Assemblerprogramme => Viren z. B.)

Dieses müßte sich trotzdem noch an einer (festen?) Stelle auf der Festplatte
befinden.

Fest nicht, aber es muss sich irgendwo verstecken. Beim Low-Level-Format gehen diese Daten jedoch verlohren. Ein High-Level-Format könnten die Daten überleben (meistens wird dann nur die FAT bzw. Nodes neu erstellt)... Jedoch, um ein Programm in 512 Bytes zu coden, welches dann auch noch die versteckten anderen Dateien findet halte ich für fast unmöglich. Was feststeht ist, dass die Daten nirgens referenziert werden dürften (eg. keine FAT Tabellen oder Inodes), und woher soll dann das kleine Assembler-Ding im MBR oder BIOS wissen, wo sich die Dateien befinden??

Viele Grüsse

Philipp

PS: Ich erlebe gerade wieder Kindheitsgefühle (Assembler, Pascal und DOS-Interrupts) ;-)

[Slyh]

Hallo,

Ja, das stimmt. Programme im Bootsektor werden auch meistens nur dazu verwendet, um dann die System-Komponenten zu laden (primitiv gesagt eine Linksammlung, was als nächstes geschehen soll)... Wenn das genannte Programm wirklich so funktioniert, müssten noch zahlreiche andere Dateien irgendwo auf der Festplatte liegen (512 Bytes reichen nur für kleine Assemblerprogramme => Viren z. B.)

Gut, dann habe ich das ja sogar richtig verstanden. Mit dem Boot-Sektor
hatte ich mich früher nicht beschäftigt.

Dieses müßte sich trotzdem noch an einer (festen?) Stelle auf der Festplatte
befinden.

Fest nicht, aber es muss sich irgendwo verstecken. [..] Jedoch, um ein Programm in 512 Bytes zu coden, welches dann auch noch die versteckten anderen Dateien findet halte ich für fast unmöglich. Was feststeht ist, dass die Daten nirgens referenziert werden dürften (eg. keine FAT Tabellen oder Inodes), und woher soll dann das kleine Assembler-Ding im MBR oder BIOS wissen, wo sich die Dateien befinden??

Deshalb müßten sich diese wirklich irgendwo an einer festen Stelle befinden -
also eben in einem definitiv nie vom Betriebssystem benutzten Bereich der
Festplatte - sofern es einen solchen gibt. Auf das Dateisystem des Betriebs-
systems hat das Programm ja noch keinen Zugriff, und daß es eine eigene
Zugriffsfunktionalität für die verschiednen Dateisystem mitbringt, halte
ich für unwahrscheinlich.
Also müssen es wohl doch ein oder mehrere feste Sektor auf der Platte sein,
die sich das Programm von den vom Betriebssystem eingerichteten Partition(en)
abzwackt, indem es die Partition(en) z.B. um die benötigte Größe verkleinert.
Diese Funktionalität könnte man ja dann sogar ins eigentliche (Windows-)
Programm stecken. Das MBR-Programm müßte dann nur die Programme in den Sektoren
aufrufen, die sich nicht mehr in den vom Betriebssystem verwalteten
Partitionen befinden. Die Programme hätten natürlich auch keine Größenbeschränkung
auf 512 Bytes. Sie würden sich also als TSR einrichten und könnten permanent den Boot-
Sektor überwachen. Das würde sich allerdings natürlich durch (fast) permanenten
Festplattenzugriff bemerkbar machen. Klüger wäre es, sich in die verschiedenen
BIOS-Interrupts zum Zugriff auf die Festplatte einzuklinken und alle Schreib-
versuche dahingehend zu überprüfen, ob der eigene Speicherbereich im MBR
überschrieben wird, und das zu verhindern oder nach erfolgtem Überschreiben
den eigenen MBR wieder zurückzuschreiben.
Der Fantasie sind keine Grenzen gesetzt! :-)

PS: Ich erlebe gerade wieder Kindheitsgefühle (Assembler, Pascal und DOS-Interrupts) ;-)

Du auch? Ja, das waren noch Zeiten, damals. Da war die Welt noch nicht
von Windows verweichlicht! ;-)

Gruß
Slyh

[Philipp Hasenfratz]

Halihallo

Dieses müßte sich trotzdem noch an einer (festen?) Stelle auf der Festplatte
befinden.

Fest nicht, aber es muss sich irgendwo verstecken. [..] Jedoch, um ein Programm in 512 Bytes zu coden, welches dann auch noch die versteckten anderen Dateien findet halte ich für fast unmöglich. Was feststeht ist, dass die Daten nirgens referenziert werden dürften (eg. keine FAT Tabellen oder Inodes), und woher soll dann das kleine Assembler-Ding im MBR oder BIOS wissen, wo sich die Dateien befinden??

Deshalb müßten sich diese wirklich irgendwo an einer festen Stelle befinden -
also eben in einem definitiv nie vom Betriebssystem benutzten Bereich der
Festplatte - sofern es einen solchen gibt. Auf das Dateisystem des Betriebs-
systems hat das Programm ja noch keinen Zugriff, und daß es eine eigene
Zugriffsfunktionalität für die verschiednen Dateisystem mitbringt, halte
ich für unwahrscheinlich.

dito ;)

Also müssen es wohl doch ein oder mehrere feste Sektor auf der Platte sein,
die sich das Programm von den vom Betriebssystem eingerichteten Partition(en)
abzwackt, indem es die Partition(en) z.B. um die benötigte Größe verkleinert.
Diese Funktionalität könnte man ja dann sogar ins eigentliche (Windows-)
Programm stecken. Das MBR-Programm müßte dann nur die Programme in den Sektoren
aufrufen, die sich nicht mehr in den vom Betriebssystem verwalteten
Partitionen befinden. Die Programme hätten natürlich auch keine Größenbeschränkung
auf 512 Bytes. Sie würden sich also als TSR einrichten und könnten permanent den Boot-
Sektor überwachen. Das würde sich allerdings natürlich durch (fast) permanenten
Festplattenzugriff bemerkbar machen.

Ja, da hast du recht. Noch ein kleiner Gedankengang:
Die Festplatte wird ja in logische Sektoren unterteilt (bei Unix in Inodes). Eine Datei füllt in den meisten Fällen nicht einen ganzen Sektor; im übrigen Platz könnte man die Dateien unterbringen. Das Auslesen der "wirklichen" Datei in diesem Sektor würde auch ganz normal ausgelesen, der restliche Bereich wird ja nie überprüft... Und fester Ort? - Nicht umbedingt... Es gibt z. B. einen Virus, der eine infizierte Datei daran erkennt, ob sie drei NOP's enthält (ein Assembler-Befehl, der einfach gar nix macht, 0x90 der Bytecode [ich Angeber ;)]). Es wäre möglich die Daten irgendwo auf der Platte zu speichern, jedoch du hast mich hierbei bereits "wiederlegt": Das auffinden dieser Zeichenkette wäre ein viel zu grosser Aufwand und würde bemerkt werden.

Klüger wäre es, sich in die verschiedenen
BIOS-Interrupts zum Zugriff auf die Festplatte einzuklinken und alle Schreib-
versuche dahingehend zu überprüfen, ob der eigene Speicherbereich im MBR
überschrieben wird, und das zu verhindern oder nach erfolgtem Überschreiben
den eigenen MBR wieder zurückzuschreiben.
Der Fantasie sind keine Grenzen gesetzt! :-)

Das ist ein sehr guter Vorschlag! - Mag mich da noch an ein kleines Programm erinnern, dass mir bei jedem Lese-/Schreibzugriff ein Symbol ganz rechts oben im DOS-Fenster angezeigt hat... Das liesse sich sicher entsprechend erweitern.

PS: Ich erlebe gerade wieder Kindheitsgefühle (Assembler, Pascal und DOS-Interrupts) ;-)

Du auch? Ja, das waren noch Zeiten, damals. Da war die Welt noch nicht
von Windows verweichlicht! ;-)

OHHHHH, JAAAAA, 100%-ige Übereinstimmung! :-)
War doch schön, als man sich noch um Listen/Sortier-Algorithmen kümmern musste und nicht einfach

push @list, 'value';
oder
sort keys %hello_world

eintippen konnte... ;-)
Entschuldigt bitte, wenn ich hier altklug wirke; solange ist das bei mir ja noch nicht her. Aber es waren eben schon noch andere, ebenso schöne Zeiten...

Viele Grüsse

Philipp

[Slyh]

Hallo,

Ja, da hast du recht. Noch ein kleiner Gedankengang:
Die Festplatte wird ja in logische Sektoren unterteilt (bei Unix in Inodes). Eine Datei füllt in den meisten Fällen nicht einen ganzen Sektor; im übrigen Platz könnte man die Dateien unterbringen. Das Auslesen der "wirklichen" Datei in diesem Sektor würde auch ganz normal ausgelesen, der restliche Bereich wird ja nie überprüft...

Auch eine schöne Idee! (Das machen doch einige Viren sogar so!?)
Da müßte man dann aber wiederum aufpassen, wenn die wirkliche Datei in der
Größe verändert, gelöscht oder überschrieben wird. Sonst ist nämlich das
eigene Programm weg.
Auch müßte man wieder die FAT (oder was auch immer) von Hand auslesen, um
die tatsächliche Belegung des einzelnen Clusters zu ermitteln.

Und fester Ort? - Nicht umbedingt... Es gibt z. B. einen Virus, der eine infizierte Datei daran erkennt, ob sie drei NOP's enthält (ein Assembler-Befehl, der einfach gar nix macht, 0x90 der Bytecode [ich Angeber ;)]). Es wäre möglich die Daten irgendwo auf der Platte zu speichern,

Was ein NOP ist, weiß ich. Den Opcode hätte ich dir auswendig aber nicht
mehr sagen können. :-)
Wie funktioniert das mit den 3 NOPs genau? Wo lassen sich die finden und
wo schreibt sich der Viren-Teil hin?
Man müßte ja dann wirklich alle Dateien durchsuchen, wenn ich das richtig sehe.

Klüger wäre es, sich in die verschiedenen
BIOS-Interrupts zum Zugriff auf die Festplatte einzuklinken

Das ist ein sehr guter Vorschlag! - Mag mich da noch an ein kleines Programm erinnern, dass mir bei jedem Lese-/Schreibzugriff ein Symbol ganz rechts oben im DOS-Fenster angezeigt hat... Das liesse sich sicher entsprechend erweitern.

Ich kenne auch ein solches Programm. Das hatte jeden Zugriff jedoch in der
kleinen Scroll Lock-LED auf der Tastatur angezeigt. War auch sehr nett
anzusehen. Ich meine mich sogar erinnern zu können, daß dieses Programm
auch unter Windows noch weitergelaufen ist. (Wenn man es vorher von DOS aus
gestartet hat. In der DOS-Box läuft sowas wohl eher nicht.)
Ich könnte mich aber auch täuschen.

Du auch? Ja, das waren noch Zeiten, damals. Da war die Welt noch nicht
von Windows verweichlicht! ;-)

OHHHHH, JAAAAA, 100%-ige Übereinstimmung! :-)

Laß mich raten: Du hast zumindest "PC Intern" gelesen, wenn nicht sogar
noch "PC Underground". Beide von Data Becker. Die einzigen anständigen
Bücher, die Data Becker je veröffentlicht hat. ;-)
(Abmahnungen bitte an oben angegebene eMail-Adresse richten! ;-))

War doch schön, als man sich noch um Listen/Sortier-Algorithmen kümmern musste

Nee, also Sortier-Algorithmen konnte ich nie leiden. Da bin ich über jede
Art von vor-implementiertem Sortier-Algorithmus schon ganz froh. Aber ansonsten
geb ich dir recht. :-)

Gruß
Slyh

[Philipp Hasenfratz]

Immer wieder ein Vergnügen ;-)

Ja, da hast du recht. Noch ein kleiner Gedankengang:
Die Festplatte wird ja in logische Sektoren unterteilt (bei Unix in Inodes). Eine Datei füllt in den meisten Fällen nicht einen ganzen Sektor; im übrigen Platz könnte man die Dateien unterbringen. Das Auslesen der "wirklichen" Datei in diesem Sektor würde auch ganz normal ausgelesen, der restliche Bereich wird ja nie überprüft...

Auch eine schöne Idee! (Das machen doch einige Viren sogar so!?)

Ist anzunehmen, kann dir aber keine beim Namen nennen (ich werde international gesucht und kann deswegen keine Stellung dazu nehmen, aber ganz unter uns: einige sind von mir :-) )

Da müßte man dann aber wiederum aufpassen, wenn die wirkliche Datei in der
Größe verändert, gelöscht oder überschrieben wird. Sonst ist nämlich das
eigene Programm weg.
Auch müßte man wieder die FAT (oder was auch immer) von Hand auslesen, um
die tatsächliche Belegung des einzelnen Clusters zu ermitteln.

Ja, das ist "leider" wahr... Zudem kann man das herzlich schlecht in 512 Bytes unterbringen (um mal wieder auf den Boden zu kommen) ;)

Und fester Ort? - Nicht umbedingt... Es gibt z. B. einen Virus, der eine infizierte Datei daran erkennt, ob sie drei NOP's enthält (ein Assembler-Befehl, der einfach gar nix macht, 0x90 der Bytecode [ich Angeber ;)]). Es wäre möglich die Daten irgendwo auf der Platte zu speichern,

Was ein NOP ist, weiß ich. Den Opcode hätte ich dir auswendig aber nicht
mehr sagen können. :-)

Ich glaube ich habe alle bis auf den vergessen ;-)

Wie funktioniert das mit den 3 NOPs genau? Wo lassen sich die finden und
wo schreibt sich der Viren-Teil hin?

da bin ich jetzt überfragt... Das einzige was ich sagen kann ist, dass der Virus die drei NOP's für die Wiedererkennung benutzt, sodass er eine Datei nicht zweimal infiziert. Wenn er eine neue Datei infizieren will, schaut er zuerst nach diesen drei NOP's... Wo er diese speichert und auch den eigenen Code repliziert, kann ich dir nicht sagen. Diese Bildungslücke hatte ich schon immer:
Wenn ein Virus eine com/exe infiziert, _muss_ der Code doch am Ende der Datei stehen. Würde er das nicht, wär die Datei nicht mehr lauffähig, da dann alle Referenzen (RAM-Speicheradressen, jmp's CS:IP etc.) nimmer stimmen würden => Absturz mit grösster Wahrscheinlichkeit... Es sei den, er würde den Code analysieren und entsprechend "umkodieren"... Weisst du wie das gemacht wird/wurde?

Man müßte ja dann wirklich alle Dateien durchsuchen, wenn ich das richtig sehe.

Ja. Natürlich könnte man dieses Verfahren verschnellern, wenn der Code schon einige "Beschränkungen" kennt. z. B. nur fehlende Bytes in logischen Sektoren benutzt, welche mit Dateien mit anfangsbuchstaben 'A' beginnen o. ä. bzw. nur logische Sektoren im Intervall [1..1000] infiziert... Das wäre eine wesentliche Performancesteigerung (würde sogar nicht einmal bemerkt werden)...

Klüger wäre es, sich in die verschiedenen
BIOS-Interrupts zum Zugriff auf die Festplatte einzuklinken

Das ist ein sehr guter Vorschlag! - Mag mich da noch an ein kleines Programm erinnern, dass mir bei jedem Lese-/Schreibzugriff ein Symbol ganz rechts oben im DOS-Fenster angezeigt hat... Das liesse sich sicher entsprechend erweitern.

Ich kenne auch ein solches Programm. Das hatte jeden Zugriff jedoch in der
kleinen Scroll Lock-LED auf der Tastatur angezeigt. War auch sehr nett
anzusehen. Ich meine mich sogar erinnern zu können, daß dieses Programm
auch unter Windows noch weitergelaufen ist. (Wenn man es vorher von DOS aus
gestartet hat. In der DOS-Box läuft sowas wohl eher nicht.)
Ich könnte mich aber auch täuschen.

*cool* :-)
Wüsstest du noch, wie man die LED anspricht??? - Da wär ich voll aufgeschmissen ;)

Du auch? Ja, das waren noch Zeiten, damals. Da war die Welt noch nicht
von Windows verweichlicht! ;-)

OHHHHH, JAAAAA, 100%-ige Übereinstimmung! :-)

Laß mich raten: Du hast zumindest "PC Intern" gelesen, wenn nicht sogar
noch "PC Underground". Beide von Data Becker. Die einzigen anständigen
Bücher, die Data Becker je veröffentlicht hat. ;-)
(Abmahnungen bitte an oben angegebene eMail-Adresse richten! ;-))

bingo! - PC Intern.
Und noch einige andere...
Aber die sind ja mitlerweilen schon alle wieder verkommen... Alles geht nur noch um SOAP, Webservices, Dreamwaver, HTML, Flash, "Windowsprogramme unter 1MB coden"...
Ach, waren das noch Zeiten... *träum* *seufz* :-))

War doch schön, als man sich noch um Listen/Sortier-Algorithmen kümmern musste

Nee, also Sortier-Algorithmen konnte ich nie leiden. Da bin ich über jede
Art von vor-implementiertem Sortier-Algorithmus schon ganz froh. Aber ansonsten
geb ich dir recht. :-)

ich hab mich auch nie über den Bubble hinwegbewegen können :-))
War schon ganz OK für die kleinen Datenbeständen von damals (waren bei mir auch nur private Projekte => um 1 ms kam's da nicht an).

Viele Grüsse

Philipp

PS: Du hast mich richtig in "Fahrt" gebracht! - Wenn ich mal weniger zu tun habe, arbeite ich mich wieder in die Abgründe und hintersten Ecken des Computers ein... Vielleicht krieg ich dann endlich mal mein Multitasking zum laufen...

[Henryk Plötz]

Moin,

Klüger wäre es, sich in die verschiedenen BIOS-Interrupts zum Zugriff auf die Festplatte einzuklinken und alle Schreibversuche dahingehend zu überprüfen, ob der eigene Speicherbereich im MBR überschrieben wird, und das zu verhindern oder nach erfolgtem Überschreiben den eigenen MBR wieder zurückzuschreiben.

Das meinte ich ja, dass das nicht geht. Sobald das Betriebssystem geladen ist (naja, zumindest eines von den neueren Modellen) kannst du die TST-Routinen oder Interrupthandler die du vorher aufgesetzt hast vergessen. Das Betriebssystem macht Schreibzugriffe am BIOS und seinen Softwareinterrupts vorbei. Das bedeutet, dass a) das im MBR sitzende Programm nicht verhindern kann das es überschrieben wird und b) es keine Kontrolle über irgendeinen Aspekt des danach geladenen Betriebssystems, also insbesondere auch nicht der Internetverbindung, hat.

Fassen wir also zusammen dass die betreffende Software keinen dieser Tricks anwenden wird, und sich sowohl von einer Festplattenformatierung, -repartitionieren oder dem gezielen Löschen von Dateien entfernen lassen wird.

Nebenbei (ich bin mir sicher das hier schonmal geschrieben zu haben, kann es aber nicht finden): Du kannst schon seit Jahren keine Festplatten mehr Low-Level formatieren. Google mal nach den FAQs der entsprechenden Newsgroups, da wird das recht ausführlich behandelt.

--
Henryk Plötz
Grüße aus Berlin

[Slyh]

Hi!

Klüger wäre es, sich in die verschiedenen BIOS-Interrupts zum Zugriff auf die Festplatte einzuklinken und alle Schreibversuche dahingehend zu überprüfen, ob der eigene Speicherbereich im MBR überschrieben wird, und das zu verhindern oder nach erfolgtem Überschreiben den eigenen MBR wieder zurückzuschreiben.

Das meinte ich ja, dass das nicht geht. Sobald das Betriebssystem geladen ist (naja, zumindest eines von den neueren Modellen) kannst du die TST-Routinen oder Interrupthandler die du vorher aufgesetzt hast vergessen. Das Betriebssystem macht Schreibzugriffe am BIOS und seinen Softwareinterrupts vorbei.

Oh, richtig, neuere Betriebssysteme schreiben gar nicht mehr über's BIOS,
sondern direkt über den Festplatten-Controller(?). Da muß ich dir recht geben.

Das bedeutet, dass a) das im MBR sitzende Programm nicht verhindern kann das es überschrieben wird und

Ja.

b) es keine Kontrolle über irgendeinen Aspekt des danach geladenen Betriebssystems, also insbesondere auch nicht der Internetverbindung, hat.

Das wäre ohnehin noch ein weiterer Aspekt gewesen, den wir bisher völlig
außer Acht gelassen haben. Irgendwie müßte ja noch ein Windows-Programm
geladen werden... Richtig...

Fassen wir also zusammen dass die betreffende Software keinen dieser Tricks anwenden wird, und sich sowohl von einer Festplattenformatierung, -repartitionieren oder dem gezielen Löschen von Dateien entfernen lassen wird.

Stimmt.

Nebenbei (ich bin mir sicher das hier schonmal geschrieben zu haben, kann es aber nicht finden): Du kannst schon seit Jahren keine Festplatten mehr Low-Level formatieren. Google mal nach den FAQs der entsprechenden Newsgroups, da wird das recht ausführlich behandelt.

Aah, ich verstehe. Laut http://www.seagate.com/support/kb/disc/low_level_ata.html
ist das, was man früher als Low-Level-Format bezeichnet hat, von dem was man
heute als Low-Level-Format bezeichnet, verschieden. Ich habe Low-Level-Format
bisher immer so verstanden, daß sämtlicher Inhalt der Platte gelöscht wird,
also mit Nullen überschrieben wird. Das ist wohl das, was man auch als
Mid-Format bezeichnen könnte. Das alte Low-Level-Format, also das
ersten Formatieren beim Hersteller und das in den alten BIOSen, ist deshalb
nicht mehr in den BIOSen enthalten, weil es nicht mehr kompatibel ist. Verstehe.

Ich meinte bisher also das Überschreiben des kompletten Festplatteninhalts
mit Nullen.

Gruß
Slyh

[Philipp Hasenfratz]

Halihallöchen ;)

Klüger wäre es, sich in die verschiedenen BIOS-Interrupts zum Zugriff auf die Festplatte einzuklinken und alle Schreibversuche dahingehend zu überprüfen, ob der eigene Speicherbereich im MBR überschrieben wird, und das zu verhindern oder nach erfolgtem Überschreiben den eigenen MBR wieder zurückzuschreiben.

Das meinte ich ja, dass das nicht geht. Sobald das Betriebssystem geladen ist (naja, zumindest eines von den neueren Modellen) kannst du die TST-Routinen oder Interrupthandler die du vorher aufgesetzt hast vergessen. Das Betriebssystem macht Schreibzugriffe am BIOS und seinen Softwareinterrupts vorbei.

Oh, richtig, neuere Betriebssysteme schreiben gar nicht mehr über's BIOS,
sondern direkt über den Festplatten-Controller(?). Da muß ich dir recht geben.

Yep ;)
Die Sperren so ziemlich alles und machen einen Driver drum herum ;)
Die Zapfen den Port/IRQ des Controlers auf'm ISA oder PCI or what-ever an...

b) es keine Kontrolle über irgendeinen Aspekt des danach geladenen Betriebssystems, also insbesondere auch nicht der Internetverbindung, hat.

Das wäre ohnehin noch ein weiterer Aspekt gewesen, den wir bisher völlig
außer Acht gelassen haben. Irgendwie müßte ja noch ein Windows-Programm
geladen werden... Richtig...

Stimmt... Der Thread ist bei uns etwas in Abwege geraten, jedoch nicht minder interessant ;)
Aber ein Windowsprogramm dann zu starten ist nach unseren Überlegungen ziemlich das einfachste unterfangen ;-)

Nebenbei (ich bin mir sicher das hier schonmal geschrieben zu haben, kann es aber nicht finden): Du kannst schon seit Jahren keine Festplatten mehr Low-Level formatieren. Google mal nach den FAQs der entsprechenden Newsgroups, da wird das recht ausführlich behandelt.

Ich meinte bisher also das Überschreiben des kompletten Festplatteninhalts
mit Nullen.

Es gab sogar ultrakorrekte Programme, die die Festplatte zuerst mit 0-en, dann mit 254-ern und dann nochmals mit 0-en überschrieben... Na, ja, dass auch kein einziges Molekühl mehr flasch rum liegt bzw. falsch magnetisiert ist...

Viele Grüsse

Philipp

[Henryk Plötz]

Moin,

Ich meinte bisher also das Überschreiben des kompletten Festplatteninhalts
mit Nullen.

Gut, das hätte ich als einfach formatieren verstanden. Das andere was nur das Dateisystem anlegt (aka quick-format) heisst dann logischerweise "Dateisystem anlegen".

BTW: Wenn man nicht nur Nullen sondern Zufallswerte nimmt, sollte man Hexadezimalzahlen nehmen, das ist nämlich sicherer als mit Dezimalzahlen: http://groups.google.de/groups?selm=slrna7ao6p.n1e.netnews%40itreff.de ;-)

--
Henryk Plötz
Grüße aus Berlin

[Philipp Hasenfratz]

Halihallo

BTW: Wenn man nicht nur Nullen sondern Zufallswerte nimmt, sollte man Hexadezimalzahlen nehmen, das ist nämlich sicherer als mit Dezimalzahlen: http://groups.google.de/groups?selm=slrna7ao6p.n1e.netnews%40itreff.de ;-)

Schade, Norton war immer mein Vorbild... - jetzt macht er Windows-Programme...! - und erkennt plötzlich einen Unterschied zwischen Hex und Dec. *pahhh*

Wo bleibt mein alter Peter?
Wo bleibt der alte Norton Commander, oder GEM (kannte das mal einer?)?

Viele Grüsse

Philipp

[Clemens]

Hi Henryk!

Die Leute verspielen ihre potentielle Glaubwürdigkeit schon im Ansatz, indem sie die 'Ortung' per IP-Addresse vornehmen wollen.

Naja, so supertoll ist das zwar nicht, aber theoretisch immer noch die einzige Möglichkeit so etwas wie Ortung zu realisieren. Lustig wird es aber bestimmt, wenn du auf die nächste Polizeiwache gehst und sagst, "verhaften sie mal den Dieb an IP 132.156.12.1". Was geht kann man auf http://www.php-homepage.de/ recht nett sehen (gleich unter der Überschrift), keine Ahnung wie differenziert man das herunterbrechen kann, mehr als Städtenamen ist wohl nicht drinnen, anders sieht es aus, wenn das feste IP-Adressen sind oder ein Provider die Zugangsdaten protokolliert (oder das muss). Allerdings ist dann wieder die Frage, ob ein potentieller Laptopklau dann ausreicht auf die Daten zugreifen zu können.

Clemens

[Henryk Plötz]

Moin,

Naja, so supertoll ist das zwar nicht, aber theoretisch immer noch die einzige Möglichkeit so etwas wie Ortung zu realisieren.

Ja, das mit Strafverfolgungsbehörden ist schon klar. Aber das dort las sich eher wie "Sie sagen uns die IP-Addresse, wir sagen ihnen wo der Bösewicht ist." und das ist nunmal nicht realisierbar.

Was geht kann man auf http://www.php-homepage.de/ recht nett sehen (gleich unter der Überschrift), keine Ahnung wie differenziert man das herunterbrechen kann, mehr als Städtenamen ist wohl nicht drinnen.

Hmm, meinen Arcor-Anschluss in Berlin hat es angezeigt, aber als ich es von trash.net aus der Schweiz aufgerufen habe, hat es geschwiegen.

--
Henryk Plötz
Grüße aus Berlin

[Clemens]

Hmm, meinen Arcor-Anschluss in Berlin hat es angezeigt, aber als ich es von trash.net aus der Schweiz aufgerufen habe, hat es geschwiegen.

Interessant ist auch die Meldung auf http://jan.kneschke.de/projects/localizer/index.php
wenn bei Test it yourself nichts gefunden wird: "I can not find any informations for the IP (213.139.94.131) You can help to improve the database"

und dann soll man Provider, Stadt, Region und Land eingeben, wenn das so direkt in der Datenbank landet...

Aber dennoch, ich habe schon etwas geschaut, als ich das erste mal da gelandet bin.

Clemens

[Frank Schönmann]

hi!

Hmm, meinen Arcor-Anschluss in Berlin hat es angezeigt, aber als ich
es von trash.net aus der Schweiz aufgerufen habe, hat es geschwiegen.

Bei mir: "Wie gehts denn so in Wesel?" Weit gefehlt. Ich weiß nicht
mal, wo Wesel liegt... ;) Richtig wäre sowas wie Aschaffenburg oder
wenigstens Frankfurt als nächste Großstadt.

bye, Frank!

[Henryk Plötz]

Moin,

Ich weiß nicht mal, wo Wesel liegt... ;)

Hmm, da mag ich Google. Einfach den Namen einer größeren Stadt eingeben und es zeigt einem den dazugehörigen Directory-Eintrag, in diesem Fall
World > Deutsch > Regional > Europa > Deutschland > Nordrhein-Westfalen > Landkreise > Wesel

--
Henryk Plötz
Grüße aus Berlin

[Slyh]

Hallo,

ich bin heute auf http://www.chip.de/news_stories/news_stories_8771062.html gestoßen. Der Hersteller schreibt, dass sich (zumindest die kostenpflichtige Version) nicht durch Formatierung/fdisk entfernen lassen soll. Wie kann das funktionieren?

Gar nicht.
Spätestens bei einem Low-Level-Format ist wirklich alles auf der Festplatte
weg. Auch die Aussage, daß dieses Programm nicht entdeckt werden kann,
weil es "unsichtbar" im Hintergrund läuft, ist natürlich Quatsch. Nur weil
das Programm nicht im Taskmanager sichtbar ist, heißt das noch lange nicht,
daß man es nicht mit spezieller Software aufspüren und abschießen könnte.
Auch die Aussage, daß die Programmdateien versteckt seien und damit nicht
löschbar sind, halte ich für Quatsch. Wenn man wirklich etwas auf der Platte
verstecken will (und das heißt nicht, daß es durch ein Format nicht
entfernt werden könnte), müßte man schon heftig rumtricksen. Z.B. in
irgendwelche Bereiche der Festplatte schreiben, die vom Betriebssystem
nie verwendet werden, und das ganze dann bei jedem Betriebssystem-Start
"von Hand" laden und der Programmausführung zugänglich machen.
Unter'm Strich möchte ich die gemachten Aussagen doch stark anzweifeln.
(Natürlich lasse ich mich aber gerne und jeder Zeit eines besseren belehren.)

Gruß
Slyh

[Philipp Hasenfratz]

Halihallo

ich bin heute auf http://www.chip.de/news_stories/news_stories_8771062.html gestoßen. Der Hersteller schreibt, dass sich (zumindest die kostenpflichtige Version) nicht durch Formatierung/fdisk entfernen lassen soll. Wie kann das funktionieren? Kann das überhaupt gehen? Wenn die Platte in einen anderen Computer eingebaut wird (ok, bei Notebooks nicht so einfach, aber laut Hersteller ist das Programm nicht nur für Notebooks) oder von Diskette gebootet wird (mal vorausgesetzt, dass das nicht irgendwie per BIOS gesperrt ist) lässt sich doch alles platt machen oder etwa nicht?

Dem genannten kann ich nur zustimmen... Nun, vielleicht eine kleine Möglichkeit, wie ich sowas machen würde:

Klar, bei einer Low-Level-Formatierung gehen alle Daten verloren, jedoch nicht der RAM Speicher. Ich würde ein TSR-programm schreiben, welches den INT28 anzapft (wird von DOS alle 1/18.2 Sekunde aufgerufen und dient als Timer) und dann z. B. alle 50 Ticks überprüft, ob das Programm noch im MBR steht. Falls nicht (nach Low-Level-Format oder fdisk /mbr), wird es einfach wieder dort reingeschrieben...
Aber diese Umsetzung wäre ziemlich krass und wird heutzutage wohl von niemandem mehr gemacht (die Welt ist verkommen; hochleben die alten TSR-Programme)... Wüsste auch nicht, ob die DOS-Emu ab den neuen Win-Generationen dies noch unterstützen...

Keine Ahnung, ob das auch hinhauen könnte... Ist auch nur ein Vorschlag...

Viele Grüsse

Philipp

[Slyh]

Hallo,

Klar, bei einer Low-Level-Formatierung gehen alle Daten verloren, jedoch nicht der RAM Speicher. Ich würde ein TSR-programm schreiben, welches den INT28 anzapft (wird von DOS alle 1/18.2 Sekunde aufgerufen und dient als Timer) und dann z. B. alle 50 Ticks überprüft, ob das Programm noch im MBR steht. Falls nicht (nach Low-Level-Format oder fdisk /mbr), wird es einfach wieder dort reingeschrieben...

Das ist eine sehr schöne Idee. Die funktioniert aber natürlich nur solange
der Rechner auch von der Festplatte gebootet wurde, also das TSR überhaupt eine
Chance hatte sich selbst zu laden. Gegen Bootdisketten ist es also machtlos.
Genauso gegen Low-Level-Formats aus dem BIOS heraus. (Gibt's sowas überhaupt
noch? Ist schon Jahre her, daß ich ein BIOS gesehen habe, das eine solche
Möglichkeit geboten hat.)

Aber diese Umsetzung wäre ziemlich krass und wird heutzutage wohl von niemandem mehr gemacht (die Welt ist verkommen; hochleben die alten TSR-Programme)...

Jawoll! :-)

Wüsste auch nicht, ob die DOS-Emu ab den neuen Win-Generationen dies noch unterstützen...

Da braucht's gar keine DOS-Emulation. Der Interrupt 28 (also 1Ch) ist ein
BIOS-Interrupt, hat also mit dem Betriebssystem selbst gar nichts am Hut.
Die Frage ist nur - und damit kenne ich mich nicht aus - ob das TSR das
Umschalten des Prozessors in den Protected-Mode überstehen würde.

Das wäre ja fast mal ein Proof-Of-Concept wert. Hat jemand zu viel Zeit
übrig? ;-)

Keine Ahnung, ob das auch hinhauen könnte... Ist auch nur ein Vorschlag...

Aber dafür ein richtig guter Vorschlag!

Gruß
Slyh

[Philipp Hasenfratz]

Halihallo

Klar, bei einer Low-Level-Formatierung gehen alle Daten verloren, jedoch nicht der RAM Speicher. Ich würde ein TSR-programm schreiben, welches den INT28 anzapft (wird von DOS alle 1/18.2 Sekunde aufgerufen und dient als Timer) und dann z. B. alle 50 Ticks überprüft, ob das Programm noch im MBR steht. Falls nicht (nach Low-Level-Format oder fdisk /mbr), wird es einfach wieder dort reingeschrieben...

Das ist eine sehr schöne Idee. Die funktioniert aber natürlich nur solange
der Rechner auch von der Festplatte gebootet wurde, also das TSR überhaupt eine
Chance hatte sich selbst zu laden. Gegen Bootdisketten ist es also machtlos.

Jetzt bin ich geschlagen ;-)
Ja, da hast du absolut recht...

Genauso gegen Low-Level-Formats aus dem BIOS heraus. (Gibt's sowas überhaupt
noch? Ist schon Jahre her, daß ich ein BIOS gesehen habe, das eine solche
Möglichkeit geboten hat.)

Ich hab ja ein ziemlich alter Computer, und sogar da gibt's das nimmer... Das letzte mal hab ich das auf meinem 386-er gesehen... Aber man kann das ja auch programmieren (und vorher mit Bootdisk starten)...

Wüsste auch nicht, ob die DOS-Emu ab den neuen Win-Generationen dies noch unterstützen...

Da braucht's gar keine DOS-Emulation. Der Interrupt 28 (also 1Ch) ist ein
BIOS-Interrupt, hat also mit dem Betriebssystem selbst gar nichts am Hut.

das dachte ich auch, aber meine versuche mit TSR-programmen unter windows sind jämmerlich fehlgeschlagen; ich nehm an, dass Win das unterbindet!? :-(

Die Frage ist nur - und damit kenne ich mich nicht aus - ob das TSR das
Umschalten des Prozessors in den Protected-Mode überstehen würde.

Ist schon sehr, sehr lange her, wo ich dieses Wort das letzte mal gehört habe... Ich dachte, das hat was mit dem Erweiterten Speicher zu tun? - Schlimm wirds doch für das Programm erst, wenn in den Virtual-Mode gegangen wird (so hiess das glaub ich)... Aber da begeb ich mich in Bereiche von Fachwissen, welches ich schon längst wieder vergessen habe, leider.

Das wäre ja fast mal ein Proof-Of-Concept wert. Hat jemand zu viel Zeit
übrig? ;-)

In den nächsten Ferien versuch ich's mal wieder ;-)

Keine Ahnung, ob das auch hinhauen könnte... Ist auch nur ein Vorschlag...

Aber dafür ein richtig guter Vorschlag!

Danke, danke... Ich versuche mich ständig in TIMTOWTDI ;-)
Und ich habe ja eigentlich gar nicht auf das Ausgangsposting geantwortet... Bin schon ziemlich weit abgeschweift... Das Problem hat mich grad sehr fasziniert und meine Kindheit wieder aufleben lassen... Also was heisst hier Kindheit? - Sowas hab ich glaub in der ersten Sek. (7. Jahr in der Schule) so getrieben... Aber die Programme waren meist zum Tode verurteilt... Der Computer ist mir bestimmt 1000-mal abgestürtzt/aufgehängt... Ja, ja, Multitasking Versuche über den 1C INT... Ist nie gut gekommen ;)

Viele Grüsse

Philipp

[Carsten]

Hallo Slyh!

Das ist eine sehr schöne Idee. Die funktioniert aber natürlich nur solange der Rechner auch von der Festplatte gebootet wurde, also das TSR überhaupt eine Chance hatte sich selbst zu laden. Gegen Bootdisketten ist es also machtlos.

Jein. Man könnte das auf die Diskette geschrieben DOS ja gleich entsprechend patchen. Dann müsste die Boot-Diskette schon von einem anderen System stammen.

Das ganze bekommt mehr und mehr von einem Virus. Die Verbreitung müsste nur auf das eine System beschränkt werden. (Seriennummer der Platte z.b.)

Gruss,
 Carsten

[Stefan]

Hallo,
ich bin heute auf http://www.chip.de/news_stories/news_stories_8771062.html gestoßen. Der Hersteller schreibt, dass sich (zumindest die kostenpflichtige Version) nicht durch Formatierung/fdisk entfernen lassen soll. Wie kann das funktionieren? Kann das überhaupt gehen?

Kann ich mir nicht vorstellen. Vielleicht wird die Software auf freien Speicherplatz im Flash-ROM des BIOS geschrieben. Das erfordert aber das Deaktivieren weiterer Sicherunfgen (Jumper auf dem Mainboard. Sieh mal nach, ob darüber in der Installationsanleitung etwas steht).

Wenn die Platte in einen anderen Computer eingebaut wird (ok, bei Notebooks nicht so einfach, aber laut Hersteller ist das Programm nicht nur für Notebooks) oder von Diskette gebootet wird (mal vorausgesetzt, dass das nicht irgendwie per BIOS gesperrt ist) lässt sich doch alles platt machen oder etwa nicht?

Falls das Programm sich im BIOS einnistet, würde selbst ein Austausch der Festplatte nicht helfen, wohl aber ein BIOS-Update.

Stefan

[Korbinian Bachl]

Hallo,

also ich kenne das Prinzip von vielen Herstellern... die schreiben Ihr BIOS ja oftmals auf die Festplatte, in eine eigen definierte Partition - dh. wenn man eine Partition vom Typ FAT12 oder Fat XX anlegt wird Sie von windoof und von fdisk nicht erkannt, nur zusätzliche Partitionsmanager wie PQ MAgic und einige von Linux erkennen dies... aber Linux auf einem Laptop ist sehr selten...

wenn diese Programm sich dann bei jedem start in den Speicher im Hintergrund einnistet und auf Core ebene neben dem Windowskernel läuft ist es durchausmöglich das es dann "nach hause telefonieren" kann....

wie gesagt ein Profi kann es löschen, aber eine einfaches fdisk /mbr oder win-neuinstall reichen nicht - ich denke das gut 95 - 98% aller menschen es nicht wegbekommen würden und obendrauf es nur 0,01% der Menscheit auffallen würde das da ein programm im speicher hängt (im unteren 640k segment) das versucht nauch hause zu telefonieren...

es kann durchaus sehr sicher sein zumal die leute mit genug know how selten gewalttäter oder diebe sind...

mfg

Korbinian Bachl
www.whiskyworld.de

[Henryk Plötz]

Moin,

aber Linux auf einem Laptop ist sehr selten...

Merkwürdig, > 50% der Leute mit Laptop die ich kenne lassen darauf Linux laufen. Muss wohl an der Uni-Umgebung liegen.

wenn diese Programm sich dann bei jedem start in den Speicher im Hintergrund einnistet und auf Core ebene neben dem Windowskernel läuft ist es durchausmöglich das es dann "nach hause telefonieren" kann....

Das möchtest du jetzt näher erläutern. Schon seit Windows 3.1 nicht mehr im Kompatibilitätsmodus läuft haben DOS-TSRs keine Möglichkeit mehr parallel zu Windows zu laufen. Selbst wenn, könnte man von dort aus vielleicht noch Manipulationen auf niedriger Ebene durchführen aber ganz sicher nicht auf den TCP/IP-Stack von Windows zugreifen. Dazu braucht es dann wieder ein Windows-Programm dass sich ganz sicher relativ leicht ausschalten lässt (mit wintop killen, oder -wenn es dort als nichtkillbarer Systemprozess auftauch- die dazugehörige Datei löschen).

wie gesagt ein Profi kann es löschen, aber eine einfaches fdisk /mbr

Doch, dieses Kommando schreibt den MBR einfach neu. Was dann evt. noch in nicht direkt sichtbaren Partitionen rumliegt ist schlichtweg irrelevant, da es nicht ausgeführt wird.

win-neuinstall reichen nicht

Es ist glücklicherweise schon ein bisschen her, dass ich das letzte mal mit Windows zu tun hatte, aber hat die Installationsroutine nicht implizit den MBR neu geschrieben. Ich kann mich dunkel erinnern, dass man nach dem Windowssetup öfter mal Lilo neu installieren musste.

--
Henryk Plötz
Grüße aus Berlin