Ausserdem sind die Scan- und Desinfektionswerkzeuge in sehr naivem Stil geschrieben.
Haben die noch wie was von mmap(2) gehört?
Es sieht so aus, dass sich der Virus an des Ende des Codesegmentes hängt.
Anscheinend ist zwischen Code- und nachfolgenden Datensegment bei normalen (nicht infizierten Programmen) immer mindestens eine Seite (4096 Byte) frei.
Auf meinem zeitgenössischen RedHat 7.2 sieht das etwa so aus:
$ readelf -l /bin/sh | grep LOAD
LOAD 0x000000 0x08048000 0x08048000 0x79273 0x79273 R E 0x1000
LOAD 0x079280 0x080c2280 0x080c2280 0x057e0 0x09bd0 RW 0x1000
Die erste Zeile ist das Codesegment, erkennbar an den Flags "R E" für Read und Execute.
Zweite Zeile ist das Datensegment, Read und Write.
Zweite Spalte ist der Offset innerhalb der Datei. Dritte Spalte die virtuelle Adresse an der das Segment im Speicher eingeblendet wird.
Der Wert 0x08048000 ist anscheinend Standard. Das heißt, jedes Programm sollte an dieser Adresse seinen eigenen ELF-Header finden. Folgendes Beispiel gibt also "ELF" aus:
#include <stdio.h>
int main() { return printf("%.3s\n", 0x08048001); }
Details dazu in /usr/include/elf.h.
Die sechste Spalte ist die Größe des Segments im Speicher.
Ende des Codesegments:
0x08048000 + 0x79273 = 0x80C1273
Anfang des Datensegments - Ende des Codesegments:
0x080c2280 - 0x80C1273 = 0x100D = 4109 Byte
Warum macht der gcc bzw. ld das?
Wozu ist diese Leerseite gut (ausser um da einen Virus unterzubringen)?
--
Ich bin ein Teletubby. Und das ist auch gut so.
| 
