camsshaft/ionstack-s22-cve-2026-43499Android-Kernel-Exploit für Samsung Galaxy S22, der über CVE-2026-43499 Root im Kernel-Bereich erlangt, mit SELinux permissive, gerätespezifischen kallsyms und Panik-Protokollierung.
Voller Root in der Kernel-Domain mit selinux permissive auf meinem SM-S901W S22 5.10.168-android12-9-27760517-abS901WVLS4DWL3.
Ich werde hier nicht ins große Detail gehen oder lange Texte schreiben, da es da draußen etwa 5.000 andere Repos gibt und, wie ich gelernt habe, fast jede dieser Variationen desselben Exploits einzigartig für das Gerät ist, für das sie maßgeschneidert ist, und ich habe es satt, diese auszufüllen. Meine im Besonderen stammt von diesem talentierten Herrn hier und alle Anerkennung gebührt ihm für diese Methode https://github.com/sarabpal-dev/IonStack-S22U Ich zeige genau, warum eine ausführliche Abhandlung sinnlos ist und alle enthaltenen Informationen als Vorlage völlig ausreichen. Unten ist das Gerät, das sarabpal-dev verwendet hat, und darunter ist meins.
Device: Samsung Galaxy S22 Ultra (SM-S908W)
Codename: b0q
Android: 15 / SDK 35
Build number: AP3A.240905.015.A2.S908WVLS8FYG7
Build display ID: AP3A.240905.015.A2.S908WVLS8FYG7
Build fingerprint: samsung/b0qcsx/b0q:15/AP3A.240905.015.A2/S908WVLS8FYG7:user/release-keys
Kernel: 5.10.226-android12-9-30958166-abS908WVLS8FYG7
Architecture: aarch64
Device: Samsung Galaxy S22 (SM-S901W)
Codename: r0q
Android: 14 / SDK 34
Build number: UP1A.231005.007.S901WVLS4DWL3
Build display ID: UP1A.231005.007.S901WVLS4DWL3
Build fingerprint: samsung/r0qcsx/r0q:14/UP1A.231005.007/S901WVLS4DWL3:user/release-keys
Kernel: 5.10.168-android12-9-27760517-abS901WVLS4DWL3
Architecture: aarch64
Wie du also sehen kannst, sind sie sich sehr ähnlich, aber es gibt einen großen Unterschied zwischen ihnen. Seine Version verwendet eine ausführbare Datei, die vollständig in 32 Bit erstellt wurde, während ich meine in 64 Bit ändern musste und sie dennoch mit dem Rest des Codes kompatibel bleiben musste. Es erforderte eine ganze Menge Disassemblierung, um unter anderem zu überprüfen, ob es überhaupt ein gültiger, ausnutzbarer Weg war. Glücklicherweise war es das, aber ich gebe keine Garantien für irgendjemanden sonst. Ich hoffe, dass es immer noch eine gute Methode ist, die viele Leute nutzen können, aber das müsst ihr selbst herausfinden. Die Readmes und einige Kommentare könnten für dieses Gerät nicht zutreffen, aber der Code ist korrekt, und das war es, was für mich zählte.
P.S. Was du brauchst, ist das android-ndk in termux und die boot.img deiner exakten Firmware-Version, um den Kernel und die kallsyms zu extrahieren. Ich habe eine Protokollierung hinzugefügt, sodass eine Datei unter /sdcard/cve-2026-43499.log gespeichert wird, damit du im Falle eines Panics zumindest einige Informationen hast, mit denen du arbeiten kannst, falls du nicht weißt, wie du die relevanten Informationen nach einem Neustart findest (du solltest das eigentlich nicht tun, wenn das der Fall ist, aber das spielt keine Rolle).