学习笔记: Mach-O 文件

Mach-O入门理解 背景   工作以来代码中涉及Mach-o文件的操作和理解内容较多,一直也没有做一个比较全面的学习,今天先简单整理一下相关的内容,step by step,冲鸭! What Why How 阅读详情

“结构决定性质,性质决定用途”。如果不了解结构,是很难真正理解的。

通过一个示例的可执行文件了解Mach-O文件的结构

Mach-O基本结构

  1. Header: :文件类型、目标架构类型等
  2. Load Commands:描述文件在虚拟内存中的逻辑结构、布局
  3. Data: 在Load commands中定义的Segment的数据

2025-04-17 14.57.00.png

Header

2025-04-17 14.59.03.png

Header的结构定义在loader.h

/*
 * The 64-bit mach header appears at the very beginning of object files for
 * 64-bit architectures.
 */
struct mach_header_64 {
    // 魔数:64位的mach-o有两个取值
    // #define MH_MAGIC_64 0xfeedfacf -- 小端:Intel
    // #define MH_CIGAM_64 0xcffaedfe -- 大端:以前macOS在PowerPC安装
    uint32_t	magic;		/* mach magic number identifier */
    // cpu类型
    // 在machine.h中定义
    // 例子中的显示的cpu的Value是:CPU_TYPE_ARM,根据下面的定义 0x0000000C | 0x01000000 = 0x0100000C
    // #define CPU_ARCH_ABI64          0x01000000      /* 64 bit ABI */
    // #define CPU_TYPE_ARM            ((cpu_type_t) 12)
    // #define CPU_TYPE_ARM64 (CPU_TYPE_ARM | CPU_ARCH_ABI64)
    int32_t		cputype;	/* cpu specifier */
    /*
     *  ARM64 subtypes
     *  ARM64的具体类型
     *  例子中的显示的值是0,即CPU_SUBTYPE_ARM64_ALL
     */
    // #define CPU_SUBTYPE_ARM64_ALL           ((cpu_subtype_t) 0)
    // #define CPU_SUBTYPE_ARM64_V8            ((cpu_subtype_t) 1)
    // #define CPU_SUBTYPE_ARM64E              ((cpu_subtype_t) 2)
    int32_t		cpusubtype;	/* machine specifier */
    // 文件类型
    /**
     * #define	MH_OBJECT	0x1 -- .o文件,.a是.o的合集
     * #define	MH_EXECUTE	0x2 -- 可执行文件
     * #define	MH_DYLIB	0x6 -- 动态库
     * #define	MH_DYLINKER	0x7 -- dyld链接器
     * #define	MH_DSYM		0xa -- 符号表文件
     */
    // 例子中的是2,即MH_EXECUTE,可执行文件
    uint32_t	filetype;	/* type of file */
    // Load Commands加载命令的条数
    // 例子中是23条
    uint32_t	ncmds;		/* number of load commands */
    // Load Commands部分的长度
    // 例子中是2864byte
    uint32_t	sizeofcmds;	/* the size of all the load commands */
    // mach-o的标志,通过位移枚举定义
    // 例子中的
    /**
     * #define	 MH_NOUNDEFS	0x1 -- 没有未定义的引用
     * #define MH_DYLDLINK	0x4 -- 已经静态链接过了,可以动态链接
     * #define MH_TWOLEVEL	0x8 -- 链接时:库名 + 函数减少同名冲突 见参考一
     * #define	MH_PIE 0x200000 -- 每次加载主程序在一个随机地址,增加安全
     */
    uint32_t	flags;		/* flags */
    // 保留
    uint32_t	reserved;	/* reserved */
};

Load Commands

每个Load Commands都有对应的结构体

LC_SEGMENT_64

/*
 * The 64-bit segment load command indicates that a part of this file is to be
 * mapped into a 64-bit task's address space.  If the 64-bit segment has
 * sections then section_64 structures directly follow the 64-bit segment
 * command and their size is reflected in cmdsize.
 */
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 */
	int32_t  maxprot;	/* maximum VM protection */
	int32_t	initprot;	/* initial VM protection */
	uint32_t	nsects;		/* number of sections in segment */
	uint32_t	flags;		/* flags */
};

使用segment_command_64结构体的segment

Segment: __PAGEZERO

__PAGEZERO用于捕捉NULL指针引用

2025-04-18 13.29.35.png

#define LC_SEGMENT_64 0x19 // 即64位的segment

// vm_prot.h
typedef int             vm_prot_t;

#define VM_PROT_NONE    ((vm_prot_t) 0x00)

// 读/写/执行
#define VM_PROT_READ    ((vm_prot_t) 0x01)      /* read permission */
#define VM_PROT_WRITE   ((vm_prot_t) 0x02)      /* write permission */
#define VM_PROT_EXECUTE ((vm_prot_t) 0x04)      /* execute permission */
...

变量名值说明
cmd0x19segment的类型
cmdsize0x48segment的长度, 这里是0x48 = 0x000000068 - 0x00000020
segname0x5F5F504147455A45524F000000000000segment的名,这里是__PAGEZERO, ASCII表示:5F = ‘_’,50 = ‘P’,41 = ‘A’…,4F = ‘O’
vmaddr0segment在虚拟内存的起始地址,8个字节uint64_t
vmsize0x0000000100000000segment的长度,2^32 = 4GB,即64位的虚拟内存的前4G都是__PAGEZERO
fileoff0文件的偏移量,从磁盘的角度看
filesize0占用文件的大小,这是磁盘的角度看,实际未占用磁盘大小
maxprot0虚拟内存的最高的权限设置,未设置,即不能读,不能写,也不能被加载到cpu中执行
initprot0初始化时的虚拟内存的权限设置,未设置
nsects0segment中包含的section的数量,这里为0个
flags0标志,没有
Segment: __TEXT 代码

__TEXT用于描述代码segment的一些信息

2025-04-18 13.59.07.png

也是segment_command_64结构体,可以看到这个segment中的initprot中是有VM_PROT_EXECUTE,声明这部分是可以被执行的。segment中9个sections

Section: __text

每个section的结构体如下

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

2025-04-18 14.12.42.png

#define	S_REGULAR		0x0	/* regular section */
#define S_ATTR_PURE_INSTRUCTIONS 0x80000000 // 这个sections只包含机器指令
#define S_ATTR_SOME_INSTRUCTIONS 0x00000400	/* section contains some
						   machine instructions */
变量名值说明
sectname0x5F5F7465787400000000000000000000section的名称,__text
segname0x5F5F5445585400000000000000000000section所属segment的名称,__TEXT
addr0x0000000100005F04虚拟内存的起始地址
size0x0000000000000564section的长度
offset0x5F04代码在文件的具体偏移量,每个应用都不一样
align4对齐
reloff0静态链接重定位,.a文件中__objc_const能看到
nreloc0静态链接重定位的符号的数量
flags0x80000400标志,详见loader.h
reserved1保留,动态链接时的符号
reserved2保留,动态链接时的符号数量
reserved3保留

2025-04-18 14.29.09.png

然后因为__PAGEZERO占用了0x0000000100000000 加上前面文件占用了空间,所以应用的汇编代码的起始位置在0x5F04位置,从上面的截图看确实如此

Section: __stubs

动态链接的符号,看reserved2有12个,这部分在二进制中的地址是0x0000000100006468

2025-04-18 15.19.43.png

到0x0000000100006468查看

2025-04-18 15.21.09.png

这里存放的是运行时需要从系统和其他动态库中加载的符号

Section: __stub_helper

加载动态库有rebinding符号的过程,比如上面__stub的需要12个外部的符号,__stub_helper是辅助该过程能顺利完成

Section: __objc_stubs

__objc_stubs is a section in iOS binaries that contains stub functions for Objective-C calls. These stubs are used for debugging and analyzing Objective-C code

iOS Apps compiled with recent versions of XCode can generate stubs for msgSend calls, where each stub is just a call to the actual msgSend address after setting a specific selector:

应该是个高版本SDK跳过消息查找过程,加快方法调用的优化,后面再探究。

Section: __objc_methods

OC方法的信息

#define	S_CSTRING_LITERALS	0x2	/* section with only literal C strings*/ // sections里只有C语言的常量字符串

2025-04-18 15.58.12.png

Section:__objc_classname

OC的类名相关的描述,和__objc_methods差不多

Section:__objc_methtype

OC的方法签名部分的描述

找到Data部分实际存的内容

2025-04-19 16.25.52.png

Section: __cstring

C的常量字符串的描述

Section: __unwind_info

用于存储处理异常情况的信息

Segment: __DATA 数据

对数据部分的组织规则的描述,这部分也有一些sections

Section: __got

非懒加载指针,dyld 加载时会立即绑定表项中的符号

2025-04-18 17.39.32.png

dyld_stub_binder 负责绑定符号,objc_msgSend消息发送,这两个懒加载没有意义

Seciton: __la_symbol_ptr

相对的是懒加载指针,表中的指针一开始都指向 __TEXT.__stub_helper

Section: __cfstring

Core Foundation 字符串

Section: __objc_classlist

记录了App中所有的class,包括meta class。该节中存储的是一个个的指针,指针指向的地址是class结构体所在的地址

2025-04-18 20.40.30.png

这里Address是0x100008090,去掉前面的0x100000000(__PAGEZERO),找0x8090的地址

2025-04-18 20.41.38.png

里面的值是0x00000001000091A0,描述是指针,再去找0x91A0,走到__DATA.__objc_data,这里存着实际的OC的类

2025-04-18 20.49.16.png

Section: __objc_protolist

2025-04-18 21.00.38.png

0x1000080A8 => 0x0000000100009298,到了 __DATA.__data?

2025-04-18 21.00.48.png

2025-04-18 21.03.23.png

Section: __objc_imageInfo

主要用来区分OC的版本是 1.0 还是 2.0

Section: __objc_const

记录在OC内存初始化过程中的不可变内容,比如 method_t 结构体定义

Section: __objc_selrefs

标记哪些SEL对应的字符串被引用了

Section: __objc_classrefs

标记哪些类被引用了

Section: __objc_superrefs

Objective-C 超类引用

Section: __objc_ivar

存储程序中的 ivar 变量

Section: __objc_data

用于保存 OC 类需要的数据。最主要的内容是映射 __objc_const 地址,用于找到类的相关数据

Section: __data

初始化过的可变数据

Segment: __LINKEDIT16.23.03

fileOffset是 0xc000,size是0x7850,两者相加得 0x13850,从下图可知Dynamic Loader Info 到Code Signature都是这个区间内,里面包含动态库加载哪些符号,符号表,二进制的签名信息。所以可执行文件的加载指令后的实际内容就是__TEXT,__DATA,__LINKEDIT,__PAGEZERO是占位

# 用size命令显示macho文件时就是4个段
$ size -x -m path/to/macho-execute

2025-04-18 18.24.32.png

2025-04-18 16.26.29.png

2025-04-18 16.28.03.png

使用其他结构体的Command

Command:LC_DYLD_INFO_ONLY

描述dyld要绑定动态库的哪些符号,是强绑定还是弱绑定

/*
 * The dyld_info_command contains the file offsets and sizes of 
 * the new compressed form of the information dyld needs to 
 * load the image.  This information is used by dyld on Mac OS X
 * 10.6 and later.  All information pointed to by this command
 * is encoded using byte streams, so no endian swapping is needed
 * to interpret it. 
 */
struct dyld_info_command {
    uint32_t   cmd;		/* LC_DYLD_INFO or LC_DYLD_INFO_ONLY */
    uint32_t   cmdsize;		/* sizeof(struct dyld_info_command) */
    uint32_t   rebase_off;	/* file offset to rebase info  */
    uint32_t   rebase_size;	/* size of rebase info   */
    uint32_t   bind_off;	/* file offset to binding info   */
    uint32_t   bind_size;	/* size of binding info  */
    uint32_t   weak_bind_off;
    uint32_t   weak_bind_size;  /* size of weak binding info  */
    uint32_t   lazy_bind_off;
    uint32_t   lazy_bind_size;  /* size of lazy binding infs */
    uint32_t   export_off;	/* file offset to lazy binding info */
    uint32_t   export_size;	/* size of lazy binding infs */
};
Command: LC_SYMTAB

macho文件的符号表的描述

/*
 * The symtab_command contains the offsets and sizes of the link-edit 4.3BSD
 * "stab" style symbol table information as described in the header files
 * <nlist.h> and <stab.h>.
 */
struct symtab_command {
	uint32_t	cmd;		/* LC_SYMTAB */
	uint32_t	cmdsize;	/* sizeof(struct symtab_command) */
	uint32_t	symoff;		/* symbol table offset */
	uint32_t	nsyms;		/* number of symbol table entries */
	uint32_t	stroff;		/* string table offset */
	uint32_t	strsize;	/* string table size in bytes */
};
Command: LC_DYSYMTAB

macho文件依赖的动态库的符号表

Command: LC_LOAD_DYLINKER

加载dyld链接器

/*
 * A program that uses a dynamic linker contains a dylinker_command to identify
 * the name of the dynamic linker (LC_LOAD_DYLINKER).  And a dynamic linker
 * contains a dylinker_command to identify the dynamic linker (LC_ID_DYLINKER).
 * A file can have at most one of these.
 * This struct is also used for the LC_DYLD_ENVIRONMENT load command and
 * contains string for dyld to treat like environment variable.
 */
struct dylinker_command {
	uint32_t	cmd;		/* LC_ID_DYLINKER, LC_LOAD_DYLINKER or
					   LC_DYLD_ENVIRONMENT */
	uint32_t	cmdsize;	/* includes pathname string */
	union lc_str    name;		/* dynamic linker's path name */
};

2025-04-18 16.41.23.png

Command: LC_UUID

静态连接器生成的128位随机数,用于标识macho文件

/*
 * The uuid load command contains a single 128-bit unique random number that
 * identifies an object produced by the static link editor.
 */
struct uuid_command {
    uint32_t	cmd;		/* LC_UUID */
    uint32_t	cmdsize;	/* sizeof(struct uuid_command) */
    uint8_t	uuid[16];	/* the 128-bit uuid */
};
Command: LC_VERSION_MIN_IPHONEOS

指定最低版本号

/*
 * The version_min_command contains the min OS version on which this 
 * binary was built to run.
 */
struct version_min_command {
    uint32_t	cmd;		/* LC_VERSION_MIN_MACOSX or
				   LC_VERSION_MIN_IPHONEOS or
				   LC_VERSION_MIN_WATCHOS or
				   LC_VERSION_MIN_TVOS */
    uint32_t	cmdsize;	/* sizeof(struct min_version_command) */
    uint32_t	version;	/* X.Y.Z is encoded in nibbles xxxx.yy.zz */
    uint32_t	sdk;		/* X.Y.Z is encoded in nibbles xxxx.yy.zz */
};
Command: LC_SOURCE_VERSION

指定iOS SDK系统库的版本

/*
 * The source_version_command is an optional load command containing
 * the version of the sources used to build the binary.
 */
struct source_version_command {
    uint32_t  cmd;	/* LC_SOURCE_VERSION */
    uint32_t  cmdsize;	/* 16 */
    uint64_t  version;	/* A.B.C.D.E packed as a24.b10.c10.d10.e10 */
};
Command: LC_MAIN

应用程序入口

/*
 * The entry_point_command is a replacement for thread_command.
 * It is used for main executables to specify the location (file offset)
 * of main().  If -stack_size was used at link time, the stacksize
 * field will contain the stack size need for the main thread.
 */
struct entry_point_command {
    uint32_t  cmd;	/* LC_MAIN only used in MH_EXECUTE filetypes */
    uint32_t  cmdsize;	/* 24 */
    uint64_t  entryoff;	/* file (__TEXT) offset of main() */
    uint64_t  stacksize;/* if not zero, initial stack size */
};

2025-04-18 16.52.55.png

地址是 0x6120,找到对应地址可知就是 _main函数的地址

2025-04-18 16.53.19.png

Command: LC_ENCRYPTION_INFO_64
/*
 * The encryption_info_command contains the file offset and size of an
 * of an encrypted segment.
 */
struct encryption_info_command {
   uint32_t	cmd;		/* LC_ENCRYPTION_INFO */
   uint32_t	cmdsize;	/* sizeof(struct encryption_info_command) */
   uint32_t	cryptoff;	/* file offset of encrypted range */
   uint32_t	cryptsize;	/* file size of encrypted range */
   uint32_t	cryptid;	/* which enryption system,
				   0 means not-encrypted yet */
};

加密部分是Crypt Offset:0x4000 , Crypt Size: 0x4000,两者相加末尾地址为0x8000,根据下图看,实际加密的部分是代码Segment的内容

2025-04-18 17.11.15.png

2025-04-18 17.11.34.png

Command: LC_LOAD_DYLIB

有若干个该命令,用于加载系统及应用链接的动态库

/*
 * Dynamicly linked shared libraries are identified by two things.  The
 * pathname (the name of the library as found for execution), and the
 * compatibility version number.  The pathname must match and the compatibility
 * number in the user of the library must be greater than or equal to the
 * library being used.  The time stamp is used to record the time a library was
 * built and copied into user so it can be use to determined if the library used
 * at runtime is exactly the same as used to built the program.
 */
struct dylib {
    union lc_str  name;			/* library's path name */
    uint32_t timestamp;			/* library's build time stamp */
    uint32_t current_version;		/* library's current version number */
    uint32_t compatibility_version;	/* library's compatibility vers number*/
};

/*
 * A dynamically linked shared library (filetype == MH_DYLIB in the mach header)
 * contains a dylib_command (cmd == LC_ID_DYLIB) to identify the library.
 * An object that uses a dynamically linked shared library also contains a
 * dylib_command (cmd == LC_LOAD_DYLIB, LC_LOAD_WEAK_DYLIB, or
 * LC_REEXPORT_DYLIB) for each library it uses.
 */
struct dylib_command {
	uint32_t	cmd;		/* LC_ID_DYLIB, LC_LOAD_{,WEAK_}DYLIB,
					   LC_REEXPORT_DYLIB */
	uint32_t	cmdsize;	/* includes pathname string */
	struct dylib	dylib;		/* the library identification */
};

2025-04-18 17.17.48.png

name字段指明加载路径

Command: LC_RPATH

前面动态库name里有@rpath变量的描述,@rpath的值在这里指定

Command: LC_FUNCTION_STARTS

该命令用于描述函数的起始地址信息,指向了链接信息段中 Function Starts 的首地址 Function Starts 定义了一个函数起始地址表,调试器和其他程序通过该表可以很容易地判断出一个地址是否在函数内

Command: LC_DATA_IN_CODE

该命令使用一个 struct linkedit_data_command 指向一个 data_in_code_entry 数组 data_in_code_entry 数组中的每一个元素,用于描述代码段中一个存储数据的区域

Command: LC_CODE_SIGATURE

签名信息的描述,从这里可知,二进制文件的签名是在文件内

Data

Load Commands部分是在描述MachO文件如何组织。比如代码部分的长度是多少,这种很像C语言操作数组时要传长度。如果再扩展一下概念,网络协议通过各种包的格式控制数据的传输,那前面这些命令也是在控制如何解析后面的Data。

参考

  1. MacOS 链接特性:Two-Level Namespace
  2. ghidra-issues
  3. MachO文件学习笔记
震惊!用刚发布的GPT-5写研究现状,文献综述写作一整个大逆袭(附步骤+10条AI提示词) 每类分别给出:国内重点(3 条)、国外重点(3 条)、代表性方法(2–3 条)、代表成果(各 1–2 条)、主要问题(2 条)。每个场景给出:技术方案(2–3 种)、研究目标、实际成效/案例、当前挑战(3 点)。指令:基于国内外现状,系统列出当前学界的研究空白、关键未解问题与争议焦点(每项配简要证据/示例),并针对每个空白提出 1–2 条可行的研究方向或方法路径。三、差异与研究空白分析(≥300 字)。对每个小节提供:小标题、中心论点(1 句)、拟写要点(3–5 条)、建议引用类型(理论/方法/案例)。 阅读详情

相关推荐

5分钟上手,Cursor + IntelliJ IDEA 双端开发:高效协同的终极方案

最好的工具,是让你忘记工具的存在。通过AI 的创造力(Cursor)IDE 的工程力(IDEA)无缝的上下文流转(插件协同)从此,不再手忙脚乱切窗口,不再迷失在文件树中。只需一个快捷键,专注编码本身。装上这两个插件后,日常开发体验虽然没有天翻地覆的变化, 但至少摸鱼的几个小时时间是有的!

weixin_44058951的博客 2197

Mach-O文件

Mach-O文件简介

零丁若叹 1367

智能环境感知:STM32多传感器数据融合与报警策略设计

本文详细介绍了基于STM32的多传感器数据融合系统设计,整合DHT11温湿度传感器、MQ-2烟雾检测和光照强度检测模块,通过智能算法实现环境感知与动态报警。系统采用数据滤波、多传感器校验和自适应阈值策略,显著提升监测精度与可靠性,并通过OLED显示屏提供清晰的多级报警界面。

plant的博客 200

[iOS]分析Mach-O文件

Mach-O为Mach Object文件格式的缩写,它是一种用于可执行文件,目标代码,动态库,内核转储的文件格式。 每个Mach-O文件包括一个Mach-O头,然后是一系列的载入命令,再是一个或多个块,每个块包括0到255个段。

Gamin 3576

学习Python,小白如何搭建Python环境?

学习Python,首先需要搭建好Python环境,主要分为【运行环境搭建】、【开发环境搭建】以及【Python环境配置】三个环节,接下来我将对Python环境搭建这三个部分进行介绍。

weixin_72923265的博客 8997

GEE入门之路(从【初学者】角度,大白话)——附海面风速插值代码

非常初级的GEE入门教程!大白话!有手就行!附海面风速插值代码,克里金插值,时间插值。

weixin_46812066的博客 4084

MachO--文件结构详解

概念——什么是MachO?  苹果开发者对它一定不陌生,特别是喜欢逆向的同学,对它的研究更是必不可少。在可安装的每一个.app包中,都有一个与app同名的可执行文件,它可能长这样:(如果你碰到显示为白色的MachO文件,说明当前用户对其没有可执行权限)  MachO其实是Mach Object的缩写,是在Mac以及iOS上可执行的一种文件格式,包括但不限于:可执行文件(.out .o)、动态库、...

weixin_33859844的博客 2000

电池管理系统(BMS)系列—状态估计之SOH

BMS系列文章,介绍了SOH估计

zxx52113140的博客 1843

iOS-MachO文件介绍

本篇文章主要分析MachO文件(也称作二进制可执行文件),相信大家在平时开发中都会碰到MachO文件这个概念,但是大部分人不清楚是个什么东西,本篇文章就和大家一起来具体分析它的由来以及它的内部结构。

gcs的博客 975

快充协议全兼容!HUSB390对比测试:iPhone/小米/华为哪个充电最快?

本文深入评测了HUSB390快充协议芯片的全兼容性能,展示了其在iPhone、小米和华为设备上的极速充电表现。通过智能功率分配算法和多协议并行处理引擎,HUSB390实现了高效的动态调压和温度控制,显著提升多设备充电效率。特别适合需要同时为不同品牌设备快充的用户。

dd012的博客 1万+

车辆网络安全ISO/SAE 21434解读(一)概述

ISO/SAE 21434 《道路车辆 网络安全工程》是SAE和ISO共同制定的一项针对道路车辆的网络安全标准,它是一个面向汽车行业全供应链(OEM及各级供应商)的车辆网络安全管理指导文件

xiaoxiabang的博客 8420

Mach-O文件初识

一、什么是Mach-O文件? Mach-O 即 Mach Object,它是一种文件格式(Mac OS 二进制可执行文件)。 二、Mach-O 文件内容详解 Mach-O 二进制文件由段(segment)组成,可通过 MachOView 查看。 一个segment由零个或者多个section组成,每个section里面会放置不同的数据或代码。 segment需要页对齐(Mac OS 页大小4k,iOS 页大小16k),section不一定是页面对齐的。 segment、section命名规则: (1)se

Spencer Yang的博客 804

YOLOv8车辆碰撞识别检测系统(项目源码+YOLO数据集+模型权重+UI界面+python+深度学习+环境配置+目标检测)

随着我国汽车保有量的持续攀升,道路交通事故数量居高不下,车辆碰撞损伤的快速、精准评估已成为交通安全管理、保险理赔定损以及汽车后市场服务中的关键环节。传统的人工目视查验方法高度依赖评估人员的专业经验,不仅主观性强、效率低下,而且在复杂光照、多角度遮挡等真实场景下难以保证评估的一致性和可复现性。计算机视觉与深度学习技术的迅猛发展,为目标检测任务提供了强有力的技术支撑,使得基于视觉的车辆损伤自动化识别成为可能。

斌擎科技 128

Mach-O文件介绍

在Linux操作系统上,以及很多的类Unix操作系统,可执行文件的格式是ELF。mac OS虽然也是类Unix操作系统,然而mac OS以及iOS上,可执行文件的格式是Mach-O。 先理清一个易混淆的点,Mach-O和Mac没有什么关系。Mac是苹果电脑Macintosh的简称,而Mach是一种操作系统微内核,苹果公司的设备上操作系统内核使用的是Mach。在Mach内核中,一种可执行文件格式是...

TuGeLe的博客 3422

ET2012新版免狗免安装绿色软件

ET2012新版免狗免安祖昂绿色软件。,新界面,新视觉,

visio安装包

Microsoft Office Visio 是一款专业的制图软件。利用经过更新的形状、协作工具和数据链接图表,创建专业级图表以简化复杂的信息。

iOS进阶 - Mach-O文件解析

Segment load command 分为32位和64位,32位和64位的 Segment load command 基本类似,只不过在64位的结构中,把和寻址相关的数据类型,由32位的 uint32_t 改为了64位的 uint64_t 类型。在这么多的 load command 中,需要我们重点关注的是 segment load command。是一个特殊的 Segment,这个 Segment 其实是苹果虚拟出来的,只是一个逻辑上的段,而在Data中,根本没有对应的内容,也没有占用任何硬盘空间。

KevenLin的博客 1725

IEM模型,地表粗糙度模拟

利用微波反演土壤水分时候,利用IEM模型可以实现对随机地表的模拟

Mach-O文件格式

一个简单的程序 #include int main(int argc, const char * argv[]) { // insert code here... printf("Hello, World!\n"); return 0; } 对 mach-o 的分析从这个简单的 小程序开始 可执行文件的结构 我们用 MachOView 打开我们刚刚写了

兰亭白菜 2313

Devexpress16.2.6破解工具

Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具Devexpress16.2.6破解工具

03-什么是Mach-O文件?

App从开发到安装到手机上的过程 想要了解Mach-O文件,首先要了解从编写代码,开发App到App打包并安装到手机上的整个过程 首先代码经过编译、链接、签名获得一个“xxx.app”包,app包里面就装着nib文件、资源文件以及可执行文件(Mach-O文件),我们编写的代码其实就放在这个Mach-O文件里面 大 然后经过zip压缩,将app包转成ipa包,而ipa包就可通过以下几个途径可以装到手机里 上传至App Store,自行下载 通过Xcode、爱思助手、iFunBox等工具安装 逆向App

TSLee的博客 1687

探索Mach-O文件的神器:Mach-O Explorer

在软件开发中,有时我们需要深入理解二进制文件,尤其是MacOS平台上的Mach-O文件。这就是[Mach-O Explorer](https://github.com/DeVaukz/MachO-Explorer)大展拳脚的地方——一个专为macOS设计的强大图形化Mach-O查看器。 ## 1、项目介绍 Mach-O Explorer是一个直观且功能丰富的工具,它允许开发者和安全研究人员以可

gitblog_00083的博客 621

mach-o 介绍

一、简介 Mach-O是一种文件格式,是mac上可执行文件的格式,类似于windows上的PE格式 (Portable Executable ), linux上的elf格式 (Executable and Linking Format)。我们编写的C、C++、swift、OC,最终编译链接生成Mach-O可执行文件 二、mach-o文件类型分为: image 总共有11种。 M...

chqj_163的专栏 1504

iOS Mach-O文件

Mach-O文件格式介绍

叶阳的博客 1113

Mach-O文件和Facebook的fishhook

1. 概述 我们知道Windows下的文件都是PE文件,同样在OS X和iOS中可执行文件是Mach-o格式的。 Mach-O通常有三部分组成: 头部 (Header): Mach-O文件的架构 比如Mac的 PPC, PPC64, IA-32, x86-64,ios的arm系列. 加载命令(Load commands): . 原始段数据(Raw segment data):可以拥有多个段(se...

yhawaii的专栏 933

3、iOS Mach-O文件再解读

Mach-O文件概述: Mach-O(Mach Object)是macOS、iOS、iPadOS存储程序和库的文件格式。对应系统通过应用二进制接口(application binary interface),缩写为ABI来运行该格式的文件。 Mach-O格式用来替代BSD(Berkeley Software Distribution:伯克利软件套件)Unix衍生系统的a.out格式。Mach-O文件格式保存在编译过程和链接过程中产生的机器代码和数据,从而为静态链接和动态链接的代码提供了单一文件格式。 段.

Holothurian 1371

iOS开发:Mach-O入门理解

Mach-O:是的缩写,是Mac\iOS上用于存储程序、库的标准格式。属于Mach-O格式的文件类型有: 可以在源码中,可以查看到Mach-O格式的详细定义(https://opensource.apple.com/tarballs/xnu/)1、MH_OBJECT2、MH_EXECUTE:可执行文件3、MH_DYLIB:动态库文件4、MH_DYLINKER:动态链接编辑器5、MH_DSYM:存储着二进制文件符号信息的文件.o文件编译生成的流程: 官方描述 https://developer.apple.c

chenzimin_blog 2690

分析可执行文件mach-o

一、什么是可执行文件 Mach-O 是针对不同运行时可执行文件的文件类型。在Windows上.exe(Portable Executable )是可直接执行的文件扩展名,而在Linux(以及很多版本的Unix)系统上ELF (Executable and Linking Format)是可直接执行的文件格式,那么在苹果的操作系统上又是怎样的呢?在iOS(和Mac OS X)上,主要的可执行文件格式是Mach-O格式。 【mx:就是说以mach-o结尾的文件都是可执行文件】 【mx:是不是一个app就只有一

三线程序员的博客 2249

Mach-O

一、什么是Mach-O文件? Mach-O是Mach Object文件格式的缩写,是mac以及iOS上可执行文件的格式。Mach-O文件对应有多种格式: 目标文件.o 库文件: .a静态库文件 .dylib动态库文件 .framework系统级为动态库文件,自己创建的为静态库文件 可执行文件及MDW.app内部的MDW文件(通用二进制文件) dyld动态链接器将依赖的动态库加载到内存 .dsy...

yahibo的博客 683

Mach-O结构分析

可执行文件 我们运行一个程序(进程)是把一些特殊文件在内存中加载并运行得到的结果。那么这类文件的格式必须是系统内核可以理解的,系统内核才能正确解析。这类文件被称为可执行的文件。 不同操作系统的可执行文件格式不同: 在现代通用计算机系统中,虽然不同平台的可执行文件的格式不完全一样,但是原理大体相同,基本都是基于段结构的,可执行文件的结构基本可以分为: header段:用于让操作系统识别可执行文件 TEXT段:存放编译后的函数的二进制代码,TEXT段的内容被标记为只读的,可执行的。如果试图修改TEXT段的内

XA403 2158
上一篇: 音视频学习 - ffmpeg 编译与调试
下一篇: optool为macho文件增加动态库
忘川三
博客等级 码龄12年 208粉丝 45原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明:

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

余额充值