witaqua-tools/root-my-deviceKSU-Installer für unterstützte Firmware mit CVE-2026-43499
Ein Fork von BuSung-dev/Root-My-Galaxy, unter der Apache License 2.0 — siehe LICENSE und Credits.
Root My Device ist ein Ein-Klick-Installer für explizit unterstützte Firmware-Builds. Die Anwendung selbst ist getrennt von Geräte-Offsets, nativen Exploit-Payloads und KernelSU-Build-Artefakten.
Der Geräte-Feed und die nativen Payloads werden in
Root-My-Device-Payloads gepflegt.
Jeder Push auf dessen main-Branch baut die Payloads und veröffentlicht sie als
GitHub-Release unter einem für diesen Lauf eindeutigen Tag. Die App löst
releases/latest dieses Repositorys auf, liest das Asset targets-v2.json daraus und
lädt jedes darin benannte Artefakt herunter — die Menge der installierten Payloads ist
somit nach der Veröffentlichung unveränderlich, und nichts wird als Binärdatei committet.
Die App wählt automatisch eine exakte Übereinstimmung für Kernel-Release, vollständige Build-Anzeige-ID, SDK, ABI und Seitengröße aus. Der erweiterte Modus kann ein Profil manuell auswählen und zeigt separate Warnungen zu Kernel-Release und Build an.
Ein Profil bleibt aus dem Feed heraus, bis die eigene Route der App auf diesem Gerät abgeschlossen wurde, und der Feed ist das, was die App liest — der Lauf, der feststellen würde, ob diese Route funktioniert, hat also nichts zum Herunterladen. Der Debug-Modus ist für diesen Fall gedacht: ein separater Schalter zum erweiterten Modus, standardmäßig aus, der die Payload aus einem Ordner auf dem Gerät liest. Wenn er aktiviert wird, wird der Ordner angezeigt, auf den er zeigen soll, der auf seiner obersten Ebene drei Dateien enthält:
profile.json
cve-2026-43499-app.release.so
ksud
Die beiden Artefakte sind das, was das Payload-Repository baut, und diese Namen sind die Standardwerte. Ein Daemon, der unter dem Namen ksud-<id> geführt wird, den die Releases dieses Repositories verwenden, muss umbenannt oder im Manifest als kernelsu.name (exploit.name für das Payload) benannt werden.
profile.json enthält nur das, was nicht vom Gerät übernommen werden kann, unter den eigenen Schlüsselnamen des Feeds:
{
"profileId": "xig07-jp-OS3.0.7.0.WNEJPKD",
"kernelsu": { "kmi": "android14-6.1", "managerPackage": "me.weishu.kernelsu" }
}
Diese drei Felder sind erforderlich. Jedes Feld, anhand dessen der Feed ein Gerät abgleicht –
Kernel-Release, Build-Display-ID, SDK, ABI, Seitengröße – stammt stattdessen von diesem Gerät,
da ein lokales Profil nicht gegen irgendetwas abgeglichen wird. Die Angabe von
kernelRelease oder buildDisplay ist dennoch optional und wird gegen das
Gerät geprüft, was es sicher macht, die Ordner mehrerer Ziele nebeneinander
zu behalten.
Keine der Prüfungen, denen eine heruntergeladene Payload unterzogen wird, gelten hier, und die App sagt das auch. Ein
Lauf aus einem Ordner wird als solcher im Log, in der Übersicht und als
local:<folder> in seinem Verlaufseintrag gekennzeichnet, sodass kein abgeschlossener Lauf im Nachhinein
als Feed-Lauf gelesen werden kann.
Voraussetzungen:
Das APK enthält ein natives Programm, das nicht aus dem eigenen Quellcode dieses Repositorys gebaut wird, daher mit Submodulen klonen:
git clone --recurse-submodules https://github.com/Witaqua-tools/Root-My-Device
# or, in an existing checkout
git submodule update --init payloads
$env:JAVA_HOME='C:\Program Files\Android\Android Studio\jbr'
.\gradlew.bat :app:assembleDebug
Ich kann keine Übersetzung erstellen, da kein Eingabetext bereitgestellt wurde. Der Abschnitt „INPUT:“ ist leer.
Bitte senden Sie den zu übersetzenden Markdown-Inhalt (Chunk 9 von 11), und ich liefere die deutsche Übersetzung gemäß den angegebenen Regeln.
app/build/outputs/apk/debug/app-debug.apk
lib/arm64-v8a/libcve43499root.so in der APK ist keine Bibliothek — es ist der
Bootstrap-Helfer, ein ausführbares Programm, das die App mit ProcessBuilder aus
nativeLibraryDir startet. Er lädt eine heruntergeladene Payload und stellt
danach su über einen Socket bereit, sobald die Payload Root-Rechte erlangt hat.
Er wird aus dem Quellcode über app/src/main/cpp/CMakeLists.txt
kompiliert und nicht als Binärdatei eingecheckt. Der Quellcode liegt jedoch nicht
hier: Der eigenständige Pfad der Payload führt dasselbe Programm aus einem festen
Pfad aus, daher muss das Payload-Repository es ebenfalls bauen, und es bleibt die
einzige Kopie. Dieses Repository erreicht es über das payloads-Submodul, dessen
fixierter Commit genau festhält, aus welcher Revision eine APK gebaut wurde.
Das bedeutet bewusst zwei Builds aus einer Quelle. Das Payload-Repository pinnt
NDK 29 auf API 35, weil seine Exploit-Payload ein Blob fester Größe ist, dessen
Toolchain Teil seiner Identität ist; hier verwendet CMake die ndkVersion dieses
Moduls auf minSdk. Der Helfer hängt von keinem von beiden ab — er ist in beiden
Fällen dasselbe Programm, und die Kopie, die die App ausliefert, ist die hier
gebaute.
Zwei Dinge an ihm sind tragend und lassen sich leicht versehentlich rückgängig
machen: Er muss eine ausführbare Datei sein (add_executable plus -pie,
damit er einen PT_INTERP hat, den eine Shared Library nicht hätte), und er muss
lib*.so heißen mit jniLibs.useLegacyPackaging = true, denn nur so wird er
als echte Datei mit gesetztem Ausführungsbit nach nativeLibraryDir extrahiert.
Beides ist an der jeweiligen Stelle kommentiert.
Nur auf Geräten verwenden, die Sie besitzen oder für die Sie ausdrücklich eine Testgenehmigung haben.
Ein Fork von Root-My-Galaxy von BuSung-dev, der die ursprüngliche Apache License 2.0 beibehält — siehe LICENSE.
Diese Anwendung lädt und führt aus, was Root-My-Device-Payloads veröffentlicht — selbst ein Fork von Root-My-Galaxy-Payloads von BuSung-dev.
Nichts, was einer Payload geschuldet ist, befindet sich in diesem Repository, und nichts davon wird hier wiederholt. KernelSU — das, was ein erfolgreicher Lauf lädt —, das Upstream jedes Cores, die Quelle, von der diese Cores abstammen, und die Lizenzbedingungen von allem, was dort gebaut wird, sind im README des Payload-Repositories genannt, wo eine Danksagung auf der Payload-Seite hingehört und wo diese Artefakte gebaut werden.