Seven’s Blog

虚拟数字人-多模态数据采集（ASR模型）

Tue, 14 Apr 2026 00:00:00 GMT

背景

在情感陪伴虚拟数字人系统项目中，数字人需要理解用户输入内容与情绪状态。因此多模态数据采集与建模主要聚焦两个方向：

语音识别（ASR）：调用麦克风，识别用户语音内容

人脸/表情识别：调用摄像头，捕捉面部表情并进行情绪判断

本文档整理了当前实现与训练流程，便于复现与后续扩展。

语音识别

语音识别采用 Whisper 模型进行训练与微调。

数据处理

采用开源中文数据集 AISHELL 进行训练。由于数据集的音频文件与标注文件分开存放，需要先转换为便于训练读取的 jsonl 格式。

整体逻辑：

读取标注文件，生成 id -> 文本 的字典

递归扫描 .wav 文件，按 id 匹配文本

生成 [{audio: 路径, sentence: 文本}, ...] 列表并 dump 为 jsonl

标注文件处理要点：去噪、分割字段、去除多余空格。

有多条wav文件，就进行递归读取

匹配字典中的key和wav的id，匹配后在列表中逐个添加

最终dump到json文件中

模型训练

训练的大致逻辑为：

加载模型训练的模型以及工具→处理成可以微调的格式→读入处理好的json→样本处理拼接成batch→训练→保存模型和processor

训练预处理

单条样本变成训练特征

先将音频读进来，然后重采样到标准16kHz。

由于whisper模型是吃提取后的声学特征而不是原始的waveform，所以要在样本中添加声学特征input_features 。

最后将文本转换成token id，输入输出格式如图下所示：

将多条样本拼接成一个batch

由于我们每条样本的长度都不是对齐的，所以需要processor中进行对数据的对齐处理

tokenizer分词+转id，这样样本句子就变成了id

padding，设置统一长度以后再补空位，使所有的样本一样长形成一个矩阵

设置mask，有用数据置1，补位数据置0

最终输出一个Pytorch tensor。

由于我的数据包含input_features和labels两个元素，而input_features已经是特征向量，最终可以直接输出tensor；但是labels需要进行填充替换才能转成特征向量，依据约定将padding值改为-100才可以在loss计算时忽略填充位置。

最终将标准batch返回给Trainer进行训练。

主程序训练

加载processor和模型

LoRA配置

这里采用PEFT的LoRA进行微调，并非把whisper的全模型都训练，知识在注意力层的q_proj和v_proj上挂LoRA。

这里执行map函数时，remove可以保证后面的数据结构非常干净。为了控制传进复杂的processor时Windows不会卡死，设置进程为单进程。

上述trainer中使用自定义的collator是因为音频特征和文本标签的padding规则不同。

模型调用

本地加载模型并且挂载本地LoRA权重。

输入语音进行特征提取和解码。

结果评估

根据上述评估的指标，从训练的数据集中随机抽取100条样本进行测试，输出词错率和句错率。

人脸识别

通过直接调用API实现对人脸的识别，这里不进行赘述。

💡

有关Notion安装或者使用上的问题，欢迎您在底部评论区留言，一起交流~

通过某一题目学习安卓app逆向全流程

Mon, 09 Mar 2026 00:00:00 GMT

😀

本文是在学习安卓逆向基础时跟着文章做的复现，同时配上自己的思考和理解做了更详细的解释，整理了一般app逆向的全流程。

了解逆向一个apk需要注意的点：加固，加解密

app无壳

基本app逆向流程：

找程序入口点

com.example.flag.MainActivity 是 Android主活动的完整类名，由 “包名 + 子包名 + 类名” 组成

从onCreat（）去找app加载的关键逻辑

💡

核心生命周期回调包括：

onCreate()：Activity首次创建时调用，适合进行界面初始化、数据绑定、ViewModel关联等操作。

onStart()：Activity变为可见时调用，可在此准备进入前台的资源。

onResume()：Activity进入前台并可与用户交互时调用，适合启动动画、相机预览等前台任务。

onPause()：Activity失去焦点但可能仍可见时调用，用于暂停不必要的操作或释放部分资源。

onStop()：Activity完全不可见时调用，适合释放大量资源或保存数据。

onDestroy()：Activity销毁前调用，用于最终清理资源。

onRestart()：Activity从停止状态重新启动时调用，可重新初始化在onStop中释放的资源。

app有壳

基本逆向流程：

加壳判断

有完整类名但没有相应MainActivity代码实现

通过观察APK文件是否在AndroidManifest.xml配置Applicaiton信息来判定,该app实现了一个自定义操作，多加了name字段，将Application 类进行了自定义修改成了com.SecShell.SecShell.ApplicationWrapper来实现自己的加壳逻辑

App通过自定义的 ApplicationWrapper 类来启动壳程序

💡

梆梆加固原理:

根据APK文件是否在AndroidManifest.xml配置Applicaiton信息，梆梆加固会做不同的处理：

通过上传Applicaiton不同配置的APK文件：

当APK配置有Applicaition信息时，梆梆加固重写Application类

当APK未配置Application信息时，梆梆加固新建类，并在AndroidManifest.xml中配置自己Application类

加载本地库通常是壳的核心部分，可以去分析代码逻辑判断是否被调试等

使用Frida-DEXDump脱壳

💡

原理：

在进程的内存中搜索dex文件头

如果dex头被抹除，则需要开启深度搜索模式，搜索其他关键字段

如果dex的文件file_size字段被抹去，就需要搜索dex的尾部字段来判断是否是dex和dex的大小

（由于当时因为不可抗因素使这篇文章写的很不完善，后续会进行补充）

💡

有关Notion安装或者使用上的问题，欢迎您在底部评论区留言，一起交流~

用Java实现TEA加解密

Mon, 10 Nov 2025 00:00:00 GMT

注：以下为在原始笔记基础上的完善成稿，面向开发者阅读与实践，希望大家积极给予指正。

一、什么是 TEA（Tiny Encryption Algorithm）

分组与密钥：分组大小 64 位，密钥长度 128 位。

轮数与常量：通常使用 32 轮；增量常量 delta = ~~0x9E3779B9（与黄金分割相关）。~~（总而言之是一个常数）

轮函数：在每轮中对两个 32 位半块进行移位、加法与异或混合，形成“费斯妥结构”迭代。

优缺点：实现简单、代码短小；但已知存在相关/等价密钥等弱点，不建议生产使用。

二、Java实现思路

密钥准备与KDF说明：手动指定密钥用getbyte方法把字符串转化为字节数组将密钥拆分为4个32位的子密钥

明文分块和填充：对明文数据进行分组 64位为一组，若数据长度不是64的整数倍需要进行数据填充

大端序打包成两个32位整数：将明文分组分为左右两部分L0和R0

32轮迭代进行32轮迭代算出R[i]&L[i] k为密钥

输出编码（HEX或Base64都可，本文采用HEX）

三、实现要点与常见坑

字节序：本文实现采用大端序打包与解包。bytes[0] 为高位字节。

编码：字符串统一使用 UTF-8 进行 getBytes 与字符串还原。

💡

getBytes：把字符串按照指定的编码格式转换成字节数组。

分块与填充：对明文按 8 字节分块，最后不足一块使用 PKCS#7 风格填充，解密后去填充。

💡

PKCS#7（加密消息的语法标准）是由RSA安全体系于1993年提出的公钥加密标准，用于规范数字证书、签名及加密消息的语法结构。该标准采用ASN.1编码规则，定义了六种内容类型，包括明文数据、签名数据（SignedData）、数字信封（EnvelopedData）等，支持多重嵌套加密、时间戳验证和证书链集成。其签名流程包含哈希计算、私钥加密及证书链封装，加密流程结合对称与非对称算法实现数字信封机制。PKCS#7文件格式兼容PEM编码，常用扩展名为.p7b/.p7c，可存储证书链但不含私钥。

示例给出 ECB；如用于真实数据，至少使用 CBC+随机 IV，并需“加密+认证”（HMAC（哈希消息认证码）或 AEAD（带认证的加密算法）。~~笔者在写这篇文章的时候并没有想到这一层以及随机IV使用，但是既然有一定风险那还是强调一下~~

四、核心代码（练习示例）

五、一些在寻找资料过程中其他代码的小知识

线程安全与可重入性：本文的 TEA 实现为纯函数式计算，单块加密/解密不依赖全局可变状态，方法本身是可重入的。（可重入性在多线程编程和中断处理程序中非常重要）需要注意的是，示例中使用了 StringBuilder 在单线程场景下性能更好，但若在多线程并发写同一个 StringBuilder 对象将产生数据竞争。建议每个线程持有自己的局部缓冲，或使用线程隔离而不是使用 StringBuffer 这种全局同步容器。

随机性与 IV：ECB 仅用于教学。实际应用至少使用 CBC/CTR/GCM 等分组模式。CBC 需要随机 IV 且每次加密都要不同，IV 可与密文一同存储但不可复用。同样地，CTR/GCM 需要唯一的 nonce，复用将导致严重安全问题。

填充与密文长度：采用 PKCS#7 填充后，密文长度一定是 8 的整数倍。若将密文转为十六进制字符串，输出长度将是字节数的 2 倍。用于传输时可考虑 Base64 编码以减少输出长度并便于跨语言处理。

字节序与跨语言互通：本文使用大端序进行 int 与字节数组的互转。如果需要与 C 语言或网络协议对接，务必约定并固定字节序，避免一端大端、一端小端导致解密失败。

键值派生与管理：示例直接截断/零填充到 16 字节生成 128 位密钥。实际应用应使用 KDF（如 PBKDF2、scrypt、Argon2）从口令派生密钥，并妥善存储盐与参数，以抵抗暴力破解。

输入输出与编码：明文统一以 UTF-8 处理，跨平台时保持一致。密文存储最好明确标注格式，例如 "TEA-ECB|HEX" 或 "TEA-CBC|Base64|IV=..."，避免后续解析歧义。

HTML爬虫操作

Sun, 09 Nov 2025 00:00:00 GMT

本文是笔者第一次爬取数据分享，主要内容为爬取html中的内容图片以及转储pdf。

前提准备

首先我们发现这个数据是一个网站，我们需要这个网站的所有数据作为agent的知识库，而每一个目录下都会有链接跳转到子目录，如果在每个网页直接保存文本耗时耗力，所以想到了爬虫的办法。

HTML&网页结构

HTML是构成网页的基础语言，通过一系列标签来格式化数据，如我们可能需要链接元素，图片元素，标题元素

，列表元素

等，我们需要什么内容就可以在html代码中找到对应标签然后爬取下来。

查找方法：直接在浏览器中打开源码寻找（笔者用的是Google，~~因为认为这个ui比其他看起来好看一些~~）。

注意事项

可执行理由：每一个子目录下的url大部分都是数字连续标识，可以通过简单循环来爬取整个目录。

但是也有特殊url，如下图最后一个BONE305.html ,我翻了很多子目录查看觉得特殊url不多，出现这种情况可以选择直接爬取这一条的内容。

首先要发送请求获得网页响应；

可能需要图片另存，所以我们需要对图片进行处理和输出；

需要pdf格式，要尝试将html转成pdf；

爬虫逻辑

安装相关库

本文使用python写爬取代码，需要使用到的库有：

安装代码：

但是上述一些库的兼容性在不同python版本有差异，读者可自行试验。

💡

提一嘴：笔者在转pdf的时候使用了另一个库，但是配好tool以后已知报错显示不能用，所以换了现在使用的xhtml2pdf库，具体不能用的原因至今还未找到。。（猜测可能是与python版本不兼容的锅）

解析获取网页内容

首先尝试能否请求成功，然后试验得到了状态码200，说明可以跑，接着开始爬取内容。

最开始发现输出全是空白的，寻找html源码和自己代码比对，发现标题和内容的标签对不匹配，加入源码标签组继续跑一下，发现就能输出内容了（包括后面子目录还有无法输出的，也用同样的方法实现）。

解析图片并提取

我选择将所有照片暂时存在一个文件夹下，后续如果需要分类重新抓取即可，下直接附代码：

保存抓取的数据转储pdf

这里我选择将抓取的数据先保存成临时html网页，再通过python库和工具将html转成pdf。

保存临时html：

转存pdf：

💡

再提一嘴，每一步都加入print状态是个很好的习惯，这样可以容易看到到底有没有成功实现代码，也容易实现断点调试纠错。

循环爬取共性url

我们发现有些url是三位数字或两位数字后缀，所以可以选取某一子目录再加入循环数字实现url循环爬取。

例如：

运行代码就可以获得output

总结

完整代码（某一子目录示例）：详见GitHubS3v3ny/Crawling-HTML-data: Crawl HTML data and convert it to PDF format.。

python爬虫入门，轻松爬取网页上的数据(非常详细)_python爬虫爬取网页数据-CSDN博客

💡

本文关于爬取的样例代码已提至GitHub（，欢迎讨论交流~

uxp魔改脱壳

Sun, 26 Oct 2025 00:00:00 GMT

😀

本文是笔者在做题时偶然想通过题目学习加壳脱壳原理，并尝试手脱以及修改魔改壳来加深原理学习。

x64手脱壳

前情概念

entrypoint：镜像头指定入口，实际是一个程序的初始化和结束部分，往往是运行库的一部分。

OEP：是壳还原后原程序首次执行点。

程序运行步骤：

操作系统创建进程后，把控制权交到程序入口，这个入口往往是运行库中的某个入口函数

入口函数对运行库和程序运行环境进行初始化

入口函数完成初始化后调用main函数，开始执行程序主体

main函数执行玩返回入口函数，入口函数进行清理工作，后进行系统调用结束进程

所以我们要找未加壳的程序的真正的入口点—OEP

首先了解加壳原理

加壳是将一段代码嵌入到原始程序中，将软件的真实入口点（OEP）隐藏。加壳时，原始程序的代码可能会被压缩或加密，运行加壳后的程序时首先执行的是壳代码，然后将控制权交还给原始程序（操作系统加载器将程序读入内存，此时内存中的代码是外壳中的代码，而后CPU执行，外壳程序将CPU的执行流跳转到原始程序的真正入口点）。

脱壳的大致思路

壳把 EP 指到自己的 stub（就是起到连接过渡作用的一小段代码）。stub 先解压/解密原程序到内存，再把控制流转交到原始 OEP。理解这条链路的目的是：我们要在“壳完成还原、即将跳回原程序”的那一瞬间截停。

脱壳流程（以Vidar-Team的新生赛一题为例）

首先打开x64dbg，然后寻找OEP（有以下特点：是用户层代码，位于程序的.text段，是解压/加密完程序第一个执行点）

💡

原函数的OEP一般都是start函数的起始地址

重点要关注jmp指令，一般由jmp指令接用户层内存地址则为OEP

用户层与内核层地址范围划分：用户层（32位中）通常为0x00000000到0x7FFFFFFF，内核层通常为

0x80000000以上，低地址是用户层，高地址是内核层（通常为系统DLL的内核函数

不要用“高低地址=内核/用户”的简单二分做判断。

首先在断点处找到入口，跟进去，那个5FCF60就是入口

F9跳转过去

再F8，注意观察寄存器值的变化

发现只有RSP寄存器值发生变化，符合栈指针定律（壳在收尾出栈）

💡

栈指针定律（ESP/REP定律）是计算机领域基于堆栈平衡原理的术语，主要用于描述程序调用子程序时对堆栈指针的操作机制。其核心原理为：执行CALL指令时，系统会将下一行程序地址压入堆栈并跳转至子程序；执行RET指令时，从堆栈弹出地址并跳转回原程序，该过程需始终保持堆栈指针平衡以确保正确返回。例如处理UPX壳时，通过观察pushad和popad指令对寄存器的压栈与出栈操作，结合对ESP/RSP地址设置硬件断点，可在程序跳转至OEP时中断执行，从而绕过壳的校验机制。

x86中为ESP,x64中为RSP。

RSP右键内存窗口中转到→右键→选择四字节硬件断点（内存被读改时中断触发，硬件断点更不容易被抹除）

若断点被抹除，可以在可疑的“pop / ret / jmp”序列处设置内存访问断点，或在返回地址所在栈址下硬断点。

继续F9跳到断点处，发现断在了一堆pop下面

然后看到下面jmp有一个大跳，下个断点，F9后F7进去

这里感觉应该就是正确的OEP

💡

OEP识别要点

位于 .text，字节序列合理，有正常 prologue

上下文寄存器与返回地址指向原程序区域

命中时壳完成解压/解密，后续 API 调用能被正确解析

~~笔者在找OEP最初踩了一个大坑，错把程序加壳后的入口处当作程序入口点导致dump丢失了很多东西，所以还是不能走捷径要老老实实分析~~

选择插件Scylla（快捷键Ctrl+I）

在这里输入目标地址，点击右侧按钮

点击Get Imports，自动解析IAT中所有的API函数，确保log中全是valid条目，将invalid条目删除

再dump内存转储，选择合适路径（注意保留dump作为回滚）

再点击fix dump用于修复刚刚文件的PE头和IAT，得到最终的脱壳文件

ESP 定律法 - CTF Wiki
ESP 定律法 - CTF Wiki
CTF Wiki

x64dbg手脱壳_x64dbg 脱壳-CSDN博客
x64dbg手脱壳_x64dbg 脱壳-CSDN博客
文章浏览阅读5k次，点赞6次，收藏23次。本文详细记录了一次使用x64dbg进行逆向工程的过程，通过设置断点和分析寄存器变化，找出入口点（OEP）。作者讨论了如何确定正确的OEP，强调了在ESP寄存器首次变化后进行dump的重要性，并展示了从不同OEP dump后的反汇编差异。最后，作者提醒找到准确的OEP对于成功脱壳至关重要。

手脱壳会有一个bug是ida打开文件后函数名没了，无法复原符号，所以可以通过修改upx被魔改的地方再用脱壳工具脱掉会更好。先修改后脱还便于脱壳工具正确识别节与目录，从而更稳定地重建 IAT 和修复 PE 头。

修改魔改后脱壳

修正PE头

用010打开这个未脱壳的文件，发现正常的标准头是这样的。

但是这个魔改后的是这样的：

将那个魔改后的改成标准的，然后再用脱壳工具脱就可以了。

常见修改魔改清单

DOS stub/PE signature

节表对齐与标志

数据目录（Import/Reloc/TLS）清空或伪造

UPX 节名与属性修改

💡

后续还会接着补充其他脱壳修壳内容，欢迎大家指正补充。

Linux修改函数参数或调用目标

Fri, 19 Sep 2025 00:00:00 GMT

本文介绍在没有源码的情况下，在二进制层面修改函数参数和调用目标。本篇文章主要是笔者做题时遇到的task并总结整理得成，以 SysV为主线，提供可复现的 GDB 示例与静态 patch 步骤，并澄清SysV，Winx64，Winx86，ARM的关键差异。

一、背景与读者对象

面向人群：有 C 与基础汇编知识，正在做调试、逆向或运行时注入。

目标任务：

把 j_stage1(32) 改成 23（运行时改参数）
把 call j_stage_2_fake 重定向到 j_stage_2_real（静态或动态改调用目标）

方法路径：

动态：用调试器修改寄存器或栈
静态：改写代码段中的相对位移或借助导入表重定向

在汇编层面修改函数参数或调用目标时，需要直接操作内存或寄存器，这是由计算机执行程序的底层机制决定的。寄存器和内存栈是函数调用过程中参数和指令的实际存储位置，直接修改它们就能改变程序行为。

二、参数传递方式和调用约定

参数传递方式（以某道CTF逆向题为例）

寄存器传递（如 SysV调用约定）：

前几个参数通过特定寄存器（如 rdi, rsi, rdx）传递。
例如，j_stage1(32) 在 x64 下可能将 32 存入 rdi 寄存器，再执行 call 指令。

栈传递（如 x86 CDECL 约定）：

参数从右到左压入栈（Stack）。
例如，j_stage1(32) 会先执行 push $32（将 32 压入栈），再执行 call j_stage1。

如何确定参数传递方式

1. 确定目标架构

不同架构的参数传递规则不同：

x86（32 位）：通常通过栈传递参数（如 CDECL、STDCALL 约定）。

x64（64 位）：前几个参数通过 寄存器 传递（如 Windows 的 RCX/RDX/R8/R9，Linux 的 RDI/RSI/RDX/RCX），多余参数通过栈传递。

ARM：参数通过寄存器 R0-R3（或 X0-X7 用于 64 位）传递，多余参数通过栈。

💡

如何判断架构

指令集架构（ISA）包括x86/x86_64以及ARM

x86包含32位和64位，32位有一些标准调用约定，而x86_64包含SysV和Win64，ARM则有自己的调用约定。

在 IDA 中，打开文件后，标题栏会显示架构信息（如 x86: 64-bit）。

查看汇编指令特征：

x86：使用 EAX/EBX 等 32 位寄存器，PUSH 指令频繁用于参数压栈。
x64：使用 RAX/RBX 等 64 位寄存器，MOV 指令向寄存器赋值常见。

32位寄存器一般是e开头 64位寄存器一般是r开头

2. 识别调用约定

常见调用约定及其参数传递方式：

调用约定	参数传递方式	栈清理
x86 CDECL	参数从右到左压栈	调用者清理
x86 STDCALL	参数从右到左压栈	被调用者清理
x64 Windows	RCX、RDX、R8、R9，需 32 字节 shadow space	被调用者清理
x64 SysV	RDI、RSI、RDX、RCX、R8、R9，调用点 16 字节对齐，red zone 存在	-

💡

如何判断调用约定？

x86 看栈清理：

CALL 后紧跟 ADD ESP, X（如 add esp, 8）表示调用者清理栈（CDECL）。
函数末尾有 RET N（如 ret 8）表示被调用者清理栈（STDCALL）。

x64 默认约定：

Windows：前 4 个参数通过 RCX/RDX/R8/R9，其余通过栈。
Linux/macOS：前 6 个参数通过 RDI/RSI/RDX/RCX/R8/R9，其余通过栈。

三、动态修改函数参数

场景：将 j_stage1(32) 的参数改为 23。

原理：

如果参数通过寄存器（如 rdi）传递，在动调时直接修改寄存器值：set $rdi = 23。
如果参数通过栈传递，修改栈顶值：set {int}($esp) = 23。

断点设置与时机：在调用点前断开，或在被调函数入口断开

四、静态重定向call目标

函数跳转机制

call 指令本质是修改程序计数器（如 x86 的 eip/x64 的 rip），跳转到目标函数地址。

例如，call j_stage_2_fake 会将 rip 设置为 j_stage_2_fake 的地址。

替换函数调用-静态相对位移patch

场景：将 j_stage_2_fake() 替换为 j_stage_2_real()。

原理：

x86/x64 的 call rel32 编码形如 E8 xx xx xx xx，其中操作数是相对下一条指令地址的 32 位有符号位移。静态重定向时需重算位移：disp = target - next_ip。

💡

E8 XX XX XX XX 这个是call指令的机器码格式，其中的XX XX XX XX 是相对位移，即是目标地址相对于 “call 指令的下一条指令地址” 的有符号偏移量

若 call 指令在地址 0x1000，长度为 5 字节（E8 + 4 字节位移），则 next_ip = 0x1000 + 5 = 0x1005。

位移 disp 表示 “从 next_ip 到目标地址 target 的偏移”，即 target = next_ip + disp。

例如，将 call j_stage_2_fake 的操作数替换为 j_stage_2_real 的相对位移。

五、进阶方法

1.跳板（Trampoline）转发

适用：直接改 call 不方便，或想在“假函数”和“真函数”之间插入自己的逻辑（打印参数、检查条件、再转发）。

原理：把原本的 call 改成跳到“自定义跳板”。跳板里可以：

备份必要寄存器
可选地修改参数（按调用约定放到寄存器或栈）
跳转或调用真正的目标函数
恢复现场并返回

简化做法：

1) 在可执行的可写区域（或新分配 RX 内存）放几条指令作为跳板。

2) 把原 call 的目标改到跳板地址。

3) 在跳板里用最少指令完成“改参 → 调用 → 返回”。

注意点：

x64 SysV 调用点需要 16 字节对齐。
区分 caller-saved 与 callee-saved 寄存器，改前先备份，回去前恢复。
不要破坏原本应在寄存器里的参数位置（比如 SysV 前 6 个整数参数在 RDI…R9）。

2.IAT/PLT 级的重定向（针对库函数）

适用：想把对某个“库函数”的调用统统重定向，比如把 puts 换成自己的实现。

Windows 常见做法：

IAT 重写（修改导入表条目指向你的函数）。需要考虑目标进程内存可写性、签名、CFG 等限制。初学者可先在自己编译的小样本里练习。

Linux 两种思路：

1) 运行时层面的替换：LD_PRELOAD 预加载自己的动态库，在库里实现同名符号；真正需要时再用 dlsym(RTLD_NEXT, "puts") 调回原函数。

2) 二进制层面：改 .got/.plt 里的目标地址，要求你能准确定位并有可写权限；但遇到 RELRO 保护会受限。

六、常见坑

1. 为什么不直接修改源代码？

逆向工程中，我们通常只有编译后的二进制文件（如 .exe、.elf），没有原始源代码。此时：

静态修改：直接编辑二进制文件中的机器码（如用 IDA Pro 替换 call 指令的地址）。

动态修改：在程序运行时，通过调试器（如 GDB）临时修改内存或寄存器值。

而源代码级的修改（如将 j_stage1(32) 改为 j_stage1(23)）需要重新编译程序，这在很多场景下不可行（如没有源码、程序有数字签名等）。

2.ABI 关键约束

栈对齐：SysV AMD64 要求调用点 16 字节对齐~~（这里不对齐会崩溃）~~，Windows x64 有 32 字节 shadow space 约定。

寄存器保存：区分 caller-saved 与 callee-saved，避免误改导致不可预期崩溃。

可变参数与 SSE 寄存器：涉及浮点参数时，SysV 会用到 XMM 寄存器传参。

3.PIE 与 RIP 相对寻址

现代 Linux 默认 PIE，指令多用 RIP-relative。静态修改时要考虑 ASLR、PIE、RELRO 带来的地址与重定位影响。

七、总结：汇编层修改的本质

汇编是机器码的文本表示，直接反映了计算机执行程序的方式。在汇编层面修改程序，就是：

修改寄存器：改变函数参数、控制流程（如跳转条件）。

修改内存：

栈内存：改变函数参数、局部变量。
代码段：改变指令内容（如替换 call 目标）。