对于LaunchAnyWhere漏洞的利用，传统的思路是system uid FileProvider转换为system_app权限的任意文件读写，但是很遗憾的是Android在这里有缓解措施，不允许system和root uid随意给其它uid授予URI权限，曾经也出现过厂商在这块开后面，又被安全研究员绕过的故事，例如我给三星提的CVE-2023-21474可以实现在AOSP Nday CVE-2022-20223修复后，仍然可以进行利用。但是这类漏洞逐渐都已经修复，所以对于LaunchAnyWhere漏洞，需要思考一些其它利用方式。
本文不会讨论任何前置的LaunchAnyWhere漏洞，只讨论在实现LaunchAnyWhere之后，如何利用InstallInstalling实现自动安装。
Google在2024年10月的Android安全公告中，终于披露了我之前发现的CVE-2024-40673漏洞，并给予了高严重性和RCE的漏洞分类。这个漏洞的发现过程也算是机缘巧合，今天就来聊聊CVE-2024-40673这个漏洞。
接口信息泄漏的问题在中国大陆OEM上已经不是什么新鲜漏洞，主要也是喜欢做多屏协同这类对Window和Activity“下手”的特性，但是这次遇到的这两个同样的漏洞，还是让我觉得很有趣，在这里跟大家分享一下。
对于以低于 Android 13 的版本的 SDK 为目标平台的应用，在应用创建至少一个 NotificationChannel 后，拦截首次 activity 启动以显示权限提示，询问用户是否想要接收来自应用的通知。简单来说就是targetSDK在Android 13以前的应用，如果至少有一个NotificationChannel，则在首次Activity启动时会自动弹出通知权限授权。主要分析该机制的原理。来源：https://source.android.com/docs/core/display/notification-perm
我们都知道Android应用程序依赖Binder IPC接口和系统服务通信来完成各种操作，使用系统的各项功能。因为system_server进程中的系统服务负责了Android中许多重要的活动，例如组件、权限等的管理等，所以在OEM实现它们自己的ROM的时候，多多少少会选择为系统服务定制一些供内部使用的接口，从而方便系统级应用或是特定应用实现它们本没有权限进行的一些操作。本文主要记录了不同厂商实现这类接口的偏好，并讨论一些潜在的风险。