★ FEATURED ARTICLE 写x64汇编的日子总觉得是在跟一台机器讲悄悄话。今天聊聊x64架构的基础这是系列的第一篇。很多人一听到x64就头大觉得那是逆向工程师或编译器开发者的专属领域但实际做底层优化、写驱动、搞安全分析甚至只是想真正搞懂调试器里那些寄存器的人都绕不开这一层。这篇文章就从最核心的寄存器、寻址、调用约定说起配合一个能跑的最小示例把x64的骨架搭起来。无论你是刚接触汇编的新手还是从x86转过来的老手这篇文章都能提供一个清晰的起点。1. 为什么需要理解x641.1 从x86到x64不是简单的“位宽翻倍”x64常常被理解成“64位寄存器取代32位寄存器”但如果你真这么想后续写代码会遇到一堆莫名其妙的坑。需要明确的第一件事是x64并不是x86的简单加宽而是一次系统性的重新设计。所谓x64正式的叫法是AMD64或Intel 64最早由某芯片厂商在2000年前后提出后来被另一家主要厂商全面采纳。它保留了x86的指令集架构但扩展了地址空间、寄存器数量、以及数据路径宽度。最直观的一个变化通用寄存器从8个增加到16个每个寄存器的宽度从32位扩展到64位。但更重要的是这个架构的指令编码方式也做了调整特别是寻址方式中的RIP相对寻址这是x86时代没有的。为什么这个词会频繁出现在操作系统、编译器、甚至区块链上因为几乎所有现代操作系统Windows、Linux、macOS的64位版本都是基于这个架构构建的。如果你在进行性能分析看到一个函数反汇编是mov eax, dword ptr [rip 0x1a2b]这就是x64特有的RIP相对寻址。不理解这一点你连读汇编都困难更别谈修改或优化。从使用场景来看需要掌握x64的不仅是安全行业。做游戏逆向、写JIT编译器、优化热点函数、排查栈溢出问题都需要基本的x64汇编阅读能力。即使你只是写C/C当你调试release版本、生成core dump时也会面对这些底层指令。1.2 64位世界的规则地址空间与数据模型理解x64的另一个关键是“数据模型”。常见的模型叫做 LP64Linux和 LLP64Windows。这个术语的意思是long和pointer是64位int还是32位。Windows下则是long和pointer分开long保持32位。这意味着在Windows x64上你如果写下sizeof(long)得到的值是4而在Linux x64上得到的值是8。这种差异直接影响跨平台开发的代码。很多从x86迁移到x64的项目踩的第一个坑就是数据类型变量的占用空间变化导致结构体布局错乱尤其是那些手工填充缓冲区的代码。另一个核心点是地址空间。x64的虚拟地址空间实际上只用了48位既有的硬件限制也就是0x0000000000000000到0x00007FFFFFFFFFFF或者高地址段0xFFFF800000000000到0xFFFFFFFFFFFFFFFF。可别以为64位就是64根地址线全用满那只是理论值。这个“只用了48位”的现实直接影响指针格式和地址转换逻辑。2. 核心寄存器与数据模型2.1 通用寄存器从8个到16个x64架构下通用寄存器一共有16个RAX、RBX、RCX、RDX、RBP、RSP、RSI、RDI以及新增的R8到R15。这里有个重点每个64位寄存器的低32位部分可以单独访问比如RAX的低32位是EAX低16位是AX再低8位是AL高8位是AH。新增的R8到R15也是如此R8D表示低32位R8W表示低16位R8B表示低8位。设计这套低级访问机制多是为了兼容x86遗留代码但在手写汇编或逆向时你经常可以通过只操作低位来优化指令编码。比如你只想给一个数加1用add eax, 1比add rax, 1更短因为在x64指令集里操作32位寄存器会自动清零高32位这是x86-64的一个隐含语义。很多新手容易忽略这点写mov rax, 0xFFFFFFFF时其实RAX变成了0x00000000FFFFFFFF因为立即数会自动扩展但如果你用mov eax, 0FFFFFFFFh那么RAX的高32位会被清零最终RAX是0x00000000FFFFFFFF。这个细节在处理地址计算和高精度运算时特别容易出问题。2.2 标志寄存器与指令指针标志寄存器在x64里叫RFLAGS是32位EFLAGS的扩展但实际使用的低位标志位基本一致。常见的标志位有ZF零标志、SF符号标志、CF进位标志、OF溢出标志等。x64新增的一个特别重要的寄存器是RIP指令指针寄存器也就是保存当前执行指令地址的寄存器。在x64中RIP不能直接访问但可以用于RIP相对寻址。这意味着你可以写类似lea rax, [rip symbol]的指令直接获取当前指令后面的某个符号地址。这种机制是实现位置无关代码PIC的基础也为现代编译器生成高效代码提供了便利。对我个人来说RIP相对寻址是x64和x86的最大区别之一因为它改变了模块加载的地址计算方式。在调试时如果你看到call qword ptr [rip 0x1234]那通常是在访问某个全局变量或函数指针。理解这个模式反汇编重构就会容易得多。2.3 数据类型与内存对齐数据模型直接决定结构体在内存里的布局。在x64下指针是8字节但在Windows上long还是4字节这会导致结构体成员变量有填充字节。一个经典例子struct example { char a; // 1 byte int b; // 4 bytes long long c; // 8 bytes };在Linux x64下这个结构体的大小是16字节char占1字节填充3字节然后int占4字节再填充4字节后long long占8字节。如果你手工将这个结构体写入文件或发送到网络就需要考虑这些填充字节。这在自定义二进制协议开发或做内存取证时至关重要。我自己在处理磁盘镜像或网络数据包时必须清楚每个字段的对齐规则否则解析出来的数据全部错位。推荐使用offsetof宏来确认字段偏移而不是凭经验硬算。3. 指令集与寻址模式3.1 常用指令速览x64的指令集非常庞大但高频用到的指令无非那几十种。从我长期看汇编的经验来说下面这些是必须掌握的MOV系列数据搬运。mov rax, 1mov qword ptr [rdx], rcxLEA加载有效地址常用来做算术运算。lea rax, [rcx rdx*4]ADD/SUB加减法。注意add rax, -1实际上是sub rax, 1PUSH/POP栈操作但在x64下不常用因为调用约定会要求“影子空间”CALL/RET函数调用与返回。call会把返回地址压栈ret弹栈TEST/CMP比较操作用于设置标志位JMP/Jcc跳转包括jz、jnz、jg等条件跳转AND/OR/XOR逻辑运算常用xor eax, eax来清零寄存器SHL/SHR移位操作这些指令的编码模式并不复杂但它们在x64下的行为有些细节需要注意。例如movzx零扩展和movsx符号扩展在x64下经常出现用于不同宽度的整数转换。3.2 寻址模式理解[base index * scale disp]x64的寻址模式基本形式是[base index * scale displacement]其中index是索引寄存器scale是1、2、4、8base是基址寄存器displacement是偏移量。例如mov rax, [rcx rdx*8 0x10]这个指令计算地址为rcx rdx*8 0x10然后从这个地址加载8字节到RAX。该模式非常灵活常用于数组元素访问、结构体字段访问。配合RIP相对寻址你可以访问代码段中的常量如lea rax, [rip 0x1234] ; 计算当前指令地址 0x1234在处理PIE程序position-independent executable时这种寻址方式简直无处不在。调试时如果看到大量RIP相对地址不要慌它只是用来定位代码段内的常量。3.3 栈操作与堆栈对齐栈在x64中是16字节对齐的这是SysV ABI和Windows x64调用约定的一致要求。这意味着在调用函数之前栈指针RSP必须满足RSP % 16 0。为什么这样因为SIMD指令如movaps要求内存地址16字节对齐编译器为了安全起见强制栈对齐。你如果要手写汇编与C函数交互就必须手动维护栈对齐否则调用外部函数时可能崩溃常见的是movaps的“general protection fault”。新手最容易犯的错误是在函数开头push rbp然后操作栈但忘记最后pop rbp时要恢复RSP的原始对齐状态。我经常建议在写汇编函数时用sub rsp, 0x28这样的方式一次性分配栈空间而不是反复push/pop。4. 函数调用约定详解4.1 Windows x64调用约定Windows x64下函数调用的参数传递规则是前四个整数或指针参数依次放在RCX、RDX、R8、R9中后续参数压栈从右到左。浮点参数使用XMM0-XMM3。还有一个非常容易遗忘的细节“影子空间”shadow space。调用者在调用函数前需要在栈上至少预留32字节4个参数位置即使参数少于4个也要预留。被调用函数可以安全地在这个区域里保存RCX和RDX的值因为这是调用者分配的空间。比如你在Windows x64下写一个函数my_func: ; RCX arg1, RDX arg2 ; 先把参数搬到安全位置 mov [rsp8], rcx mov [rsp16], rdx ; 此时[rsp]是返回地址 ; [rsp8]和[rsp16]就是影子空间不保留这个影子空间调试时可能会发现函数内部的局部变量被莫名覆盖其实是因为被调用函数使用[rsp8]来保存参数。另一个要点是返回值放在RAX中无论是指针、整数还是浮点数。浮点返回结果放在XMM0。4.2 System V AMD64调用约定Linux和macOS遵循System V AMD64 ABI。参数传递规则不同前六个整数或指针参数依次放在RDI、RSI、RDX、RCX、R8、R9后续参数压栈。浮点参数使用XMM0-XMM7。System V没有“影子空间”的概念但要求栈溢出之前必须将RSP保持16字节对齐并且在调用函数时将栈上压入返回地址后RSP必须是8 mod 16。简单说就是在被调用函数的入口处RSP的值满足RSP % 16 8因为调用者已经把返回地址压栈了。举个简单的汇编函数例子; 在Linux x64下extern函数调用 my_func: ; RDI arg1, RSI arg2 ; 调用某个外部函数之前先把参数放到对应的寄存器 mov rdi, [rdi] call some_external_function ret但在调用之前你还需要确认栈对齐。我通常的做法是在进入函数时检查RSP如果不对齐就sub rsp, 8来调整。4.3 调用约定的实践陷阱调用约定是混合语言开发的重灾区。我见过太多次因为参数传递寄存器搞错导致的诡异崩溃。因此我总结了几条实操心得问题出现时先看是否是栈对齐问题。x64对栈对齐要求非常严苛编译器生成的代码会频繁使用movaps。Windows和Linux的参数寄存器完全不同。跨平台汇编代码中必须用宏或条件编译来区分。调试时用调试器查看函数原型和反汇编确认调用者到底往哪个寄存器塞了参数。在C/C里混编汇编时尽量让汇编函数只负责一小块逻辑避免复杂参数传递。如果参数超过4个或6个建议用结构体指针。不要随便在汇编函数里使用RBX、RBP、R12-R15这些非易失寄存器。如果你使用了必须手动保存并恢复否则调用者会崩溃。结论就是遵守规则但不要徒手写大段汇编。能在C里实现的逻辑就不要放到汇编里汇编只做关键热点。5. 一个最小x64汇编程序实战5.1 准备工具链nasm与ld/gcc这里用一个最简单的程序为例输出一行字符然后退出。我使用NASMNetwide Assembler作为汇编器它的语法比较直观支持x64。在Linux上安装很简单sudo apt install nasm在Windows上你可以使用MASM或GoASM但这里以Linux NASM为例因为更方便把所有细节讲透。5.2 编写“Hello, x64”并剖析创建一个hello.asm文件section .data msg db Hello, x64!, 0x0a, 0 section .text global _start _start: ; write(1, msg, 12) mov rax, 1 ; syscall number for write mov rdi, 1 ; fd stdout mov rsi, msg ; buffer pointer mov rdx, 12 ; length syscall ; exit(0) mov rax, 60 ; syscall number for exit xor rdi, rdi ; status 0 syscall这个程序没有使用C库直接调用了内核的syscall接口。关键点第一个参数放RDI第二个放RSI第三个放RDX和System V函数调用约定一致因为Linux系统调用本来就用类似规则。编译nasm -f elf64 -o hello.o hello.asm ld -o hello hello.o ./hello你应该能看到输出Hello, x64!。这里_start是整个程序入口不是main函数。5.3 从汇编调用C函数理解交互方式为了展示如何与C函数交互写一个简单示例。文件asmlib.asmsection .text global asm_add asm_add: ; rdi a, rsi b mov rax, rdi add rax, rsi retC文件main.c#include stdio.h extern long asm_add(long a, long b); int main(void) { long result asm_add(3, 4); printf(3 4 %ld\n, result); return 0; }编译nasm -f elf64 -o asmlib.o asmlib.asm gcc -o demo main.c asmlib.o ./demo这里有几个关键点第一个参数在RDI第二个在RSI返回值在RAX。C代码中extern long asm_add(long a, long b)的声明要确保类型匹配尤其是指针大小。汇编函数没有保留影子区域也不需要因为System V没有这个要求。实际操作时我发现编译器可能会在C函数里使用某些寄存器如果你的汇编函数破坏了它们逻辑就会出错。因此汇编函数内使用的所有寄存器要么自己备份要么只用易失寄存器如RAX、RCX、RDX、RSI、RDI、R8-R11。6. 常见问题与排查技巧实录6.1 段错误栈对齐引发的血案我遇到最多的问题是段错误往往源自栈对齐。例如你写了一个汇编函数调用了C库的printf然后崩溃。原因printf在用SSE指令时会检查对齐如果RSP在调用点不是16字节对齐CPU会抛出“general protection fault”。有时它不会立即崩溃而是在函数内部深处才出现这让调试变得非常棘手。排查方法在调用点下断点用调试器查看RSP的值。如果RSP % 16 ! 0说明你在函数入口处的栈操作有问题。通常进入函数时RSP是8 mod 16因为调用者压了返回地址你需要在调用其他函数前进行sub rsp, 8或sub rsp, 24等操作来调整回0 mod 16。我踩过的一个坑因为急着优化省掉了一个push结果每次运行到不同位置崩最后定位到栈对齐不一致。6.2 链接失败位宽不匹配的符号汇编器生成的目标文件需要与C编译器生成的目标文件匹配。有时你编译了一个32位汇编对象然后在64位环境链接会提示“file format not recognized”或“incompatible”。这时你就要检查NASM命令是否加了-f elf64。另外符号名称方面C编译器有时会在函数名前加下划线尤其在Windows和macOS而Linux x64通常不加。如果你在Linux下链接报“undefined reference to”可以先用nm命令查看目标文件中的导出符号。nm asmlib.o结果可能是一堆符号。如果看到_asm_add而不是asm_add说明汇编器或目标文件格式给你加了前缀那你C代码中的extern也改成_asm_add。这类问题在Linux上不常见但在Windows NASM里经常出现。6.3 调试技巧看反汇编与断点如果你要排查自己的汇编代码我强烈建议用gdb。编译时加上-g再使用gdb ./demo break main run layout asm这时可以看到当前指令的汇编视图能实时观察RSP、RIP等寄存器的变化。另一个有用的命令是info registers查看所有寄存器状态。结合x/20gx $rsp查看栈内容。如果是逆向别人的代码推荐使用radare2或Ghidra。它们能快速生成伪代码方便理解逻辑。但无论如何手工读汇编的能力不能丢因为伪代码有时会丢掉关键细节比如未对齐的缓冲区访问或者整数溢出。6.4 常见错误速查表现象可能原因排查方向立即崩溃栈未对齐检查RSP mod 16参数错乱用错寄存器参看调用约定文档链接失败目标文件格式不匹配使用file命令检查输出乱码字符串长度错误检查RDX的长度指令非法使用了32位编码确保指令支持x64这些基本能够覆盖百分之九十的起步问题。从我个人经验来看x64汇编就像一门外语刚开始读得慢每行都要查手册但一旦掌握寄存器、寻址、调用约定这三个核心框架后面的学习就会顺畅很多。建议你不要只停留在阅读层面可以找几个简单函数比如字符串长度、整数转字符串自己用汇编重新实现一遍然后反汇编编译器生成的版本做对比。这种对照练习比死记硬背有效得多。如果这篇对你有帮助后续我可以继续写x64系统调用、指令编码与重定位、以及如何在Windows x64下做类似实战。先到这里大家在实际操作中碰到什么问题欢迎带着具体的寄存器值和反汇编片段来交流。
阅读完成 · 觉得有帮助？
