为啥不利用修改 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 效验会成为常态

[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);

[honeycomb]

@xingda920813

谢谢!

我觉得也是，其它 appops 项目的也都是这样，在最后做一次兜底，如果有什么高级别 target SDK 新增的限制会在前面。

[s82kd92l]

@zjb861107 开源即可

[skylancer]

@s82kd92l 都来用 xposed 治理了我为什么还要用修改 manifest 来 revoke 权限呢，事实上 Lucky Patcher 也是利用了 art
cache 修改来覆盖 manifeat 的。签名常态都要靠 xposed 来欺骗，我为什么不用 xposed 插件来 revoke app 权限？ 所以你一切想法就是不合实际的脱裤子放屁

[skylancer]

fest.. 拼写错了

[manhere]

my android tools 就是这种工具啊

[fan123199]

权限的话，如果原来 apptarget 小于 26，那么应该是没适配，改了 target 一样跑不起来。

[DioV]

别的不说，对于一般用户来说修改权限带来的直接影响就是应用的无法使用。因为代码对于用户是一个黑盒的状态，要像修改 /关闭权限而不影响使用几乎是不可能实现的。

[windflyer]

补充一点。

如果直接在 AndroidManifest.xml 里禁用（我猜是删除掉声明），app 即使可以启动，但可能会有未被捕获的异常抛出，导致崩溃。

[huclengyue]

@s82kd92l java 有反射，禁用也可以拿到，你说的那些，禁用了都可以拿到就是麻烦点

[lackywind]

说了这么多，或许你需要一份源码自己定制系统吧

[find2bHusky]

异想天开

[honeycomb]

@huclengyue 今天有个新闻说 P 可能会进一步限制（包括通过反射）访问私有 API

[s82kd92l]

@huclengyue @honeycomb 获取签名的函数是通过 IBinder 在 ActivityMangerService 的系统进程中实现的，java 反射怎么可能穿越进程甚至穿越不同 UID 呢？

[honeycomb]

@s82kd92l 应该不是同一件事。今天的新闻内容是说 aosp 出了几个 commit，进一步阻止使用源码里被 hide 注解掉的方法（目前有一些可以通过反射调用）。

[yuriko]

@s82kd92l 我用反射取到过别的 apk 的代码，取决于 dexloader 的逻辑，我觉得顺着这个上去应该有办法？

[yingfengi]

my android tools 是个好东西
有个论坛，一个网友搞的，bbs.letitfly.me 应该是这个链接？
或者我的友链里面找找。

[imcczy]

楼主应该是没有了解过 Android 应用安全以及 Android 系统安全这些，想的太简单了，牵一发而动全身……而且这本身就是一个攻防博弈的过程，不存在一劳永逸的方法。楼主的方法可能对小厂的应用有用，大厂的想都别想…

[s82kd92l]

@skylancer 试了试改高德地图，配合这个补丁 https://github.com/Lanchon/haystack，有效运行。

@yuriko 反射只能对自身进程有效，哪怕是对同一个 app 下的另一个进程都无效，更何况是对不同 UID 下的进程。

@imcczy 应用安全 apk 加壳我不熟，但系统安全，包括 linux 内核 /selinux/binder/permission 机制我都很熟，aosp 各种系统服务源代码也没少看。


还有最近有了免 root 的 xposed 的方案:https://github.com/haygcao/VAExposed，这个是一个薄容器，里面甚至自带签名伪造功能，无需 xposed: https://github.com/haygcao/VAExposed/blob/master/VirtualApp/lib/src/main/java/com/lody/virtual/server/pm/parser/PackageParserEx.java#L53
当然，这个东西既然与 apk 本身运行与同一个进程中，那么就容易利用反射来针对。

[s82kd92l]

可安装的 apk 在这里:https://github.com/android-hacker/VAExposed/releases

[imcczy]

@s82kd92l #58 既然你接触过这些那也应该了解你的方法只对部分应用有效嘛。。你提到的方法，以及类似 VA 这样的沙盒这块学术界目前已经有非常多的研究了，其实就是权限隔离，方法五花八门，但是我目前还没有看到比较好的能用实际运用的方案。主要是，修改应用以及签名欺骗这些太容易被针对了。

[imcczy]

@s82kd92l #58 另外补充一点，应用内部是可以通过反射调用系统 API 的，这个就涉及到 BInder 本身的机制说起来太麻烦，其实就是反射的对象是一个本地代理对象。其他 App 的代码话，只要能够获取到对应的 Application 对象就可以了，或者直接手动加载 dex。

[yuriko]

@s82kd92l 没错啊，我说的是跨应用反射，所以取到的代码当然是跑在自己进程里的没问题。如果 DexLoader 能找到对应的代码，反射一份说不定可以跑啊。

[s82kd92l]

@yuriko 你要是能做到跨应用反射，去谷歌那领几百万美元奖金绝对没问题。

[yuriko]

@s82kd92l 如果你不信我也没办法，我现在就是用的这反射去操作别的 APK 实现 UI 耦合剥离，APK1 去加载 APK2 里的 UI 组件，这样就不用同时更新两个 APK 了的意思。

@imcczy 基本一个意思，能拿到对应的 Application 或者 DexLoader 相关就能加载对应的代码，反射可以随便玩。我这边用的 SystemUID 和 platform 的签名，不知道这方面有什么特别的限制么？

[s82kd92l]

@yuriko @imcczy 你们是说拿到别人的 Application Context，还是说在 PackageManager 里面的 ApplicationInfo ？ SystemUID，你是说你写的是随系统安装的 priv-app 吗？

稍微警醒点的 app 应该不会随便把 context 拱手送人，因为这就菊花外漏任人宰割了。当然很多第三方 sdk 可能会强行索取 context 不给就罢工，然后 sdk 可能偷偷把 context 走私出去？可是 android 系统级服务又不是傻子不会用调用第三方 sdk.