https://www.cnblogs.com/liuchuanloong/articles/16925695.html【背景】
近日处理现场问题时遇到了踩内存导致的崩溃问题，然而个人对反汇编程序执行过程不熟悉，通过查阅资料，对比分析两个小demo理解汇编代码踩内存的分析。
【基础】
对于反汇编过程，首先需要理解的是寄存器。以64位寄存器rax为例，其中0到31就是平常分析32位程序是常见的eax，0到15则是ax，而ah和al则分别是8到15和0到7。其中rax常用来做存储返回值的寄存器，rdi，rsi，rdx，rcx，r8，r9常用作函数的参数传递寄存器，分别对应函数的第1~6个参数，rbp、rsp、rip分别对应栈基、栈顶、指向当前栈帧中执行的指令。函数的入参顺序这里不做说明，感兴趣可以了解__stdcall、__fastcall。
对于寻址问题，这里列出几种寻址方式，具体可查阅相关资料。
【问题解析】
这里写了一个demo，先分析该demo的Begin函数的调用堆栈，如下图所示
函数在栈中内存分布大致分为四个部分：
参数空间
Call指令执行完的下一条指令地址
前EBP的值(当前EBP中保存)
局部变量空间
注意：对于__security_cookie取决于编译器
___security_cookie机制，防止栈溢出___security_cookie机制，防止栈溢出 - mavaL - 博客园
先分析正常函数的例子：
Begin函数的ebp地址为0xC8，存储main函数ebp,向下偏移4个字节为_security_cookies,向下偏移8个字节为数组地址，这里注意数组大小为6，为了内存对齐分配8个字节，向下偏移4个字节为result（int），向下偏移4个字节为数组首地址（MemCpy的参数），再向下偏移4字节地址为call下一条指令的地址，再向下4个字节为MemCpy函数的ebp
当我们修改memcpy函数将hello word！！！！（截图有误）写进大于dst空间的内存，运行马上崩溃。
分析此时的栈内存，这里看到函数Begin函数的ebp 0x0137fa5c 所存储的数据（0x0137fa50，实际为main函数的地址）被修改为（0x01000000）
【分析工具】
踩内存问题被发现，通常是程序崩溃的时候，能够生成coredump分析，知道是哪个内存被踩了，但通常是很难分析出是哪段代码出现了踩内存的问题，也就是内存践踏的第一现场，我们只能借助工具排查。
对于简单的容易发现内存被篡改的可以使用VS自带数据断点和Gdb watch，对于复杂问题可参考Mprotect、Asan、Perf(hardware breakpoint)、Valgrind、Magic number等工具。
https://blog.csdn.net/zz460833359/article/details/121769216
