mach-o格式分析

最新推荐文章于 2022-11-18 22:17:02 发布
最新推荐文章于 2022-11-18 22:17:02 发布
阅读量920 收藏
点赞数

0x00 摘要

人生无根蒂，飘如陌上尘。 分散逐风转，此已非常身。

— 陶渊明 《杂诗》

mach-o格式是OS X系统上的可执行文件格式，类似于windows的PE与linux的ELF，如果不彻底搞清楚mach-o的格式与相关知识，去做其他研究，无异于建造空中阁楼。

每个Mach-O文件斗包含一个Mach-O头，然后是载入命令(Load Commands),最后是数据块(Data)。

接下来就对整个Mach-O的格式做出详细的分析。

0x01 Mach-O格式简单介绍

Mach-O文件的格式如下图所示：

又如下几个部分组成：

  • Header：保存了Mach-O的一些基本信息，包括了平台、文件类型、LoadCommands的个数等等。
  • LoadCommands：这一段紧跟Header，加载Mach-O文件时会使用这里的数据来确定内存的分布。
  • Data：每一个segment的具体数据都保存在这里，这里包含了具体的代码、数据等等。

0x02 Headers

2.1 数据结构

Headers的定义可以在开源的内核代码中找到。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

/*
 * The 32-bit mach header appears at the very beginning of the object file for
 * 32-bit architectures.
 */
struct mach_header {
	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 */
};

/* Constant for the magic field of the mach_header (32-bit architectures) */
#define	MH_MAGIC	0xfeedface	/* the mach magic number */
#define MH_CIGAM	0xcefaedfe	/* NXSwapInt(MH_MAGIC) */

/*
 * The 64-bit mach header appears at the very beginning of object files for
 * 64-bit architectures.
 */
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 */
};

/* Constant for the magic field of the mach_header_64 (64-bit architectures) */
#define MH_MAGIC_64 0xfeedfacf /* the 64-bit mach magic number */
#define MH_CIGAM_64 0xcffaedfe /* NXSwapInt(MH_MAGIC_64) */

根据mach_header与mach_header_64的定义，很明显可以看出，Headers的主要作用就是帮助系统迅速的定位Mach-O文件的运行环境，文件类型。

2.2 实例

使用工具分析一个mach-o文件来具体的看一下Mach-O Headers。

通过otool可以得到Mach header的具体的情况，但是可读性略微有一点差。

1
2
3
4
5

➜  bin otool -h git
git:
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
 0xfeedfacf 16777223          3  0x80           2    17       1432 0x00200085

还有一个工具是MachOview可以看的更清楚一点。

  • MagicNumber的值为0xFEEDFACF所以该文件是一个64位平台上的文件
  • CPU Type和CPU SubType也很容易理解，运行在X86_64的CPU平台上
  • File Type标示了该文件是一个可执行文件，后面具体分析
  • Flags标示了这个MachO文件的四个特性，后面具体分析

2.3 具体参数

2.3.1 FileType

因为Mach-O文件不仅仅用来实现可执行文件，同时还用来实现了其他内容

  • 内核扩展
  • 库文件
  • CoreDump
  • …

他的源码定义如下：

1
2
3
4
5
6
7
8
9
10
11
12
13

#define	MH_OBJECT	0x1		/* relocatable object file */
#define	MH_EXECUTE	0x2		/* demand paged executable file */
#define	MH_FVMLIB	0x3		/* fixed VM shared library file */
#define	MH_CORE		0x4		/* core file */
#define	MH_PRELOAD	0x5		/* preloaded executable file */
#define	MH_DYLIB	0x6		/* dynamically bound shared library */
#define	MH_DYLINKER	0x7		/* dynamic link editor */
#define	MH_BUNDLE	0x8		/* dynamically bound bundle file */
#define	MH_DYLIB_STUB	0x9		/* shared library stub for static */
					/*  linking only, no section contents */
#define	MH_DSYM		0xa		/* companion file with only debug */
					/*  sections */
#define	MH_KEXT_BUNDLE	0xb		/* x86_64 kexts */

解释一下一些常用到的文件类型。

File Type 用处 例子
MH_OBJECT 编译过程中产生的*.obj文件 gcc -c xxx.c 生成xxx.o文件
MH_EXECUTABLE 可执行二进制文件 /usr/bin/git
MH_CORE CoreDump 崩溃时的Dump文件
MH_DYLIB 动态库 /usr/lib/里面的那些库文件
MH_DYLINKER 连接器linker /usr/lib/dyld文件
MH_KEXT_BUNDLE 内核扩展文件 自己开发的简单内核模块

2.3.2 flags

Mach-O headers还包含了一些很重要的dyld的加载参数。代码中的定义如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

#define	MH_INCRLINK	0x2		/* the object file is the output of an
					   incremental link against a base file
					   and can't be link edited again */
#define MH_DYLDLINK	0x4		/* the object file is input for the
					   dynamic linker and can't be staticly
					   link edited again */
#define MH_BINDATLOAD	0x8		/* the object file's undefined
					   references are bound by the dynamic
					   linker when loaded. */
#define MH_PREBOUND	0x10		/* the file has its dynamic undefined
					   references prebound. */
#define MH_SPLIT_SEGS	0x20		/* the file has its read-only and
					   read-write segments split */
#define MH_LAZY_INIT	0x40		/* the shared library init routine is
					   to be run lazily via catching memory
					   faults to its writeable segments
					   (obsolete) */
#define MH_TWOLEVEL	0x80		/* the image is using two-level name
					   space bindings */
...
//太长，有兴趣可以自己看源码
// EXTERNAL_HEADERS/mach-o/x86_64/loader.h

同样简单的介绍几个比较重要的。

Flag Type 含义
MH_NOUNDEFS 目标没有未定义的符号，不存在链接依赖
MH_DYLDLINK 该目标文件是dyld的输入文件，无法被再次的静态链接
MH_PIE 允许随机的地址空间
MH_ALLOW_STACK_EXECUTION 栈内存可执行代码，一般是默认关闭的。
MH_NO_HEAP_EXECUTION 堆内存无法执行代码

2.4 Headers小结

0x03 Load Commands

这是load_command的数据结构

1
2
3
4

struct load_command {
	uint32_t cmd;		/* type of load command */
	uint32_t cmdsize;	/* total size of command in bytes */
};

Load Commands 直接就跟在Header后面，所有command占用内存的总和在Mach-O Header里面已经给出了。在加载过Header之后就是通过解析LoadCommand来加载接下来的数据了。我简单的看了一下内核中是如何解析macho数据的，抛开内核的实现细节，逻辑其实也十分简单。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172

static
load_return_t
parse_machfile(
	struct vnode 		*vp,       
	vm_map_t		map,
	thread_t		thread,
	struct mach_header	*header,
	off_t			file_offset,
	off_t			macho_size,
	int			depth,
	int64_t			aslr_offset,
	int64_t			dyld_aslr_offset,
	load_result_t		*result
)
{
	[...] //此处省略大量初始化与检测

		/*
		 * Loop through each of the load_commands indicated by the
		 * Mach-O header; if an absurd value is provided, we just
		 * run off the end of the reserved section by incrementing
		 * the offset too far, so we are implicitly fail-safe.
		 */
		offset = mach_header_sz;
		ncmds = header->ncmds;

		while (ncmds--) {
			/*
			 *	Get a pointer to the command.
			 */
			lcp = (struct load_command *)(addr + offset);
			//lcp设为当前要解析的cmd的地址
			oldoffset = offset;
			//oldoffset是从macho文件内存开始的地方偏移到当前command的偏移量
			offset += lcp->cmdsize;
			//重新计算offset，再加上当前command的长度，offset的值为文件内存起始地址到下一个command的偏移量
			/*
			 * Perform prevalidation of the struct load_command
			 * before we attempt to use its contents.  Invalid
			 * values are ones which result in an overflow, or
			 * which can not possibly be valid commands, or which
			 * straddle or exist past the reserved section at the
			 * start of the image.
			 */
			if (oldoffset > offset ||
			    lcp->cmdsize < sizeof(struct load_command) ||
			    offset > header->sizeofcmds + mach_header_sz) {
				ret = LOAD_BADMACHO;
				break;
			}
			//做了一个检测，与如何加载进入内存无关

			/*
			 * Act on struct load_command's for which kernel
			 * intervention is required.
			 */
			switch(lcp->cmd) {
			case LC_SEGMENT:
				[...]
				ret = load_segment(lcp,
				                   header->filetype,
				                   control,
				                   file_offset,
				                   macho_size,
				                   vp,
				                   map,
				                   slide,
				                   result);
				break;
			case LC_SEGMENT_64:
				[...]
				ret = load_segment(lcp,
				                   header->filetype,
				                   control,
				                   file_offset,
				                   macho_size,
				                   vp,
				                   map,
				                   slide,
				                   result);
				break;
			case LC_UNIXTHREAD:
				if (pass != 1)
					break;
				ret = load_unixthread(
						 (struct thread_command *) lcp,
						 thread,
						 slide,
						 result);
				break;
			case LC_MAIN:
				if (pass != 1)
					break;
				if (depth != 1)
					break;
				ret = load_main(
						 (struct entry_point_command *) lcp,
						 thread,
						 slide,
						 result);
				break;
			case LC_LOAD_DYLINKER:
				if (pass != 3)
					break;
				if ((depth == 1) && (dlp == 0)) {
					dlp = (struct dylinker_command *)lcp;
					dlarchbits = (header->cputype & CPU_ARCH_MASK);
				} else {
					ret = LOAD_FAILURE;
				}
				break;
			case LC_UUID:
				if (pass == 1 && depth == 1) {
					ret = load_uuid((struct uuid_command *) lcp,
							(char *)addr + mach_header_sz + header->sizeofcmds,
							result);
				}
				break;
			case LC_CODE_SIGNATURE:
				[...]
				ret = load_code_signature(
					(struct linkedit_data_command *) lcp,
					vp,
					file_offset,
					macho_size,
					header->cputype,
					result);
				[...]
				break;
#if CONFIG_CODE_DECRYPTION
			case LC_ENCRYPTION_INFO:
			case LC_ENCRYPTION_INFO_64:
				if (pass != 3)
					break;
				ret = set_code_unprotect(
					(struct encryption_info_command *) lcp,
					addr, map, slide, vp, file_offset,
					header->cputype, header->cpusubtype);
				if (ret != LOAD_SUCCESS) {
					printf("proc %d: set_code_unprotect() error %d "
					       "for file \"%s\"\n",
					       p->p_pid, ret, vp->v_name);
					/* 
					 * Don't let the app run if it's 
					 * encrypted but we failed to set up the
					 * decrypter. If the keys are missing it will
					 * return LOAD_DECRYPTFAIL.
					 */
					 if (ret == LOAD_DECRYPTFAIL) {
						/* failed to load due to missing FP keys */
						proc_lock(p);
						p->p_lflag |= P_LTERM_DECRYPTFAIL;
						proc_unlock(p);
					 }
					 psignal(p, SIGKILL);
				}
				break;
#endif
			default:
				/* Other commands are ignored by the kernel */
				ret = LOAD_SUCCESS;
				break;
			}
			if (ret != LOAD_SUCCESS)
				break;
		}
		if (ret != LOAD_SUCCESS)
			break;
	}

	[...] //此处略去加载之后的处理代码
}

3.1cmdsize字段

这里主要看while循环刚刚进入的时候几行代码,来理解是如何通过load_command的cmd字段来解析Macho文件的数据。

1
2
3
4
5
6
7
8

...
lcp = (struct load_command *)(addr + offset);
//lcp设为当前要解析的cmd的地址
oldoffset = offset;
//oldoffset是从macho文件内存开始的地方偏移到当前command的偏移量
offset += lcp->cmdsize;
//重新计算offset，再加上当前command的长度，offset的值为文件内存起始地址到下一个command的偏移量
...

3.2 cmd字段

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107

switch(lcp->cmd) {
			case LC_SEGMENT:
				[...]
				ret = load_segment(lcp,
				                   header->filetype,
				                   control,
				                   file_offset,
				                   macho_size,
				                   vp,
				                   map,
				                   slide,
				                   result);
				break;
			case LC_SEGMENT_64:
				[...]
				ret = load_segment(lcp,
				                   header->filetype,
				                   control,
				                   file_offset,
				                   macho_size,
				                   vp,
				                   map,
				                   slide,
				                   result);
				break;
			case LC_UNIXTHREAD:
				if (pass != 1)
					break;
				ret = load_unixthread(
						 (struct thread_command *) lcp,
						 thread,
						 slide,
						 result);
				break;
			case LC_MAIN:
				if (pass != 1)
					break;
				if (depth != 1)
					break;
				ret = load_main(
						 (struct entry_point_command *) lcp,
						 thread,
						 slide,
						 result);
				break;
			case LC_LOAD_DYLINKER:
				if (pass != 3)
					break;
				if ((depth == 1) && (dlp == 0)) {
					dlp = (struct dylinker_command *)lcp;
					dlarchbits = (header->cputype & CPU_ARCH_MASK);
				} else {
					ret = LOAD_FAILURE;
				}
				break;
			case LC_UUID:
				if (pass == 1 && depth == 1) {
					ret = load_uuid((struct uuid_command *) lcp,
							(char *)addr + mach_header_sz + header->sizeofcmds,
							result);
				}
				break;
			case LC_CODE_SIGNATURE:
				[...]
				ret = load_code_signature(
					(struct linkedit_data_command *) lcp,
					vp,
					file_offset,
					macho_size,
					header->cputype,
					result);
				[...]
				break;
#if CONFIG_CODE_DECRYPTION
			case LC_ENCRYPTION_INFO:
			case LC_ENCRYPTION_INFO_64:
				if (pass != 3)
					break;
				ret = set_code_unprotect(
					(struct encryption_info_command *) lcp,
					addr, map, slide, vp, file_offset,
					header->cputype, header->cpusubtype);
				if (ret != LOAD_SUCCESS) {
					printf("proc %d: set_code_unprotect() error %d "
					       "for file \"%s\"\n",
					       p->p_pid, ret, vp->v_name);
					/* 
					 * Don't let the app run if it's 
					 * encrypted but we failed to set up the
					 * decrypter. If the keys are missing it will
					 * return LOAD_DECRYPTFAIL.
					 */
					 if (ret == LOAD_DECRYPTFAIL) {
						/* failed to load due to missing FP keys */
						proc_lock(p);
						p->p_lflag |= P_LTERM_DECRYPTFAIL;
						proc_unlock(p);
					 }
					 psignal(p, SIGKILL);
				}
				break;
#endif
			default:
				/* Other commands are ignored by the kernel */
				ret = LOAD_SUCCESS;
				break;
			}

从这一段代码可以看出，根据cmd字段的类型不同，使用了不同的函数来加载。简单的列出一张表看一看在内核代码中不同的command类型都有哪些作用。

Command类型 处理函数 用途
LC_SEGMENT；LC_SEGMENT_64 load_segment 将segment中的数据加载并映射到进程的内存空间去
LC_LOAD_DYLINKER load_dylinker 调用/usr/lib/dyld程序
LC_UUID load_uuid 加载128-bit的唯一ID
LC_THREAD load_thread 开启一个MACH线程，但是不分配栈空间。
LC_UNIXTHREAD load_unixthread 开启一个UNIX线程
LC_CODE_SIGNATURE load_code_signature 进行数字签名
LC_ENCRYPTION_INFO set_code_unprotect 加密二进制文件

0x04 Segment&Section

加载数据时，主要加载的就是LC_SEGMET活着LC_SEGMENT_64。其他的Segment的用途在上一节已经简单的介绍了，这里不做深究。

LCSEGMENT以及LC_SEGMENT_64的数据结构是这样的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


struct segment_command { /* for 32-bit architectures */
	uint32_t	cmd;		/* LC_SEGMENT */
	uint32_t	cmdsize;	/* includes sizeof section structs */
	char		segname[16];	/* segment name */
	uint32_t	vmaddr;		/* memory address of this segment */
	uint32_t	vmsize;		/* memory size of this segment */
	uint32_t	fileoff;	/* file offset of this segment */
	uint32_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 */
};


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 */
};

可以看出，这里大部分的数据是用来帮助内核将Segment映射到虚拟内存的。主要要关注的是nsects

字段，标示了Segment中有多少secetion。section是具体有用的数据存放的地方。

Section的数据结构如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

struct section { /* for 32-bit architectures */
	char		sectname[16];	/* name of this section */
	char		segname[16];	/* segment this section goes in */
	uint32_t	addr;		/* memory address of this section */
	uint32_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) */
};

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 */
};

除了同样有帮助内存映射的变量外，在了解Mach-O格式的时候，只需要知道不同的Section有着不同的作用就可以了。

Section 作用
__text 代码
__cstring 硬编码的字符串
__const const 关键词修饰过的变量
__DATA.__bss bss段

因为section类型已经是最小的分类了，还有更多复杂section段就不一一例举了，遇到没见过的section类型可以自行查找Apple文档。

0x05 小结

通过对Mach-O格式的仔细分析，可以更好的理解Mach-O文件的加载过程，为研究dyld或者其他OS X系统下的模块打好基础。

参考

1.mach-o文件加载的全过程(1)

http://dongaxis.github.io/2015/01/01/mac-o%E6%96%87%E4%BB%B6%E5%8A%A0%E8%BD%BD%E7%9A%84%E5%85%A8%E8%BF%87%E7%A8%8B-1/

2.Mach-O 可执行文件

http://objccn.io/issue-6-3/

3.iPhone Mach-O文件格式与代码签名

http://zhiwei.li/text/2012/02/15/iphone-mach-o%E6%96%87%E4%BB%B6%E6%A0%BC%E5%BC%8F%E4%B8%8E%E4%BB%A3%E7%A0%81%E7%AD%BE%E5%90%8D/

4.Dynamic Linking of Imported Functions in Mach-O

http://www.codeproject.com/Articles/187181/Dynamic-Linking-of-Imported-Functions-in-Mach-O

5.otool详解Mach-o文件头部

http://www.mc2lab.com/?p=68

PS:

希望可以多多交流，不足之处还希望大家可以给与指正：）

原文: http://turingh.github.io/2016/03/07/mach-o文件格式分析/　　作者: mrh






1212424684
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Mach-O动态链接的简单分析
05-25
Mach-O文件的通过dyld加载的时候并没有确定每一个函数的具体地址在哪里，而是在真正调用该函数的时候通过过程连接表(procedure linkage table)，后面简称PLT，来进行一次lazybind。 结合Mach-O文件的分析与代码的调试简单的分析一下，只能算是管中窥豹了。
machobot:用于Mach-O文件分析的Python工具箱
05-15
猛男 用于Mach-O文件分析的Python工具箱。 严重依赖macholib 。 安装 用途 $ [sudo] pip install machobot 为了发展 $ pip install nose macholib $ git clone https://github.com/rodionovd/machobot.git machobot $ cd ./machobot $ nosetests # run the test suite 用法 作为命令行工具： $ inject_dylib ./target " @rpath/mylib.dylib " 作为Python模块： import machobot 用法示例： import machobot . dylib as dylib dylib . insert_load_command ( "output.a" , "
iOS逆向技术视频教程
11-05
课时01.初识逆向工程 课时02.iOS系统安全机制 课时03.认识越狱设备 课时04.越狱环境配置 课时05.第一章文档总结 课时06.App结构与构建过程 课时07.寻找控件背后的代码 课时08.数据存储 课时09.类与方法 课时10.runtime特性 课时11.认识Hook 课时12.Hook原理 课时13.ARM汇编(上) 课时14.ARM汇编(下) 课时15.Mach-O文件格式(上) 课时16.Mach-O文件格式(下) 课时17.App签名 课时18.动态库 课时19.第二章文档总结 课时20.应用砸壳 课时21.class-dump 课时22.Reveal 课时23.Cycript 课时24.网络抓包 课时25.静态分析 课时26.动态调试 课时27.theos(上) 课时28.theos(下) 课时29.第三章文档总结 课时30.去除OPlayer.Lite的广告(上) 课时31.去除OPlayer.Lite的广告(下) 课时32.分析WhatsApp聊天(上) 课时33.分析WhatsApp聊天(下) 课时34.Snapchat消息收发(上) 课时35.Snapchat消息收发(下) 课时36.迁移到非越狱机器 课时37.FrIDA在逆向中的应用(上) 课时38.Frida在逆向中的应用(中) 课时39.Frida在逆向中的应用(下) 课时40.代码保护基础 课时41.数据加密 课时42.反调试和反注入(上) 课时43.反调试和反注入(下) 课时44.代码混淆(上) 课时45.代码混淆(下)
MachOview查看Mach-O文件结构.zip
01-28
MachOview用于查看Mach-O文件结构的界面工具。感兴趣的朋友可以下载下来玩一玩，学习学习。
MachOTool:用于分析和分析Mach-O二进制文件的便携式工具
04-29
介绍 Mach-O工具旨在成为分析Mach-O二进制文件的便携式工具。 它完全用Python编写，并且可以与任何标准Python 2.7安装一起使用，而无需其他软件包。 （GUI部分要求使用Tkinter，它应该是大多数平台中的标准软件包。） 它包含3个组件： Mach-O解析库。 初始版本支持对大多数常见字段/标头的解析。 长期目标是解析所有记录的字段/标头。 该库可用于构建其他Mach-O操作工具。 一个非常类似于otool，dyldinfo和nm的命令行工具。 它还具有交互模式。 用于交互式二进制分析的GUI工具。 命令行模式 要查看可用选项，只需执行：./machotool.py -h 用法：machotool.py [-h] [-i | -g] [-v] [-c] [-f] [-l] [-m] [-R] [-L] [-共享库表] [文件] .... 其中一些参数与o
iOS逆向与安全 - 5. Mach-O文件格式
NULLGIRL
03-23 1737
前言 Mach-O文件格式源码 Mach-O苹果官方手册 想要程序跑起来，那么这个可执行文件的格式就需要被当前的操作系统所理解，比如： Linux 操作系统下可执行文件格式是 ELF Windows 的可执行文件格式是 PE32/PE32+ Android 的可执行文件格式是 ELF OSX 和 iOS 的可执行文件格式是 Mach-O 准备工具 ...
【IOS实用玩机技巧】爱思助手 IPA 签名功能常见问题汇总（iOS上架）
热门推荐
不写代码没饭吃的博客
09-14 1万+
使用 Apple ID 签名 IPA 文件也就是常说的“个人签”，很多小伙伴在使用Apple ID签名时，有时候会出现证书申请失败，或者签名失败，这类报错信息。使用 Apple ID 签名的应用和设备标识绑定，签名时如果选择的是 A 设备的设备标识，就无法将签名后的 IPA 文件安装到 B 设备上。或者这种提示：get +teams+err+1100+Your+session+has+expired.+Please+log+in.原因一：该 IPA 文件签名使用的设备标识和当前安装的设备不一致。
iPhone Mach-O文件格式与代码签名
sharemyfree的专栏
03-03 2044
错误现象 1） 直接运行 /Applications/MobileFonex.app/MobileFonex Killed: 9 2）gdb调试 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 50 at address: 0×00043030 背景知识 所有的可执行文件，
[iOS]分析Mach-O文件
Gamin
11-18 2584
Mach-O为Mach Object文件格式的缩写，它是一种用于可执行文件，目标代码，动态库，内核转储的文件格式。 每个Mach-O文件包括一个Mach-O头，然后是一系列的载入命令，再是一个或多个块，每个块包括0到255个段。
strongarm:Mach-O分析库:flexed_biceps:
05-05
strongarm是功能齐全的跨平台ARM64 Mach-O分析库。 strongarm可以投入生产，并且可以在DataTheorem的iOS静态分析器堆栈中使用。 此存储库包含多种工具，可用于研究Strongarm和API。 在scripts文件夹中，一些强大...
Mach-O_File_Format
04-25
逆向 machO文件详细解析，对逆向开发 分析macho文件很有帮助
Mach-O文件格式分析
weixin_34402090的博客
06-16 484
最近用纯Swift参照非常知名的Aspects写了个Aspect，是基于Runtime进行方法交换，正好之前听说过可以通过fishhook动态修改 C 语言函数，所有就研究了一下，但是要想看懂fishhook，需要先了解Mach-O，这一块一直是我的知识盲点，这一次索性花些时间一并消化一下。苹果源码查看这里。 Mach-O简介 Mach-O，是Mach object文件格式的缩写，是一种可执行文...
python源码剖析读书笔记总结_GitHub - ESdove/interview: C/C++ 技术面试基础知识总结，包括语言、程序库、数据结构、算法、系统、网络、链接装载库等知识及面试经验、招...
weixin_39640008的博客
12-01 806
???? Github|???? Docsify简体中文|English???? 关于???? 本仓库是面向 C/C++ 技术方向校招求职者、初学者的基础知识总结，包括语言、程序库、数据结构、算法、系统、网络、链接装载库等知识及面试经验、招聘、内推等信息。???? 保存为 PDF 方式：使用 Chrome 浏览器打开 ???? Docsify 文档 页面，缩起左侧目录-右键 - 打印 - 选择目标打印机是另存为PDF - 保存(打印...
【2018年最新】 iOS面试题及答案
weixin_33775582的博客
09-05 523
设计模式是什么？ 你知道哪些设计模式，并简要叙述？ 设计模式是一种编码经验，就是用比较成熟的逻辑去处理某一种类型的事情。 1). MVC模式：Model View Control，把模型 视图 控制器 层进行解耦合编写。 2). MVVM模式：Model View ViewModel 把模型 视图 业务逻...
Python入门day11之文件
程序彤的博客
09-27 956
文件 打开文件 open(‘根目录 用双\’,‘打开模式’) r:只读方式 w:写入文件，覆盖已有内容 x:若文件存在，文件引发异常，若文件不存在，则创建新文件 b:以二进制模式打开文件 t:以文本模式打开文件（默认） +：可读写模式，如果使用r+，可对文件进行继续不覆盖写入；如果使用w+，则会清空文件中所有内容，须重新写入 f = open('D:\\学习\\python学习\\code\\day13\\file.txt','r+') f = open('D:\\学习\\python学习\\code\\d
趣探 Mach-O：文件格式分析
ssyyjj88的专栏
06-01 484
本文所读的源码，可以从这里找到，这是 Mach-O 系列的第一篇 我们的程序想要跑起来，肯定它的可执行文件格式要被操作系统所理解，比如 ELF 是 Linux下可执行文件的格式，PE32／PE32+是windows的可执行文件的格式，那么对于OS X和iOS 来说 Mach-O 是其可执行文件的格式。 我们平时了解到的可执行文件、库文件、Dsym文件、动态库、动态连接器都是这种
iOS系统分析（二）Mach-O二进制文件解析
weixin_34392906的博客
11-15 310
原文出自【听云技术博客】：http://blog.tingyun.com/web/a... 0x01 Mach-O格式简单介绍 Mach-O文件格式是 OS X 与 iOS 系统上的可执行文件格式，类似于windows的 PE 文件 与 Linux（其他 Unix like）的 ELF 文件，如果不彻底搞清楚Mach-O的格式与相关内容...
jedis示例代码压缩包
最新发布
04-23
jedis示例代码
hopper-4.0.8
08-25
Hopper-4.0.8是一款基于反编译原理的二进制文件修改工具。它提供了一种方便且功能强大的方式来分析、编辑和修改二进制文件。Hopper-4.0.8具有直观的用户界面，使用户能够轻松地浏览和编辑二进制代码。 Hopper-4.0.8支持多种二进制文件格式，包括Mach-O、ELF、PE和DEX等。它可以用于分析和修改各种应用程序、游戏、驱动程序和系统组件等二进制文件。 通过Hopper-4.0.8，用户可以查看和编辑二进制文件中的代码、变量、函数、类和数据结构等信息。它提供了反编译功能，可以将二进制代码转换为类似于高级语言的形式，以便更好地理解和修改代码。 此外，Hopper-4.0.8还提供了调试功能，可以用于单步执行代码、查看寄存器值和内存状态等。它还支持插件和脚本编写，用户可以根据自己的需求扩展和定制工具的功能。 总而言之，Hopper-4.0.8是一款功能强大的反编译工具，可用于分析、编辑和修改二进制文件。它提供了直观的用户界面，支持多种二进制文件格式，并具有反编译、调试和扩展功能。无论是研究代码结构、调试漏洞还是修改程序行为，Hopper-4.0.8都是一个很好的选择。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值