Wie funktionieren Würmer...

[Jacky2k]

Hallo,

Ihr kennt doch sicherlich diese nervigen Würmer die sich von einer zur nächsten exe Datei hangeln, sich immer da mit eintragen und die Einsprungsadresse verändern, damit erst der Wurm gestartet wird und danach dann das Hauptprogramm.
Naja ich habe mich damit ein wenig beschäftigt jedoch wird mir eins nicht ganz klar: Ich denke nicht, dass diese Würmer die Datei komplett umstrukturieren wenn sie sie infizieren, also werden sie sich vermutlich ganz hinten dran hängen und für sich ein eigenes Segment erstellen. Aber wie kann sich solch ein Wurm so dynamisch anpassen an verschiedene Dateien, denn wenn er sich immer ganz hinten ran hängt bekommt auch auch automatisch immer eine andere Adresse an der er geladen wird, somit kann er keine relativen Adressen verwenden, die sich außerhalb von seiner Section befinden, wie ruft er dann z.B. Funktionen aus der Windows API auf??? Oder sind die so geschrieben, dass diese "externen" Adressen dann immer manuell berechnet werden?

Hoffe ihr denkt jetzt nichts falsches von mir, ich bastel grade an einem kleinen Betriebssystem und hoffe damit die Struktur eines PCs besser verstehen zu können...

[Christian Marquardt]

Sämtliche Programme, DLLs sind relativ zu 0 compiliert und gelinkt. Kein Programm kann wissen, in welchem Speicherbereich es laufen wird.

Wird ein Programm geladen, so werden die Sprungadressen usw. an den aktuellen Speicher angepasst. So auch der Wurm

[Jacky2k]

Mhh so ganz kann das nicht stimmen, denn wenn ich einen absoluten jump zu 0 mache, springt er in Wirklichkeit zu 0x400000. ImageBase und so...
Naja, aber der Wurm kann es ja, wie ich beschrieben habe, nicht wissen, denn er muss sich immer ganz hinten ran hängen...oder meinst du dass der Wurm das selber macht wenn er sich an eine andere datei hängt?

Edit: Nochmal dazu dass Windows dass immer neu berechnet...ich habe nun in zahlreichen Quellen gefunden, dass er das i.d.R. nicht machen braucht. z.B. in einer Beschreibung vom PE Explorer:

In aller Regel gibt es keinen Bedarf für eine EXE, eine Basis-Standortwechsel-Tabelle zu haben. Dies ist, weil EXEs die in einen Adressraum geladene erste Sache sind, und deshalb ist garantiert, sie in die bevorzugte Speicheradresse geladen werden.

[Christian Marquardt]

Mhh so ganz kann das nicht stimmen

Gut, dann ist das halt Zauberei

http://www.windowsitlibrary.com/Content/356/11/1.html

[Jacky2k]

Hä? Da steht doch genau das was ich sage:

If the file is loaded at this address in memory, the loader need not do any base relocations. This is because the linker resolves all the base relocations at the time of linking, assuming that the file will be loaded at this address. We discuss this in more detail in the section on the relocation table. For now, it is enough to know that the loading time is reduced if a file gets loaded at the preferred base address. A file may not get loaded at the preferred base address because of the nonavailability of the address. This happens when more than one DLL used by an executable use the same preferred base address. The default preferred base address is 0x400000. You may want to have a different preferred base address for your DLL so that it does not clash with that of any other DLL used by your application. You can change the preferred base address using a linker switch. You can also change the base address of a file using the rebase utility that comes with the Win32 SDK.

Edit: Ich habe niemals von dll's gesprochen, ich habe nur von exe Dateien geredet...

[Christian Marquardt]

Bitte lies komplett und alles:

A) giblt das nur für / ab NT

B) ist es egal ob die Adresse 0 oder 0x400000 ist.

http://www.windowsitlibrary.com/Content/356/11/5.html

Grundsätzlich wird das Programm realativ zu einer Adresse erstellt. Wie sollte es anders möglich sein? Woher soll der Compiler wissen, in welchem Speicherbereich das Programm mal irgendwann laufen wird. Also geht man von Wert X aus. Ist dort alles frei, prima, alles ok. istr dort nichts mehr frei, muss ein anderer Platz gefunden werden. Dieser Offset wird auf die Adresse addiert.


If, for some reason, the file cannot be loaded at the base address of 0x400000, the loader needs to patch the call. If the loader manages to load the file at a base address of 0x600000, it needs to change the call address to 0x600100. In general, it needs to add the difference of 0x200000 to all the to-be-patched locations.

und das dürfte der Regelfall sein

Und davon profiert dein Wurm

[Jacky2k]

und das dürfte der Regelfall sein

Dass er das umändern muss? Nein! Habe inzwischen gelernt dass jedes Programm dank der Paging-Tabellen und dem CR3 Register in dem Task State Segment sein eigenen kompletten RAM hat, jedes Programm hat virtuelle 4GB zur Verfügung... von daher kann jedes Progrmm (NICHT DLL!) an 0x400000 sitzen.