寻找路径遍历漏洞：<应用程序有一处 intent-filter，表明可以接受 http/https URL，并且 mime Type 必须为 application/pdf。
例如，当带有数据的 URL（http://localhost/test.pdf）传送给 Adobe Reader 时，APP 会将文件下载到 /sdcard/Downloads/Adobe Acrobat 文件夹中，文件名为所发送 URL 的 LastPathSegment（如例子中会是 test.pdf）
然后 Activitycom.adobe.reader.AdobeReader 接收到 Intent 并启动
ARFileURLDownloadActivityActivity。<此时 ARFileURLDownloadActivity 会启动 com.adobe.reader.misc.ARFileURLDownloadService 服务。
例如，以 URL:https://localhost/x/..%2F..%2Ffile.pdf 为例，当这个 URL 传递给 getLastPathSegment () 方法时，它将接受..%2F..%2Ffile.pdf 作为 URL 的最后一段，并返回../../file.pdf 作为输出。
在将 downloadFile 变量传递到 File 实例之前，没有对其进行任何清理，于是便会导致路径遍历漏洞。
获得 RCE：
Adobe Acrobat Reader APP 使用 Google Play 核心库为用户提供移动附加功能，要知道应用程序是否正在使用 Play Core 库进行动态代码加载，一种简单的方法是检查 /data/data/:application_id/files/ 目录中的 spiltcompat 目录。
使用路径遍历漏洞，白帽小哥可以在 APP 的
/data/data/com.adobe.reader/files/splitcompat/1921618197/verified-splits/ 目录中编写任意 APK，攻击者的 APK 中的类将自动添加到 APP 的 ClassLoader 中，并在 APP 调用时执行恶意代码，更详细的解释，可移步：
https://blog.oversecured.com/Why-dynamic-code-loading-could-be-dangerous-for-your-apps-a-Google-example
Adobe Reader APP 还会在运行期间下载一个名为 FASOpenCVDF.apk 的模块，白帽小哥原本的计划是覆盖该文件并远程访问代码执行，但是无法成功实现，问题在于路径遍历漏洞无法覆盖现有文件… 只能创建新文件。
在这个阶段白帽小哥被困绕了很久，他一直在寻找一种方法在无需安装额外 APK 的前提下来远程代码执行，在白帽小哥的设备上安装的 Play Core 库分析了其他应用程序后，他看到 Play Core 库也提供了从 /data/data/com.adobe.reader/files/splitcompat/:id/native-libraries/ 目录加载本地代码 (.so 文件) 的功能。
FASOpenCVDF.apk 模块会从
/data/data/com.adobe.reader/files/splitcompat/1921819312/native-libraries/FASOpenCVDF.config.arm64_v8a 目录加载了一个本地库，于是白帽小哥决定查看 FASOpenCVDF.apk 源代码，在那里他发现这个模块还试图加载三个不可用的库 libADCComponent.so、libColoradoMobile.so 和 libopencv_info.so，于是成功解决了远程代码执行的问题。
白帽小哥创建了一个简单的本地 PoC 库，将其重命名为 libopencvinfo.so，并将其放入
/data/data/com.adobe.reader/files/splitcompat/1921819312/native-libraries/FASOpenCVDF.config.arm64_v8a 目录中，在下一次 APP 启动时，只要使用填充和签名功能，就能成功执行恶意代码了。
POC 代码：<漏洞修复：
com.adobe.libs.buildingblocks.utils.BBIntentUtils.java代码：<漏洞处理时间线：
Jul 29th,2021 - 向 Adobe 报告漏洞
Aug 4th ,2021 - 报告跟踪
Oct 13th,2021 - 漏洞修复
Dec 4th ,2021 - 获得来自 GPSRP $10,000 奖励
