您已设置了一个简单的监听服务器来捕获 XSS 负载发送的数据。每当执行负载时，服务器日志都会显示接收到的数据，这正是我们现在要做的。您可以更改代码以捕获其他信息，例如 cookie、URL 等。
利用反射型XSS
现在，我们将演示一种利用反射型 XSS 漏洞捕获敏感用户输入（例如登录凭据）并将其发送到攻击者控制的服务器的高级技术。在本次演示中，我们将再次使用 DVWA。
步骤 1：导航到“反射型 XSS”部分
在您的网络浏览器中打开 DVWA，通常可以通过 访问http://localhost/dvwa。
使用提供的凭据登录或创建新帐户。
导航到“XSS”类别下的“反射型 XSS”部分。
步骤 2：制作有效载荷
现在，我们编写一个 JavaScript 有效负载，它在执行时会捕获用户在特定表单字段中输入的内容，并将其发送到您控制的服务器。
利用反射型XSS
现在，我们将演示一种利用反射型 XSS 漏洞捕获敏感用户输入（例如登录凭据）并将其发送到攻击者控制的服务器的高级技术。在本次演示中，我们将再次使用 DVWA。
步骤 1：导航到“反射型 XSS”部分
在您的网络浏览器中打开 DVWA，通常可以通过 访问http://localhost/dvwa。
使用提供的凭据登录或创建新帐户。
导航到“XSS”类别下的“反射型 XSS”部分。
步骤 2：制作有效载荷
现在，我们编写一个 JavaScript 有效负载，它在执行时会捕获用户在特定表单字段中输入的内容，并将其发送到您控制的服务器。
hook glbic的方法更多的只是用在用户态做阻拦，例如之前文章中通过LD_PRELOAD进行动态链接阻拦的方法如果通过sudo命令运行，或者使用syscall运行的时候就无法进行拦截
现在需要将我们的思维发散，在终端下实现whoami命令的时候，调用的其实是getuid()这个函数，所以我们要针对的是getuid
引入一个Liunx下一个非常特别的内核机制，eBPF。那么什么是eBPF。eBPF（Extended Berkeley Packet Filter） 是一种高效、灵活的 内核扩展 机制，允许开发者在 不修改内核代码 的情况下，在内核中 运行安全的自定义程序，用于 网络处理、安全监控、系统跟踪、性能优化 等，最关键的一个点是它不需要直接修改Linux相关的内核，保证了内核的安全，减少了系统崩溃的风险
现在需要将我们的思维发散，在终端下实现whoami命令的时候，调用的其实是getuid()这个函数，所以我们要针对的是getuid
引入一个Liunx下一个非常特别的内核机制，eBPF。那么什么是eBPF。eBPF（Extended Berkeley Packet Filter） 是一种高效、灵活的 内核扩展 机制，允许开发者在 不修改内核代码 的情况下，在内核中 运行安全的自定义程序，用于 网络处理、安全监控、系统跟踪、性能优化 等，最关键的一个点是它不需要直接修改Linux相关的内核，保证了内核的安全，减少了系统崩溃的风险
设计流程
1. 进程监控（eBPF kprobe / tracepoint）
○ 监听 execve() / execveat() 系统调用，获取用户执行的命令。
○ 提取 命令参数（argv），解析高危行为。
2. 黑名单匹配
○ 预设 高危命令列表（如 rm -rf /*、dd if=/dev/zero、nc -e /bin/sh）。
○ 支持模式匹配（正则表达式匹配危险行为）。
3. 安全策略
○ 允许（Pass）：普通命令执行不受影响。
○ 拦截（Block）：如果检测到高危命令，则阻断执行。
○ 记录（Log）：将日志存入 eBPF Map，供用户态程序分析。
4. 用户态交互
○ 用户态程序通过 eBPF Map 获取检测数据，发送 告警通知。
○ 支持 Syslog / SIEM / Webhook 进行日志采集与分析。
1. 进程监控（eBPF kprobe / tracepoint）
○ 监听 execve() / execveat() 系统调用，获取用户执行的命令。
○ 提取 命令参数（argv），解析高危行为。
2. 黑名单匹配
○ 预设 高危命令列表（如 rm -rf /*、dd if=/dev/zero、nc -e /bin/sh）。
○ 支持模式匹配（正则表达式匹配危险行为）。
3. 安全策略
○ 允许（Pass）：普通命令执行不受影响。
○ 拦截（Block）：如果检测到高危命令，则阻断执行。
○ 记录（Log）：将日志存入 eBPF Map，供用户态程序分析。
4. 用户态交互
○ 用户态程序通过 eBPF Map 获取检测数据，发送 告警通知。
○ 支持 Syslog / SIEM / Webhook 进行日志采集与分析。
某luo数据包加密逆向
抓包发现，大部分请求包和返回包都加密了，但是发现做了frida检测
第一种是使用修改过特征的frida-server
这里使用的是florida-server
找到用于检测的库，在它检测之前nop掉检测函数或者是直接删了这个so库
运行后发现在进入了libmsaoaidsec库后发生进程终止，说明这个库里存在检测机制
进入这个app文件夹里删了这个库
抓包发现，大部分请求包和返回包都加密了，但是发现做了frida检测
第一种是使用修改过特征的frida-server
这里使用的是florida-server
找到用于检测的库，在它检测之前nop掉检测函数或者是直接删了这个so库
运行后发现在进入了libmsaoaidsec库后发生进程终止，说明这个库里存在检测机制
进入这个app文件夹里删了这个库
jadx反编译源码搜索encrypt函数，
这里对genEAS函数的返回结果进行了base64编码，传入的参数src是encrypt接收的字符串，另一个也是字符串
查看一下genEAS函数
去掉空值检查和异常处理其实就是用AES算法对输入字符串数据基于给定密钥进行加密并返回加密后的字节数组
可以跟最基本的javax.crypto包提供的 AES 加密功能实现代码
可以看到genAES函数中填充方式为C8479a.f30298b，键入进去看一下，可以看到这个值为"AES/CBC/PKCS5Padding"
这里对genEAS函数的返回结果进行了base64编码，传入的参数src是encrypt接收的字符串，另一个也是字符串
查看一下genEAS函数
去掉空值检查和异常处理其实就是用AES算法对输入字符串数据基于给定密钥进行加密并返回加密后的字节数组
可以跟最基本的javax.crypto包提供的 AES 加密功能实现代码
可以看到genAES函数中填充方式为C8479a.f30298b，键入进去看一下，可以看到这个值为"AES/CBC/PKCS5Padding"
远程
还是先创建文件映射对象 然后映射到内存 写入shellcode
额外的一步是通过MapViewOfFile2 将本地文件视图映射到远程进程
MapViewOfFile2 与 MapViewOfFile 共享文件映射句柄 所以任何对本地映射视图中的有效载荷的任何修改都会反映在远程进程的远程映射视图中的文件中
注意进程句柄必须有PROCESS_VM_OPERATION 权限 所以这里创建完进程后通过OpenProcess指定PROCESS_VM_OPERATION再拿进程句柄 pi.hProcess不行
方便起见这里用CreateRemoteThread 如果这里用EarlyBird的话就是MapViewOfFile联动EarlyBird
还是先创建文件映射对象 然后映射到内存 写入shellcode
额外的一步是通过MapViewOfFile2 将本地文件视图映射到远程进程
MapViewOfFile2 与 MapViewOfFile 共享文件映射句柄 所以任何对本地映射视图中的有效载荷的任何修改都会反映在远程进程的远程映射视图中的文件中
注意进程句柄必须有PROCESS_VM_OPERATION 权限 所以这里创建完进程后通过OpenProcess指定PROCESS_VM_OPERATION再拿进程句柄 pi.hProcess不行
方便起见这里用CreateRemoteThread 如果这里用EarlyBird的话就是MapViewOfFile联动EarlyBird
通过篡改函数 导致函数执行其它逻辑
首先是通过loadlibrary加载dll到内存 然后通过GetProcAddress检索地址
这里篡改的函数需要是非常用的 否则可能会出现问题 这里选择bthprops.cpl中的BluetoothFindDeviceClose
首先是获取地址
LPVOID sacrificedAddr = GetProcAddress(LoadLibrary(L"bthprops.cpl"), "BluetoothFindDeviceClose");
修改内存权限为RWX 写入shellcode
首先是通过loadlibrary加载dll到内存 然后通过GetProcAddress检索地址
这里篡改的函数需要是非常用的 否则可能会出现问题 这里选择bthprops.cpl中的BluetoothFindDeviceClose
首先是获取地址
LPVOID sacrificedAddr = GetProcAddress(LoadLibrary(L"bthprops.cpl"), "BluetoothFindDeviceClose");
修改内存权限为RWX 写入shellcode
初步审计与漏洞检测
首先，我们通过get_rce_vulnerability_feedback函数对代码进行初步审计。如果LLM分析到存在潜在的RCE漏洞或不安全的命令执行调用，反馈将被用来生成修复建议。
自适应反馈机制
在初次审计后，adaptive_feedback_loop函数会启动自适应反馈机制。如果漏洞未能修复，LLM根据修复建议对代码进行修改，并再次进行审计。这个过程会持续进行多次，直到漏洞被彻底修复，或者达到最大尝试次数。
修复代码并重新审计
fix_code_and_reaudit函数接收LLM给出的修复建议，修改代码后再次审计，确保修复有效。如果反馈仍然指示有漏洞存在，过程会继续。
提取修复建议
在每一轮反馈中，extract_fix_suggestions函数提取LLM给出的修复步骤，帮助开发者理解如何修复漏洞，并确保后续代码不会再有类似问题。
首先，我们通过get_rce_vulnerability_feedback函数对代码进行初步审计。如果LLM分析到存在潜在的RCE漏洞或不安全的命令执行调用，反馈将被用来生成修复建议。
自适应反馈机制
在初次审计后，adaptive_feedback_loop函数会启动自适应反馈机制。如果漏洞未能修复，LLM根据修复建议对代码进行修改，并再次进行审计。这个过程会持续进行多次，直到漏洞被彻底修复，或者达到最大尝试次数。
修复代码并重新审计
fix_code_and_reaudit函数接收LLM给出的修复建议，修改代码后再次审计，确保修复有效。如果反馈仍然指示有漏洞存在，过程会继续。
提取修复建议
在每一轮反馈中，extract_fix_suggestions函数提取LLM给出的修复步骤，帮助开发者理解如何修复漏洞，并确保后续代码不会再有类似问题。