Root My Galaxy Payloads: Firmware-Specific Exploit Artifacts for Samsung Devices

What Root My Galaxy Payloads actually ships

The README states the repository contains the device-specific native side of Root My Galaxy and, in the same sentence, that it intentionally does not contain Android application source code. That split defines everything else. What you get here is the C exploit source, the compiled payloads, a bootstrap helper, verified KernelSU late-load build artifacts and the support feed the application consumes. What you do not get is the app that drives them. If you arrived expecting an APK, this is not it.

The audience is narrow by design. Each payload in the supported table is bound to a model and a kernel version: galaxy-s25-series-2026-06-07 covers S25, S25+, S25 Edge and S25 Ultra regional models on kernel 6.6.98; e3q-S928USQS6DZF2 covers the Galaxy S24 Ultra SM-S928U1 on 6.1.145; a53x-A536EXXSNGZG3 covers the Galaxy A53 5G SM-A536E on 5.10.237. Ten entries are marked device-tested, one is test in progress and one is experimental. That status column is the most useful thing on the page, and it is also the strongest signal that this is a research artifact rather than a product.

Why firmware build strings, not model names, decide compatibility

Samsung ships different kernel builds under the same retail name depending on region and carrier, so a payload keyed only to a model would be wrong most of the time. The profile identifiers encode the build: e3q-S928USQS6DZF2 for the S24 Ultra SM-S928U1, e3q-S9280ZCS6DZF2 for the China SM-S9280, e2s-S926BXXUEDZDR for the S24+ SM-S926B. The trailing segment is the build string you see in About phone, and the leading segment is the device codename.

Schema version 3 enforces this at runtime. The README says each exploit and KernelSU artifact is stored once, and that flat models and kernelVersions arrays define runtime compatibility, with the matching rules written out in support/README.md. The feed is delivered by resolving the payload repository's current commit and then fetching support/targets-v3.json and every artifact from that immutable commit. That is a sound choice: the app cannot drift onto a half-updated feed, because all artifacts come from one commit. The cost is that per-artifact SHA-256 fields and manifest signatures are not part of schema version 3, so integrity rests on the commit pinning plus whatever the client does with it. targets-v2.json is retained for released 0.2.3 clients.

Building a payload with make and the Android NDK

The Makefile defaults TARGET to pa3q-S938NKSUACZF1 and API to 35, and it derives the compiler path from ANDROID_NDK_HOME, selecting the darwin-x86_64 or linux-x86_64 prebuilt toolchain based on uname. If the compiler is missing at that path, the build stops with an error telling you to set ANDROID_NDK_HOME to an NDK containing it. Clone the repository first, then build one profile:

make TARGET=essi-A566EXXSCCZG6 ANDROID_NDK_HOME=/path/to/android-ndk

A successful run leaves three files under the profile's output directory: cve-2026-43499, cve-2026-43499-app.so and cve-2026-43499-root. The release variant used for the app payload is a separate invocation:

make TARGET=essi-S721NKSSCDZF3 ANDROID_NDK_HOME=/path/to/android-ndk release

Two target-specific quirks are visible in the Makefile. The a53x-A536EXXSNGZG3 target pins API to 31 instead of 35, and it replaces the default source list with its own payload.c. The dm2q-S916BXXSAFZG1, dm3q-S918BXXSAFZF5, gts9u-X916BXXS6EZG3, dm1q-S911U1UES6DYI3 and gts9-X710XXS6EZF1 targets add -DSLIDE_STACK_WRITER=1 to the app target flags, which means the slide primitive is compiled differently for those devices. The release path also fixes APP_RELEASE_SIZE at 104128 bytes and links with -Wl,--gc-sections -Wl,--icf=all -s, so a release payload that changes size will not match that expectation.

The two profiles that are not finished

The README is unusually direct about the S916B FZG1 profile. Its status is experimental, described as hardware root from ADB shell, and the text says the exact tracefs route works from adb shell but direct app-domain execution is not supported. Root My Galaxy would need to delegate the native runner through an authorized shell bridge such as Shizuku. That profile is not in the app feed. Anyone who reads the model name, sees Galaxy S23+ and assumes parity with the S23 Ultra entries will be wrong.

The S918B FZF5 profile sits between the two states. Its status line says confirmed working: full chain through the app in Shizuku mode including KernelSU late-load and granted su, and the README adds that its physical-P0 fallback engages in unprivileged app-domain execution but rooting without Shizuku is not yet hardware-confirmed. The dm3q-S9180ZHS8FZF5 entry is simply test in progress. These distinctions matter more than any feature list on this page, and they are the reason the status column should be read before the compatibility table.

Where the exploit code comes from and what that implies

The README states the port is based on the exploit source published at NebuSec/CyberMeowfia under IonStack/CVE-2026-43499/exploit. That attribution is the honest framing: this repository is a porting and packaging effort across specific Samsung firmware, not the original vulnerability research. The per-device analysis documents back this up. docs/PORTING.md records the complete firmware-to-profile procedure, and individual files such as docs/SM-S928U1-SM-S928U1UES6DZF2.md, docs/SM-A566E-A566EXXSCCZG6.md and docs/SM-F9360-F9360ZCSAIZF1.md hold the analysis and validation records for single builds.

The repository also warns against a specific mistake. It notes that S921B is an Exynos 2400 target and is not a Qualcomm/Snapdragon reference for E3Q. That is the kind of note that exists because someone tried it. Porting by analogy across SoC families does not work here, and the docs are organized to make that clear rather than to hide it.

What to check before you trust a build

There is no release list retrieved for this repository, so the artifacts you build are the artifacts you get; there is no published version to compare against. The last push was on 2026-09-03. The README does not document rollback, and it does not describe a signature verification step for schema version 3 artifacts beyond fetching them from a pinned commit. If your threat model includes a tampered feed, that gap is real and you should read support/README.md before assuming otherwise.

The licence is Apache-2.0, which is permissive and includes a patent grant, but it says nothing about the legal position of modifying a device you own in your jurisdiction, and nothing about warranty. The README's closing line is a use restriction rather than a licence term: use only on devices you own or are explicitly authorized to test. Treat the two as separate questions.

How this differs from Magisk and from KernelSU alone

Magisk patches the boot image and produces a rooted system through a manager app; the device must generally be bootloader-unlocked and its data wiped in the process. This repository takes a different route entirely. It carries an app-domain exploit for CVE-2026-43499, and KernelSU arrives through late-load artifacts rather than a pre-patched boot image. The F9360 validation note in the README mentions a locked-BL, no-LTO clang-12 module, which is a configuration Magisk's boot-image approach does not address at all.

KernelSU on its own is a kernel-side root solution that still needs a way in. This repository is that way in for a fixed list of Samsung builds, with the KernelSU side vendored and versioned in kernelsu/README.md. So the honest comparison is not Root My Galaxy Payloads versus Magisk. It is whether your exact firmware is on the list, because if it is not, neither the exploit nor the late-load artifacts apply to you.

Editorial conclusion

This repository is for people who own a listed Samsung model, match the exact firmware build string, and are willing to build with the Android NDK. It is the wrong place for anyone looking for a one-tap APK, for unlisted models, or for a general-purpose root tool. Before building, verify three things: that your build number matches a profile in the table, that you have a copy of your data, and that the profile's status column says device-tested rather than test in progress or experimental.

Frequently asked questions

Official sources

1. BuSung-dev/Root-My-Galaxy-Payloads on GitHub
2. Issues
3. License: Apache-2.0
4. README