Was sind Relocation Pointer Table und Overlaynumber (EXE)?

[Dannyboy]

Ich hoffe, dies hier ist die richtige Sparte für das Thema.

Da ich versuche ein sich selbst extrahierendes Archiv zu erstellen und mir empfohlen wurde, mich
erst einmal mit der EXE-Struktur zu befassen, stelle ich hier mal 2 konkrete Fragen dazu.

Im Voraus die Information an Euch, dass ich mich natürlich bereits mit der Materie befasst habe.
Unter www.wotsit.org habe ich z.B. die Struktur von EXE-Dateien studiert.
Nur leider werden hier einfach Tatsachen geschildert, ohne diese zu erklären. (Das erinnert uns
doch an so manchen Professor :mrgreen: ).

Beim untersuchen von den EXE-Headern fiel mir auf, dass manche EXE-Dateien gar keine (null)
Einträge im Relocation Pointer Table haben. Es stellt sich mir ohnehin die Frage:

1) Wozu braucht man den Relocation Pointer Table, wenn doch der Einstiegspunkt der EXE mittels
CS:IP und der Stack mittels SS:SP ermittelt werden kann? :gruebel:

Und dann gibt es im EXE-Header noch die sogenannte Overlay Number, mit der ich auch gar
nichts anfangen kann, also stellt sich mir Frage Numero 2

2) Was ist die Overlay Nummer und wozu braucht man die? :gruebel:

Und damit ich solche Informationen gleich mal sammeln kann, kann mir der ein oder Andere von Euch
vielleicht noch einen guten URL geben, bei dem man solche spezifischen Dinge nachlessen kann? :gruebel:

Danke schon mal.

DANNYBOY

[Luckie]

Wähle bitte ein aussagekräftigeres Topic. Unter "Exe mal wieder" kann sich niemand was vorstellen.

Aber wozu muss man das Exe Format kennen, um in SFXArchiv zu bauen? Häng die Dateien eine Exe dran und diese Exe mit den angehängten Dateien kopiert selbige dann auf die Festplatte. Sie dazu auch meine SFXTools, von meiner Homepage.

[Dannyboy]

Zitat:

Zitat von Luckie

Wähle bitte ein aussagekräftigeres Topic. Unter "Exe mal wieder" kann sich niemand was vorstellen.

Ok, stimmt. :oops:
Kann ich das im Nachhinein eigentlich ändern?

@Luckie: Danke für den Hinweis, ich sehe mir das mit dem SFXArchiv gern mal an. :thuimb:

Mich interessieren immer noch die Antworten auf meine Fragen.
Weiss das jemand vielleicht? :gruebel:

[LarsMiddendorf]

Exe Dateien benötigen keine Relocation Table, weil sie immer als erstes Modul in den virtuellen Addressraum geladen werden und daher immer an die bevorzugte Addresse geladen werden können, weil der Speicher noch frei ist. Bei DLL's ist das natürlich anders und in der Relocation Table sind die Addressen angegeben bei denen im Speicher die Differenz zwischen der optimalen Ladeaddresse und der tatsächlichen aufaddiert wird. Delphi fügt immer Relocations hinzu aber es gibt auch Tools mit denen man sie wieder entfernen kann damit die Exe Datei kleiner wird.
Overlays gibt es unter Windows nicht mehr.
Eine gute Beschreibung vom PE Format gibt es hier:
http://msdn.microsoft.com/msdnmag/is...03/PE2/toc.asp.

[sakura]

Zitat:

Zitat von Dannyboy

Kann ich das im Nachhinein eigentlich ändern?

Ja. Du gehst auf den http://www.delphipraxis.net/template.../icon_edit.gif Schalter über Deinem ersten Beitrag und änderst den Titel.

...:cat:...

[Dannyboy]

Zitat:

Zitat von sakura

Zitat:

Zitat von Dannyboy

Kann ich das im Nachhinein eigentlich ändern?

Ja. Du gehst auf den http://www.delphipraxis.net/template.../icon_edit.gif Schalter über Deinem ersten Beitrag und änderst den Titel.
...:cat:...

Gesagt, getan. :coder:

@LarsMiddendorf

Danke schon mal für die Erläuterung. Interessant daran ist, dass
man laut Deiner Aussage den Relocation Pointer Table gar nicht mehr
benötigt.

Könnte ich 100%ig davon ausgehen, dass die Datei noch
funktioniert, wenn ich den kompletten reloc. Table entfernen würde? :gruebel:

[LarsMiddendorf]

Der Visual C++ Linker fügt beim Linken mit Release Einstellungen gar keine Relocations in die Exe Dateien ein. In der Datei Notepad.exe sind z.B. auch keine.

[Dannyboy]

Zitat:

Zitat von Dannyboy

Beim untersuchen von den EXE-Headern fiel mir auf, dass manche EXE-Dateien gar keine (null) Einträge im Relocation Pointer Table haben.
DANNYBOY

@ LarsMiddendorf :
Yo, das habe ich auch entdeckt, aber könnte ich auch bereits bestehene Relocs. aus
der Exe entfernen oder wäre sie dann kaputt? :gruebel:

[Luckie]

Aus einer Exe ja. Aus einer DLL nein.

Link: http://www.jrsoftware.org/striprlc.php

[Dannyboy]

Zitat:

Zitat von Luckie

Aus einer Exe ja. Aus einer DLL nein.

Ok danke, das probier' ich mal aus (ASM). :thuimb:

[NicoDE]

Zitat:

Zitat von Dannyboy

Könnte ich 100%ig davon ausgehen, dass die Datei noch funktioniert, wenn ich den kompletten reloc. Table entfernen würde?

Zu 99%.
Wenn zum Beispiel jemand Dein Programm unter Wine ausführt, kann es in einigen Fällen dazu kommen, dass das Image nicht an die bevorzugte Adresse geladen werden kann. Das gleiche gilt für Adressen oberhalb von 2GB bzw. 3GB, die durch Systembibliotheken blockiert sein könnten (auf die Idee sollte man ohnehin nicht kommen, aber wer weiss :))...
Im Normalfall kann man sowas aber vernachlässigen.


Gruss Nico

[Dannyboy]

@NicoDE

Ist Wine nicht ein Windows-Emulator für Unix/Linux?
Na ja, wenn da mein Exe-Komprimierer nicht laufen sollte, dann macht
das nix. :mrgreen:

Und das mit der 3GB Grenze, na ja .... unwahrscheinlich. :wink:

[NicoDE]

Zitat:

Zitat von Dannyboy

Ist Wine nicht ein Windows-Emulator für Unix/Linux?

"Wine Is Not an Emulator" ;)
http://www.winehq.com/site/myths

[Dannyboy]

Ok, dann nenn' ich es Implementator, da es die API implementiert. 8)

[Luckie]

Bei mir hat das irgend wie nie viel gebracht. Das höchste aller Gefühle waren mal 4 KB bei einer 794 KB großen Exe. :roll:

[Dannyboy]

Zitat:

Zitat von Luckie

Bei mir hat das irgend wie nie viel gebracht. Das höchste aller Gefühle waren mal 4 KB bei einer 794 KB großen Exe. :roll:

Oh wow! :o
Dann müsste diese EXE ja 1024 Relocation Pointer Einträge gehabt haben. So wie ich das
verstanden habe sind diese Einträge immer ein vielfaches von der Zahl 4. Das sind 'ne
ganze Menge Einträge in Anbetracht der Tatsache, dass EXE-Dateien auch ohne sie funktionieren. :mrgreen:
Betrachtet man aber die Größe Deiner EXE (794 KB), dann sind die 4 KB Verkleinerung sehr wenig,
klar.

@LarsMiddendorf:
Yup, das mit der Notepad-EXE stimmt tatsächlich! Siehe Bild (NOTEPAD.jpg) im Anhang.

Ich häng' hier gerade das Programm an, mit dem man EXE-Header lesen kann. Nix besonderes.
(Anhang)

Zitat:

Zitat von LarsMiddendorf

Overlays gibt es unter Windows nicht mehr.

Da fällt mir ein, dass Delphi beim Compilieren die Overlaynumber auf 001AH setzt. (Siehe
Datei Delphi_Overlay.jpg im Anhang)

Ich dachte bisher, wenn die Overlaynumber Null ist, dann gilt die EXE als
Hauptprogramm (laut Definition), deshalb verstehe ich nicht, warum Delphi
die Overlaynumber setzt.
Warum setzt Delphi denn Overlays und was bewirkt das? :gruebel:
Worin macht sich der Unterscied bemerkbar? :gruebel:

[NicoDE]

Zitat:

Zitat von Dannyboy

Ich dachte bisher, wenn die Overlaynumber Null ist, dann gilt die EXE als Hauptprogramm (laut Definition)

Ist eher als Richtlinie/Anhaltspunkt zu verstehen.

Zitat:

Zitat von Dannyboy

Warum setzt Delphi denn Overlays und was bewirkt das?

Die Frage kann Dir wahrscheinlich nur der Entwickler des Delphi-Linkers beantworten.
(Vielleicht ist es nur ein Zahlen-/Wortspiel - 0x1A = ACSII-Zeichen 'sub' -> s(t)ub :))

Zitat:

Zitat von Dannyboy

Worin macht sich der Unterscied bemerkbar?

Bemerkbar macht es sich sich nicht. Der Image-Loader geht dann anders mit der Größe der Datei auf der Platte und mit der Anzahl der Seiten im Header um. Es macht den Ladeprozess im ganzen nur etwas komplizierter - wenn der verwendete Image-Loader überhaupt mit Overlays umgehen kann. Bei solch einem kleinem Programm wie dem Stub ist es ohnehin unwichtig (ob die Nachricht, dass dieses Programm Windows benötigt, nun erscheint oder nicht, interessiert kaum jemand).

[LarsMiddendorf]

Du liest nur den Dos Header des Programms aus. Der Dos Teil gibt, wie schon gesagt, nur eine kurze Meldung aus. Der eigentliche Win32 PE Header folgt erst nach dem Dos Stub. Für diese kurze Meldung werden vermutlich niemals Relocations wirklich gebraucht. In dem Text, zu dem ich weiter oben den Link gepostet habe, ist beschrieben wie man den PE Header ausliest.

[Dannyboy]

O.k., ich danke Euch. Habe mir mal eben den wirklichen WIN32 PE HEADER angesehen ...
der ist ja krass komplex. :shock: :shock: :shock:
Wer soll denn da durchblicken, mal ganz abgesehen von den ganzen undefinierten Bytefolgen!
Sieht so aus, als müsste ich mich da erst einarbeiten, um mein erstes,
selbst-extrahierendes File zu schreiben. :kotz:
Egal, wenigstens habe ich den Stub-Teil bereits hinter mir. :mrgreen:
Danke noch mal an Euch alle,:cheers:, ich werde mir nun den gesamten PE_HEADER Teil
zu Gemüte führen. Wenn ich Fragen hab', dann schrei' ich einfach. :zwinker:
Also dann. :coder:

[Luckie]

Zitat:

Zitat von Dannyboy

selbst-extrahierendes File zu schreiben. :kotz:

Wie schon gesagt, wenn es nur das ist, brauchst du den ganzen PE_HEADER Kram nicht. Du kannst Dateien an eine Exe dranhängen und sie bleibt noch ausführbar. Und die Exe kann dann ihre Anhänge extrahieren.

[Dannyboy]

Zitat:

Zitat von Luckie

Wie schon gesagt, wenn es nur das ist, brauchst du den ganzen PE_HEADER Kram nicht. Du kannst Dateien an eine Exe dranhängen und sie bleibt noch ausführbar. Und die Exe kann dann ihre Anhänge extrahieren.

Yo, ich habe mir das dann quasi so gedacht, dass ich die Bytefolgen von anderen Dateien
hinten an die EXE dranhänge und diese dann von einem bestimmten Teil im Loadmodule extrahieren
lasse. Natürlich muss ich dann auch die Einstegspunkte ändern, was mein Anti-Virus-Scanner
bisher nicht so toll fand! Leider meckert er da, aber das kann man ja nachvollziehen, da das leider
genau die selbe Methode von Viren ist. Ich frage mich, wie andere selbstextrahierende Packer das
machen, ohne vom Anti-Virus-Scanner eins auf die Finger zu kriegen :gruebel:

[LarsMiddendorf]

Es reicht eigentlich wenn du die Daten direkt ans Ende anhängst. Danach schreibst du noch die Länge der Daten dahinter, damit du sie korrekt ausleste kannst. Der letzte Integer Wert in der Datei beschreibt dann die Länge der Daten. Dann kann man den Stream genau den Startpunkt berechnen.

So in etwa müßte das funktionieren (ungetestet):

Code:

var
 l:integer;
 Data:array of byte;
 st:TFileStream;
begin
st:=TFilestream.Create('',fmsharedenywrite);
st.Seek(-4,sofromend);
st.ReadBuffer(l,4);
st.Seek(-4-l,sofromend);
SetLength(Data,l);
st.ReadBuffer(Data[0],l);
st.Free;
end;

Irgendwo im Forum wurde auch mal beschrieben wie man eine Exe Datei aus dem Speicher laden kann. Die Exe Packer verändern aber tatsächlich den Einsprungspunkt aber die meisten Packer sind den Antivirenprogrammen bekannt.

[Dannyboy]

Yo, ich mache das auch ähnlich wie in Deinem Example (halt nur in Assembler).

Zitat:

Zitat von LarsMiddendorf

Irgendwo im Forum wurde auch mal beschrieben wie man eine Exe Datei aus dem Speicher laden kann. Die Exe Packer verändern aber tatsächlich den Einsprungspunkt aber die meisten Packer sind den Antivirenprogrammen bekannt.

Na super! :twisted: :twisted: :twisted: Ich kann mein Programm wohl schlecht bei allen
Antivirus-Firmen registrieren lassen, sobald es fertig ist! :twisted: Jetzt darf ich mir
noch irgendwelche Methoden einfallen lassen, damit die Anti-Virus-Software meinen Extrahierer
nicht bemängelt. Das finde ich zum :kotz: !

[Luckie]

Zitat:

Zitat von Dannyboy

Yo, ich habe mir das dann quasi so gedacht, dass ich die Bytefolgen von anderen Dateien
hinten an die EXE dranhänge und diese dann von einem bestimmten Teil im Loadmodule extrahieren
lasse.

Nicht vom Lademodul, von der Exe selber.

Zitat:

Natürlich muss ich dann auch die Einstegspunkte ändern, was mein Anti-Virus-Scanner
bisher nicht so toll fand!

Paperlapp. Sieh oben.

Kuck dir auf meiner HP die SFXTools an. Genauso mache ich es mit denen. Ich habe eine Stub an der ich die Dateien mit einer anderen Exe dranhänge. Die Stub enthält den Code um die eigenen Anhänge wieder auf Platte zu schreiben. Da die Stub vorherkopiert wird änderst sich auch nicht die Größe der original Stub. Si wird ja praktisch neu erstellt mit den angehängten Dateien. Weshalb auch kein Virenscanner mekert.

[Dannyboy]

Ja Luckie, Du hast wohl Recht. Ich wollte den Code eigentlich vollkommen allein schreiben,
aber das hatte ich mir wohl leichter vorgestellt, als es ist. Ich wollte mir die ganzen
Informationen aneignen, die ich benötige, dabei aber dennoch auf jeglichen Sourcecode
verzichten. Anscheinend geht das wohl doch nicht und ich bin doch auf bereits existenten
Code angewiesen. :cry: Sowas ärgert mich! :evil:

[Luckie]

Wieso existierender Code? Niemand hält dich davon ab die Routinen zum Anhängen und Extrahieren selber zu schreiben. Hinweis: Kuck dir mal TFileStream an.

[Dannyboy]

Zitat:

Zitat von Luckie

Wieso existierender Code? Niemand hält dich davon ab die Routinen zum Anhängen und Extrahieren selber zu schreiben. Hinweis: Kuck dir mal TFileStream an.

Yo, ich werd's mir zumindest mal anschauen um mir die ein oder andere Idee zu holen. :mrgreen:
Filestream kenne ich, aber ich schreibe das Programm komplett in Assembler. :!:

[Luckie]

Darf man fragen warum? :roll:

[Dannyboy]

Zitat:

Zitat von Luckie

Darf man fragen warum? :roll:

Na klar doch. Ich würde ja gern so was erzählen wie : "Bla bla, Performance hin,
Performance her, bla bla, Assembler ist schneller" und das übliche Zeug einfach.
Aber das hat in Wirklichkeit gar nichts mit Performance zu tun.

Ich hatte während des Abiturs mal Assembler und in den 2 Jahren danach habe
ich einen Großteil dessen wieder vergessen (oder verdrängt :wink: ). Ich wollte
mir Assembler wieder aneignen und fing dann mit einfacheren Aufgaben an,
wie Stringschupsereien und Stack Rumgepusche und "Gepoppe". :wink:
Yo, nachdem ich mir dann das Wissen dieser Themen wieder angeeignet hatte,
fing ich mit Dateiverarbeitung in Assembler an. Auf meinem Weg dort hin,
habe ich hier im Forum die korrespondierenden Fragen zu ASSEMBLER gestellt.
Das sieht man hier:Dannyboy AND Assembler.
Yo, und da bin ich nun. :thuimb:

[Fukiszo]

man kanns auch total billig aber dafür kompatibel zu jedem AV programm so machen:
erstelle ein kleines konsolen programm (stub) das code für folgendes enthält
- schreiben von resourcen in speicher
- code zum ausführen des speichers
- code der das obrige beim starten ausführt

füge deine PE datei als resource der stub datei zu.
PE datei kann im vorfeld mit was auch immer bearbeitet sein,
wie meistens gibt es auch hier ausnahmen (selfcheck, programme die ihre config in exe speichern usw...)
aber der großteil der programme greift ja glücklicherweise nicht direkt auf sich selbst zu. (spring zu offset X und lad Y bytes etc...)

Im groben arbeitet so mein AV-Helper, was lediglich ein stub ist mit paar schmankerl (RC4 verschlüsselung, RtlCompressBuffer als packer)
kann logischerweise per memory-dump teilweise "zurückverwandelt" werden aber nicht per PE extraktion einfach aus exe-datei gespeichert werden.

[Zacherl]

Das Thema ist 14! Jahre alt 8-) Mitlerweile sucht der TE denke ich nicht mehr nach einer Antwort.

Das was du vorschlägst ist besser bekannt als RunPE und wird seit Jahren von Malware eingesetzt, weshalb auch hier einige Antiviren Programme recht schnell Alarm schlagen werden.

[Fukiszo]

ja sorry, ich bin neu hier und gerade solche thematik mag ich sehr.
so wie ich es einsetze bleiben AV's happy da meine IAT etwas abgeändert ist.

in den VARs definier ich relativ normal die funktion, nur halt das "Extern" bleibt weg.

hier ist der knackpunkt der AV's glücklich macht:

Delphi-Quellcode:

@zCreateProcessA := GetProcAddress(KERNEL32, pChar(deCrypt('zeichenkette die CreateProcessA enthält', 'Alarm, böse funktion')));

ich lad dann die funktion dynamisch rein und nicht statisch.
ich bin auf suche nach PE packern oder kryptern halt auf dieses Thema gestossen.
meine bisherigen suchergebnisse im DP forum führten bisher leider nicht zu einem packer/kryptor sondern nur zu diskussionen wie sinnvoll ein packer wie "UPX" ist oder fragende wurden schlichtweg ausgelacht.

da kompression/kryptologie älter als jeder PC ist, häng ich da kein datum als referenz ran.

RunPE ist eine möglichkeit etwas auszuführen, jupp.

Da mein code absolut bösen krams beinhaltet,
meine bisherigen vorschläge zu thema xyz stark kritisiert wurden wegen bösartigkeit bzw da ich nicht unicode konform programmiere, siehe meine definition da, wieder nur ein pChar, untersage ich es mir selbst so ein produkt hier vorzustellen.
zumal ich auch noch was undokumentiertes zur kompression einsetze "RtlCompressBuffer" was möglicherweise nicht in jeder windows version zur verfügung steht und bestimmte menschen gleich wieder schreien "msdn sagt xyz dazu"....

aber darüber reden sollte doch ok sein hoff ich.