Stealth PR4: replace /entrypoint.sh + stealth.rc with a Magisk module
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 1
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
Summary
The largest single drop in visible-from-userspace surface. Today Beetroot adds two Beetroot-specific filesystem tells (risk: High each):
/system/etc/init/stealth.rc— a non-AOSP init file with a literal giveaway name./entrypoint.shat filesystem root — real Android images have no such file; a singlestat()reveals the container.
Move both into a Magisk module: a directory under /data/adb/modules/<random>/ containing a service.d/<random>.sh script. Magisk runs service.d/*.sh during the standard post-fs-data phase under the same u:r:magisk:s0 SELinux context we use today — no custom init.rc, no /entrypoint.sh at root, and the module dir is denylist-hidden from GMS.
Scope
- Generate
module.prop+service.d/<random>.shat Docker build time with randomized IDs. - Drop
docker/stealth.rcfrom the Dockerfile'sCOPYlist. - Move
entrypoint.sh(and its helper split) into the module'sservice.d/. - Boot trigger changes from
sys.boot_completed=1to Magiskpost-fs-data(earlier — the script must poll for Zygote start before writing the denylist;magisk-config.shalready polls, so no helper change needed). - Land behind the opt-in
BEETROOT_STEALTH_MODULE_IDflag until the CI fingerprint audit (#6 / PR7) is green for both modes.
Complexity: L.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the Dockerfile, docker/stealth.rc, entrypoint.sh, its helper, and magisk-config.sh, then read §3.4 and §7 of docs/design/stealth-posture.md. Trace how the current boot trigger and build-time files are assembled. Done means the opt-in module flag produces randomized module files, removes the root entrypoint and custom init file, and preserves both-mode CI fingerprint coverage.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android, docker, shell
- Domain
- devops, mobile-dev, security
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100