iOS性能优化iOS逆向

iOS启动优化-1

2022-06-22  本文已影响0人  f8d1cf28626a

启动优化基本概念1

虚拟内存 & 物理内存

早期的数据访问是直接通过物理地址访问的,这种方式有以下两个问题:

内存不够用的方案:虚拟内存

针对问题1,我们在进程和物理内存之间增加一个中间层,这个中间层就是所谓虚拟内存,主要用于解决当多个进程同时存在时,对物理内存的管理。提高CPU的利用率,使多个进程可以时、按需加载。所以虚拟内存其本质就是虚拟地址和物理地址对应关系映射表

如下图所示,虚拟内存与物理内存间的关系

虚拟内存&物理内存

内存数据的安全问题:ASLR技术

在上面解释的虚拟内存中,我们提到了虚拟内存的起始地址与大小都是固定的,这意味着,当我们访问时,其数据的地址也是固定的,这会导致我们的数据非常容易被破解,为了解决这个问题,所以苹果为了解决这个问题,在iOS4.3开始引入了ASLR技术。

ASLR的概念:(Address Space Layout Randomization ) 地址空间配置随机加载,是一种针对缓冲区溢出安全保护技术,通过对堆、栈、共享库映射等线性区布局的随机化,通过增加攻击者预测目的地址的难度,防止攻击者直接定位攻击代码位置,达到阻止溢出攻击的目的的一种技术。

其目的的通过利用随机方式配置数据地址空间,使某些敏感数据(例如APP登录注册、支付相关代码)配置到一个恶意程序无法事先获知的地址,令攻击者难以进行攻击。

由于ASLR的存在,导致可执行文件和动态链接库在虚拟内存中的加载地址每次启动都不固定,所以需要在编译时来修复镜像中的资源指针,来指向正确的地址。即正确的内存地址 = ASLR地址 + 偏移值

可执行文件

不同的操作系统,其可执行文件的格式也不同。系统内核将可执行文件读取到内存,然后根据可执行文件的头签名(magic魔数)判断二进制文件的格式

可执行文件

其中PE、ELF、Mach-O这三种可执行文件格式都是COFF(Command file format)格式的变种,COFF的主要贡献是目标文件里面引入了“段”的机制,不同的目标文件可以拥有不同数量和不同类型的“段”。

通用二进制文件

因为不同CPU平台支持的指令不同,比如arm64x86,苹果中的通用二进制格式就是将多种架构的Mach-O文件打包在一起,然后系统根据自己的CPU平台,选择合适的Mach-O,所以通用二进制格式也被称为二进制格式,如下图所示

胖二进制格式

通用二进制格式的定义在<mach-o/fat.h>中,可以在下载xnu,然后根据xun -> EXTERNAL_HEADERS ->mach-o中找到该文件,通用二进制文件开始的Fat Headerfat_header结构体,而Fat Archs是表示通用二进制文件中有多少个Mach-O,单个Mach-O的描述是通过fat_arch结构体。两个结构体的定义如下

/*
 - magic:可以让系统内核读取该文件时知道是通用二进制文件
 - nfat_arch:表明下面有多个fat_arch结构体,即通用二进制文件包含多少个Mach-O
 */
struct fat_header {
    uint32_t    magic;      /* FAT_MAGIC */
    uint32_t    nfat_arch;  /* number of structs that follow */
};

/*
 fat_arch是描述Mach-O
 - cputype 和 cpusubtype:说明Mach-O适用的平台
 - offset(偏移)、size(大小)、align(页对齐)描述了Mach-O二进制位于通用二进制文件的位置
 */
struct fat_arch {
    cpu_type_t  cputype;    /* cpu specifier (int) */
    cpu_subtype_t   cpusubtype; /* machine specifier (int) */
    uint32_t    offset;     /* file offset to this object file */
    uint32_t    size;       /* size of this object file */
    uint32_t    align;      /* alignment as a power of 2 */
};

所以,综上所述,

-由于通用二进制文件会同时存储多种架构,所以比单一架构的二进制文件大很多,会占用大量的磁盘空间,但由于系统会自动选择最合适的,不相关的架构代码不会占用内存空间,且执行效率高

Mach-O文件

Mach-O文件是Mach Object文件格式的缩写,它是用于可执行文件、动态库、目标代码的文件格式。作为a.out格式的替代,Mach-O格式提供了更强的扩展性,以及更快的符号表信息访问速度

熟悉Mach-O文件格式,有助于更好的理解苹果底层的运行机制,更好的掌握dyld加载Mach-O的步骤

查看Mach-O文件

如果想要查看具体的Mach-O文件信息,可以通过以下两种方式,推荐使用第二种方式,更直观

MachOView

Mach-O文件格式

对于OS X 和iOS来说,Mach-O是其可执行文件的格式,主要包括以下几种文件类型

下面图示是Mach-O 镜像文件格式

mach-O镜像文件

以上是Mach-O文件的格式,一个完成的Mach-O文件主要分为三大部分:

Header

Mach-O的Header包含了整个Mach-O文件的关键信息使CPU快速知道Mac-O的基本信息,其在Mach.h(路径同前文的fat.h一致)针对32位和64位架构的cpu,分别使用了mach_headermach_header_64结构体来描述Mach-O头部mach_header是连接器加载时最先读取的内容,决定了一些基础架构系统类型指令条数等信息,这里查看64位架构的mach_header_64结构体定义,相比于32位架构的mach_header,只是多了一个reserved保留字段,

/*
 - magic:0xfeedface(32位) 0xfeedfacf(64位),系统内核用来判断是否是mach-o格式
 - cputype:CPU类型,比如ARM
 - cpusubtype:CPU的具体类型,例如arm64、armv7
 - filetype:由于可执行文件、目标文件、静态库和动态库等都是mach-o格式,所以需要filetype来说明mach-o文件是属于哪种文件
 - ncmds:sizeofcmds:LoadCommands加载命令的条数(加载命令紧跟header之后)
 - sizeofcmds:LoadCommands加载命令的大小
 - flags:标志位标识二进制文件支持的功能,主要是和系统加载、链接有关
 - reserved:保留字段
 */
struct mach_header_64 {
    uint32_t    magic;      /* mach magic number identifier */
    cpu_type_t  cputype;    /* cpu specifier */
    cpu_subtype_t   cpusubtype; /* machine specifier */
    uint32_t    filetype;   /* type of file */
    uint32_t    ncmds;      /* number of load commands */
    uint32_t    sizeofcmds; /* the size of all the load commands */
    uint32_t    flags;      /* flags */
    uint32_t    reserved;   /* reserved */
};

其中filetype主要记录Mach-O的文件类型,常用的有以下几种

#define MH_OBJECT   0x1     /* 目标文件*/
#define MH_EXECUTE  0x2     /* 可执行文件*/
#define MH_DYLIB    0x6     /* 动态库*/
#define MH_DYLINKER 0x7     /* 动态链接器*/
#define MH_DSYM     0xa     /* 存储二进制文件符号信息,用于debug分析*/

相对应的,HeaderMachOView中的展示如下

Header展示

Load Commands

在Mach-O文件中,Load Commands主要是用于加载指令,其大小和数目在Header中已经被提供,其在Mach.h中的定义如下

/*
 load_command用于加载指令
 - cmd 加载命令的类型
 - cmdsize 加载命令的大小
 */
struct load_command {
    uint32_t cmd;       /* type of load command */
    uint32_t cmdsize;   /* total size of command in bytes */
};

我们在MachOView中查看Load Commands,其中记录了很多信息,例如动态链接器的位置程序的入口、依赖库的信息、代码的位置、符号表的位置等等,如下所示

Load Commands展示

其中LC_SEGMENT_64的类型segment_command_64定义如下

/*
 segment_command 段加载命令
 - cmd:表示加载命令类型,
 - cmdsize:表示加载命令大小(还包括了紧跟其后的nsects个section的大小)
 - segname:16个字节的段名字
 - vmaddr:段的虚拟内存起始地址
 - vmsize:段的虚拟内存大小
 - fileoff:段在文件中的偏移量
 - filesize:段在文件中的大小
 - maxprot:段页面所需要的最高内存保护(4 = r,2 = w,1 = x)
 - initprot:段页面初始的内存保护
 - nsects:段中section数量
 - flags:其他杂项标志位
 
 - 从fileoff(偏移)处,取filesize字节的二进制数据,放到内存的vmaddr处的vmsize字节。(fileoff处到filesize字节的二进制数据,就是“段”)
 - 每一个段的权限相同(或者说,编译时候,编译器把相同权限的数据放在一起,成为段),其权限根据initprot初始化。initprot指定了如何通过读/写/执行位初始化页面的保护级别
 - 段的保护设置可以动态改变,但是不能超过maxprot中指定的值(在iOS中,+x和+w是互斥的)
 */
struct segment_command_64 { /* for 64-bit architectures */
    uint32_t    cmd;        /* LC_SEGMENT_64 */
    uint32_t    cmdsize;    /* includes sizeof section_64 structs */
    char        segname[16];    /* segment name */
    uint64_t    vmaddr;     /* memory address of this segment */
    uint64_t    vmsize;     /* memory size of this segment */
    uint64_t    fileoff;    /* file offset of this segment */
    uint64_t    filesize;   /* amount to map from the file */
    vm_prot_t   maxprot;    /* maximum VM protection */
    vm_prot_t   initprot;   /* initial VM protection */
    uint32_t    nsects;     /* number of sections in segment */
    uint32_t    flags;      /* flags */
};

Data

Load Commands后就是Data区域,这个区域存储了具体的只读、可读写代码,例如方法、符号表、字符表、代码数据、连接器所需的数据(重定向、符号绑定等)。主要是存储具体的数据。其中大多数的Mach-O文件均包含以下三个段:

Data区中Section占了很大的比例,SectionMach.h中是以结构体section_64(在arm64架构下)表示,其定义如下

/*
 Section节在MachO中集中体现在TEXT和DATA两段里.
 - sectname:当前section的名称
 - segname:section所在的segment名称
 - addr:内存中起始位置
 - size:section大小
 - offset:section的文件偏移
 - align:字节大小对齐
 - reloff:重定位入口的文件偏移
 - nreloc:重定位入口数量
 - flags:标志,section的类型和属性
 - reserved1:保留(用于偏移量或索引)
 - reserved2:保留(用于count或sizeof)
 - reserved3:保留
 */

struct section_64 { /* for 64-bit architectures */
    char        sectname[16];   /* name of this section */
    char        segname[16];    /* segment this section goes in */
    uint64_t    addr;       /* memory address of this section */
    uint64_t    size;       /* size in bytes of this section */
    uint32_t    offset;     /* file offset of this section */
    uint32_t    align;      /* section alignment (power of 2) */
    uint32_t    reloff;     /* file offset of relocation entries */
    uint32_t    nreloc;     /* number of relocation entries */
    uint32_t    flags;      /* flags (section type and attributes)*/
    uint32_t    reserved1;  /* reserved (for offset or index) */
    uint32_t    reserved2;  /* reserved (for count or sizeof) */
    uint32_t    reserved3;  /* reserved */
};
Section展示

其中常见的section,主要有以下一些

section - __TEXT 说明
__TEXT.__text 主程序代码
__TEXT.__cstring C语言字符串
__TEXT.__const const 关键字修饰的常量
__TEXT.__stubs 用于 Stub 的占位代码,很多地方称之为桩代码
__TEXT.__stubs_helper 当 Stub 无法找到真正的符号地址后的最终指向
__TEXT.__objc_methname Objective-C 方法名称
__TEXT.__objc_methtype Objective-C 方法类型
__TEXT.__objc_classname Objective-C 类名称
section - __DATA 说明
__DATA.__data 初始化过的可变数据
__DATA.__la_symbol_ptr lazy binding 的指针表,表中的指针一开始都指向 __stub_helper
__DATA.nl_symbol_ptr 非 lazy binding 的指针表,每个表项中的指针都指向一个在装载过程中,被动态链机器搜索完成的符号
__DATA.__const 没有初始化过的常量
__DATA.__cfstring 程序中使用的 Core Foundation 字符串(CFStringRefs)
__DATA.__bss BSS,存放为初始化的全局变量,即常说的静态内存分配
__DATA.__common 没有初始化过的符号声明
__DATA.__objc_classlist Objective-C 类列表
__DATA.__objc_protolist Objective-C 原型
__DATA.__objc_imginfo Objective-C 镜像信息
__DATA.__objc_selfrefs Objective-C self 引用
__DATA.__objc_protorefs Objective-C 原型引用
__DATA.__objc_superrefs Objective-C 超类引用

所以,综上所述,Mach-O的格式图示,如下所示

Mach-O的格式图示
上一篇下一篇

猜你喜欢

热点阅读