了解iOS上的可执行文件和Mach-O格式

>>>  創業先鋒 眾人拾柴火焰高  >>> 簡體     傳統


很多朋友都知道,在Windows上exe是可直接执行的文件扩展名,而在Linux(以及很多版本的Unix)系统上ELF是可直接执行的文件格式,那么在苹果的操作系统上又是怎样的呢?在iOS(和Mac OS X)上,主要的可执行文件格式是Mach-O格式。本文就关于iOS上的可执行文件和Mach-O格式做一个简要整理。


Mach-O格式是iOS系统上应用程序运行的基础,了解Mach-O的格式,对于调试、自动化测试、安全都有意义。在了解二进制文件的数据结构以后,一切就都显得没有秘密。


0Mach与Mach-O



这里先提醒大家一下,Mach不是Mac,Mac是苹果电脑Macintosh的简称,而Mach则是一种操作系统内核。Mach内核被NeXT公司的NeXTSTEP操作系统使用。在Mach上,一种可执行的文件格是就是Mach-O(Mach Object file format)。1996年,乔布斯将NeXTSTEP带回苹果,成为了OS X的内核基础。所以虽然Mac OS X是Unix的“后代”,但所主要支持的可执行文件格式是Mach-O。


iOS是从OS X演变而来,所以同样是支持Mach-O格式的可执行文件。


1iOS可执行文件初探



作为iOS客户端开发者,我们比较熟悉的一种文件是ipa包(iPhone Application)。但实际上这只是一个变相的zip压缩包,我们可以把一个ipa文件直接通过unzip命令解压。


解压之后,会有一个Payload目录,而Payload里则是一个.app文件,而这个实际上又是一个目录,或者说是一个完整的App Bundle。


在这个目录中,里面体积最大的文件通常就是和ipa包同名的一个二进制文件。找到它,我们用file命令来看一下这个文件的类型:


XXX: Mach-O universal binary with 2 architectures

XXX (for architecture armv7): Mach-O executable arm

XXX (for architecture armv7s): Mach-O executable arm


由此看来,这是一个支持armv7和armv7s两种处理器架构的通用程序包,里面包含的两部分都是Mach-O格式。


对于一个二进制文件来讲,每个类型都可以在文件最初几个字节来标识出来,即“魔数”。比如PNG图片的最初几个字节是\211 P N G \r \n \032 \n (89 50 4E 47 0D 0A 1A 0A)。我们再来看下这个Mach-O universal binary的:


0000000 ca fe ba be 00 00 00 02 00 00 00 0c 00 00 00 09


没错,开始的4个字节是cafe babe,即“Cafe baby”。了解Java或者说class文件格式的同学可能会很熟悉,这也是.class文件开头的“魔数”,但貌似是Mach-O在更早的时候就是用了它。在OS X上,可执行文件的标识有这样几个魔数(也就是文件格式):


cafebabe


feedface


feadfacf


还有一个格式,就是以#!开头的脚本


cafebabe就是跨处理器架构的通用格式,feedface和feedfacf则分别是某一处理器架构下的Mach-O格式,脚本的就很常见了,比如#!/bin/bash开头的shell脚本。


这里注意一点是,feedface和cafebabe的字节顺序不同,我们可以用lipo把上面cafebabe的文件拆出armv7架构的,看一下开头的几个字节:


0000000 ce fa ed fe 0c 00 00 00 09 00 00 00 02 00 00 00


2Mach-O格式



接下来我们再来看看这个Mach-O格式到底是什么样的格式。我们可以通过二进制查看工具查看这个文件的数据,结果发现,不是所有数据都是相连的,而是被分成了几个段落。


在一位叫做JOE SAVAGE的老兄发布的图片上来看,Mach-O的文件数据显现出来是这个样子的:



大家可以对数据的分布感受下。


虽然被五颜六色的标记出来,可能这还不是特别直接。再来引用苹果官方文档的示意图:



从这张图上来看,Mach-O文件的数据主体可分为三大部分,分别是头部(Header)、加载命令(Load commands)、和最终的数据(Data)。


回过头来,我们再看上面那张图,也许就都明白了。黄色部分是头部、红色是加载命令、而其它部分则是被分割成Segments的数据。


3Mach-O头部



这里,我们用otool来看下Mach-O的头部信息,得到:


magic cputype cpusubtype  caps    filetype ncmds sizeofcmds    flags

0xfeedface      12          9  0x00          2    45       4788 0x00218085


更详细的,我们可以通过otool的V参数得到翻译版:


Mach header

magic cputype cpusubtype  caps    filetype ncmds sizeofcmds   flags

MH_MAGIC ARM   V7  0x00     EXECUTE    45       4788   NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK PIE


前面几个字段的意义,上下对比就能看懂,我这里主要说下这样几个字段:


filetype,这个可以有很多类型,静态库(.a)、单个目标文件(.o)都可以通过这个类型标识来区分。


ncmdssizeofcmds,这个cmd就是加载命令,ncmds就是加载命令的个数,而sizeofcmds就是所占的大小。


flags里包含的标记很多,比如TWOLEVEL是指符号都是两级格式的,符号自身+加上自己所在的单元,PIE标识是位置无关的。


4加载命令



上面头部中的数据已经说明了整个Mach-O文件的基本信息,但整个Mach-O中最重要的还要数加载命令。它说明了操作系统应当如何加载文件中的数据,对系统内核加载器和动态链接器起指导作用。一来它描述了文件中数据的具体组织结构,二来它也说明了进程启动后,对应的内存空间结构是如何组织的。


我们可以用otool -l xxx来看一个Mach-O文件的加载命令:


Load command 0

     cmd LC_SEGMENT

 cmdsize 56

 segname __PAGEZERO

  vmaddr 0x00000000

  vmsize 0x00004000

 fileoff 0

filesize 0

 maxprot ---

initprot ---

  nsects 0

   flags (none)

Load command 1

     cmd LC_SEGMENT

 cmdsize 736

 segname __TEXT

  vmaddr 0x00004000

  vmsize 0x00390000

 fileoff 0

filesize 3735552

 maxprot r-x

initprot r-x

  nsects 10

   flags (none)

Section

 sectname __text

  segname __TEXT

     addr 0x0000b0d0

     size 0x0030e7f4


上面这段是执行结果的一部分,是加载PAGE_ZERO和TEXT两个segment的load command。PAGE_ZERO是一段“空白”数据区,这段数据没有任何读写运行权限,方便捕捉总线错误(SIGBUS)。TEXT则是主体代码段,我们注意到其中的r-x,不包含w写权限,这是为了避免代码逻辑被肆意篡改。


我再提一个加载命令,LC_MAIN。这个加载指令,会声明整个程序的入口地址,保证进程启动后能够正常的开始整个应用程序的运行。


除此之外,Mach-O里还有LC_SYMTAB、LC_LOAD_DYLIB、LC_CODE_SIGNATURE等加载命令,大家可以去官方文档查找其含义。


至于Data部分,在了解了头部和加载命令后,就没什么特别可说的了。Data是最原始的编译数据,里面包含了Objective-C的类信息、常量等。


本文是对Mach-O文件格式的一个理解小结,希望能够抛砖引玉,帮助各位朋友把握可执行文件的主题脉络,进而解决各类问题。


(来源:三·石道)



CocoaChina 2015-08-23 08:44:21

[新一篇] 現實版吃豆人游戲 拿著手機奔跑吧!否則就被……

[舊一篇] 《暗黑黎明》新手成長分析:新手流程和玩法元素
回頂部
寫評論


評論集


暫無評論。

稱謂:

内容:

驗證:


返回列表