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

mortal

2018-01-17 19:00:29 +08:00

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

s82kd92l

2018-01-17 19:03:48 +08:00

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

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

honeycomb

2018-01-17 19:14:57 +08:00

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

meisky6666

2018-01-17 19:19:52 +08:00

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

s82kd92l

2018-01-17 19:29:04 +08:00

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

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

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

honeycomb

2018-01-17 19:30:38 +08:00

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

honeycomb

2018-01-17 19:32:31 +08:00

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

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

didikee

2018-01-17 19:33:22 +08:00

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

est

2018-01-17 19:37:06 +08:00

直接底层改 chroot + setns

s82kd92l

2018-01-17 19:38:41 +08:00

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

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

s82kd92l

2018-01-17 19:40:41 +08:00

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

tscat

2018-01-17 19:48:28 +08:00

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

s82kd92l

2018-01-17 19:51:25 +08:00

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

meisky6666

2018-01-17 19:59:18 +08:00

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

skylancer

2018-01-17 20:44:14 +08:00

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

pq

2018-01-17 20:50:39 +08:00

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

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

skylancer

2018-01-17 20:53:08 +08:00

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

s82kd92l

2018-01-17 21:17:10 +08:00

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

zjb861107

2018-01-17 21:20:15 +08:00

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

xingda920813

2018-01-17 21:27:41 +08:00

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