为啥不利用修改 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，流程简单，效果超过现有方案，为啥没人做呢？

[ju5t4fun]

很多 APP 启动的时候会校验自身签名，你怎么跳过？

[s82kd92l]

@ju5t4fun 这种应该不占大多数吧，实在不行就把保存在 manifest 里面的原始签名发给他。（用 xposed 可做到...门槛开始有点高了）

[leafleave]

幸运破解器，破解安装包可以做到

[s82kd92l]

@leafleave 能改 targetSdkVersion 吗？

[s82kd92l]

之前听说过 lucky patcher 貌似要 root

[Leafove]

App 启动先检查自身是否完整,如果不完整直接更新或者弹窗提示程序损坏..
你能把联网禁了?

[s82kd92l]

@Leafove App 通过什么途径检查自身完整呢？还是只能通过系统提供的 api 吧。这种一般都是付费软件防盗版用的，要不就不装，要不就用 xposed 治理。

[honeycomb]

改 manifest 有这些问题：

1，破坏了应用的签名，这肯定是不可取的。
有的应用自己还会检查签名，特别是那些特意做了加固的，也就是说，这是一个普遍行为。

2，在 manifest 禁用权限以后，应用使用相关权限控制的 API 时，会抛出 SecurityException，应用基本不可能去 catch 这些东西，意味着这不实用，比 AppOps 返回 null/empty 对象的做法更不实用。

--------------------------------------

关于主题里琐碎的项目：

“如果能自己改 targetSdkVersion，流氓们只能在 8.1 下面乖乖睡觉”
有现成的 workaround，直接把应用在 AppOps 的 RUN_IN_BACKGROUND 改成 ignore 即可。

注:
应用的电池选项里，有时可以直接改这个设置(8.0 和 8.1 的表现不同，8.0 是只需要应用运行过就可以开启这个限制，8.1 需要别的条件，我没看过具体的源代码)
AOSP 上的 8.1 及 pixel 2 代的全部官方 rom 的开发者选项-->background check 可直接改


“直接修改 /删除四大组件的申明 让 broadcastreceiver 再也收不到“开机 /网络变更 /摄像头开启”之类的唤醒，直接禁用 service/content provider， 或者使其无法向第三方开放。 ”

在 Android 8.0，绝大部分隐式广播已经无法触发系统定义的那些 receiver。
除此以外可以用修改 IFW 配置的方法(如绿色守护的处方特性)，pm disable(MyAndroidTools)来处理它们


“ Oreo 对 bound service/content provider 没有约束”
似乎没什么好办法

[Totato5749]

太理想了。。。不可能实现的
manifest 如同字面意思，只是清单不是合约，只是告诉了系统 app 的全部功能与要求。

比如将 targetsdk 改为 6.0，那么在 6.0 以上的系统中权限必须是动态申请的，但是 app 原来并不是给 6.0 适配的，根本没有申请权限的代码，这样的 app 是跑不起来的。

楼主可能以为 6.0 以上的申请权限是系统行为？并不是的，这个是需要开发者自己添加代码弹出申请权限对话框并在回调中检查是否获取到对应权限的。所以简单地将 targetsdk 小于 6.0 的 app 改为 targetsdk 为 6.0 会导致应用无法使用

[tscat]

幸运破解器就是这么个路子。
然后 App 是会做签名验证的。。
而且一般都是用 so 做校验，你得反汇编二进制文件去修改。
然后这个不只是为了反盗版，还有为了做安全校验的，防止去广告的。比如腾讯视频会校验签名。

[geelaw]

比如这样做是非法的。

[ysc3839]

@s82kd92l 不需要 root，root 模式修改只是为了保留应用数据以及绕过自校验。

[s82kd92l]

@honeycomb 那也得 targetSdkVersion>O，限制才有效吧。我自己在用 oreo+appops，可是对于广大非 root 的手机，和那些无法升级到 oreo 的这个是值得一试的方案。

@Totato5749 6.0 的权限除了动态申请，用户也可以在软件管理界面里手动赋予的。

@Leafove @ju5t4fun 这个是个现成的 xposed 签名修改模块，目前用于欺骗 google sdk，应该也能用于欺骗那些做加固自签名校验的:
http://repo.xposed.info/module/com.thermatk.android.xf.fakegapps

[XinLake]

我觉得 8 楼说的挺好。从策略出发，你改别人的东西总是不太好的吧。

我觉得这个要宏观层面提高国产 APP 的素质，要国内的那些巨头，带好头，做好榜样。其次也要加强监管、监督，让 APP 的开发企业不能为所欲为，要有个可约束的良性发展循环。

[s82kd92l]

@XinLake 这个不是我们改，而是授之以渔让用户自己改，区别很大的。

指望提高素质是没用的，道德永远没有制度管用。Android 生态最大的问题在于，既没有 apple 的人工审核机制，也不让用户有更多选择权，而是在权限问题上做 all-or-nothing 的一锤子买卖，从而赋予开发者最大的话语权。我这个想法无非是给用户更多权利罢了。

[s82kd92l]

还想说一点，很多人指责国内 android 环境太差，说国外月亮更圆。然而事实上国外的 app 并没有更安分到哪里去，去搜一搜 android information flow leak 就能知道即使在 google play 上面上架的应用，照样普遍利用 android 不完善机制达到各种泄漏。
国内不好的地方在于没有推送机制所以要各种保活，以至于使用户卡顿。然而就算有了推送机制，有了统一的 app 发布平台，只要开发者有一锤子买卖的权力，那么 android 沙盒照样是漏洞百出，用户隐私依然形同虚设。

[zjp]

还有一种方式，安卓自带的 IFW

[Qlccks2]

全家桶都验证签名

[honeycomb]

@s82kd92l

RUN_IN_BACKGROUND 设置成 ignore 后的限制不受 targetSDK 影响，具体看源代码，最初的 commit 是 dianne hackborn 签署的，这人也是 Android 团队的老人了。

这里的关系是，targetSDK 从 26 开始，应用默认受到这个限制，并且在用户界面没有关闭的选项（ appops 的值为未设置，即 appops get 是获取不到值得）。

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

[huclengyue]

@s82kd92l 如果你说的这中做法成为普遍，那 apk 效验会成为常态