安装即启动?探索流氓App的自启动“黑科技” (Android系统内鬼之ContentProvider篇)

本文主要是介绍安装即启动?探索流氓App的自启动“黑科技” (Android系统内鬼之ContentProvider篇),希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

前段时间发现了一个神奇的app,它居然可以在安装之后立即自启动:

在这里插入图片描述

看到没有,在提示安装成功大概1到2秒后,就直接弹出Toast和通知了! 好神奇啊,在没有第三方app帮忙唤醒的前提下,它是怎么做到首次安装即自启动的呢?


初步分析

难道它监听了应用安装的广播,在收到广播之后立即启动后台服务?
用jadx打开一看,确实有监听应用安装和卸载的BroadcastReceiver:

请添加图片描述

但是从截图上来看,这个receiver只有2个常见的属性: enableexported,甚至intent-filter都没有设置优先级,分明就是一个很普通的receiver嘛。
而且按常理,在android系统上,新安装的app如果没有主动运行过一次,那么它所有的BroadcastReceiver都是不会生效的,例如监听应用安装卸载、监听设备开机、熄屏亮屏等。
就算它有办法绕过这个限制,那它真的能接收到自身的安装广播吗?(反正这种操作我是第一次见)

不过我还是仿照它的做法,写demo测试了一下……

得到的结果是: 接收不到任何广播。
这就说明这个app的【安装完自启动】并不是通过监听自身的安装广播来实现的。

那么,它到底是怎么启动的呢,会是谁启动了它呢?

也许我们可以使用debug法来进行分析(当然,debug系统进程需要手机获取root权限,或者直接刷入一个user-debug/eng系统,这不在本文的讨论范围内)。

有同学可能会说,可以在AMS的attachApplication方法里打断点,因为这是app进程启动的必经之路。
emmmm,这是必经之路没错,但如果在这里打断点已经迟了,因为这时候进程已经启动,依然无法得知是由哪个进程发起的。
所以我们应该尽量在靠近启动源头的地方打断点。


寻找启动源头

先来复习一下常规应用进程的启动流程:

在这里插入图片描述

查看大图

可以看到,向zygote发起fork请求的是system_process进程,我们可以在system_process这条线上的任意一个方法打断点,比如ZygoteProcess.start方法:

在这里插入图片描述

等下就可以顺着堆栈去找到启动的源头了。

如果你的手机不是user-debug/eng系统但有root权限(现在获取root权限基本上都是刷magisk了吧?),可以直接在shell中通过以下命令来临时(重启后失效)开启全局debug:
magisk resetprop ro.debuggable 1&&stop;start

好,attach上system_process进程:

请添加图片描述

请添加图片描述

现在卸载重新安装一遍(等它自启动):

在这里插入图片描述

来了来了,就是这个com.fg!来看下调用链的前半段(注意选中的那个lambda):

请添加图片描述

原来这里有个Handler.post,我们在它外面再打一个断点,这样就能看到post之前的调用链了:

在这里插入图片描述

好,再次卸载重新安装(等它自启动):

在这里插入图片描述

咦???为什么源头是AMS的getContentProvider方法啊?
看下变量面板:

在这里插入图片描述

这个callingPackage就是本次调用getContentProvider方法的进程包名;
name即目标ContentProvider在AndroidManifest中声明的authorities(系统唯一);

现在可以得出结论:
app在安装之后,com.android.providers.blockednumber进程会通过getContentProvider获取com.fg.account.kp.provider而间接启动了进程!

那么,为什么blockednumber进程要获取这个provider呢?

还是继续debug根据堆栈来溯源吧:

在这里插入图片描述

咦?奇怪,居然没有com.android.providers.blockednumber进程。
很有可能是它修改了进程名。 我们现在已经知道了它的包名,可以通过pm path命令来得到对应apk的路径:

:~$ adb shell pm path com.android.providers.blockednumberpackage:/system/priv-app/BlockedNumberProvider/BlockedNumberProvider.apk

把它pull上来然后拖进as看下AndroidManifest:

:~$ adb pull /system/priv-app/BlockedNumberProvider/BlockedNumberProvider.apk ./system/priv-app/BlockedNumberProvider...ed. 12.6 MB/s (303518 bytes in 0.023s)

在这里插入图片描述

emmmm,果然没猜错,进程名改为android.process.acore了,也就是上图中的第二个进程。
赶紧attach上,然后给IActivityManager的getContentProvider方法打上断点:

在这里插入图片描述

再把那个apk继续重安装一遍(等它自启动):

在这里插入图片描述

断点到了!把调用链整理一下:

android.app.IActivityManager$Stub$Proxy.getContentProvider() -->
android.app.ActivityThread.acquireProvider() -->
android.content.ContextImpl$ApplicationContentResolver.acquireUnstableProvider() -->
android.content.ContentResolver.acquireUnstableProvider() -->
android.content.ContentResolver.query() -->
com.android.providers.contacts.ContactDirectoryManager.queryDirectoriesForAuthority() -->
com.android.providers.contacts.ContactDirectoryManager.updateDirectoriesForPackage() -->
com.android.providers.contacts.ContactDirectoryManager.onPackageChanged() -->
com.android.providers.contacts.ContactsProvider2.onPackageChanged() -->
com.android.providers.contacts.ContactsPackageMonitor.onPackageChanged() -->
com.android.providers.contacts.ContactsPackageMonitor.onPerformTask() -->
com.android.providers.contacts.ContactsTaskScheduler$MyHandler.handleMessage() -->
android.os.Handler.dispatchMessage() -->
android.os.Looper.loop() -->
android.os.HandlerThread.run()

原来getContentProvider是因为ContactDirectoryManager.queryDirectoriesForAuthority里面调用了ContentResolver.query方法而间接调用到的。
继续往下看,是连续三个onPackageChanged,根据方法名再结合刚刚安装apk的现象,就很容易能猜到它是监听了应用安装的广播。
好,现在用jadx打开刚刚pull上来的BlockedNumberProvider.apk,看下它这几个类的代码:

在这里插入图片描述

咦??为什么没有这些类呢? 甚至都没看到com.android.providers.contacts包名!
再看一眼Manifest:

在这里插入图片描述

它居然指定了sharedUserId为android.uid.shared!这样看来,很可能不止它一个app在用这个sharedUserId。了解过sharedUserId的同学都知道,如果不同的app声明了相同的sharedUserId和相同的进程名,那么这些app就会运行在同一个进程中!
所以我们前面debug时看到的com.android.providers.contacts这些包名的class,很可能就在另外一个app上。
有什么办法可以查到还有哪些app跟它使用了同样的sharedUserId呢?

很简单,只需要运行adb shell dumpsys package com.android.providers.blockednumber

在这里插入图片描述

看第二个: com.android.providers.contacts,这不刚好就是上面调用了ContentResolver.query方法的包名吗?

用前面的方法把它pull上来用jadx看看吧:

在这里插入图片描述

上面调用链里出现的类,在这里都找到了。
再确认一下Manifest:

在这里插入图片描述

看到没? sharedUserIdprocess都跟BlockedNumberProvider.apk是一样的,这就证明了这两个apk是运行在同一进程中的。


代码分析

先回顾一下之前断点到的调用链:

android.app.IActivityManager$Stub$Proxy.getContentProvider() -->
android.app.ActivityThread.acquireProvider() -->
android.content.ContextImpl$ApplicationContentResolver.acquireUnstableProvider() -->
android.content.ContentResolver.acquireUnstableProvider() -->
android.content.ContentResolver.query() -->
com.android.providers.contacts.ContactDirectoryManager.queryDirectoriesForAuthority() -->
com.android.providers.contacts.ContactDirectoryManager.updateDirectoriesForPackage() -->
com.android.providers.contacts.ContactDirectoryManager.onPackageChanged() -->
com.android.providers.contacts.ContactsProvider2.onPackageChanged() -->
com.android.providers.contacts.ContactsPackageMonitor.onPackageChanged() -->
com.android.providers.contacts.ContactsPackageMonitor.onPerformTask() -->
com.android.providers.contacts.ContactsTaskScheduler$MyHandler.handleMessage() -->
android.os.Handler.dispatchMessage() -->
android.os.Looper.loop() -->
android.os.HandlerThread.run()

最后是在ContactDirectoryManager的queryDirectoriesForAuthority方法里调用ContentResolver.query方法,看下它的代码:

protected void queryDirectoriesForAuthority(ArrayList<DirectoryInfo> arrayList, ProviderInfo providerInfo) {Cursor cursor = null;try {cursor = this.mContext.getContentResolver().query(new Uri.Builder().scheme("content").authority(providerInfo.authority).appendPath("directories").build(), DirectoryQuery.PROJECTION, null, null, null);if (cursor == null) {......} else {while (cursor.moveToNext()) {DirectoryInfo directoryInfo = new DirectoryInfo();directoryInfo.packageName = providerInfo.packageName;directoryInfo.authority = providerInfo.authority;directoryInfo.accountName = cursor.getString(0);directoryInfo.accountType = cursor.getString(1);directoryInfo.displayName = cursor.getString(2);......arrayList.add(directoryInfo);}}} catch (Throwable th) {......}
}

大致的逻辑就是把查询出来的Provider信息放进一个ArrayList里面。
注意:上面调用getContentResolver().query的时候,如果要查询的Provider进程不在运行中,AMS会尝试启动这个Provider所在进程!

好,接下来看看在什么情况下它会调用这个queryDirectoriesForAuthority方法:

private List<DirectoryInfo> updateDirectoriesForPackage(PackageInfo packageInfo, boolean z) {......ArrayList<DirectoryInfo> newArrayList = Lists.newArrayList();ProviderInfo[] providerInfoArr = packageInfo.providers;if (providerInfoArr != null) {for (ProviderInfo providerInfo : providerInfoArr) {// 这里if (isDirectoryProvider(providerInfo)) {queryDirectoriesForAuthority(newArrayList, providerInfo);}}}......
}

原来是通过isDirectoryProvider方法来判断的,看下它的代码:

static boolean isDirectoryProvider(ProviderInfo providerInfo) {if (providerInfo == null) return false;Bundle metaData = providerInfo.metaData;if (metaData == null) return false;Object obj = metaData.get("android.content.ContactDirectory");return obj != null && Boolean.TRUE.equals(obj);
}

它是判断这个provider的metaData中的"android.content.ContactDirectory"属性是否为true!

还记得前面debug看到的那个被拉起的provider叫什么吗?
没错就是com.fg.account.kp.provider,那么现在我们来看下它在AndroidManifest中的声明:

在这里插入图片描述

妈耶!!!它meta-data里的"android.content.ContactDirectory"属性就是true!

真的只有这么简单吗?只需要在provider里面设置这个meta-data属性为true就可以实现安装自启动?
我们来写个demo来验证下叭!


效果验证

首先写一个ContentProvider,并在onCreate方法里打印日志:

class AutoStartProvider : ContentProvider() {override fun onCreate(): Boolean {Log.e("AutoStartProvider", "process started")return true}override fun query(uri: Uri?, projection: Array<out String>?, selection: String?, selectionArgs: Array<out String>?, sortOrder: String?) = nulloverride fun getType(uri: Uri?) = nulloverride fun insert(uri: Uri?, values: ContentValues?) = nulloverride fun delete(uri: Uri?, selection: String?, selectionArgs: Array<out String>?) = 0override fun update(uri: Uri?, values: ContentValues?, selection: String?, selectionArgs: Array<out String>?) = 0
}

然后在AndroidManifest里声明一下,并加上"android.content.ContactDirectory"属性:

<providerandroid:name=".AutoStartProvider"android:authorities="AutoStartProvider"android:exported="true"><meta-dataandroid:name="android.content.ContactDirectory"android:value="true" />
</provider>

再加个前台服务,跟随app一起启动:

class AutoStartService : Service() {override fun onCreate() {super.onCreate()setForeground()Toast.makeText(this, "Service started", Toast.LENGTH_LONG).show()}private fun setForeground() {val channelId = "auto_start"(getSystemService(NOTIFICATION_SERVICE) as NotificationManager).createNotificationChannel(NotificationChannel(channelId, channelId, NotificationManager.IMPORTANCE_HIGH).apply {setSound(null, null)setShowBadge(false)})startForeground(1, Notification.Builder(this, channelId).setContentTitle("Service started").setSmallIcon(R.drawable.ic_launcher_foreground).build())}override fun onBind(intent: Intent?): IBinder? = null
}

好,push到测试机上安装看看:

在这里插入图片描述

哈哈哈哈哈,成功了!居然真的就这么简单!

好了,最后我们来总结一下叭:


总结

  1. 我们发现了一个"神奇"的app之后,准备搞清楚它的原理;

  2. 首先是进行了初步的猜测: 是否监听了自身的安装广播。但在动手验证之后发现并不是;

  3. 接着通过debug法,发现原来是com.android.providers.blockednumber进程调用了getContentProvider获取com.fg.account.kp.provider的实例时,从而间接启动了进程;

  4. 当我们准备debug com.android.providers.blockednumber时却发现在running app list没有这个进程;

  5. 经查看它apk的AndroidManifest.xml文件发现原来是进程名改为android.process.acore了;

  6. 但当我们试图进一步查看反编译之后的class代码时,居然没有找到先前debug时调用堆栈的那些类;

  7. 后面发现原来有好几个跟它声明了相同sharedUserIdprocess的其他app;

  8. 经过分析正确app的代码发现,原来只需要在provider的meta-data里面设置"android.content.ContactDirectory"的属性值为true即可;

  9. 最后我们自己动手写了demo并验证通过。

(以上内容仅供学习交流,不要用来干坏事噢~)

文章到此结束,有错误的地方请指出,谢谢大家!

这篇关于安装即启动?探索流氓App的自启动“黑科技” (Android系统内鬼之ContentProvider篇)的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/866817

相关文章

不懂推荐算法也能设计推荐系统

本文以商业化应用推荐为例,告诉我们不懂推荐算法的产品,也能从产品侧出发, 设计出一款不错的推荐系统。 相信很多新手产品,看到算法二字,多是懵圈的。 什么排序算法、最短路径等都是相对传统的算法(注:传统是指科班出身的产品都会接触过)。但对于推荐算法,多数产品对着网上搜到的资源,都会无从下手。特别当某些推荐算法 和 “AI”扯上关系后,更是加大了理解的难度。 但,不了解推荐算法,就无法做推荐系

Zookeeper安装和配置说明

一、Zookeeper的搭建方式 Zookeeper安装方式有三种,单机模式和集群模式以及伪集群模式。 ■ 单机模式:Zookeeper只运行在一台服务器上,适合测试环境; ■ 伪集群模式:就是在一台物理机上运行多个Zookeeper 实例; ■ 集群模式:Zookeeper运行于一个集群上,适合生产环境,这个计算机集群被称为一个“集合体”(ensemble) Zookeeper通过复制来实现

CentOS7安装配置mysql5.7 tar免安装版

一、CentOS7.4系统自带mariadb # 查看系统自带的Mariadb[root@localhost~]# rpm -qa|grep mariadbmariadb-libs-5.5.44-2.el7.centos.x86_64# 卸载系统自带的Mariadb[root@localhost ~]# rpm -e --nodeps mariadb-libs-5.5.44-2.el7

Centos7安装Mongodb4

1、下载源码包 curl -O https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-rhel70-4.2.1.tgz 2、解压 放到 /usr/local/ 目录下 tar -zxvf mongodb-linux-x86_64-rhel70-4.2.1.tgzmv mongodb-linux-x86_64-rhel70-4.2.1/

基于人工智能的图像分类系统

目录 引言项目背景环境准备 硬件要求软件安装与配置系统设计 系统架构关键技术代码示例 数据预处理模型训练模型预测应用场景结论 1. 引言 图像分类是计算机视觉中的一个重要任务,目标是自动识别图像中的对象类别。通过卷积神经网络(CNN)等深度学习技术,我们可以构建高效的图像分类系统,广泛应用于自动驾驶、医疗影像诊断、监控分析等领域。本文将介绍如何构建一个基于人工智能的图像分类系统,包括环境

水位雨量在线监测系统概述及应用介绍

在当今社会,随着科技的飞速发展,各种智能监测系统已成为保障公共安全、促进资源管理和环境保护的重要工具。其中,水位雨量在线监测系统作为自然灾害预警、水资源管理及水利工程运行的关键技术,其重要性不言而喻。 一、水位雨量在线监测系统的基本原理 水位雨量在线监测系统主要由数据采集单元、数据传输网络、数据处理中心及用户终端四大部分构成,形成了一个完整的闭环系统。 数据采集单元:这是系统的“眼睛”,

深入探索协同过滤:从原理到推荐模块案例

文章目录 前言一、协同过滤1. 基于用户的协同过滤(UserCF)2. 基于物品的协同过滤(ItemCF)3. 相似度计算方法 二、相似度计算方法1. 欧氏距离2. 皮尔逊相关系数3. 杰卡德相似系数4. 余弦相似度 三、推荐模块案例1.基于文章的协同过滤推荐功能2.基于用户的协同过滤推荐功能 前言     在信息过载的时代,推荐系统成为连接用户与内容的桥梁。本文聚焦于

MySQL数据库宕机,启动不起来,教你一招搞定!

作者介绍:老苏,10余年DBA工作运维经验,擅长Oracle、MySQL、PG、Mongodb数据库运维(如安装迁移,性能优化、故障应急处理等)公众号:老苏畅谈运维欢迎关注本人公众号,更多精彩与您分享。 MySQL数据库宕机,数据页损坏问题,启动不起来,该如何排查和解决,本文将为你说明具体的排查过程。 查看MySQL error日志 查看 MySQL error日志,排查哪个表(表空间

嵌入式QT开发:构建高效智能的嵌入式系统

摘要: 本文深入探讨了嵌入式 QT 相关的各个方面。从 QT 框架的基础架构和核心概念出发,详细阐述了其在嵌入式环境中的优势与特点。文中分析了嵌入式 QT 的开发环境搭建过程,包括交叉编译工具链的配置等关键步骤。进一步探讨了嵌入式 QT 的界面设计与开发,涵盖了从基本控件的使用到复杂界面布局的构建。同时也深入研究了信号与槽机制在嵌入式系统中的应用,以及嵌入式 QT 与硬件设备的交互,包括输入输出设

JAVA智听未来一站式有声阅读平台听书系统小程序源码

智听未来,一站式有声阅读平台听书系统 🌟&nbsp;开篇:遇见未来,从“智听”开始 在这个快节奏的时代,你是否渴望在忙碌的间隙,找到一片属于自己的宁静角落?是否梦想着能随时随地,沉浸在知识的海洋,或是故事的奇幻世界里?今天,就让我带你一起探索“智听未来”——这一站式有声阅读平台听书系统,它正悄悄改变着我们的阅读方式,让未来触手可及! 📚&nbsp;第一站:海量资源,应有尽有 走进“智听