为啥不利用修改 apk 的 manifest 来控制软件行为？

[s82kd92l]

现有控制软件行为的方案，绿守 /黑域 /写轮眼 /xposed 无一不是入侵式的，对 root/adb 要求很高效果却不完美，为啥没大神做基于 manifest 编辑+自签名打包来做到免 root 限制流氓呢？

Manifest 就像是 apk 和 android 系统签订的一份合约， 其内容完全决定了 android 沙盒如何限制 apk 的行为。Google 目前的做法是让用户无条件接受这份合约（ 6.0 之前）或者只有极小协商空间(就是 6.0 的可选权限)。如果能修改 manifest,用户可以达到这些效果(从简单到难):
1. 修改 targetSdkVersion 很多新系统对流氓的控制，流氓都会通过 target 老旧的 sdk 来应付，如果能自己改 targetSdkVersion，流氓们只能在 8.1 下面乖乖睡觉，在 6.0 下面乖乖把部分敏感权限选择权交给用户
2. 直接删除 /添加权限申明。6.0 下面的权限只有部分是可选的，通过修改 manifest，所有权限用户都能控制
3. 直接修改 /删除四大组件的申明 让 broadcastreceiver 再也收不到“开机 /网络变更 /摄像头开启”之类的唤醒，直接禁用 service/content provider， 或者使其无法向第三方开放。

如此以来，再也不需要在运行时控制自启动 /切断唤醒路径， 因为新合约让流氓无路可走。还有 Oreo 对 bound service/content provider 没有约束的情况，manifest 也可以弥补。只要限制得当，这个沙盒能比 iOS 更加给力。
改完后重新打包，尽量做到每个 apk 单独签名。还有就是最好把 apk 的原始签名加入 manifest 中，这样升级的时候可防止下载到一个已经被人动过手脚的 apk。

如果要做这种修改软件，界面可以像写轮眼那样非常清晰明了。如果能借绿色守护的处方语法就更好了，那样小白就可以利用网上现成的处方来决定哪些权限 /组建可删可改以及怎么改。免 root，流程简单，效果超过现有方案，为啥没人做呢？

[mortal]

UU 安全好像就是这个路子？

[s82kd92l]

@Qlccks2 @huclengyue @tscat apk 签名校验是可以通过 xposed 或者对 rom 本身做修改来绕过的，连谷歌全家桶都能被欺骗，参见
https://github.com/Lanchon/haystack
https://github.com/thermatk/FakeGApps

如果哪一天签名校验成了常态，装个 xposed 就好了。

[honeycomb]

@s82kd92l 所以你就知道系统的签名校验是一个很重要的机制，关闭它换取 hack/workaround 程度的控制代价太大（伤敌一千自损三千）

[meisky6666]

改了那个文件，里面的函数请求不到那个权限会闪退

[s82kd92l]

@honeycomb 并不是对所有程序关闭校验，而是可以让用户选择性替换。

再说了，签名机制对用户的保护无非就是防止升级包被篡改，但这个功能可以让修改 manifest 的 app 自己做到，提供相同级别的保护。

这里有一个安装前 /安装后签名校验的区别。所有对自身签名验证的 apk,都是利用系统提供的 api,因为他们没法直接读取自身的 apk 文件，只能依靠系统服务。而安装前我们是可以直接读取 apk 文件的，得到的签名信息是绝对可靠的，不存在安全问题。

[honeycomb]

@s82kd92l
这么重要的东西变得可选就是很大的攻击面。
签名保护的不仅仅是升级，随便举个例子，Android 里

[honeycomb]

@s82kd92l
抱歉手滑了没写完就发出来

例如：
Android 里有一种权限是 signature 级别的

[didikee]

不知道楼主对安卓理解有多少，现实是你估计也就禁用广播和服务，其他的你改了配置没有用，代码没改该怎么还是怎么。而且崩溃概率大幅度上升。而且广播可以动态注册，不需要写在清单文件里

[est]

直接底层改 chroot + setns

[s82kd92l]

@meisky6666 修改 2 确实可能出现这个问题，但还有 1 和 3 可以改，风险相对小。

还可以利用社区的力量，做些类似于绿守处方的东西，让小白也知道对于某些特定 apk，哪些服务 /权限能禁哪些不能禁。比如*.permission.MIPUSH_RECEIVE 这种权限，我打赌你全禁掉也没事。

[s82kd92l]

@honeycomb 所以我在原帖了说了“尽量做到每个 apk 单独签名"，这样不同的 app 就没法利用相同签名获取别人家的权限。

[tscat]

@s82kd92l 欺骗自然是可以的。没有存在完全不可破解的。但是你这么做，还不如直接用 xposed 直接给个假的隐私。

[s82kd92l]

@didikee java 代码是孙悟空，manifest 是如来神掌。java 代码怎么写也不能脱离 manifest 控制，动态广播没有权限是没用的，哪怕有权限，app 不在后台运行时也是没用的。

[meisky6666]

@s82kd92l 我刷的 cm 有隐私保护功能，可以看到每个权限的使用次数，还可以把摄像头和位置设置成每次询问，这是最安全的了

[skylancer]

发帖前我建议你先试试看可不可行
另外，Android 拿 IMEI 当年禁止 READ_PHONE_STATE 还能用 API 取到，改了 manifest 根本不会有用

[pq]

在百度输入法 2.x 时代，我就曾经是这么干的，但 3.x 之后，不仅没法正常用 apktools 解包，而且，用其它办法解包修改之后再打包，它会在启动时提示包损坏然后直接退出。

腾讯的许多 app，都是没法解包修改并重新打包的，也是在启动时先检查包的完整性。

[skylancer]

@pq 还是有很多方法能解包修改并重新打包的，不然 ROMer 很多时候没法插 smali，但是最大的问题是在于会检查签名.. 就很蛋疼

[s82kd92l]

@skylancer 之前改过 whatsapp 和另外一款依赖 gcm 的开源软件，可以运行。国内流氓还没试过。待会儿试试高德地图

[zjb861107]

我为什么不信任大厂，反而来信任一个小作坊？谁来保证重签名过程中的安全？

[xingda920813]

@honeycomb

"有人说 appops 层可以设置为 allow 以关闭，我没有验证过。"

不行的, 具体可以看 int ActivityManagerService.appRestrictedInBackgroundLocked(int uid, String packageName, int packageTargetSdk),

target O+ 的直接 return ActivityManager.APP_START_MODE_DELAYED_RIGID, 然后 Legacy 的才会去读 AppOps 的值.

// Apps that target O+ are always subject to background check
if (packageTargetSdk >= Build.VERSION_CODES.O) {
return ActivityManager.APP_START_MODE_DELAYED_RIGID;
}
// ...and legacy apps get an AppOp check
int appop = mAppOpsService.noteOperation(AppOpsManager.OP_RUN_IN_BACKGROUND, uid, packageName);