Translated ['src/generic-methodologies-and-resources/basic-forensic-meth

2025-10-10 18:36:50 +00:00 · 2025-09-04 09:32:46 +00:00 · 2025-09-04 09:32:46 +00:00 · 36b13dc56b
commit 36b13dc56b
parent 748b459159
3 changed files with 122 additions and 122 deletions
--- a/src/generic-methodologies-and-resources/basic-forensic-methodology/malware-analysis.md
+++ b/src/generic-methodologies-and-resources/basic-forensic-methodology/malware-analysis.md
@ -1,8 +1,8 @@
-# Malware-Analyse
+# Malware Analysis

 {{#include ../../banners/hacktricks-training.md}}

-## Forensik-CheatSheets
+## Forensik-Cheat-Sheets

 [https://www.jaiminton.com/cheatsheet/DFIR/#](https://www.jaiminton.com/cheatsheet/DFIR/)

@ -25,7 +25,7 @@ sudo apt-get install -y yara
 #### Regeln vorbereiten

 Verwende dieses Skript, um alle yara malware rules von github herunterzuladen und zusammenzuführen: [https://gist.github.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9](https://gist.github.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9)\
-Erstelle das _**rules**_ Verzeichnis und führe das Skript aus. Dadurch wird eine Datei namens _**malware_rules.yar**_ erstellt, die alle yara malware rules enthält.
+Erstelle das _**rules**_ Verzeichnis und führe es aus. Dadurch wird eine Datei mit dem Namen _**malware_rules.yar**_ erstellt, die alle yara rules für malware enthält.
 ```bash
 wget https://gist.githubusercontent.com/andreafortuna/29c6ea48adf3d45a979a78763cdc7ce9/raw/4ec711d37f1b428b63bed1f786b26a0654aa2f31/malware_yara_rules.py
 mkdir rules
@ -36,9 +36,9 @@ python malware_yara_rules.py
 yara -w malware_rules.yar image  #Scan 1 file
 yara -w malware_rules.yar folder #Scan the whole folder
 ```
-#### YaraGen: Auf malware prüfen und yara rules erstellen
+#### YaraGen: Auf Malware prüfen und Regeln erstellen

-Du kannst das Tool [**YaraGen**](https://github.com/Neo23x0/yarGen) verwenden, um yara rules aus einer Binärdatei zu generieren. Sieh dir diese Tutorials an: [**Part 1**](https://www.nextron-systems.com/2015/02/16/write-simple-sound-yara-rules/), [**Part 2**](https://www.nextron-systems.com/2015/10/17/how-to-write-simple-but-sound-yara-rules-part-2/), [**Part 3**](https://www.nextron-systems.com/2016/04/15/how-to-write-simple-but-sound-yara-rules-part-3/)
+Du kannst das Tool [**YaraGen**](https://github.com/Neo23x0/yarGen) verwenden, um yara rules aus einem binary zu generieren. Schau dir diese Tutorials an: [**Part 1**](https://www.nextron-systems.com/2015/02/16/write-simple-sound-yara-rules/), [**Part 2**](https://www.nextron-systems.com/2015/10/17/how-to-write-simple-but-sound-yara-rules-part-2/), [**Part 3**](https://www.nextron-systems.com/2016/04/15/how-to-write-simple-but-sound-yara-rules-part-3/)
 ```bash
 python3 yarGen.py --update
 python3.exe yarGen.py --excludegood -m  ../../mals/
@ -57,25 +57,25 @@ clamscan folderpath #Scan the whole folder
 ```
 ### [Capa](https://github.com/mandiant/capa)

-**Capa** erkennt potenziell bösartige **Fähigkeiten** in ausführbaren Dateien: PE, ELF, .NET. Es findet daher Dinge wie Att\&ck-Taktiken oder verdächtige Fähigkeiten wie:
+**Capa** erkennt potenziell bösartige **capabilities** in ausführbaren Dateien: PE, ELF, .NET. Es findet also Dinge wie Att\&ck tactics, oder verdächtige capabilities wie:

 - check for OutputDebugString error
 - run as a service
 - create process

-Holen Sie es sich im [**Github repo**](https://github.com/mandiant/capa).
+Hol es dir im [**Github repo**](https://github.com/mandiant/capa).

 ### IOCs

-IOC bedeutet Indicator Of Compromise. Ein IOC ist eine Menge von **Bedingungen, die** bestimmte potenziell unerwünschte Software oder bestätigte **Malware** identifizieren. Blue Teams verwenden diese Art von Definition, um **nach dieser Art von bösartigen Dateien** in ihren **Systemen** und **Netzwerken** zu suchen.\
-Das Teilen dieser Definitionen ist sehr nützlich, denn wenn Malware auf einem Computer identifiziert und ein IOC für diese Malware erstellt wird, können andere Blue Teams es nutzen, um die Malware schneller zu identifizieren.
+IOC bedeutet Indicator Of Compromise. Ein IOC ist eine Menge von **Bedingungen, die** potenziell unerwünschte Software oder bestätigte **malware** identifizieren. Blue Teams verwenden diese Art von Definition, um **nach dieser Art bösartiger Dateien** in ihren **Systemen** und **Netzwerken** zu suchen.\
+Das Teilen dieser Definitionen ist sehr nützlich, denn wenn auf einem Rechner malware identifiziert wird und dafür ein IOC erstellt wird, können andere Blue Teams es nutzen, um die malware schneller zu erkennen.

-Ein Tool zum Erstellen oder Ändern von IOCs ist [**IOC Editor**](https://www.fireeye.com/services/freeware/ioc-editor.html)**.**\
-Sie können Tools wie [**Redline**](https://www.fireeye.com/services/freeware/redline.html) verwenden, um **nach definierten IOCs auf einem Gerät zu suchen**.
+Ein Tool, um IOCs zu erstellen oder zu bearbeiten, ist [**IOC Editor**](https://www.fireeye.com/services/freeware/ioc-editor.html).\
+Man kann Werkzeuge wie [**Redline**](https://www.fireeye.com/services/freeware/redline.html) verwenden, um **nach definierten IOCs auf einem Gerät zu suchen**.

 ### Loki

-[**Loki**](https://github.com/Neo23x0/Loki) ist ein Scanner für einfache IOCs.\
+[**Loki**](https://github.com/Neo23x0/Loki) ist ein Scanner für Simple Indicators of Compromise.\
 Die Erkennung basiert auf vier Erkennungsmethoden:
 ```
 1. File Name IOC
@ -92,41 +92,41 @@ Compares process connection endpoints with C2 IOCs (new since version v.10)
 ```
 ### Linux Malware Detect

-[**Linux Malware Detect (LMD)**](https://www.rfxn.com/projects/linux-malware-detect/) ist ein Malware-Scanner für Linux, veröffentlicht unter der GNU GPLv2-Lizenz, der für die Bedrohungen in gemeinsam genutzten Hosting-Umgebungen entwickelt wurde. Er nutzt Threat-Daten aus network edge intrusion detection systems, um Malware zu extrahieren, die aktiv in Angriffen eingesetzt wird, und erzeugt Signaturen zur Erkennung. Zusätzlich stammen Threat-Daten auch aus user submissions über die LMD checkout-Funktion und aus malware community resources.
+[**Linux Malware Detect (LMD)**](https://www.rfxn.com/projects/linux-malware-detect/) ist ein Malware-Scanner für Linux, veröffentlicht unter der GNU GPLv2-Lizenz, der auf die Bedrohungen ausgelegt ist, denen Shared-Hosting-Umgebungen ausgesetzt sind. Er nutzt Bedrohungsdaten aus Netzwerk-Edge-Intrusion-Detection-Systemen, um Malware zu extrahieren, die aktiv in Angriffen verwendet wird, und erzeugt Signaturen zur Erkennung. Zusätzlich stammen Bedrohungsdaten auch aus Nutzer-Einsendungen über die LMD checkout-Funktion und aus Ressourcen der Malware-Community.

 ### rkhunter

-Werkzeuge wie [**rkhunter**](http://rkhunter.sourceforge.net) können verwendet werden, um das Dateisystem auf mögliche **rootkits** und Malware zu überprüfen.
+Tools wie [**rkhunter**](http://rkhunter.sourceforge.net) können verwendet werden, um das Dateisystem auf mögliche **rootkits** und Malware zu überprüfen.
 ```bash
 sudo ./rkhunter --check -r / -l /tmp/rkhunter.log [--report-warnings-only] [--skip-keypress]
 ```
 ### FLOSS

-[**FLOSS**](https://github.com/mandiant/flare-floss) ist ein Tool, das versucht, obfuskierte Strings in ausführbaren Dateien mit verschiedenen Techniken zu finden.
+[**FLOSS**](https://github.com/mandiant/flare-floss) ist ein Tool, das versucht, obfuskierte Strings in ausführbaren Dateien mithilfe verschiedener Techniken zu finden.

 ### PEpper

-[PEpper ](https://github.com/Th3Hurrican3/PEpper)prüft einige grundlegende Dinge in der ausführbaren Datei (Binärdaten, Entropie, URLs und IPs, einige Yara-Regeln).
+[PEpper ](https://github.com/Th3Hurrican3/PEpper) prüft grundlegende Dinge in der ausführbaren Datei (Binärdaten, Entropie, URLs und IPs, einige yara-Regeln).

 ### PEstudio

-[PEstudio](https://www.winitor.com/download) ist ein Tool, das Informationen zu Windows-Executables wie imports, exports, headers liefert, prüft außerdem virus total und findet potenzielle Att\&ck techniques.
+[PEstudio](https://www.winitor.com/download) ist ein Tool, das Informationen zu Windows-Executables wie Imports, Exports, Headern liefert, aber auch Virus Total prüft und potenzielle Att\&ck-Techniken findet.

 ### Detect It Easy(DiE)

-[**DiE**](https://github.com/horsicq/Detect-It-Easy/) ist ein Tool, um zu erkennen, ob eine Datei **encrypted** ist und außerdem **packers** findet.
+[**DiE**](https://github.com/horsicq/Detect-It-Easy/) ist ein Tool, um zu erkennen, ob eine Datei **verschlüsselt** ist, und um **Packer** zu finden.

 ### NeoPI

-[**NeoPI** ](https://github.com/CiscoCXSecurity/NeoPI) ist ein Python-Skript, das eine Vielzahl von **statistical methods** nutzt, um **obfuscated** und **encrypted** content in Text-/Script-Dateien zu erkennen. Der Zweck von NeoPI ist, bei der **detection of hidden web shell code** zu unterstützen.
+[**NeoPI** ](https://github.com/CiscoCXSecurity/NeoPI) ist ein Python-Skript, das verschiedene **statistische Methoden** verwendet, um **obfuskierte** und **verschlüsselte** Inhalte in Text-/Script-Dateien zu erkennen. Der Zweck von NeoPI ist es, bei der **Erkennung von verstecktem Webshell-Code** zu unterstützen.

 ### **php-malware-finder**

-[**PHP-malware-finder**](https://github.com/nbs-system/php-malware-finder) versucht so gut wie möglich, **obfuscated**/**dodgy code** zu erkennen sowie Dateien, die **PHP**-Funktionen verwenden, die oft in **malwares**/webshells vorkommen.
+[**PHP-malware-finder**](https://github.com/nbs-system/php-malware-finder) versucht bestmöglich, **obfuskierten**/**verdächtigen Code** sowie Dateien mit **PHP**-Funktionen zu erkennen, die häufig in **Malware**/Webshells verwendet werden.

 ### Apple Binary Signatures

-Beim Überprüfen eines **malware sample** solltest du immer die **Signatur** der Binary prüfen, da der **developer**, der sie signiert hat, bereits mit **malware** in Verbindung stehen könnte.
+Beim Prüfen einer **Malware sample** sollten Sie immer die **Signatur** der Binärdatei prüfen, da der **developer**, der sie signiert hat, möglicherweise bereits mit **malware** in Verbindung steht.
 ```bash
 #Get signer
 codesign -vv -d /bin/ls 2>&1 | grep -E "Authority|TeamIdentifier"
@ -141,23 +141,23 @@ spctl --assess --verbose /Applications/Safari.app

 ### File Stacking

-Wenn du weißt, dass ein Ordner mit den **Dateien** eines Webservers **zu einem bestimmten Datum zuletzt aktualisiert** wurde, **prüfe** das **Datum**, an dem alle **Dateien** im **Webserver** erstellt und geändert wurden. Wenn ein Datum **verdächtig** ist, untersuche diese Datei.
+Wenn Sie wissen, dass ein Ordner, der die **Dateien** eines Webservers enthält, **zu einem bestimmten Datum zuletzt aktualisiert wurde**, **prüfen** Sie das **Datum**, an dem alle **Dateien** auf dem **Webserver** erstellt und geändert wurden, und wenn ein Datum **verdächtig** ist, untersuchen Sie diese Datei.

 ### Baselines

-Wenn die Dateien eines Ordners **nicht verändert worden sein sollten**, kannst du die **Hashes** der **Originaldateien** des Ordners berechnen und mit den **aktuellen** vergleichen. Alles, was verändert wurde, ist **verdächtig**.
+Wenn die **Dateien** eines Ordners **nicht hätten verändert werden dürfen**, können Sie den **hash** der **originalen Dateien** des Ordners berechnen und **mit** den **aktuellen** vergleichen. Alles, was verändert wurde, ist **verdächtig**.

 ### Statistische Analyse

-Wenn die Informationen in Logs gespeichert sind, kannst du **Statistiken prüfen, z. B. wie oft jede Datei eines Webservers aufgerufen wurde**, da eine web shell zu den am häufigsten aufgerufenen gehören könnte.
+Wenn die Informationen in Logs gespeichert sind, können Sie **Statistiken prüfen**, z. B. wie oft jede Datei eines Webservers aufgerufen wurde — eine web shell könnte zu den am häufigsten aufgerufenen gehören.

 ---

-### Android in-app native telemetry (no root)
+### Android in-app native Telemetrie (no root)

-Auf Android kannst du nativen Code im Prozess der Ziel-App instrumentieren, indem du vor der Initialisierung anderer JNI-Libs eine kleine Logger-Library preloadest. Das ermöglicht frühe Einsicht in natives Verhalten ohne systemweite Hooks oder Root. Ein verbreiteter Ansatz ist SoTap: lege libsotap.so für die richtige ABI in das APK und injiziere einen System.loadLibrary("sotap")-Aufruf früh (z. B. statischer Initializer oder Application.onCreate), und sammle dann Logs aus internen/externen Pfaden oder als Logcat-Fallback.
+Auf Android können Sie nativen Code innerhalb des Ziel-App-Prozesses instrumentieren, indem Sie vor der Initialisierung anderer JNI libs eine kleine Logger-Library vorladen. Das ermöglicht frühe Einsicht in natives Verhalten ohne systemweite Hooks oder root. Ein verbreiteter Ansatz ist SoTap: legen Sie libsotap.so für das passende ABI in das APK und fügen Sie früh einen System.loadLibrary("sotap")-Aufruf ein (z. B. im static initializer oder in Application.onCreate), danach sammeln Sie Logs aus internen/externen Pfaden oder als Fallback Logcat.

-Siehe die Seite zum Android native reversing für Setup-Details und Log-Pfade:
+Siehe die Android native reversing Seite für Details zur Einrichtung und zu den Log-Pfaden:

 {{#ref}}
 ../../mobile-pentesting/android-app-pentesting/reversing-native-libraries.md
@ -167,11 +167,11 @@ Siehe die Seite zum Android native reversing für Setup-Details und Log-Pfade:

 ## Deobfuskation dynamischer Control-Flow (JMP/CALL RAX Dispatchers)

-Moderne Malware-Familien missbrauchen stark Control-Flow Graph (CFG) Obfuskation: statt eines direkten jump/call berechnen sie das Ziel zur Laufzeit und führen ein `jmp rax` oder `call rax` aus. Ein kleiner *Dispatcher* (typischerweise neun Instruktionen) setzt das finale Ziel abhängig von den CPU-`ZF`/`CF` Flags und zerstört damit vollständig die statische CFG-Rekonstruktion.
+Moderne Malware-Familien missbrauchen stark die Control-Flow Graph (CFG)-Obfuskation: anstatt eines direkten jump/call berechnen sie das Ziel zur Laufzeit und führen einen `jmp rax` oder `call rax` aus. Ein kleiner *dispatcher* (typischerweise neun Instruktionen) legt das endgültige Ziel abhängig von den CPU-Flags `ZF`/`CF` fest und bricht damit die statische CFG-Wiederherstellung vollständig.

-Die Technik – demonstriert vom SLOW#TEMPEST loader – lässt sich mit einem dreistufigen Workflow umgehen, der nur auf IDAPython und dem Unicorn CPU-Emulator basiert.
+Die Technik – demonstriert vom SLOW#TEMPEST loader – lässt sich mit einem dreistufigen Workflow umgehen, der nur auf IDAPython und dem Unicorn CPU emulator basiert.

-### 1. Lokalisieren Sie jeden indirekten jump / call
+### 1. Alle indirekten jump / call lokalisieren
 ```python
 import idautils, idc

@ -180,7 +180,7 @@ mnem = idc.print_insn_mnem(ea)
 if mnem in ("jmp", "call") and idc.print_operand(ea, 0) == "rax":
 print(f"[+] Dispatcher found @ {ea:X}")
 ```
-### 2. Dispatcher-Bytecode extrahieren
+### 2. Extrahiere den dispatcher byte-code
 ```python
 import idc

@ -211,9 +211,9 @@ mu.reg_write(UC_X86_REG_RAX, 0)
 mu.emu_start(BASE, BASE+len(code))
 return mu.reg_read(UC_X86_REG_RAX)
 ```
-Führe `run(code,0,0)` und `run(code,1,1)` aus, um die *false* und *true* branch targets zu erhalten.
+Führe `run(code,0,0)` und `run(code,1,1)` aus, um die *false*- bzw. *true*-Branch-Ziele zu ermitteln.

-### 4. Einen direkten jump / call zurückpatchen
+### 4. Direkten jump / call zurückpatchen
 ```python
 import struct, ida_bytes

@ -222,22 +222,22 @@ op   = 0xE8 if is_call else 0xE9           # CALL rel32 or JMP rel32
 disp = target - (ea + 5) & 0xFFFFFFFF
 ida_bytes.patch_bytes(ea, bytes([op]) + struct.pack('<I', disp))
 ```
-Nach dem Patchen IDA dazu zwingen, die Funktion neu zu analysieren, damit der vollständige CFG und die Hex-Rays-Ausgabe wiederhergestellt werden:
+Nach dem Patchen erzwingen, dass IDA die Funktion neu analysiert, damit das vollständige CFG und die Hex-Rays-Ausgabe wiederhergestellt werden:
 ```python
 import ida_auto, idaapi
 idaapi.reanalyze_function(idc.get_func_attr(ea, idc.FUNCATTR_START))
 ```
-### 5. Label indirect API calls
+### 5. Indirekte API-Aufrufe kennzeichnen

-Sobald das echte Ziel jedes `call rax` bekannt ist, können Sie IDA mitteilen, was es ist, damit Parametertypen & Variablennamen automatisch wiederhergestellt werden:
+Sobald das tatsächliche Ziel jedes `call rax` bekannt ist, können Sie IDA mitteilen, was es ist, damit Parameter-Typen und Variablennamen automatisch wiederhergestellt werden:
 ```python
 idc.set_callee_name(call_ea, resolved_addr, 0)  # IDA 8.3+
 ```
 ### Praktische Vorteile

-* Stellt das echte CFG wieder her → decompilation geht von *10* Zeilen auf Tausende.
-* Ermöglicht string-cross-reference & xrefs, making behaviour reconstruction trivial.
-* Scripts sind wiederverwendbar: Einfach in jeden loader legen, der durch denselben Trick geschützt ist.
+* Stellt die reale CFG wieder her → Dekomplilierung geht von *10* Zeilen auf Tausende.
+* Ermöglicht string-cross-reference & xrefs, macht die Rekonstruktion des Verhaltens trivial.
+* Scripts sind wiederverwendbar: Platziere sie in jeden loader, der durch denselben Trick geschützt ist.

 ---

--- a/src/mobile-pentesting/android-app-pentesting/reversing-native-libraries.md
+++ b/src/mobile-pentesting/android-app-pentesting/reversing-native-libraries.md
@ -1,50 +1,50 @@
-# Reverse Engineering nativer Bibliotheken
+# Reversing Native Libraries

 {{#include ../../banners/hacktricks-training.md}}


-**Für weitere Informationen siehe:** [**https://maddiestone.github.io/AndroidAppRE/reversing_native_libs.html**](https://maddiestone.github.io/AndroidAppRE/reversing_native_libs.html)
+**Für weitere Informationen:** [**https://maddiestone.github.io/AndroidAppRE/reversing_native_libs.html**](https://maddiestone.github.io/AndroidAppRE/reversing_native_libs.html)

-Android-Apps können native Bibliotheken verwenden, typischerweise in C oder C++, für performance-kritische Aufgaben. Malware-Autoren missbrauchen diese Bibliotheken ebenfalls, weil ELF shared objects nach wie vor schwerer zu dekompilieren sind als DEX/OAT-Bytecode.
-Diese Seite konzentriert sich auf *praktische* Workflows und *aktuelle* Tool-Verbesserungen (2023-2025), die das Reversing von Android `.so`-Dateien erleichtern.
+Android-Apps können native Bibliotheken verwenden, typischerweise in C oder C++, für leistungsintensive Aufgaben. Malware-Autoren missbrauchen diese Bibliotheken ebenfalls, weil ELF shared objects immer noch schwerer zu dekompilieren sind als DEX/OAT byte-code.
+Diese Seite konzentriert sich auf *praktische* Workflows und *aktuelle* Verbesserungen der Tools (2023–2025), die das reversing von Android `.so`-Dateien erleichtern.

 ---

 ### Schneller Triage-Workflow für eine frisch gezogene `libfoo.so`

-1. **Bibliothek extrahieren**
+1. **Extract the library**
 ```bash
 # From an installed application
 adb shell "run-as <pkg> cat lib/arm64-v8a/libfoo.so" > libfoo.so
 # Or from the APK (zip)
 unzip -j target.apk "lib/*/libfoo.so" -d extracted_libs/
 ```
-2. **Architektur & Schutzmechanismen identifizieren**
+2. **Identify architecture & protections**
 ```bash
 file libfoo.so        # arm64 or arm32 / x86
 readelf -h libfoo.so  # OS ABI, PIE, NX, RELRO, etc.
 checksec --file libfoo.so  # (peda/pwntools)
 ```
-3. **Exportierte Symbole & JNI-Bindings auflisten**
+3. **List exported symbols & JNI bindings**
 ```bash
 readelf -s libfoo.so | grep ' Java_'     # dynamic-linked JNI
 strings libfoo.so   | grep -i "RegisterNatives" -n   # static-registered JNI
 ```
-4. **In einen Decompiler laden** (Ghidra ≥ 11.0, IDA Pro, Binary Ninja, Hopper or Cutter/Rizin) und Auto-Analyse ausführen.
-Neuere Ghidra-Versionen haben einen AArch64-Decompiler eingeführt, der PAC/BTI-Stubs und MTE-Tags erkennt und die Analyse von Bibliotheken, die mit dem Android 14 NDK gebaut wurden, deutlich verbessert.
-5. **Abwägen: static vs dynamic reversing:** stripped, obfuscated code benötigt oft *instrumentation* (Frida, ptrace/gdbserver, LLDB).
+4. **Load in a decompiler** (Ghidra ≥ 11.0, IDA Pro, Binary Ninja, Hopper or Cutter/Rizin) and run auto-analysis.
+Neuere Ghidra-Versionen enthalten einen AArch64-Decompiler, der PAC/BTI-Stubs und MTE-Tags erkennt und die Analyse von Bibliotheken, die mit dem Android 14 NDK erstellt wurden, deutlich verbessert.
+5. **Decide on static vs dynamic reversing:** stripped, obfuscated code often needs *instrumentation* (Frida, ptrace/gdbserver, LLDB).

 ---

 ### Dynamische Instrumentation (Frida ≥ 16)

-Frida’s 16-Serie brachte mehrere Android-spezifische Verbesserungen, die helfen, wenn das Ziel moderne Clang/LLD-Optimierungen verwendet:
+Die 16er-Serie von Frida brachte mehrere Android-spezifische Verbesserungen, die helfen, wenn das Ziel moderne Clang/LLD-Optimierungen verwendet:

-* `thumb-relocator` kann jetzt *tiny ARM/Thumb functions* hooken, die von LLDs aggressiver Alignment-Strategie (`--icf=all`) erzeugt werden.
-* Enumerating and rebinding *ELF import slots* funktioniert auf Android, wodurch pro Modul `dlopen()`/`dlsym()`-Patching möglich ist, wenn inline hooks abgelehnt werden.
-* Java hooking wurde für den neuen **ART quick-entrypoint** behoben, der verwendet wird, wenn Apps mit `--enable-optimizations` auf Android 14 kompiliert werden.
+* `thumb-relocator` can now *hook tiny ARM/Thumb functions* generated by LLD’s aggressive alignment (`--icf=all`).
+* Enumerating and rebinding *ELF import slots* works on Android, enabling per-module `dlopen()`/`dlsym()` patching when inline hooks are rejected.
+* Java hooking was fixed for the new **ART quick-entrypoint** used when apps are compiled with `--enable-optimizations` on Android 14.

-Beispiel: Alle durch `RegisterNatives` registrierten Funktionen aufzählen und deren Adressen zur Laufzeit ausgeben:
+Beispiel: enumerating all functions registered through `RegisterNatives` and dumping their addresses at runtime:
 ```javascript
 Java.perform(function () {
 var Runtime = Java.use('java.lang.Runtime');
@ -61,29 +61,29 @@ console.log('[+] RegisterNatives on ' + clazz.getName() + ' -> ' + count + ' met
 });
 });
 ```
-Frida funktioniert sofort auf PAC/BTI-aktivierten Geräten (Pixel 8/Android 14+), solange du frida-server 16.2 oder neuer verwendest – ältere Versionen konnten das padding für inline hooks nicht finden.
+Frida will work out of the box on PAC/BTI-enabled devices (Pixel 8/Android 14+) as long as you use frida-server 16.2 or later – earlier versions failed to locate padding for inline hooks.

-### Prozesslokale JNI-Telemetrie durch vorgeladenes .so (SoTap)
+### Process-local JNI telemetry via preloaded .so (SoTap)

-Wenn vollwertige Instrumentation übertrieben oder blockiert ist, kannst du trotzdem native Sichtbarkeit gewinnen, indem du einen kleinen Logger im Zielprozess vorgeladst. SoTap ist eine leichte Android-native (.so) Bibliothek, die das Laufzeitverhalten anderer JNI (.so) Libraries innerhalb desselben App-Prozesses protokolliert (kein Root erforderlich).
+Wenn vollumfängliche Instrumentierung übertrieben oder blockiert ist, kannst du trotzdem native Sichtbarkeit gewinnen, indem du einen kleinen Logger im Zielprozess vorgeladen. SoTap ist eine leichte Android native (.so) Bibliothek, die das Laufzeitverhalten anderer JNI (.so) Bibliotheken im selben App-Prozess protokolliert (no root required).

-Wesentliche Eigenschaften:
+Wichtige Eigenschaften:
 - Initialisiert früh und beobachtet JNI/native Interaktionen innerhalb des Prozesses, der es lädt.
- Speichert Logs über mehrere beschreibbare Pfade mit einem sanften Fallback zu Logcat, wenn Speicher eingeschränkt ist.
- Quellcode-anpassbar: editier sotap.c, um zu erweitern/anzupassen, was geloggt wird, und rebuild pro ABI.
+- Persistiert Logs über mehrere beschreibbare Pfade mit einem sauberen Fallback zu Logcat, wenn der Speicher eingeschränkt ist.
+- Quellcode-anpassbar: bearbeite sotap.c, um zu erweitern/anpassen, was geloggt wird, und baue pro ABI neu.

-Setup (APK neu packen):
-1) Lege den richtigen ABI-Build in das APK, damit der Loader libsotap.so auflösen kann:
- lib/arm64-v8a/libsotap.so (für arm64)
- lib/armeabi-v7a/libsotap.so (für arm32)
-2) Stelle sicher, dass SoTap vor anderen JNI-Libs geladen wird. Injiziere einen frühen Aufruf (z. B. Application subclass static initializer oder onCreate), damit der Logger zuerst initialisiert wird. Smali-Snippet Beispiel:
+Setup (repack the APK):
+1) Drop the proper ABI build into the APK so the loader can resolve libsotap.so:
+- lib/arm64-v8a/libsotap.so (for arm64)
+- lib/armeabi-v7a/libsotap.so (for arm32)
+2) Ensure SoTap loads before other JNI libs. Inject a call early (e.g., Application subclass static initializer or onCreate) so the logger is initialized first. Smali snippet example:
 ```smali
 const-string v0, "sotap"
 invoke-static {v0}, Ljava/lang/System;->loadLibrary(Ljava/lang/String;)V
 ```
-3) Rebuild/sign/install, starte die App und sammle dann die Logs.
+3) Rebuild/sign/install, run the app, then collect logs.

-Log-Pfade (der Reihe nach geprüft):
+Log paths (checked in order):
 ```
 /data/user/0/%s/files/sotap.log
 /data/data/%s/files/sotap.log
@ -92,45 +92,45 @@ Log-Pfade (der Reihe nach geprüft):
 # If all fail: fallback to Logcat only
 ```
 Hinweise und Fehlerbehebung:
- ABI-Ausrichtung ist obligatorisch. Eine Nichtübereinstimmung löst UnsatisfiedLinkError aus und der Logger wird nicht geladen.
- Speicherbeschränkungen sind bei modernen Android-Geräten üblich; falls Dateischreibvorgänge fehlschlagen, gibt SoTap weiterhin Ausgaben über Logcat aus.
- Das Verhalten/der Detailgrad ist zur Anpassung gedacht; nach dem Bearbeiten von sotap.c aus dem Quellcode neu bauen.
+- ABI-Ausrichtung ist zwingend. Eine Nichtübereinstimmung löst eine UnsatisfiedLinkError aus und der Logger wird nicht geladen.
+- Speicherbeschränkungen sind auf modernen Android-Geräten üblich; wenn Datei-Schreibvorgänge fehlschlagen, gibt SoTap weiterhin über Logcat aus.
+- Verhalten und Ausgabedetailgrad sind anpassbar; nach Änderungen an sotap.c aus dem Quellcode neu bauen.

-Dieser Ansatz ist nützlich für Malware-Triage und JNI-Debugging, wenn das Beobachten nativer Aufrufflüsse vom Prozessstart an kritisch ist, aber systemweite Hooks oder Root nicht verfügbar sind.
+Dieser Ansatz ist nützlich für Malware-Triage und JNI-Debugging, wenn das Beobachten nativer Aufrufflüsse vom Prozessstart an kritisch ist, aber Root-/systemweite Hooks nicht verfügbar sind.

 ---

-### Kürzlich veröffentlichte Verwundbarkeiten, nach denen es sich in APKs zu suchen lohnt
+### Jüngste Schwachstellen, nach denen man in APKs suchen sollte

 | Year | CVE | Affected library | Notes |
 |------|-----|------------------|-------|
-|2023|CVE-2023-4863|`libwebp` ≤ 1.3.1|Heap buffer overflow reachable from native code that decodes WebP images. Several Android apps bundle vulnerable versions. When you see a `libwebp.so` inside an APK, check its version and attempt exploitation or patching.| |
-|2024|Multiple|OpenSSL 3.x series|Several memory-safety and padding-oracle issues. Many Flutter & ReactNative bundles ship their own `libcrypto.so`.|
+|2023|CVE-2023-4863|`libwebp` ≤ 1.3.1|Heap-Buffer-Overflow, zugänglich aus nativen Code, der WebP-Bilder decodiert. Mehrere Android-Apps enthalten verwundbare Versionen. Wenn Sie eine `libwebp.so` in einer APK finden, prüfen Sie deren Version und versuchen Sie Exploitierung oder Patchen.| |
+|2024|Multiple|OpenSSL 3.x series|Mehrere Speicher-Sicherheits- und Padding-Oracle-Probleme. Viele Flutter- & ReactNative-Bundles liefern ihre eigene `libcrypto.so` mit.|

-Wenn Sie *third-party* `.so`-Dateien in einem APK entdecken, gleichen Sie deren Hash immer mit den Upstream-Advisories ab. SCA (Software Composition Analysis) ist auf Mobilgeräten unüblich, daher sind veraltete verwundbare Builds weit verbreitet.
+Wenn Sie *third-party* `.so`-Dateien in einer APK entdecken, gleichen Sie deren Hash stets mit Upstream-Advisories ab. SCA (Software Composition Analysis) ist auf Mobilgeräten selten, daher sind veraltete, verwundbare Builds weit verbreitet.

 ---

-### Anti-Reversing & Härtungstrends (Android 13-15)
+### Anti-Reversing & Hardening trends (Android 13-15)

-* **Pointer Authentication (PAC) & Branch Target Identification (BTI):** Android 14 aktiviert PAC/BTI in Systembibliotheken auf unterstützter ARMv8.3+ Hardware. Decompiler zeigen jetzt PAC‐bezogene Pseudo-Instruktionen; für dynamische Analyse injiziert Frida Trampolines *nach dem Entfernen von PAC*, aber Ihre eigenen Trampolines sollten, wo nötig, `pacda`/`autibsp` aufrufen.
-* **MTE & Scudo hardened allocator:** Memory-Tagging ist optional (opt-in), aber viele Play-Integrity-bewusste Apps werden mit `-fsanitize=memtag` gebaut; verwenden Sie `setprop arm64.memtag.dump 1` plus `adb shell am start ...`, um Tag-Fehler zu erfassen.
-* **LLVM Obfuscator (opaque predicates, control-flow flattening):** kommerzielle Packer (z. B. Bangcle, SecNeo) schützen zunehmend *native* Code, nicht nur Java; erwarten Sie falsche Kontrollflüsse und verschlüsselte String-Blobs in `.rodata`.
+* **Pointer Authentication (PAC) & Branch Target Identification (BTI):** Android 14 aktiviert PAC/BTI in Systembibliotheken auf unterstütztem ARMv8.3+ Silizium. Decompiler zeigen jetzt PAC-bezogene Pseudo-Instruktionen; für dynamische Analyse injiziert Frida Trampoline *nachdem* PAC entfernt wurde, aber Ihre eigenen Trampoline sollten bei Bedarf `pacda`/`autibsp` aufrufen.
+* **MTE & Scudo hardened allocator:** Memory-Tagging ist optional, aber viele Play-Integrity-bewusste Apps werden mit `-fsanitize=memtag` gebaut; verwenden Sie `setprop arm64.memtag.dump 1` plus `adb shell am start ...`, um Tag-Faults zu erfassen.
+* **LLVM Obfuscator (opaque predicates, control-flow flattening):** Kommerzielle Packer (z. B. Bangcle, SecNeo) schützen zunehmend *nativen* Code, nicht nur Java; erwarten Sie gefälschte Kontrollflüsse und verschlüsselte String-Blobs in `.rodata`.

 ---

 ### Ressourcen

- **ARM Assembly lernen:** [Azeria Labs – ARM Assembly Basics](https://azeria-labs.com/writing-arm-assembly-part-1/)
+- **ARM-Assembly lernen:** [Azeria Labs – ARM Assembly Basics](https://azeria-labs.com/writing-arm-assembly-part-1/)
 - **JNI- & NDK-Dokumentation:** [Oracle JNI Spec](https://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/jniTOC.html) · [Android JNI Tips](https://developer.android.com/training/articles/perf-jni) · [NDK Guides](https://developer.android.com/ndk/guides/)
 - **Debugging nativer Bibliotheken:** [Debug Android Native Libraries Using JEB Decompiler](https://medium.com/@shubhamsonani/how-to-debug-android-native-libraries-using-jeb-decompiler-eec681a22cf3)

 ### Referenzen

- Frida 16.x change-log (Android hooking, tiny-function relocation) – [frida.re/news](https://frida.re/news/)
- NVD-Hinweis für den `libwebp`-Overflow CVE-2023-4863 – [nvd.nist.gov](https://nvd.nist.gov/vuln/detail/CVE-2023-4863)
- SoTap: Leichter In-App JNI (.so)-Verhaltenslogger – [github.com/RezaArbabBot/SoTap](https://github.com/RezaArbabBot/SoTap)
+- Frida 16.x Änderungsprotokoll (Android hooking, tiny-function relocation) – [frida.re/news](https://frida.re/news/)
+- NVD-Meldung für `libwebp`-Overflow CVE-2023-4863 – [nvd.nist.gov](https://nvd.nist.gov/vuln/detail/CVE-2023-4863)
+- SoTap: Leichter In-App-JNI (.so)-Verhaltenslogger – [github.com/RezaArbabBot/SoTap](https://github.com/RezaArbabBot/SoTap)
 - SoTap Releases – [github.com/RezaArbabBot/SoTap/releases](https://github.com/RezaArbabBot/SoTap/releases)
- Wie man mit SoTap arbeitet? – [t.me/ForYouTillEnd/13](https://t.me/ForYouTillEnd/13)
+- Wie arbeitet man mit SoTap? – [t.me/ForYouTillEnd/13](https://t.me/ForYouTillEnd/13)

 {{#include ../../banners/hacktricks-training.md}}
--- a/src/mobile-pentesting/android-app-pentesting/smali-changes.md
+++ b/src/mobile-pentesting/android-app-pentesting/smali-changes.md
@ -1,80 +1,80 @@
-# Smali - Decompilieren/[Modifizieren]/Kompilieren
+# Smali - Decompiling/[Modifying]/Compiling

 {{#include ../../banners/hacktricks-training.md}}


-Manchmal ist es interessant, den Anwendungscode zu modifizieren, um für dich auf versteckte Informationen zuzugreifen (z. B. stark obfuskierte Passwörter oder Flags). Dann kann es sinnvoll sein, die apk zu dekompilieren, den Code zu ändern und sie wieder zu kompilieren.
+Manchmal ist es interessant, den Anwendungscode zu verändern, um für dich versteckte Informationen zu erhalten (z. B. gut obfuskierte Passwörter oder flags). Dann kann es sinnvoll sein, die apk zu dekompilieren, den Code zu ändern und wieder zu kompilieren.

 **Opcodes-Referenz:** [http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html](http://pallergabor.uw.hu/androidblog/dalvik_opcodes.html)

-## Schnelle Methode
+## Schneller Weg

-Mit **Visual Studio Code** und der Erweiterung [APKLab](https://github.com/APKLab/APKLab) kannst du die Anwendung **automatisch dekompilieren**, ändern, **wieder kompilieren**, signieren und installieren, ohne einen Befehl auszuführen.
+Mit **Visual Studio Code** und der Erweiterung [APKLab](https://github.com/APKLab/APKLab) kannst du die Anwendung **automatically decompile**, ändern, **recompile**, signieren & installieren, ohne einen Befehl auszuführen.

 Ein weiteres **Skript**, das diese Aufgabe stark erleichtert, ist [**https://github.com/ax/apk.sh**](https://github.com/ax/apk.sh)

 ## APK dekompilieren

-Mit APKTool kannst du auf die **smali code and resources** zugreifen:
+Mit APKTool kannst du auf den **smali code und die Ressourcen** zugreifen:
 ```bash
 apktool d APP.apk
 ```
-Wenn **apktool** einen Fehler ausgibt, versuche[ die **neueste Version** zu installieren](https://ibotpeaches.github.io/Apktool/install/)
+Wenn **apktool** dir einen Fehler meldet, versuche[ installing the **latest version**](https://ibotpeaches.github.io/Apktool/install/)

-Einige **interessante Dateien, die du dir ansehen solltest, sind**:
+Einige **interessante Dateien, die du dir ansehen solltest**, sind:

- _res/values/strings.xml_ (und alle XML-Dateien in res/values/*)
+- _res/values/strings.xml_ (und alle xml-Dateien in res/values/*)
 - _AndroidManifest.xml_
 - Jede Datei mit der Erweiterung _.sqlite_ oder _.db_

-Wenn `apktool` **Probleme beim Dekodieren der Anwendung** hat, siehe [https://ibotpeaches.github.io/Apktool/documentation/#framework-files] oder versuche das Argument **`-r`** zu verwenden (Ressourcen nicht dekompilieren). Dann, wenn das Problem in einer Ressource und nicht im Quellcode lag, wirst du das Problem nicht haben (du wirst die Ressourcen auch nicht dekompilieren).
+Wenn `apktool` **Probleme beim Decodieren der Anwendung** hat, sieh dir [https://ibotpeaches.github.io/Apktool/documentation/#framework-files](https://ibotpeaches.github.io/Apktool/documentation/#framework-files) an oder versuche das Argument **`-r`** zu verwenden (Ressourcen nicht decodieren). Wenn das Problem also in einer Ressource und nicht im Quellcode lag, wirst du das Problem nicht mehr haben (du wirst die Ressourcen dann auch nicht dekompilieren).

 ## Smali-Code ändern

-Du kannst **Anweisungen** ändern, den **Wert** einiger Variablen ändern oder neue Anweisungen **hinzufügen**. Ich ändere den Smali-Code mit [**VS Code**](https://code.visualstudio.com), anschließend installierst du die **smalise extension** und der Editor zeigt dir, ob eine **Anweisung inkorrekt ist**.\
+Du kannst **Anweisungen ändern**, den **Wert** einiger Variablen ändern oder neue Anweisungen **hinzufügen**. Ich ändere den Smali-Code mit [**VS Code**](https://code.visualstudio.com), du installierst dann die **smalise extension** und der Editor zeigt dir, ob eine **Anweisung inkorrekt ist**.\ 
 Einige **Beispiele** findest du hier:

 - [Smali changes examples](smali-changes.md)
 - [Google CTF 2018 - Shall We Play a Game?](google-ctf-2018-shall-we-play-a-game.md)

-Or you can [**check below some Smali changes explained**](smali-changes.md#modifying-smali).
+Oder du kannst [**check below some Smali changes explained**](smali-changes.md#modifying-smali).

 ## APK neu kompilieren

-Nach dem Ändern des Codes kannst du den Code mit folgendem Befehl **neu kompilieren**:
+Nachdem du den Code geändert hast, kannst du den Code **rekompilieren** mit:
 ```bash
 apktool b . #In the folder generated when you decompiled the application
 ```
-Die neue APK wird **kompiliert** **innerhalb** des _**dist**_ Ordners.
+Es wird die neue APK **compile** **innerhalb** des _**dist**_ Ordners.

-Wenn **apktool** einen **Fehler** wirft, versuche[ installing the **latest version**](https://ibotpeaches.github.io/Apktool/install/)
+Wenn **apktool** einen **error** wirft, versuche, [die **latest version** zu installieren](https://ibotpeaches.github.io/Apktool/install/)

-### **Signiere die neue APK**
+### **Sign the new APK**

-Dann musst du einen **key generieren** (du wirst nach einem Passwort und einigen Informationen gefragt, die du zufällig ausfüllen kannst):
+Anschließend musst du **generate a key** (du wirst nach einem password und nach einigen Informationen gefragt, die du beliebig ausfüllen kannst):
 ```bash
 keytool -genkey -v -keystore key.jks -keyalg RSA -keysize 2048 -validity 10000 -alias <your-alias>
 ```
-Schließlich, **signiere** die neue APK:
+Zum Schluss das neue APK **signieren**:
 ```bash
 jarsigner -keystore key.jks path/to/dist/* <your-alias>
 ```
 ### Neue Anwendung optimieren

-**zipalign** ist ein Tool zur Ausrichtung von Archiven, das wichtige Optimierungen für Android-Anwendungsdateien (APK) bereitstellt. [Weitere Informationen](https://developer.android.com/studio/command-line/zipalign).
+**zipalign** ist ein Tool zur Ausrichtung von Archiven, das wichtige Optimierungen für Android-Anwendungen (APK-Dateien) bereitstellt. [Weitere Informationen hier](https://developer.android.com/studio/command-line/zipalign).
 ```bash
 zipalign [-f] [-v] <alignment> infile.apk outfile.apk
 zipalign -v 4 infile.apk
 ```
-### **Die neue APK signieren (nochmal?)**
+### **Signiere die neue APK (nochmals?)**

-Wenn du **lieber** [**apksigner**](https://developer.android.com/studio/command-line/) statt jarsigner verwendest, **solltest du die APK signieren** nachdem du **die Optimierung mit** zipaling angewendet hast. ABER BEACHTE, DASS DU DIE ANWENDUNG NUR EINMAL MIT jarsigner (vor zipalign) ODER MIT aspsigner (nach zipaling) SIGNIEREN MUSST.
+Wenn du **lieber** [**apksigner**](https://developer.android.com/studio/command-line/) statt jarsigner verwendest, **solltest du die APK signieren** nachdem du **die Optimierung mit** zipaling angewendet hast. ABER BEACHTE, DASS DU DIE ANWENDUNG NUR EINMAL **DIE ANWENDUNG NUR EINMAL SIGNIEREN** MIT jarsigner (vor zipalign) ODER MIT aspsigner (nach zipaling).
 ```bash
 apksigner sign --ks key.jks ./dist/mycompiled.apk
 ```
 ## Smali ändern

-Für den folgenden Hello-World-Java-Code:
+Für den folgenden Hello World Java-Code:
 ```java
 public static void printHelloWorld() {
 System.out.println("Hello World")
@ -90,13 +90,13 @@ invoke-virtual {v0,v1}, Ljava/io/PrintStream;->println(Ljava/lang/String;)V
 return-void
 .end method
 ```
-Der Smali-Instruktionssatz ist verfügbar [here](https://source.android.com/devices/tech/dalvik/dalvik-bytecode#instructions).
+Das Smali-Instruktionsset ist [hier](https://source.android.com/devices/tech/dalvik/dalvik-bytecode#instructions).

 ### Leichte Änderungen

-### Ändern der Anfangswerte einer Variable innerhalb einer Funktion
+### Initialwerte einer Variable innerhalb einer Funktion ändern

-Einige Variablen werden am Anfang der Funktion mit dem Opcode _const_ definiert, du kannst ihre Werte ändern oder neue definieren:
+Einige Variablen werden am Anfang der Funktion mit dem Opcode _const_ definiert; du kannst deren Werte ändern oder neue definieren:
 ```bash
 #Number
 const v9, 0xf4240
@ -129,7 +129,7 @@ goto :goto_6 #Always go to: :goto_6
 ```
 ### Größere Änderungen

-### Protokollierung
+### Logging
 ```bash
 #Log win: <number>
 iget v5, p0, Lcom/google/ctf/shallweplayagame/GameActivity;->o:I #Get this.o inside v5
@ -140,17 +140,17 @@ invoke-static {v5, v1}, Landroid/util/Log;->d(Ljava/lang/String;Ljava/lang/Strin
 ```
 Empfehlungen:

- Wenn du deklarierte Variablen innerhalb der Funktion verwenden willst (deklariert v0,v1,v2...) füge diese Zeilen zwischen der _.local <number>_ und den Deklarationen der Variablen (_const v0, 0x1_) ein
- Wenn du den Logging-Code in die Mitte des Codes einer Funktion einfügen willst:
- Erhöhe die Anzahl der deklarierten Variablen um 2: z.B. von _.locals 10_ auf _.locals 12_
- Die neuen Variablen sollten die nächsten Nummern nach den bereits deklarierten Variablen sein (in diesem Beispiel sollten es _v10_ und _v11_ sein, denke daran, dass bei v0 begonnen wird).
- Ändere den Code der Logging-Funktion und verwende _v10_ und _v11_ statt _v5_ und _v1_.
+- Wenn du deklarierte Variablen innerhalb der Funktion verwenden willst (deklarierte v0,v1,v2...) setze diese Zeilen zwischen der _.local <number>_ und den Deklarationen der Variablen (_const v0, 0x1_).
+- Wenn du den Logging-Code in die Mitte des Codes einer Funktion einfügen möchtest:
+  - Erhöhe die Anzahl der deklarierten Variablen um 2: z. B. von _.locals 10_ auf _.locals 12_.
+  - Die neuen Variablen sollten die nächsthöheren Nummern der bereits deklarierten Variablen sein (in diesem Beispiel sollten es _v10_ und _v11_ sein, denk daran, dass es bei v0 beginnt).
+  - Ändere den Code der Logging-Funktion und verwende _v10_ und _v11_ statt _v5_ und _v1_.

-### Toasting
+### Toasts

-Denke daran, am Anfang der Funktion 3 zu der Anzahl der _.locals_ hinzuzufügen.
+Denk daran, am Anfang der Funktion 3 zur Anzahl der _.locals_ hinzuzufügen.

-Dieser Code ist dafür vorbereitet, in die **Mitte einer Funktion** eingefügt zu werden (**ändere** die Anzahl der **Variablen** nach Bedarf). Er nimmt den **Wert von this.o**, **wandelt** ihn in einen **String** und erstellt anschließend einen **toast** mit dessen Wert.
+Dieser Code ist dafür vorbereitet, in die **Mitte einer Funktion** eingefügt zu werden (**ändere** die Anzahl der **Variablen** bei Bedarf). Er nimmt den **value of this.o**, wandelt ihn in einen **String** um und zeigt dann einen **toast** mit dessen Wert an.
 ```bash
 const/4 v10, 0x1
 const/4 v11, 0x1
@ -164,7 +164,7 @@ invoke-virtual {v12}, Landroid/widget/Toast;->show()V
 ```
 ### Laden einer nativen Bibliothek beim Start (System.loadLibrary)

-Manchmal muss man eine native Bibliothek vorgeladen, damit sie sich vor anderen JNI-Libs initialisiert (z. B. um prozesslokale Telemetrie/Logging zu ermöglichen). Man kann einen Aufruf von System.loadLibrary() in einen statischen Initialisierer oder früh in Application.onCreate() injizieren. Beispiel smali für einen statischen Klassen-Initializer (<clinit>):
+Manchmal müssen Sie eine native Bibliothek vorladen, damit sie sich vor anderen JNI libs initialisiert (z. B. um process-local telemetry/logging zu ermöglichen). Sie können einen Aufruf von System.loadLibrary() in einen statischen Initialisierer oder früh in Application.onCreate() injizieren. Beispiel-smali für einen statischen Klasseninitialisierer (<clinit>):
 ```smali
 .class public Lcom/example/App;
 .super Landroid/app/Application;
@ -176,7 +176,7 @@ invoke-static {v0}, Ljava/lang/System;->loadLibrary(Ljava/lang/String;)V
 return-void
 .end method
 ```
-Alternativ platzieren Sie dieselben beiden Anweisungen am Anfang Ihrer Application.onCreate(), um sicherzustellen, dass die library so früh wie möglich geladen wird:
+Alternativ platzieren Sie dieselben zwei Anweisungen am Anfang Ihrer Application.onCreate(), um sicherzustellen, dass die Bibliothek so früh wie möglich geladen wird:
 ```smali
 .method public onCreate()V
 .locals 1
@ -189,11 +189,11 @@ return-void
 .end method
 ```
 Hinweise:
- Stellen Sie sicher, dass die korrekte ABI-Variante der Bibliothek unter lib/<abi>/ vorhanden ist (z. B. arm64-v8a/armeabi-v7a), um UnsatisfiedLinkError zu vermeiden.
- Frühes Laden (class static initializer) garantiert, dass der native logger nachfolgende JNI-Aktivität beobachten kann.
+- Stellen Sie sicher, dass die korrekte ABI-Variante der Bibliothek unter lib/<abi>/ (z. B. arm64-v8a/armeabi-v7a) vorhanden ist, um UnsatisfiedLinkError zu vermeiden.
+- Sehr frühes Laden (class static initializer) garantiert, dass der native Logger nachfolgende JNI-Aktivität beobachten kann.

 ## Referenzen

- SoTap: Leichtgewichtiger in-app JNI (.so) behavior logger – [github.com/RezaArbabBot/SoTap](https://github.com/RezaArbabBot/SoTap)
+- SoTap: Leichter In-App-JNI (.so)-Verhaltenslogger – [github.com/RezaArbabBot/SoTap](https://github.com/RezaArbabBot/SoTap)

 {{#include ../../banners/hacktricks-training.md}}