Android系统安全和反编译实战_笔记(二)

Android SDK版本名和API level对照表 API_VERSION.png

基础漏洞类型

• 栈溢出
• 堆益处
• 未初始化
• OOB
• UAF
• 条件竞争/TOCTOU漏洞

在了解了基础知识之后，可以进一步学习Andriod自身的体系结构。
Binder方面可以学习调试几个经典漏洞（GitHub - flankerhqd/mediacodecoob: Infoleak and PC control poc for CVE-2015-6620 (24445127), I’ll add after conference， https://www.blackhat.com/asia-16/briefings.html#hey-your-parcel-looks-bad-fuzzing-and-exploiting-parcel-ization-vulnerabilities-in-android）
文件格式漏洞自然是经典的stagefright，https://www.exploit-db.com/docs/39527.pdf。
驱动/内核漏洞3636和1805（https://www.blackhat.com/docs/us-15/materials/us-15-Xu-Ah-Universal-Android-Rooting-Is-Back.pdf）。
Chrome V8相关：GitHub - 4B5F5F4B/Exploits
关注每个月的android security bulletin, 尝试从diff反推漏洞研究如何触发和利用。
代码审计：经典书籍 The art of software security assessment
fuzzing
当然，只要掌握了计算机体系结构，熟悉了程序的运作方式，到达一定境界之后那么各种漏洞、各种系统之间的界限也就渐渐模糊了。
Android漏洞列表：
http://androidvulnerabilities.org/by/version/

DEX相关基础知识

      DEX是Dalvik EXecutable的简称。
      打包.class文件为单一DEX文件并运行于Dalvik虚拟机。
      DEX文件打包进APK文件中（本质上是jar或zip文件）。

image

安装时，系统提取DEX文件进行检查和验证。
第一次运行时，系统完成DEX优化，转换成odex文件。
odex文件存放在/data/dalvik-cache目录并在执行时加载进内存执行。
Dex文件头主要包括校验和以及其他结构的偏移地址和长度信息。

image
image dex.png
dex2.png

魔数字段

魔数字段，主要就是Dex文件的标识符，它占用4个字节，在目前的源码里是 “dex\n”，它的作用主要是用来标识dex文件的，比如有一个文件也以dex为后缀名，仅此并不会被认为是Davlik虚拟机运行的文件，还要判断这 四个字节。另外Davlik虚拟机也有优化的Dex，也是通过个字段来区分的，当它是优化的Dex文件时，它的值就变成”dey\n”了。根据这四个字 节，就可以识别不同类型的Dex文件了。

检验码字段

主要用来检查从这个字段开始到文件结尾，这段数据是否完整，有没有人修改过，或者传送过程中是否有出错等等。通常用来检查数据是否完整的算法，有 CRC32、有SHA128等，但这里采用并不是这两类，而采用一个比较特别的算法，叫做adler32，这是在开源zlib里常用的算法，用来检查文件 是否完整性。该算法由MarkAdler发明，其可靠程度跟CRC32差不多，不过还是弱一点点，但它有一个很好的优点，就是使用软件来计算检验码时比较 CRC32要快很多。可见Android系统，就算法上就已经为移动设备进行优化了。
Java中可使用java.util.zip.Adler32类做校验操作

SHA-1签名字

dex文件头里，前面已经有了面有一个4字节的检验字段码了，为什么还会有SHA-1签名字段呢？不是重复了吗？可是仔细考虑一下，这样设计自有道理。因 为dex文件一般都不是很小，简单的应用程序都有几十K，这么多数据使用一个4字节的检验码，重复的机率还是有的，也就是说当文件里的数据修改了，还是很 有可能检验不出来的。这时检验码就失去了作用，需要使用更加强大的检验码，这就是SHA-1。SHA-1校验码有20个字节，比前面的检验码多了16个字 节，几乎不会不同的文件计算出来的检验是一样的。设计两个检验码的目的，就是先使用第一个检验码进行快速检查，这样可以先把简单出错的dex文件丢掉了， 接着再使用第二个复杂的检验码进行复杂计算，验证文件是否完整，这样确保执行的文件完整和安全。
SHA（Secure Hash Algorithm, 安全散列算法）是美国国家安全局设计，美国国家标准与技术研究院发布的一系列密码散列函数。SHA-1看起来和MD5算法很像，也许是Ron Rivest在SHA-1的设计中起了一定的作用。SHA-1的内部比MD5更强，其摘要比MD5的16字节长4个字节，这个算法成功经受了密码分析专家 的攻击，也因而受到密码学界的广泛推崇。这个算法在目前网络上的签名，BT软件里就有大量使用，比如在BT里要计算是否同一个种子时，就是利用文件的签名 来判断的。同一份8G的电影从几千BT用户那里下载，也不会出现错误的数据，导致电影不播放。

map_off字段

这个字段主要保存map开始位置，就是从文件头开始到map数据的长度，通过这个索引就可以找到map数据。map的数据结构如下：

名称 大小 说明
size 4字节 map里项的个数
list 变长 每一项定义为12字节，项的个数由上面项大小决定。
map数据排列结构定义如下：

/*
*Direct-mapped "map_list".
*/

typedef struct DexMapList {
u4 size; /* #of entries inlist /
DexMapItem list[1]; / entries */
}DexMapList;
每一个map项的结构定义如下：

/*
*Direct-mapped "map_item".
*/

typedef struct DexMapItem {
u2 type; /* type code (seekDexType* above) /
u2 unused;
u4 size; / count of items ofthe indicated type /
u4 offset; / file offset tothe start of data */
}DexMapItem;
DexMapItem结构定义每一项的数据意义：类型、类型个数、类型开始位置。

其中的类型定义如下：

/*map item type codes */
enum{
kDexTypeHeaderItem = 0x0000,
kDexTypeStringIdItem = 0x0001,
kDexTypeTypeIdItem = 0x0002,
kDexTypeProtoIdItem = 0x0003,
kDexTypeFieldIdItem = 0x0004,
kDexTypeMethodIdItem = 0x0005,
kDexTypeClassDefItem = 0x0006,
kDexTypeMapList = 0x1000,
kDexTypeTypeList = 0x1001,
kDexTypeAnnotationSetRefList = 0x1002,
kDexTypeAnnotationSetItem = 0x1003,
kDexTypeClassDataItem = 0x2000,
kDexTypeCodeItem = 0x2001,
kDexTypeStringDataItem = 0x2002,
kDexTypeDebugInfoItem = 0x2003,
kDexTypeAnnotationItem = 0x2004,
kDexTypeEncodedArrayItem = 0x2005,
kDexTypeAnnotationsDirectoryItem = 0x2006,
};

从上面的类型可知，它包括了在dex文件里可能出现的所有类型。可以看出这里的类型与文件头里定义的类型有很多是一样的，这里的类型其实就是文件头里定义 的类型。其实这个map的数据，就是头里类型的重复，完全是为了检验作用而存在的。当Android系统加载dex文件时，如果比较文件头类型个数与 map里类型不一致时，就会停止使用这个dex文件
string_ids_size/off字段

这两个字段主要用来标识字符串资源。源程序编译后，程序里用到的字符串都保存在这个数据段里，以便解释执行这个dex文件使用。其中包括调用库函数里的类名称描述，用于输出显示的字符串等。

string_ids_size标识了有多少个字符串，string_ids_off标识字符串数据区的开始位置。字符串的存储结构如下：

/*

• Direct-mapped "string_id_item".
  /
  typedef struct DexStringId {
  u4 stringDataOff; / file offset to string_data_item /
  } DexStringId;
  可以看出这个数据区保存的只是字符串表的地址索引。如果要找到字符串的实际数据，还需要通过个地址索引找到文件的相应开始位置，然后才能得到字符串数据。 每一个字符串项的索引占用4个字节，因此这个数据区的大小就为4string_ids_size。实际数据区中的字符串采用UTF8格式保存。

例如,如果dex文件使用16进制显示出来内容如下：
063c 696e 6974 3e00
其实际数据则是”<init>\0”

另外这段数据中不仅包括字符串的字符串的内容和结束标志，在最开头的位置还标明了字符串的长度。上例中第一个字节06就是表示这个字符串有6个字符。

关于字符串的长度有两点需要注意的地方：

1、关于长度的编码格式

dex文件里采用了变长方式表示字符串长度。一个字符串的长度可能是一个字节（小于256）或者4个字节（1G大小以上）。字符串的长度大多数都是小于 256个字节，因此需要使用一种编码，既可以表示一个字节的长度，也可以表示4个字节的长度，并且1个字节的长度占绝大多数。能满足这种表示的编码方式有 很多，但dex文件里采用的是uleb128方式。leb128编码是一种变长编码，每个字节采用７位来表达原来的数据，最高位用来表示是否有后继字节。

它的编码算法如下：

/*

• Writes a 32-bit value in unsigned ULEB128 format.
• Returns the updated pointer.
  /
  DEX_INLINE u1 writeUnsignedLeb128(u1* ptr, u4 data)
  {
  while (true) {
  u1 out = data & 0x7f;
  if (out != data) {
  *ptr++ = out | 0x80;
  data >>= 7;
  } else {
  *ptr++ = out;
  break;
  }
  }
  return ptr;
  }
  它的解码算法如下：

/*

• Reads an unsigned LEB128 value, updating the given pointer to point
• just past the end of the read value. This function tolerates
• non-zero high-order bits in the fifth encoded byte.
  /
  DEX_INLINE int readUnsignedLeb128(const u1* pStream) {
  const u1* ptr = *pStream;
  int result = *(ptr++);
  if (result > 0x7f) {
  int cur = *(ptr++);
  result = (result & 0x7f) | ((cur & 0x7f) << 7);
  if (cur > 0x7f) {
  cur = *(ptr++);
  result |= (cur & 0x7f) << 14;
  if (cur > 0x7f) {
  cur = (ptr++);
  result |= (cur & 0x7f) << 21;
  if (cur > 0x7f) {
  /
  * Note: We don't check to see if cur is out of
  * range here, meaning we tolerate garbage in the
  * high four-order bits.
  */
  cur = *(ptr++);
  result |= cur << 28;
  }
  }
  }
  }
  *pStream = ptr;
  return result;
  }
  根据上面的算法分析上面例子字符串，取得第一个字节是06，最高位为0，因此没有后继字节，那么取出这个字节里7位有效数据，就是6，也就是说这个字符串是6个字节，但不包括结束字符“\0”。

2、关于长度的意义

由于字符串内容采用的是UTF-8格式编码，表示一个字符的字节数是不定的。即有时是一个字节表示一个字符，有时是两个、三个甚至四个字节表示一个字符。 而这里的长度代表的并不是整个字符串所占用的字节数，表示这个字符串包含的字符个数。所以在读取时需要注意，尤其是在包含中文字符时，往往会因为读取的长 度不正确导致字符串被截断。

分区加载机制

在 Android 设别中，整个分区的类别如下所示。