自定义su

一 理论基础第一阶段准备作案工具与物理提权编译与打包参与者device.mkfs_config首先你得把提权工具su塞进系统里device.mk。但这还不够在 Linux 万物皆文件的体系下权限是由文件属性决定的。fs_config就像是系统打包时的“造物主”它在镜像生成的那一刻给su文件强行打上了Set-UID (S位)这个物理印记。这是整个 Root 逻辑的基石没有这一步后面的软件逻辑全是空中楼阁。同时device.mk还负责在系统属性里挂上ro.secure0的“免检”牌子。第二阶段解除全局宏观封锁系统 Init 阶段参与者selinux.cpp工具放进去了系统也开始启动了。此时遇到了 Android 最强大的底层安保——SELinux (MAC 强制访问控制)。哪怕你有 S 位哪怕你是 Root只要 SELinux 策略不放行操作依然会被拦截。因此在 Init 进程的极早期我们通过修改selinux.cpp强行将系统置于Permissive模式这就相当于彻底切断了整个安保系统的报警线为后续的越权操作扫清了最大的系统级障碍。第三阶段打通外部 VIP 通道PC 端调试参与者adb守护进程 (main.cpp/restart_service.cpp)在开发和调试时我们需要从 PC 端外部直连系统底层。原生系统中adbd发现环境不安全就会“自废武功”降级为shell用户。修改这部分代码就是为了留住这条外部 VIP 通道让adbd强行保持 UID0从而实现adb root、adb remount等极其便利的外部调试功能。第四阶段拆除内部调用软墙App 端执行参与者su.cpp外部通道通了那内部普通的 Android App 想要 Root 怎么办它们只能去调用第一阶段塞进去的su文件。然而 AOSP 的su源码内部有自己的“查户口”逻辑DAC 自主访问控制拒绝普通 UID 的调用。修改su.cpp就是拆除了这最后一道软件防御代码让任何内部 App 只要拿到su就能变身 Root。总结这五个文件的修改完美覆盖了“预置与赋权 (mk/fs) - 绕过宏观审计 (selinux) - 外部直通 (adb) - 内部提权 (su)”这一完整的逻辑闭环。只有将它们结合起来才能在 Android 严苛的安全体系中撕开一道口子实现真正意义上的全局开发权限。二 实操1.设备.mkdevice/rockchip/rk3576/device.mk2.adb文件alp/packages/modules/adb/daemon/restart_service.cppalp/packages/modules/adb/daemon/main.cppalps/system/core/adb/Android.bp3.selinuxalp/system/core/init/selinux.cpp4.su文件system/extras/su/su.cpp5.fs_config文件三 调试which su