1.AnimeGANv2复现【动漫风格迁移】
2.ThinkPHP多语言rce复现分析
3.fastjson 1.2.24源码分析以及漏洞复现
4.mobile aloha代码解析和复现
5.notepad++堆缓冲区溢出漏洞CVE-2023-40031分析与复现
6.log4j2远程代码执行漏洞本地复现
AnimeGANv2复现【动漫风格迁移】
前几天，源码复现我看到了一篇关于AnimeGANv2复现的源码复现博客，觉得这个项目非常有趣，源码复现因此决定进行一次复现。源码复现在进行复现的源码复现过程中，我遇到了一些问题，源码复现重构源码现在我将这些问题分享给大家。源码复现
项目获取的源码复现方式有两种：首先，你可以通过Git Bash将代码克隆下来，源码复现或者直接在GitHub上下载压缩包并保存。源码复现
为了搭建环境，源码复现我使用了Python社区版、源码复现PyTorch、源码复现CUDA、源码复现cudnn以及Anaconda。源码复现以下是具体的配置步骤：
1. 首先下载并安装Anaconda，网上有许多教程可以参考。
2. 创建一个新的虚拟环境。
3. 下载适用于你电脑的CUDA和cudnn版本。
4. 访问PyTorch官网获取对应版本的安装命令。
5. 打开Anaconda Prompt，输入activate [你的环境名称]激活环境，然后输入安装PyTorch的命令。
6. 接着，在Anaconda Navigator中找到新创建的环境，并安装OpenCV。
7. 安装Python社区版后，打开文件。
配置完成后，我们就可以进行项目运行了。在博客中提到可以直接输入命令，但在实际操作中我遇到了一些问题：
1. 大小问题，博客中没有明确提及这一点。代码并未对图像进行预处理，我最初以为代码中包含了这个步骤，结果却因为大小过大而导致显存不足。越大，字符动画源码大全需要的显存越多。因此，在输入时需要进行裁剪（如果你的预算允许的话）。如果仍然遇到显存不足的情况，建议使用CPU。
2. 输入命令时，需要指定目录，这里的目录指的是文件夹而非单个图像。
3. 模型文件的路径在源码中默认存在一些问题，代码中的默认路径并不存在，所以需要更改所有路径。模型文件共有四个权重文件，你可以根据个人喜好选择使用。
建议大家先进行初步的配置并尝试运行，避免每次遇到问题都需重新配置，这样会比较麻烦。
我复现的结果如下：
原：...
处理后的：...
总体而言，这个项目非常有趣，我计划后续对视频进行处理，并对代码进行优化。如果有任何问题，欢迎在评论区留言。这篇文章使用了Zhihu On VSCode进行创作和发布。
ThinkPHP多语言rce复现分析
前言
最近对 ThinkPHP 多语言远程代码执行 (RCE) 漏洞进行了一番深入学习，该漏洞在特定版本的 ThinkPHP 中存在，本文将详细分析其利用条件、环境搭建、漏洞流程以及漏洞复现的过程。
一、漏洞信息
利用该漏洞，需满足以下条件：
1. 确保已安装 ThinkPHP，并知道 pearcmd.php 文件的位置（默认为 /usr/local/lib/php/pearcmd.php，Docker 版本镜像中 pear 默认已安装）
2. 需开启 php.ini 中的 register_argc_argv 选项（Docker 的 PHP 镜像是默认开启的）
3. ThinkPHP 需开启多语言功能
影响范围：
主要影响 ThinkPHP 版本在 6.0.1、5.0.0、5.1.0 以下至对应补丁修复版本的用户。
二、co指标源码图环境搭建
首先，从 GitHub 下载 ThinkPHP 源码（例如，版本为 6.0.），解压后，通过 composer 安装依赖。在 app/middleware.php 文件中取消注释以开启多语言功能。接着，通过 go-pear.phar 或 Docker 安装 pear。
三、漏洞分析
漏洞主要在于 LoadLangPack 类中的 handle 函数，该函数先通过 detect() 方法检查请求参数是否设置了语言，之后将设置值返回并用于切换语言集。在传递给 load() 函数后，参数又传入 parse() 函数，直接用 include 包含文件，此为漏洞触发点。从获取参数到传入 parse() 函数前，均未对内容进行过滤。
四、漏洞复现
在测试环境中（macOS、PHP 7.3、Apache 2.4），通过以下步骤进行复现：
1. 验证 pearcmd 的存在，获取正确路径（当前环境为 /usr/local/pear/share/pear/pearcmd.php）。
2. 了解如何利用 pear，在开启 register_argc_argv 选项后，参数将作为 $_SERVER['argv'] 的一部分传入。
3. 使用 poc 测试，在 /tmp 目录下写入 admin.php 文件，确保正确写入，验证参数解析过程。
4. 利用文件包含访问写入的文件，实现漏洞复现。
注意，除了使用 config-create 命令，还可以使用 Install 命令进行下载操作。题库源码微擎若喜欢本文，别忘了点赞与收藏。关注雷石安全实验室，获取更多网络安全知识与技术文章。
fastjson 1.2.源码分析以及漏洞复现
反序列化，这个过程将字节序列恢复为Java对象。例如在使用Python做自动化测试时，通过字符串名字调用相同名字的方法。Fastjson的功能允许通过字符串引用如`@type":"com.sun.rowset.JdbcRowSetImpl`来执行内部方法。由此，我们能利用Fastjson提供的便利，通过调用对应的函数来验证漏洞。
在渗透测试中，漏洞的验证通常需要满足几个条件：判断指纹和指纹回显，Fastjson的特性使得这一步变得简单。然而，在利用过程中，要考虑到Fastjson本身的限制、JDK的限制以及可能的安全配置限制。因此，POC验证方案需考虑这些限制的版本和配置。
Fastjson通过JSON抽象类实现JSONAware接口，并提供两个常用方法：`toJSONString`用于对象转换为JsonString，`parseObject`用于将JSON字符串转换为对象。这次的漏洞主要与反序列化相关。
反序列化的执行发生在`DefaultJSONParser.java`类中。关键代码中，固定键`@type`对应反序列化类的全路径，其中`typeName`为传入类的全路径。在Fastjson 1.2.版本中，`loadClass`方法未进行任何过滤，允许传入任何JVM加载的类，并执行`setKey`方法，其中Key为可变参数。
要利用这个反序列化漏洞，需要满足以下条件：JVM加载的买卖图指标源码类、有非静态set方法和传入一个参数。使用RPC远程执行代码的思路实现POC，此处使用了`com.sun.rowset.JdbcRowSetImpl`实现。
JNDI全称为Java Naming and Directory Interface，主要提供应用程序资源命名与目录服务。其底层实现之一是RMI（Remote Method Invocation），用于Java环境的远程方法调用。在`com.sun.rowset.JdbcRowSetImpl`类中，关注点在于`getDataSourceName()`和`setAutoCommit()`方法。`getDataSourceName()`用于传值，`setAutoCommit()`用于确认调用set方法。
实现过程包括引用`com.sun.rowset.JdbcRowSetImpl`类、设置`dataSourceName`传值以及通过`autoCommit`属性触发执行方法。完成方法确认后，使用`marshalsec`项目启动RMI服务并加载远程类。
POC的实现步骤如下：首先确认目标是否使用Fastjson且存在漏洞；利用Fastjson的反序列化功能传输引用类和执行方法；使用`com.sun.rowset.JdbcRowSetImpl`执行验证POC的脚本，并观察回显结果；最后，完成漏洞利用。
具体操作包括搭建环境，如使用CentOS虚拟机作为RMI服务器和远程调用服务，KALI机器作为靶机和抓包测试。进行指纹确认、安装maven、构建RMI服务器和客户端、调用测试文件，并观察DNS日志以验证漏洞成功利用。通过DNS日志确认漏洞利用成功后，可以进一步尝试反弹shell，实现远程控制。
综上所述，Fastjson的反序列化漏洞是一个可以被利用的安全问题，通过合理的利用，可以实现远程代码执行。了解和研究这类漏洞有助于增强对Fastjson以及类似技术的防御能力。
mobile aloha代码解析和复现
本文基于 mobile-aloha的开源代码复现工作，分为四大部分：下载与修改源代码、安装依赖、准备数据集、训练与评估。
首先，下载仓库源代码，链接为：github.com/MarkFzp/act-plus-plus。注意，源代码中存在一些小错误或说明不清，已做修改。可直接pull本仓库代码。
为简化步骤，使用requirements.txt文件通过pip安装依赖。部分代码错误已解决，可直接pull代码。
运行代码前，确认默认代码使用wandb进行日志记录和可视化。若希望自行可视化，修改wandb用户名和key，查看相关教程。默认代码使用wandb，自定义设置账号。
数据集分为实际采集和仿真两种。实际数据需下载解压，确保路径正确。仿真数据集通过特定脚本可视化，实际数据集则使用不同脚本处理。
训练过程包括数据准备、训练和评估。下载数据、执行训练脚本并选择适当任务。使用预设参数训练策略，记录训练过程。评估策略时，考虑策略表现和潜在改进。
算法实现细节解析中，mobile-aloha核心为ACT算法，模仿学习过程通过行为克隆、GAN、VAE等模型实现。VAE架构包含编码器、隐变量、解码器。编码器输出高斯分布，解码器预测动作序列。推理阶段隐变量设置为标准高斯分布。
文章结束处提及后续研究方向，包括泛化性、任务适应性和结合大模型等。对代码理解不清晰或有遗漏之处，欢迎指出。
notepad++堆缓冲区溢出漏洞CVE--分析与复现
Notepad++，这款备受推崇的开源代码编辑器，近期曝出了一处高危漏洞CVE--，得分为7.8分（CVSS3）。漏洞焦点在于Utf8__Read::convert函数，其在执行UTF-到UTF-8转换时，错误估计了转换后缓冲区的大小，导致缓冲区外内存被非法覆盖，可能导致代码执行权限的滥用。此漏洞影响了Notepad++版本<=8.5.6，复现环境为Win7 SP1，使用IDA、WinDbg和OLLYDBG等工具可验证。
安全研究人员通过Python生成PoC（Proof-of-Concept）文件，尝试在8.5.2版本的Notepad++中打开，虽然程序未崩溃，但溢出数据可能未触发明显异常。借助Windbg调试工具，可以看到在堆检查中，当打开PoC文件时，堆溢出在地址0xF4AFF8，溢出点在HeapFree函数中，内存已受损。
源码的可读性使得安全专家能够利用AddressSanitizer技术定位问题，最终发现溢出发生在Utf8__Read::convert的特定代码行。函数首先申请大小为len的缓冲区，然后尝试复制UTF-数据，关键在于每次读取文件内容时，大小计算错误导致溢出。例如，第一次读取0x字节，第二次读取时，由于未清除上一次读取的内容，导致新缓冲区大小计算错误，从而引发溢出。
总的来说，当文件内容编码为奇数时，且在UTF-到UTF-8转换过程中，计算错误可能导致一个字节的溢出。虽然off-by-one漏洞通常难以直接利用，但需要额外技巧结合其他漏洞利用技术，如内存泄漏或数据覆盖，以实现代码执行控制（RCE）。更多详细信息可参考github.com/webraybtl/CV...链接。
log4j2远程代码执行漏洞本地复现
本文仅供学习参考，请勿在真实环境进行网络攻击行为。
一、背景
Log4j 2 是 Java 中应用非常广泛的一个日志框架，在 年底，一个名为 CVE--（也称为 Log4Shell）的严重漏洞被发现，该漏洞被CVSS评为分最高级别。网络攻击者利用这个漏洞不需要服务器密码就可以访问并操作服务器，攻击方式非常简单，技术门槛低，危害极大。受影响版本：Apache log4j2 2.0 - 2..1 下面先简单看一下攻击原理，然后直接开始操作。
二、攻击原理
假设现在有个网站，当用户登录时，正常请求路径如下：
如果应用服务端的登录接口中使用漏洞版本的log4j2打印请求参数的日志，就有可能被注入。如图所示：
三、复现步骤
以下代码已放在github仓库：log4j漏洞复现代码
1. jdk版本
作者使用jdk1.8.0_和1.8.0_复现成功，1.8.0_复现失败。
JDK 6u、7u、8u之后：增加了com.sun.jndi.ldap.object.trustURLCodebase选项，默认为false，禁止LDAP协议使用远程codebase的选项，把LDAP协议的攻击途径也给禁了。
使用1.8.0_的情况下，将trustURLCodebase属性设置为true也没复现成功，原因暂未深究。
2. 模拟被攻击的应用服务器
写一个springboot项目，模拟被攻击的应用服务端登录接口，接口中打印了userName参数日志，启动此项目。端口为。访问地址为 .0.0.1:/login
3. 编写恶意代码
写一个在应用服务端执行的恶意代码，这里用删除一个服务器文件做演示，实际上可以使用反弹shell等做更多有害操作。编译这个类，生成class文件。
4. 启动/zchrissirhcz...
3. Linux下的运行结果和分析
3.1 运行结果： 使用 SYSTEM 后， 头文件 hello/hello.h 不再触发编译报错
3.2 检查 compile_commands.json 里的具体编译命令, -I 被 -isystem 替代
3.3 -I 和 -isystem 的区别是什么? man gcc 可以知道, 被 -isystem 指定的目录， 会被当作标准系统目录对待:
而人们提到的
-isystem
会忽略自行在 makefile/CMakeLists.txt 中指定的 warning, 可以在 gcc 在线文档中找到：
3.4include_directories() 和 target_include_directories() 也可以用 SYSTEM 在 How to suppress GCC warnings from library headers? 问答中， 有人提到可以在 include_directories() 中指定 SYSTEM 关键字来抑制编译警告：
查看文档得到验证：
实际上，
target_include_directories()
也可以用
SYSTEM
关键字， 也是生成
-isystem
的编译命令：
查看 compile_commands.json 验证：
4. 使用 -isystem 的进一步探讨
4.1 -Wsystem-headers 开启 system headers 的 warning man gcc 可以知道， 提供的 -Wsystem-headers 编译选项， 是把 system headers 里的警告开启， 也就是说当你用 -isystem 指定了一个三方库路径后， 如果想开启它里面的 warning， 可以用 -I 替代 -isystem 来开启 warning， 也可以用 -Wsystem-headers 来开启 warning：
4.2 使用 -fsystem-headers 的提议 (尚未实现)
在 Bug - Create hybrid of -I and -isystem that is like -I but deactivates warnings 中有人提到， 人们使用 -isystem /some/path 替代 -I /some/path， 有点滥用系统头文件路径的问题， 考虑让 gcc 增加 -fsystem-headers 参数， 进而使用:
来让/some/path 被搜索时忽略警告。 不过这个 feature 尚未实现。
5. MSVC 下的结果
MSVC 使用/I， 和 GCC 的 -I 对应； MSVC 使用 /externel:W0, 和 GCC 里的 -isystem 对应。
作为实验， 先前-Werror=shadow 的写法， 在 MSVC 下要更换为：
6. 总结
CMake 中， 有如下几个命令， 都可以使用SYSTEM 关键字， 使得被添加的头文件搜索目录中， 头文件里的 warning 完全被编译器忽略：
上述这些 cmake 命令， 是映射-I dir 为 -isystem dir， 根据 GCC 文档， -isystem 指定的 dir 被当作标准系统头文件目录：
由于编译器本身忽略了-isystem 指定目录中的警告， 那么开发者在 CMakeLists.txt 里指定的 treat warnings as errors 的设定， 由于没捕获到这些目录里的 waring， 因而不会触发编译报错。 这是一种避免陷入修改第三方库头文件源码的方法， 它仅对于头文件有效， 对于 add_subdirectories() 引入的源代码文件 (.c/.cpp) 不起作用。
在 GCC 和 MSVC 下，SYSTEM 关键字都起作用。
7. References
本文使用 Zhihu On VSCode 创作并发布
