Habe es gerade ausprobiert. Eine 1GByte grosse Datei mit lauter Nullen wird von bzip auf eine Groesse von 600Byte "herunterkomrimiert". gzip macht daraus eine ca. 400KByte grosse Datei. Ob es allerdins ein netter Gag ist, wenn einer eine 1TByte grosse Datei auf so eine Groesse komprimiert und diese dann einem "Freund" schickt, ist eher fraglich.
Warum? Es ist eine mehr oder weniger normale Datei die (wenn man sie rekursiv auspackt) halt Plattenplatz verbraucht.
Daran ist nicht verboten. Es wäre ja noch schöner wenn dies verboten wäre. (Man kann ja nicht wissen das die zip Datei automatisch und rekursiv entpackt wird ;))
voila, wir erhalten einen etwa 120 Byte grossen File der komplett entpackt gute 16 Gigabyte gross ist.
Man kann natürlich auch mit dd einen noch viel grösseren File erstellen (wie wäre es mit 200GB ?) und damit provozieren dass einem Mail-Virenscanner beim Versuch das ganze zu entpacken dann der Festplattenspeicher ausgeht :->
200GB (oder TB) wirst du auf deiner Fetzbladde nicht so leicht mal nebenbei hinbekommen. mach das so: mkfifo meine_pipe #legt pipe an dd if=/dev/zero bs=1M count=200M | bzip -9 -c > meine_pipe& #schreibt in pipe (das UND ("&") muss da sein!) gzip meine_pipe #liest aus pipe
Ich möchte mich bei den Absendern von schrottmails mit einer Antwort "bedanken", die deren Nerven strapaziert, in der Hoffnung, dass die Sch... dann aufhört. Hat jemand eine Vorstellung wie ich soetwas anstellen muß?
das entpacken der bzip2 Datei dauert etwa 2-3 Minuten auf meinem System (GNU/Linux 2.6, Athlon XP 2000+, 512 MB RAM, Festplatte: 47.42 MB/sec)
Die Zip Datei zu fälschen ist übrigens sehr einfach, die Unkomprimierte Größe steht (bei meiner Test-Datei) am Anfang und Ende der Datei, und ist 4 Bytes lang (einfach die echte Byte-Größe in eine hex-zahl konvertieren und mit einem hex-editor nach der Größe suchen (auf Endian achten!))
ich werd mal ausprobieren, was Winzip macht, wenn man in Outlook auf den Anfang klickt :) (vielleicht sollte man die neue Größe so wählen, dass keine negative Rate herauskommt)
Anleitung für das erzeugen einer "bzip-bombe": cat /dev/zero | bzip2 --best > bombe.bz2
einfach aufhören, wenn bombe.bz2 groß genug ist ...
Wie wär's denn mit dd if=/dev/zero bs=1G count=1024|bzip -9>ganz\ klein.bz2?
Ist auch ein netter Benchmark. real 1m4.019s user 0m59.003s sys 0m4.016s
Die gepackte Datei ist übrigens nur 6KByte groß.
In einer Vorlesung über Kompressionsalgorithmen wurde mal ein Verfahren gezeigt, mit dem man quasi "unendliche" Dateien erzeugen kann, die den Entpacker in eine Endlosschleife treiben. Bezog sich damals auf den ARJ-Packer, dürfte aber auch auf andere übertragbar sein. Wenn ich meine Aufzeichnungen finde, scanne ich sie mal ein.
Nur so ne Frage, aber: Was hast Du für eine Maschine?! Bei mir hat das eine gute Viertelstunde gedauert! Auf einem P4 3.2HT mit nice -n -19. Im Übrigen lässt sich das .bz2 nochmal packen und kommt dann auf ein halben KByte. Wer rechnet mal aus, wieviel Megaprozent das sind?
Könnte man da nicht einen Angriff in die andere Richtung machen? Wenn man ein zip-File so manipuliert, dass es ganz groß aussieht, wird es vom Scanner nicht ausgepackt. Wenn da nun ein Virus drin ist ...
Ich habe es mal geschafft einen Terrabyte nullen in 238 byte zu packen... Einfach zweimal durch bzip2 gejagt. Per Mail habe ich das allesdings noch nicht verschickt. Wer das Ding haben will kann sich gerne melden.
gerne, schicks einfach an askbill@microsoft.com *g* mich würd abermal interresieren was man gegen solche mail anhänge machen kann... eigentlich garnix oder?
wäre korrekt. Zum kennt dd kein kleines m, es muss schon ein großes sein, zum anderen hättest du keinen ganzen Terrabyte bekommen (wenn, dann wollen wir es doch auch richtig machen
Doch, aber da hat man noch andere Probleme. *SCNR* ;-)
Aber mal im Ernst, was bringt diese Archiv-Suche eigentlich wirklich? Hat schonmal jemand einen Virus in freier Wildbahn gesehen, der sich selbst in ein ZIP (oder BZip2, *g*) einpackt und damit verschickt. Wenn es eine SFX ist, okay, aber dann gehört die unzip-Routing halt zum Virencode und wird auch direkt erkannt. Aber wann lohnt sich bei einem eMail-Scanner das Durchsuchen von Archiven?
das ganze ist ne Null-Info und ein netter Gag. Ne Mail mit 'nem Anhang (egal wie der aussieht) von unbekannter Herkunft wird einfach gelöscht und gut is.
Einzige Gefahr ist doch eine als Software-Download getarnte Bombe... oder??
Trotzdem, da schreibt man ein kleines Progrämmchen, daß einem meldet, wenn beim Entpacken 1 GB (von mir aus einstellbar) überschritten wird. Es stoppt den Entpacker und gut is. So, man weiß Bescheid, rm Bombe.tar.gz und gut is. Meine Mails lasse ich auf dem Server liegen, und Mails mit Attachment, die ich nicht kenne, werden gnadenlos gelöscht.
Es geht hier um das Verhalten von Virenscannern und komprimierten Dateien. Ein Virenscanner versucht komprimierte Anhaenge zu entpacken und in den Inhalt nach Viren zu suchen, also ist es schon ein Problem.
Du denkst zu kurz. Firmen, die ein Linux-Mailserver betreiben und dort Anhänge nach Viren scannen, denen kann mit solchen Mails schnell der Mailserver abgeschossen werden. Diese Firmen können nun auch nicht einfach alle Anhänge löschen, das würde die Kommunikation via eMail doch arg einschränken.
Privat brauche ich keinen Virenscanner, der Win32-Viren in Anhängen sucht, die laufen eh nicht
ich glaub Konquerer entpackt das auchc irgendwo temporär, anderst könnt ich es mir ned vorstellen. und dann wär das auch keine andere methode wies der virenscanner macht.
Tja Leute, da muss ich sagen MacOS hat das Problem ganz einfach gelöst. Eine Datei kann einfach nicht grösser als 2GB sein, weil es sinnloss wäre. Ist si trotzdem grösser, dann wird sie nicht beachtet. Und als Tipp - wie viele Viren gibt es den für MacOS?
Kleiner Tipp von mir: Wie viele Viren gibt es unter Linux? (Also, real, in the wild, nicht irgendwelche proof of concept-teile)
Was die 2 GB angeht: Das kann ich mir erstens fast nicht vorstellen (man kann doch mit MacOS auch Videoschnitt machen??) und zweitens ist das unter Linux LEIDER immer noch gelegentlich ein Problem, dass Programme mit größeren Dateien nicht klarkommen. Es gibt genügend Anwendungen dafür (Backups in ner Datei, wie gesagt Videoschnitt, umfangreiche Audiobearbeitungen etc.).
Diese 2GB Grenze ist echter Müll, und so weit ich weis kann man unter OSX mit HSF+ auch grössere Dateien anzeigen lassen. Und wen is mit HSF nicht geht kann man auch andere Unix Filesysteme unter OSX nutzten. Wie auch immer ich habe bereits an einem MAC gearbeitd an dem ich sehr grosse Dateien bearbeiten konnte.
Hinweis: Der Original Poster spricht von "MacOS" und nicht von "MacOSX"! Das klassische MacOS hat so seine Tücken und Begrenzungen. Das UNIX basierende MacOSX hingegen spielt schon in einer ganz anderen Liga. Erst recht auf den 64bittigen G5 Rechnern.
Hab einfach ein 1GB grosses bzip2 gemacht und mir in Ark den Inhalt anzeigen lassen. Der scheint nur Dateinamen zu sammeln und die grösse zu zählen, während er den Rest verwirft. RAM bleibt frei.
Wenn aber z.B. ein auf 500MB gebrachtes,grosses Backup genommen wird, genehmigt sich Ark viel Speicher
42.zip exisitiert schon länger ;)
Und es ist ein netter Gag damit die Problematik von automatischem Entpacken von Archiven aufzuzeigen.
Ist die Verwendung dieses Files nicht verboten?
und weg
Daran ist nicht verboten. Es wäre ja noch schöner wenn dies verboten wäre. (Man kann ja nicht wissen das die zip Datei automatisch und rekursiv entpackt wird ;))
http://www.ijs.si/software/amavisd/#sec-dos
Es gibt nicht nur Freunde im Internet...
Einen Virenfreien Tag wünsch ich euch alle
Gruss Joachim
Eine 1GByte grosse Datei mit lauter Nullen wird von bzip auf eine Groesse von 600Byte "herunterkomrimiert".
=====
Das geht noch besser:
dd if=/dev/zero of=16G_null_dat bs=1M count=16M
bzip -9 16G_null_dat
gzip 16G_null_dat.bz2
voila, wir erhalten einen etwa 120 Byte grossen File der komplett entpackt gute 16 Gigabyte gross ist.
Man kann natürlich auch mit dd einen noch viel grösseren File erstellen
(wie wäre es mit 200GB ?) und damit provozieren dass einem Mail-Virenscanner beim Versuch das ganze zu entpacken dann der Festplattenspeicher ausgeht :->
Das geht noch besser:
dd if=/dev/zero of=16G_null_dat bs=1M count=16M
bzip -9 16G_null_dat
gzip 16G_null_dat.bz2
voila, wir erhalten einen etwa 120 Byte grossen File der komplett entpackt gute 16 Gigabyte gross ist.
Wären dann aber 16 Terabyte, nich 16 Gigabyte.
mach das so:
mkfifo meine_pipe #legt pipe an
dd if=/dev/zero bs=1M count=200M | bzip -9 -c > meine_pipe& #schreibt in pipe (das UND ("&") muss da sein!)
gzip meine_pipe #liest aus pipe
MFG
Hinnerk
gzip: 5 MegaByte
zip: 5 MegaByte
bzip2: 4 KiloByte
das entpacken der bzip2 Datei dauert etwa 2-3 Minuten
auf meinem System (GNU/Linux 2.6, Athlon XP 2000+,
512 MB RAM, Festplatte: 47.42 MB/sec)
Die Zip Datei zu fälschen ist übrigens sehr einfach,
die Unkomprimierte Größe steht (bei meiner
Test-Datei) am Anfang und Ende der Datei, und
ist 4 Bytes lang (einfach die echte Byte-Größe
in eine hex-zahl konvertieren und mit einem hex-editor
nach der Größe suchen (auf Endian achten!))
z.B.:
zipinfo TEST.zip
Archive: TEST.zip 5142381 bytes 1 file
prw------- 2.3 unx 32 b- defX 14-Jan-04 01:49 -
1 file, 32 bytes uncompressed, 5142281 bytes compressed: -2647755.3%
ich werd mal ausprobieren, was Winzip macht, wenn
man in Outlook auf den Anfang klickt :)
(vielleicht sollte man die neue Größe so wählen,
dass keine negative Rate herauskommt)
Anleitung für das erzeugen einer "bzip-bombe":
cat /dev/zero | bzip2 --best > bombe.bz2
einfach aufhören, wenn bombe.bz2 groß genug ist ...
funktioniert natürlich nicht!
cat /dev/zero > bombe
bzip2 --best bombe
Ist auch ein netter Benchmark.
real 1m4.019s
user 0m59.003s
sys 0m4.016s
Die gepackte Datei ist übrigens nur 6KByte groß.
In einer Vorlesung über Kompressionsalgorithmen wurde mal ein Verfahren gezeigt, mit dem man quasi "unendliche" Dateien erzeugen kann, die den Entpacker in eine Endlosschleife treiben. Bezog sich damals auf den ARJ-Packer, dürfte aber auch auf andere übertragbar sein. Wenn ich meine Aufzeichnungen finde, scanne ich sie mal ein.
Im Übrigen lässt sich das .bz2 nochmal packen und kommt dann auf ein halben KByte.
Wer rechnet mal aus, wieviel Megaprozent das sind?
Wenn man ein zip-File so manipuliert, dass es ganz groß aussieht, wird es vom Scanner nicht ausgepackt. Wenn da nun ein Virus drin ist ...
auch sein, dass Winzip dann Alarm schlägt ...
müsste man ausprobieren
mich würd abermal interresieren was man gegen solche mail anhänge machen kann...
eigentlich garnix oder?
dd if=/dev/zero bs=1m count=1000000 | bzip2 | bzip2 > interesting.bz2
Man braucht also kein Terabyte seines kostbaren Plattenplatzes zu opfern
wäre korrekt. Zum kennt dd kein kleines m, es muss schon ein großes sein, zum anderen hättest du keinen ganzen Terrabyte bekommen (wenn, dann wollen wir es doch auch richtig machen
Panda z.B.
Bei dem kein Problem.
Und 20fach rekursiv gepackt durchsucht er
auch noch.
Kennt jemand noch andere, die das machen?
gruss
grüsse,
Calle
Aber mal im Ernst, was bringt diese Archiv-Suche eigentlich wirklich? Hat schonmal jemand einen Virus in freier Wildbahn gesehen, der sich selbst in ein ZIP (oder BZip2, *g*) einpackt und damit verschickt. Wenn es eine SFX ist, okay, aber dann gehört die unzip-Routing halt zum Virencode und wird auch direkt erkannt. Aber wann lohnt sich bei einem eMail-Scanner das Durchsuchen von Archiven?
cu, Bernd
das ganze ist ne Null-Info und ein netter Gag. Ne Mail mit 'nem Anhang (egal wie der aussieht) von unbekannter
Herkunft wird einfach gelöscht und gut is.
Einzige Gefahr ist doch eine als Software-Download getarnte Bombe...
oder??
einstellbar) überschritten wird. Es stoppt den Entpacker und gut is. So, man weiß Bescheid, rm Bombe.tar.gz
und gut is. Meine Mails lasse ich auf dem Server liegen, und Mails mit Attachment, die ich nicht kenne,
werden gnadenlos gelöscht.
So what?
Markus
Von Mails unbekannter Herkunft?? Die löscht man, kann ja nix Gutes sein.
Also, wer das nicht kapiert hat...
Markus
Und wer entscheited das bei einer Automatik am Mailserver? DU? Na dann viel spaß mit deinem Chef ;))
Privat brauche ich keinen Virenscanner, der Win32-Viren in Anhängen sucht, die laufen eh nicht
Konqueror kann sogar eine Datei in einer gepackten Datei öffnen.
Wieso machen die Virus scanner es nicht genauso wie konqueror.
anderst könnt ich es mir ned vorstellen.
und dann wär das auch keine andere methode wies der virenscanner macht.
Was die 2 GB angeht: Das kann ich mir erstens fast nicht vorstellen (man kann doch mit MacOS auch Videoschnitt machen??) und zweitens ist das unter Linux LEIDER immer noch gelegentlich ein Problem, dass Programme mit größeren Dateien nicht klarkommen.
Es gibt genügend Anwendungen dafür (Backups in ner Datei, wie gesagt Videoschnitt, umfangreiche Audiobearbeitungen etc.).
Es fehlt eine sehr wichtige Anwendung: ISO-Dateien
Und wen is mit HSF nicht geht kann man auch andere Unix Filesysteme unter OSX nutzten.
Wie auch immer ich habe bereits an einem MAC gearbeitd an dem ich sehr grosse Dateien bearbeiten konnte.
Grüsse,
Calle
Der Original Poster spricht von "MacOS" und nicht von "MacOSX"!
Das klassische MacOS hat so seine Tücken und Begrenzungen. Das UNIX basierende MacOSX hingegen spielt schon in einer ganz anderen Liga. Erst recht auf den 64bittigen G5 Rechnern.
Wenn aber z.B. ein auf 500MB gebrachtes,grosses Backup genommen wird, genehmigt sich Ark viel Speicher