简介Android的USB有host和Accessory两种模式，处于Host模式下的Android设备可以对外围设备进行交互，如读取U盘数据、USB键盘鼠标等。当有外设插入到Android设备上时，系统读取外设的一些硬件信息（如LABEL、UUID等）并自动为其挂载。 常见的USB设备有以下几种： USB Sticks即U盘，用于手机和U盘之间拷贝数据，即使处于锁屏状态，系统也会自动mount。（Android 9之后，系统阻止了锁屏情况下的mount） USB keyboardsUSB键盘或鼠标，可以用来操控手机，在锁屏下也会自动mount。 USB ethernet adaptersUSB网卡，插入手机后，通过DHCP可以获取ip地址联通网络，锁屏下也可以使用 Android系统中由Vold进程（Volume Daemon）负责管理和控制外设，Vold进程如果在挂载外设时没有正确的对硬件信息进行解析，则有可能出现安全问题。CVE-2018-9445就是Vold在挂载外设时，由于未正确获取UUID导致的目录穿越问题。 漏洞细节当USB设备插到Android手机上时，Vold进程（Volume Daemon）会自动为USB设备进行mount，即使手机处于锁屏状态。Vold进程在mount之前需要知道所连接设备的一些硬件信息，如UUID、type、Label等，其具体实现在system/vold/Utils.cpp的readMetadata()函数中： 12345678910111213141516171819202122232425262728293031323334353637383940414243/*https://android.googlesource.com/platform/system/vold/+/master/Utils.cpp#212*/std: ...

关于Personal Dictionary（个人字典）Personal Dictionary（个人字典）是Android系统提供的一个自定义的字典，用于存放用户经常输入的数据或字符以提高输入效率，它位于“设置”—— “语言和输入法” —— “个人字典”中，某些情况下Personal Dictionary中可能存放用户的隐私信息，如密码、地址、电话、信用卡账号等信息。https://ioactive.com/wp-content/uploads/2018/07/exploit-user-dictionary-poc.png 用户也可以为一个字符串自定义一个shortcut，例如输入myhome，会自动出来详细的地址https://ioactive.com/wp-content/uploads/2018/07/exploit-user-dictionary-poc2.png 在Andorid系统内部，这些字符保存在一个sqlite数据库中，表名称为“words”，其中包含6个列：_id (INTEGER, PRIMARY KEY)word (TEXT)frequency (INTEGER)locale (TEXT)appid (INTEGER)shortcut (TEXT) 漏洞细节早期版本的Android系统中，操作Personal Dictionary需要申请权限：android.permission.READ_USER_DICTIONARYandroid.permission.WRITE_USER_DICTIONARY从Android 6.0（API 23）开始, Android规定只有IME和spellchecker才可以操作Personal Dictionary，并提供了对应的provider —— content://user_dictionary/words co ...

iOS的Sandbox和IPC机制iOS的sandbox限制了普通的应用程序只能访问自身沙箱内的资源，应用程序在进行系统调用时会受到sandbox的策略限制。因此，为了实现权限提升，逃逸iOS的sandbox是必要的。 iOS系统提供了IPC机制（进程间通信），如URL schemes, Mach, pipes等，Mach IPC是一套面向消息的IPC机制，实现对象与对象之间的通信，源对象发送一条消息，这条消息加入到目标对象的队列中等待处理。如果产生应答，则通过另一条消息传递回去。消息分简单消息和复杂消息，分别对应两种不同的结构： 简单消息 复杂消息 Mach对象之间的消息时基于端口传递的，消息从某一个端口发送到另一个端口。向一个端口发送消息实际上是将消息放在队列中，直到消息被处理。查找一个对象的句柄(标识应用程序中的不同对象和同类中的不同的实例的值)，实际上查找的是这个对象端口的句柄，给定一个对象的端口，就可以通信了。Mach消息传递使用的是Mach_msg()函数。 基于Mach的消息机制，iOS又提供了XPC、NSXPC等进程间通信机制，通过这些机制，sandbox内的应用可以和没有sandbox的Mach service进行通信，如果这些service在处理消息时发生错误，就有可能出现由sandbox到非sandbox的代码执行。 为了发现这些问题，我们将目标放在Mach service的消息处理上，那么如何找到实现Mach service的binary文件呢？ /System/Library/LaunchDaemons的plist文件包含了大多数Mach service，其中MachServices字段指向了一组Mach services,ProgramArguments字段指向实现这些Mach service的binary文件。 CVE-2018- ...

dumpsysdumpsys命令用来查询界面元素层级、系统服务运行状态、电池、网络等一些信息。用法：12345678910HWVTR:/ # dumpsys --helpusage: dumpsys To dump all services.or: dumpsys [-t TIMEOUT] [--help | -l | --skip SERVICES | SERVICE [ARGS]] --help: shows this help -l: only list services, do not dump them -t TIMEOUT: TIMEOUT to use in seconds instead of default 10 seconds --skip SERVICES: dumps all services but SERVICES (comma-separated list) SERVICE [ARGS]: dumps only service SERVICE, optionally passing ARGS to it 常用功能： “dumpsys activity activities | grep mResumedActivity” 或者“dumpsys window | grep mCurrentFocus” 获取顶层activity dumpsys -l 支持dumpsys服务的所有列表 dumpsys wifiscanner 获取wifi信息 dumpsys webviewupdate 获得webview版本等信息 dumpsys usagestats|grep com.tencent.mm 某个APP的使用情况 dumpsys sho ...

frida代码结构：frida-core: Frida core library intended for static linking into bindingsfrida-gum: Low-level code instrumentation library used by frida-corebindings:frida-python: Frida Python bindingsfrida-node: Frida Node.js bindingsfrida-qml: Frida Qml pluginfrida-swift: Frida Swift bindingsfrida-tools: Frida CLI toolscapstone: instruction disammbler frida-gum解析：frida-gum 本身就是一种跨平台的设计. 有两个点需要处理统一: 1. 针对 CPU 架构的代码 2. 针对操作系统(Backend) 的代码. 同时要在这两个点上构建 CPU/OS 无关代码, 以及规定一些统一的接口. frida-gum/gum/arch-* 定义的是与 CPU 架构有关的代码,也就是汇编级操作, 比如汇编指令的读/写/修复. frida-gum/gum/backend-* 分两种情况: 1. 定义的是与操作系统有关的代码, 更多是一些内存/进程等操作 2. 对 arch 层级代码的封装成统一逻辑 frida-gum/* 对 arch 和 backend 的抽象封装成上层的平台/架构无关代码. frida-gum/bindings/gumjs/：分V8和Duktape两个引擎，实现了Module、Memory、NativeFunction等功能（https://www.frida.re/docs/javascript-api/） 两种模式 ...

一、简介Android 提供了一个可管理和操作设备的API叫DevicePolicyManager，使用这个API可以接管手机的应用权限，对手机做出很重要很多大胆的操作,比如设置锁屏方式、恢复出厂设置、设置密码、强制清除密码，修改密码等操作。 很多“远程查找手机”的实现使用了设备管理器功能，可以实现远程锁定手机，远程擦除，远程响铃等。 此外，很多恶意软件通过设备管理器进行“锁屏勒索”等恶意操作，为了限制设备管理器被滥用，Android N 规定，第三方应用开发者只能使用DevicePolicyManager.resetPassword为无密码设备设置初始密码，而不能重置或清除已有的设备密码，但在Android N以下还是存在该类型的勒索攻击。 由于设备管理器的高权限，因此要谨慎对待申请激活设备管理器的App，例如：今日头条、某些安全管家等等， 二、设备管理器使用 Menifest文件中注册receiver 123456789101112<receiver android:name=".demo.DeviceReceiver" android:permission="android.permission.BIND_DEVICE_ADMIN"> <meta-data android:name="android.app.device_admin" android:resource="@xml/device_admin" /> <intent-filter> <action android:name=&q ...

简介最近在对华为P10刷机时，发现解锁bootloader需要关闭“查找我的手机“功能，此外，解锁bootloader后刷recovery时，仍然需要关闭“查找我的手机”才能进行，这种现象表明了Android主系统可以操作bootloader和recovery分区，一番查找后，发现这个功能叫做FRP（Factory Reset Protection）,自Android 5.0后引入，为了防止手机被盗后被刷机而引入的一种保护机制。 FRP工作机制我们假设手机被盗取后的几个场景来分析： 一、手机有锁屏密码，盗取者无法进入主系统方案1：盗取者为了使用该设备，此时，很容易想到进入recovery模式去恢复出厂设置，即使这样，原机主的设备在reset后数据被清除，但重启后再次进入系统前，FRP保护开始工作，要求输入原设备绑定的账号解锁。如下是在华为手机上做的实验： 方案2：既然原设备的recovery有检查，那盗取者可以刷第三方的recovery,此时便需要解锁bootloader。然而，随着很多手机厂商都不提供解锁bootloader服务，仅仅是解锁bootloader就很困难了，我们再假设盗取者有解锁bootloader的能力，然而FRP又发挥了作用，在bootloader中设置了一个标记位，只有这个标记位置零时才允许解锁bootloader。同样道理，即使完成了解锁bootloader这一关，刷第三方recovery时依然受到FRP保护。 两种方案都失败了，对于盗取者来说，只能眼睁睁看着设备卖废铁了，所以FRP作用还是挺大的。 二、无锁屏密码或被破解，盗取者可以进入主系统这个时候就比较尴尬了，失主的数据当然一览无余，但盗取者可能有三种操作： 关闭FRP保护 添加一个自己的账户或删除原机主账户 在设置中恢复出厂设置这三种操作无论哪一个，都需要输入原账户的口令进行验证。 当然 ...

一、简介近期微信支付SDK爆出了一个严重的XXE漏洞（http://seclists.org/fulldisclosure/2018/Jul/3），可导致商家服务器上的文件被窃取。 XXE (XML External Entity Injection) 漏洞发生在应用程序解析 XML 输入时，没有禁止外部实体的加载。在web上愈来愈少，但在一些大家不容易想到的地方还是存在很多，例如之前apktool工具爆出的XXE漏洞用来攻击APK分析人员。 二、漏洞原理XML用于标记电子文件使其具有结构性的标记语言，可以用来标记数据、定义数据类型，是一种允许用户对自己的标记语言进行定义的源语言。XML文档结构包括XML声明、DTD文档类型定义（可选）、文档元素。 DTD（文档类型定义）DTD（文档类型定义）的作用是定义 XML 文档的合法构建模块。DTD 可以在 XML 文档内声明，也可以外部引用。 内部声明DTD 1<!DOCTYPE 根元素 [元素声明]> 引用外部DTD123<!DOCTYPE 根元素 SYSTEM "文件名">//或者<!DOCTYPE 根元素 PUBLIC "public_ID" "文件名"> DTD文档中有很多重要的关键字如下： - DOCTYPE（DTD的声明） - ENTITY（实体的声明） - SYSTEM、PUBLIC（外部资源申请） ENTITY（实体）实体可以理解为变量，其必须在DTD中定义申明，可以在文档中的其他位置引用该变量的值。 根据引用方式，实体可分为内部实体、外部实体、参数实体。完整的实体类别可参考 DTD - Entities（https://www.tutorialspoint.com/dtd/dtd_entities.htm） ...

简介ZipperDown是盘古实验室公布的一个由目录穿越导致RCE的漏洞，根据盘古的检测，发现约10%的iOS应用可能受此漏洞的影响。经过手工分析，确认微博、陌陌、网易云音乐、QQ音乐、快手等流行应用受影响。 漏洞原理 iOS平台没有提供官方解压类库，所以开发中往往引用第三方库来实现解压功能； 由于现有的iOS App基本上采用SSZipArchive或Ziparchive来实现解压，因此漏洞是来自使用第三方Zip库解压Zip文件的过程中没有对Zip内文件名做校验导致的； 例如 SSZipArchive解压时会吧文件名直接拼接到目标路径后面，如果文件名中含有“../”则可以实现目录的上一级跳转，从而实现应用内任意目录的跳转，进一步可以实现文件覆盖； 如果把App的热修复hotpatch文件覆盖替换了，可以达到执行黑客指定指令，从而按照黑客的意图实现任意应用内攻击。 攻击条件 使用了SSZipArchive或Ziparchive第三方解压库; Zip包在解压时没有做完整性校验; 文件名中包含../等路径特殊符号，解压时没有对文件名过滤处理; 使用了JSPatch或其他热修复库，且本地脚本没有加密等安全处理; 连接不可靠的WIFI热点或者网络被人劫持。 漏洞分析iOS平台的两个解压缩库（SSZipArchive和ZipArchive）在解压缩过程中没有考虑到文件名中包含”../”的情况，造成了文件释放过程中路径穿越，导致恶意Zip文件可以在App沙盒范围内，覆盖任意可写文件。具体代码如下： ZipArchive相关代码1234567891011121314151617-(BOOL) UnzipFileTo:(NSString*) path overWrite:(BOOL) overwrite{ [...] // check if it contains ...

简介目前市面上充斥着各种诸如“充电1分钟，通话2小时”的宣传，手机快速充电成为手机厂商们追逐的一个技术指标。常见的标准充电装置通常为5V/1A 或 5V/2A，快速充电意味着要在电流或电压上有所提高，于是就出现了如QC、PD等各式各样的充电协议，本文作一个简单介绍。 几个关键知识点： MicroUSB最大支持电流为2A,TYPE-C口最多支持5A PD协议是谷歌和USB-IF推出的，QC是高通推出的 PD 3.0收编了QC 4.0,PD可能会成为主流,谷歌已经强制安卓阵营使用USB接口就必须支持PD协议 所有用来充电的type-c接口都支持pd2.0协议吗？并不是，type-c只是接口形状，支持的协议各不相同。 充电要考虑的问题一、电池的接受能力充电本质上就是“喂饱电池”，目前市面上比较流行的iphone x，华为P9，小米note等，电池容量都不超过3000mAH，按照4.35V作为最高电压，1.5C（C为充电或放电倍率，对于3000mAh的电池1.5C电流就是4500mA）充电来看，最大可能接受的充电功率约为20W（4.35V*4.5A约等于20W），当然，这是极限情况。除了功率接收能力，还要涉及到电流接受能力。在1.5C充电时，3000mAH的电池充电电流将达到4.5A，因此，电池触点和电芯内部的电流传输结构都要进行必要的优化。 二、适配器的功率提供能力在不考虑接口承受能力的情况下，20W功率对适配器来说是轻而易举。但是传统的MicroUSB接口，在标准规范里面最大电流承载能力是2A，最高电压是5.25V。仅仅有10.5W，无法达到20W的要求。怎么解决这个问题呢？显然有两种解决方案，增大电流，或者提升电压。 如果不改动物理接口，增大电流是不可能的选项，所以，提升电压，是MicroUSB时代的唯一选项，这就是高通QC快速充电方法的由来。所以，我们可以看到，1.5A ...