Gin Blog

五月AI-SRC赏金记录

Mon, 01 Jun 2026 00:00:00 GMT

五月七零八散赏金破万，没有努力，全靠 AI 的辛勤付出和好师傅们的带飞，感谢所有带飞我的师傅们！

五月赏金1

五月赏金2

AI渗透初步成果

Fri, 22 May 2026 00:00:00 GMT

AI 在应用层面上已经远超预期，无论在黑盒测试还是白盒测试都已经达到了非常夸张的效果，在常规测试下无疑是降维打击。个人认为工作流的搭建对于 AI 实际应用中的效果非常的夸张，研究了很长一段时间的 AI，在现阶段也取得了一些微薄的成果，SSRF 以及 RCE 也都有产出，非常感谢朋友们对于我思路的认可！

成果1

成果2

再唱十年！！！

Fri, 17 Apr 2026 00:00:00 GMT

再唱十年！！！

再唱十年

小记录

Tue, 07 Apr 2026 00:00:00 GMT

两年没有逆向了，依旧宝刀未老！

再晒一下厦大，老师也有格局，狠狠支持！

051

052

053

054

055

056

MCP 统一入口设计思路

Wed, 11 Mar 2026 00:00:00 GMT

概述 MCP（Model Context Protocol）架构采用统一入口设计模式，将原本分散的多个功能整合到单一的工具接口中，通过 `action` 参数区分不同的子操作。这种设计大幅”#

tags: [“开发”]#

MCP 统一入口设计思路#

概述#

MCP（Model Context Protocol）架构采用统一入口设计模式，将原本分散的多个功能整合到单一的工具接口中，通过 action 参数区分不同的子操作。这种设计大幅减少了工具数量，提高了系统的可维护性和易用性。

设计动机#

问题 1：工具泛滥#

如果有 20 个功能模块，每个模块有 5-6 个操作，会产生 100+ 个 MCP 工具：

工具过多导致 Agent 难以选择
增加调用错误的概率
Agent 需要记忆大量工具名称

问题 2：功能分散#

相似功能分散在不同工具中：

代码重复严重
维护和扩展困难
需要在多个工具中同步修改

问题 3：接口不一致#

不同工具的参数命名、返回格式不统一：

Agent 需要记忆每个工具的特殊用法
增加学习成本
容易出错

统一入口的定义#

公式：统一入口 = 单一 MCP 工具 + action 参数 + 多个子操作

对比示例#

传统方式：多个独立工具#

1
# 6 个独立工具
2
@tool
3
def search_knowledge(query: str, ...) -> str: ...
4

5
@tool
6
def add_knowledge(content: str, ...) -> str: ...
7

8
@tool
9
def get_detail_knowledge(entry_id: str) -> str: ...
10

11
@tool
12
def export_knowledge() -> str: ...
13

14
@tool
15
def list_backups() -> str: ...
16

17
@tool
18
def restore_backup(backup_file: str) -> str: ...

展开收起

统一入口方式：1 个工具 + action 参数#

1
@tool(name='knowledge')
2
def knowledge(
3
    action: str,
4
    query: Optional[str] = None,
5
    content: Optional[str] = None,
6
    entry_id: Optional[str] = None,
7
    backup_file: Optional[str] = None,
8
    ...
9
) -> str:
10
    """知识库统一入口 - 整合 6 个知识库相关工具"""
11
    if action == 'search': ...
12
    elif action == 'add': ...
13
    elif action == 'get_detail': ...
14
    elif action == 'export': ...
15
    elif action == 'list_backups': ...
16
    elif action == 'restore': ...

展开收起

效果：工具数量从 6 个减少到 1 个，减少 83%

架构分层#

MCP 架构中的统一入口分为三个层次：

核心层统一入口（逻辑断层相关）#

工具名	功能描述	支持的操作
`context`	防遗忘统一入口	`get_planner_summary` / `get_reflector_summary` / `add_objective` / `clear`
`context_compress`	上下文压缩统一入口	`should_compress` / `compress` / `get_history` / `clear`
`reflector`	反思器统一入口	`reflect_execution` / `reflect_batch` / `reflect_global` / `get_insights` / `get_patterns` / `get_vetoed` / `clear_veto`
`failure_attribution`	失败归因统一入口	`attribute` / `get_stats` / `clear`
`planner`	规划器统一入口	`initial_plan` / `dynamic_plan` / `get_history` / `get_rejected` / `add_rejected`
`agent`	P-E-R Agent 统一入口	`run`

功能层统一入口（渗透测试相关）#

工具名	功能描述	支持的操作
`knowledge`	知识库统一入口	`search` / `add` / `get_detail` / `export` / `list_backups` / `restore`
`param_library`	参数库统一入口	`extract_js` / `extract_response` / `get_common` / `get_for_api` / `stats` / `save`
`browser`	浏览器操作统一入口	`navigate` / `screenshot` / `capture` / `interactive` / `list` / `close`
`session`	会话管理统一入口	`add` / `get` / `clear` / `list`
`llm`	LLM 操作统一入口	`analyze` / `report` / `enhance` / `status` / `set_key`
`pentest_tools`	渗透测试工具统一入口	`list` / `run` / `recommend` / `guidelines`
`workflow`	工作流管理统一入口	`set_target` / `status` / `recommend` / `plan` / `finding` / `complete`
`file_operation`	文件操作统一入口	`write` / `classify` / `organize` / `info`
`dev_tools`	开发工具统一入口	`predev_check` / `opt_record` / `opt_list` / `opt_view` / `dev_start` / `dev_complete` / `dev_status` / `dev_register` / `dev_list`
`mcp_log`	MCP 日志统一入口	`list` / `stats` / `session` / `clear`

专项工具统一入口#

工具名	功能描述	支持的操作
`miniprogram_decompiler`	微信小程序反编译工具	解包 / 扫描 / 提取 API / 分析签名

实现模式#

命令模式（Command Pattern）#

每个统一入口都是一个命令处理器，通过 action 参数区分不同的子命令：

1
@self._logged_tool(name='context', description='【防遗忘统一入口】上下文管理')
2
async def context(
3
    action: str = Field(description='操作类型：get_planner_summary/get_reflector_summary/add_objective/clear'),
4
    objective: Optional[str] = Field(default=None, description='长期目标（add_objective 时必填）'),
5
    goal: Optional[str] = Field(default=None, description='长期目标别名')
6
) -> str:
7
    """防遗忘统一入口 - 管理上下文和防止遗忘"""
8
    try:
9
        if not self.context_manager:
10
            return "错误：context_manager 未初始化"
11

12
        if goal and not objective:
13
            objective = goal
14

15
        if action == 'get_planner_summary':
16
            # 处理子命令 1
17
            summary = self.context_manager.get_planner_summary()
18
            return format_summary(summary)
19

20
        elif action == 'get_reflector_summary':
21
            # 处理子命令 2
22
            summary = self.context_manager.get_reflector_summary()
23
            return format_summary(summary)
24

25
        elif action == 'add_objective':
26
            # 处理子命令 3（需要额外参数）
27
            if not objective:
28
                return "错误：add_objective 操作需要 objective 参数"
29
            self.context_manager.add_long_term_objective(objective)
30
            return f"✅ 长期目标已添加：{objective}"
31

32
        elif action == 'clear':
33
            # 处理子命令 4
34
            self.context_manager.clear_planner_context()
35
            self.context_manager.clear_reflector_context()
36
            return "✅ 所有上下文已清空"
37

38
        else:
39
            return f"错误：未知的操作类型 '{action}'"
40

41
    except Exception as e:
42
        return f"错误：{str(e)}"

展开收起

参数验证模式#

统一入口通过参数验证确保子命令的正确执行：

1
@self._logged_tool(name='planner', description='【逻辑断层统一入口】规划器')
2
async def planner(
3
    action: str = Field(description='操作类型：initial_plan/dynamic_plan/get_history/get_rejected/add_rejected'),
4
    goal: Optional[str] = Field(default=None, description='目标（initial_plan/dynamic_plan 时必填）'),
5
    context: Optional[str] = Field(default=None, description='上下文（JSON 格式字符串）'),
6
    strategy_name: Optional[str] = Field(default=None, description='策略名称（add_rejected 时必填）'),
7
    reason: Optional[str] = Field(default=None, description='原因（add_rejected 时必填）')
8
) -> str:
9
    """逻辑断层统一入口 - 规划器操作"""
10
    try:
11
        if action == 'initial_plan':
12
            # 验证必填参数
13
            if not goal:
14
                return "错误：initial_plan 操作需要 goal 参数"
15
            ctx = json.loads(context) if context else None
16
            result = self.planner.initial_plan(goal, ctx)
17
            return format_result(result)
18

19
        elif action == 'add_rejected':
20
            # 验证多个必填参数
21
            if not strategy_name or not reason:
22
                return "错误：add_rejected 操作需要 strategy_name 和 reason 参数"
23
            self.planner.add_rejected_strategy(strategy_name, reason)
24
            return f"✅ 策略已标记为拒绝：{strategy_name}"

展开收起

结果格式化模式#

统一入口使用一致的格式返回结果：

1
def format_result(result: Dict) -> str:
2
    """统一的结果格式化"""
3
    lines = ["=" * 70, "📋 标题", "=" * 70]
4

5
    # 添加关键指标
6
    lines.append(f"指标 1: {result.get('key_metric_1')}")
7
    lines.append(f"指标 2: {result.get('key_metric_2')}")
8

9
    # 添加列表内容
10
    if 'items' in result:
11
        lines.append("\n【列表内容】:")
12
        for item in result['items']:
13
            lines.append(f"  - {item}")
14

15
    lines.append("=" * 70)
16
    return "\n".join(lines)

展开收起

关键技术细节#

工具注册装饰器#

统一入口通过装饰器自动注册到 MCP 服务器：

1
def _logged_tool(self, name, description):
2
    """带日志记录的工具装饰器工厂"""
3
    def decorator(func):
4
        # 1. 创建带日志包装的工具函数
5
        logged_func = self._create_logged_tool(name, func)
6

7
        # 2. 注册到 FastMCP 服务器
8
        self.server.tool(name=name, description=description)(logged_func)
9

10
        # 3. 自动记录到 registered_tools 字典
11
        if not hasattr(self, 'registered_tools'):
12
            self.registered_tools = {}
13
        self.registered_tools[name] = logged_func
14

15
        return logged_func
16
    return decorator

展开收起

ToolRouter 的参数映射#

统一入口通过 ToolRouter 进行参数映射，解决 Planner 与工具之间的参数名不匹配问题：

1
def _map_tool_arguments(self, tool_name: str, args: Dict[str, Any]) -> Dict[str, Any]:
2
    """根据工具名映射参数"""
3
    mapped_args = args.copy()
4
    tool_name_lower = tool_name.lower()
5

6
    # 处理 target_url -> url（browser, http_request 等）
7
    if 'target_url' in mapped_args:
8
        if 'browser' in tool_name_lower or 'http_request' in tool_name_lower:
9
            mapped_args['url'] = mapped_args.pop('target_url')
10

11
    # 处理 target -> goal（ai_pentest）
12
    if 'target' in mapped_args:
13
        if 'ai_pentest' in tool_name_lower:
14
            mapped_args['goal'] = mapped_args.pop('target')
15

16
    return mapped_args

展开收起

异步调用与重试机制#

统一入口支持异步调用和自动重试：

1
async def call_tool(
2
    self,
3
    tool_name: str,
4
    args: Optional[Dict[str, Any]] = None,
5
    max_retries: int = 3,
6
    timeout: int = 300
7
) -> Dict[str, Any]:
8
    """调用 MCP 工具（带重试机制）"""
9

10
    tool_func = self.registered_tools[tool_name]
11
    args = args or {}
12

13
    for attempt in range(1, max_retries + 1):
14
        try:
15
            if asyncio.iscoroutinefunction(tool_func):
16
                result = await asyncio.wait_for(
17
                    tool_func(**args),
18
                    timeout=timeout
19
                )
20
            else:
21
                result = await asyncio.wait_for(
22
                    asyncio.get_event_loop().run_in_executor(
23
                        None, lambda: tool_func(**args)
24
                    ),
25
                    timeout=timeout
26
                )
27

28
            return result
29

30
        except asyncio.TimeoutError:
31
            if attempt == max_retries:
32
                return {
33
                    "success": False,
34
                    "error": f"工具调用超时：{tool_name} (>{timeout}s)",
35
                    "attempts": attempt
36
                }
37
            await asyncio.sleep(1 * attempt)  # 指数退避
38

39
        except Exception as e:
40
            if attempt == max_retries:
41
                return {
42
                    "success": False,
43
                    "error": f"工具执行失败：{str(e)}",
44
                    "attempts": attempt
45
                }
46
            await asyncio.sleep(1 * attempt)

展开收起

设计优势#

减少工具数量#

方案	工具数量	Agent 选择难度
传统方式	100+ 个独立工具	高（容易选错）
统一入口	17 个统一入口	低（清晰明确）

工具数量减少：约 85%

提高可维护性#

传统方式：

1
# 修改搜索逻辑需要改 3 个地方
2
def search_knowledge_v1(...): ...
3
def search_knowledge_v2(...): ...
4
def search_knowledge_by_category(...): ...

统一入口方式：

1
# 修改搜索逻辑只需改 1 个地方
2
def knowledge(action: str, ...):
3
    if action == 'search':
4
        # 统一的搜索逻辑

增强一致性#

所有统一入口遵循相同的设计模式：

1
# 1. 统一的参数命名
2
action: str = Field(description='操作类型')
3

4
# 2. 统一的错误处理
5
try:
6
    # 业务逻辑
7
except Exception as e:
8
    return f"错误：{str(e)}"
9

10
# 3. 统一的结果格式
11
lines = ["=" * 70, "标题", "=" * 70]
12
return "\n".join(lines)

便于扩展#

添加新子操作只需在现有统一入口中添加分支：

1
@self._logged_tool(name='context', description='【防遗忘统一入口】上下文管理')
2
async def context(action: str, ...) -> str:
3
    # 原有操作
4
    if action == 'get_planner_summary': ...
5
    elif action == 'get_reflector_summary': ...
6

7
    # ✅ 新增操作（不影响现有功能）
8
    elif action == 'export_context':
9
        # 新功能
10
        pass
11

12
    # ✅ 继续添加更多操作...

设计模式总结#

命令模式（Command Pattern）#

应用：通过 action 参数区分不同子操作
优势：将请求封装为对象，支持参数化和队列化

适配器模式（Adapter Pattern）#

应用：ToolRouter 适配 Planner 与 MCP 工具
优势：解决接口不匹配问题

单例模式（Singleton Pattern）#

应用：各组件（context_manager, planner, reflector 等）全局唯一
优势：确保状态一致性

工厂模式（Factory Pattern）#

应用：_logged_tool 装饰器工厂
优势：统一工具注册逻辑

策略模式（Strategy Pattern）#

应用：Planner 根据上下文选择不同规划策略
优势：灵活切换算法

观察者模式（Observer Pattern）#

应用：Reflector 观察执行结果并反思
优势：解耦观察者和被观察者

最佳实践#

命名规范#

1
# ✅ 好的命名：清晰表达功能领域
2
'context'      # 上下文管理
3
'reflector'    # 反思器
4
'planner'      # 规划器
5
'knowledge'    # 知识库
6
'param_library' # 参数库
7

8
# ❌ 避免模糊命名
9
'tool1'        # 无意义
10
'manager'      # 太宽泛

Action 参数设计#

1
# ✅ 使用枚举式字符串
2
action: str = Field(
3
    description='操作类型：search/add/get_detail/export'
4
)
5

6
# ✅ 在 docstring 中明确说明
7
"""
8
知识库统一入口 - 整合 6 个知识库相关工具
9

10
操作类型:
11
  - search: 搜索知识
12
  - add: 添加知识
13
  - get_detail: 获取详情
14
  - export: 导出知识库
15
"""

展开收起

参数验证#

1
# ✅ 清晰标注必填参数
2
if action == 'add':
3
    if not content:
4
        return "错误：add 操作需要 content 参数"
5

6
# ✅ 使用类型提示
7
action: str
8
query: Optional[str]
9
limit: int = 5

错误处理#

1
# ✅ 统一的错误处理模式
2
try:
3
    # 业务逻辑
4
    if not self.component:
5
        return f"错误：{component_name} 未初始化"
6

7
    # 参数验证
8
    if action == 'xxx' and not required_param:
9
        return f"错误：{action}操作需要{param_name}参数"
10

11
    # 执行逻辑
12
    result = self.component.do_something()
13
    return format_result(result)
14

15
except Exception as e:
16
    return f"错误：{str(e)}"

展开收起

架构图#

1
┌─────────────────────────────────────────────────────────┐
2
│                    Agent (Executor)                      │
3
└────────────────────┬────────────────────────────────────┘
4
                     │
5
                     ▼
6
┌─────────────────────────────────────────────────────────┐
7
│                    ToolRouter                            │
8
│  • 工具路由  • 参数映射  • 重试机制  • 超时控制          │
9
└────────────┬─────────────────────────────────┬──────────┘
10
             │                                 │
11
             ▼                                 ▼
12
    ┌─────────────────┐              ┌─────────────────┐
13
    │  核心层统一入口  │              │  功能层统一入口  │
14
    ├─────────────────┤              ├─────────────────┤
15
    │ context         │              │ knowledge       │
16
    │ context_compress│              │ param_library   │
17
    │ reflector       │              │ browser         │
18
    │ failure_attrib. │              │ session         │
19
    │ planner         │              │ llm             │
20
    │ agent           │              │ pentest_tools   │
21
    └─────────────────┘              │ workflow        │
22
                                     │ file_operation  │
23
                                     │ dev_tools       │
24
                                     │ mcp_log         │
25
                                     └─────────────────┘

展开收起

总结#

MCP 架构中的统一入口设计体现了以下核心思想：

化繁为简：将 100+ 个工具精简为 17 个统一入口
模式统一：所有统一入口遵循相同的设计模式
易于扩展：添加新功能不影响现有代码
高内聚低耦合：每个统一入口负责一个功能领域
用户体验优先：减少 Agent 的选择负担，提高调用准确性

这种设计模式不仅适用于 MCP 架构，也可以应用到其他需要管理大量工具/命令的系统中。

文档生成时间: 2026-03-11
文档版本: v1.0
作者: MCP Architecture Team

小聚

Mon, 09 Mar 2026 00:00:00 GMT

久违了。

小聚1

小聚2

小聚3

AI Pentest Agent 架构分析报告

Sat, 14 Feb 2026 00:00:00 GMT

基于朋友的开发思路，我进行了改进 ## 一、防止灾难性遗忘（Catastrophic Forgetting Prevention） ### 1.1 问题定义在长时间渗透测试任务中，LLM 的上下文窗口有限，随着对话轮次增加，早期的关键信息（发现的漏洞、失败的策略、目标特征等）会因上下文截断而丢失，导致 Agent 重复尝试已失败的方法或遗忘” tags: [“开发”]#

AI Pentest Agent 架构分析报告#

基于朋友的开发思路，我进行了改进

一、防止灾难性遗忘（Catastrophic Forgetting Prevention）#

1.1 问题定义#

在长时间渗透测试任务中，LLM 的上下文窗口有限，随着对话轮次增加，早期的关键信息（发现的漏洞、失败的策略、目标特征等）会因上下文截断而丢失，导致 Agent 重复尝试已失败的方法或遗忘已发现的攻击面。

1.2 多层防遗忘架构#

项目通过 4 层机制 协同工作来对抗灾难性遗忘：

第一层：持久化上下文对象（Persistent Context Objects）#

ai_pentest/context/manager.py:16-31 定义了两个关键的持久化上下文对象：

1
class PlannerContext(BaseModel):
2
    """规划器上下文对象，保存历史规划信息"""
3
    planning_history: List[Dict[str, Any]] = []        # 所有规划尝试的完整记录
4
    rejected_strategies: Dict[str, str] = {}            # 被拒绝的策略及原因
5
    long_term_objectives: List[str] = []                # 长期战略目标
6
    latest_reflection_report: Optional[Dict[str, Any]]  # 最新反思报告
7
    previous_planning_session: Optional[Dict[str, Any]] # 上一次规划会话
8

9
class ReflectorContext(BaseModel):
10
    """反思器上下文对象，保存历史反思信息"""
11
    reflection_log: List[Dict[str, Any]] = []           # 反思日志
12
    validated_patterns: List[Dict[str, Any]] = []       # 已验证的攻击模式
13
    persistent_insights: List[Dict[str, Any]] = []      # 持久化洞察

这些对象独立于 LLM 对话历史存在，即使对话被压缩，这些结构化数据仍然保留。

关键代码：ai_pentest/context/manager.py:146-182 中的 update_planner_context() 方法持续追加规划历史、被拒策略和反思报告。被拒策略使用 Dict[str, str] 存储，key 为策略名，value 为拒绝原因，确保 Planner 不会重复提出已被否决的方案。

第二层：智能上下文压缩（LLM-based Context Compression）#

ai_pentest/context/compression.py:13-21 实现了三策略触发的压缩机制：

1
class ContextCompressor:
2
    """
3
    基于三种策略进行智能压缩：
4
    1. 消息数量阈值（默认 50 条）
5
    2. 执行轮次阈值（每 10 轮）
6
    3. 估算 token 超限（默认 100000）
7
    """

触发判断（ai_pentest/context/compression.py:54-88）：

1
def should_compress(self, messages, execution_count) -> tuple[bool, str]:
2
    # 策略 1: 消息数量 > 50
3
    if len(messages) > self.message_threshold:
4
        return True, f"消息数量过多"
5
    # 策略 2: 每 10 轮定期压缩
6
    if execution_count > 0 and execution_count % self.compress_interval == 0:
7
        return True, f"定期压缩"
8
    # 策略 3: 估算 token > 100000
9
    estimated_tokens = total_chars // 4
10
    if estimated_tokens > self.token_threshold:
11
        return True, f"估算 token 超限"

压缩策略（ai_pentest/context/compression.py:90-154）：

压缩后的消息列表 = 系统提示词(不变) + LLM 生成的历史摘要 + 最近 10 条消息(不变)

核心是 ai_pentest/context/compression.py:176-186 的压缩提示词，要求 LLM 在摘要中保留：

所有重要的决策和行动
关键的工具调用和结果
失败原因和教训
时间顺序

这确保了即使历史消息被压缩，关键的决策轨迹和失败教训不会丢失。

第三层：ChromaDB 向量知识库（Long-term Memory）#

ai_pentest/knowledge/chroma.py:36-50 基于 ChromaDB 向量数据库实现持久化知识存储。这层提供跨任务的长期记忆：

攻击 payload 库（如 SQL WAF 绕过技术）
漏洞利用经验
工具使用经验

知识库在 MCP Server 启动时自动预加载（ai_pentest/mcp_server.py:76-80），确保 Agent 在任何新任务开始时都能检索到历史积累的知识。

第四层：STE 经验提取（Strategy-Tactics-Example）#

ai_pentest/core/reflector.py:144-188 的 reflect_global() 方法在任务结束时执行全局反思，提取可复用的 STE 经验：

1
STE 结构:
2
├── 战略原则（Strategic Principle）：最高层次的攻击原则
3
├── 战术手册（Tactical Manual）：有序的、抽象的步骤列表
4
└── 适用场景（Applicable Scenarios）：标签列表，定义复用场景

这些 STE 经验存储到 ReflectorContext.persistent_insights 中，为后续任务提供可复用的攻击模式。

1.3 信息流转闭环#

1
Executor 执行 → 结果存入 message_history
2
      ↓
3
Reflector 反思 → validated_patterns / persistent_insights 存入 ReflectorContext
4
      ↓
5
compress_if_needed() → 历史消息压缩为摘要，但 PlannerContext/ReflectorContext 不受影响
6
      ↓
7
Planner 动态规划 → 从 get_planner_summary() 获取完整历史
8
      ↓
9
rejected_strategies 防止重复 → 新规划避免已失败方法

二、逻辑断层解决方案（Logic Gap Resolution）#

2.1 问题定义#

逻辑断层指 Agent 在渗透测试过程中出现的推理链条断裂：子任务失败后不知道为什么失败、反思结论无法传导到下一次规划、或者 Executor 盲目重试而不调整策略。

2.2 P-E-R 协作架构#

ai_pentest/core/agent.py:33-42 实现了 Planner-Executor-Reflector (P-E-R) 三角协作架构来消除逻辑断层：

1
                    ┌─────────┐
2
                    │ Planner │ ← rejected_strategies, latest_reflection_report
3
                    └────┬────┘
4
                         │ initial_plan / dynamic_plan
5
                         ▼
6
              ┌──────────────────────┐
7
              │  Execute-Reflect     │ ← _execute_reflect_loop (max 100 iterations)
8
              │  Loop                │
9
              │                      │
10
              │  Executor ──→ Reflector
11
              │     ↑           │    │
12
              │     └───────────┘    │
13
              │  (VETO / intelligence)│
14
              └──────────────────────┘

2.3 分层失败归因（L0-L5 Failure Attribution）#

这是消除逻辑断层的核心机制。ai_pentest/failure_attribution/levels.py:35-46 定义了严格的 6 层递进归因体系：

1
L0 (Observation)  → 工具原始输出（最基础层）
2
L1 (Tool Failure) → 工具执行失败（超时、命令不存在、权限不足）
3
L2 (Prerequisite) → 前提条件失败（会话过期、认证失败、依赖缺失）
4
L3 (Environment)  → 环境阻断（WAF拦截、防火墙、速率限制）
5
L4 (Hypothesis)   → 假设被证伪（需 3+ 次失败才能归因到此层）
6
L5 (Strategy)     → 战略缺陷（需 3+ 个 L4 失败形成模式）

严格的递进原则（ai_pentest/failure_attribution/levels.py:322-397）：

1
def attribute(self, ...):
2
    # 必须逐层排查，低层未排除不能归因到高层
3
    l1_result = self._check_l1_tool_failure(...)  # 先排查工具问题
4
    if l1_result: return l1_result
5

6
    l2_result = self._check_l2_prerequisite_failure(...)  # 再排查前提条件
7
    if l2_result: return l2_result
8

9
    l3_result = self._check_l3_environment(...)  # 再排查环境因素
10
    if l3_result: return l3_result
11

12
    # 只有排除 L0-L3 后，才能归因到 L4
13
    if hypothesis and evidence:
14
        l4_result = self._check_l4_hypothesis(...)
15
        # L4 需要 failed_attempts >= 3 才触发
16

17
    # 只有多个 L4 失败形成模式（l4_failure_count >= 3），才归因到 L5
18
    if strategy:
19
        l5_result = self._check_l5_strategy(...)

展开收起

这防止了最常见的逻辑断层：Agent 错误地将工具级失败归因为策略失败，从而过早放弃正确的攻击路径。

2.4 Reflector 的 VETO 权力#

ai_pentest/core/reflector.py:39 和 ai_pentest/core/agent.py:229-236：

1
# Reflector 返回的 rejected_staged_nodes 列表
2
rejected_nodes = reflection_result.get("rejected_staged_nodes", [])
3
if rejected_nodes:
4
    self.veto_count += 1
5
    # 直接移除被拒绝的节点
6
    tasks = [t for t in tasks if t.get("id") not in rejected_nodes]

Reflector 拥有否决 Executor 提交的因果图节点的权力。这防止了 Executor 在执行中产生的错误推理被无条件接受，形成逻辑链条上的”坏节点”。

2.5 动态规划闭环#

ai_pentest/core/agent.py:242-258 实现了反思驱动的动态规划：

1
# 基于 Reflector 的情报摘要触发动态规划
2
if reflection_result.get("intelligence_summary"):
3
    dynamic_plan_result = await self.planner.dynamic_plan(
4
        goal=goal,
5
        graph_summary=graph_summary,
6
        intelligence_summary=reflection_result.get("intelligence_summary"),
7
        failure_patterns_summary=reflection_result.get("attribution_result"),
8
        failed_nodes=[t for t in tasks if t.get("status") == "failed"]
9
    )

动态规划的提示词（ai_pentest/core/planner.py:267-356）明确要求：

失败驱动：优先处理失败或阻塞的任务
诊断优先：为失败任务设计诊断或替代方案
避免重复：不要重复已失败的方法

同时，Planner 通过 get_planner_summary() 获取包含 rejected_strategies 的完整历史，确保新规划不会重蹈覆辙。

2.6 逻辑断层消除的完整链条#

1
Executor 执行失败
2
    ↓
3
FailureAttributor 进行 L0-L5 递进归因 → 精确定位失败根因
4
    ↓
5
Reflector 审核执行结果:
6
    ├── 验证/否决 Executor 的发现（VETO 权力）
7
    ├── 生成 intelligence_summary（攻击情报）
8
    └── 生成 attribution_result（归因结果）
9
    ↓
10
intelligence_summary 触发 Planner 动态规划
11
    ├── 输入：失败归因 + 失败节点 + 情报摘要
12
    ├── 参考：rejected_strategies（避免重复）
13
    └── 输出：诊断任务或替代攻击路径
14
    ↓
15
新任务注入 execute_reflect_loop → 继续执行

展开收起

三、命令执行防沉迷机制（Anti-Addiction / Loop Prevention）#

3.1 问题定义#

LLM Agent 在渗透测试中容易陷入以下模式：

无限循环：反复执行相似命令（如同一 payload 的微小变体）
过度枚举：对 IDOR 等场景进行逐个 ID 遍历
超时阻塞：长时间运行的命令阻塞整个流程
瞬时故障重试：网络抖动导致的无意义重试

3.2 三大防护机制#

机制一：SequenceMatcher 相似度检测#

ai_pentest/meta_tooling/anti_addiction.py:43-51 核心参数：

1
class AntiAddiction:
2
    def __init__(self,
3
        similarity_threshold: float = 0.85,  # 相似度阈值
4
        max_similar_count: int = 18,          # 最大连续相似次数
5
        command_timeout: int = 300,            # 命令超时 (秒)
6
        max_retries: int = 3                   # 最大重试次数
7
    ):

检测流程（ai_pentest/meta_tooling/anti_addiction.py:87-114）：

1
def _is_similar_to_last_command(self, current_cmd: str) -> bool:
2
    # 1. 命令太短 (< 10 字符) 不检测
3
    if len(current_cmd) < self._min_cmd_length:
4
        return False
5
    # 2. 用 SequenceMatcher 计算与上一条命令的相似度
6
    similarity = SequenceMatcher(None, current_cmd, last_cmd).ratio()
7
    # 3. 相似度 >= 0.85 判定为相似命令
8
    return similarity >= self.similarity_threshold

滑动窗口历史（ai_pentest/meta_tooling/anti_addiction.py:23-40）：

1
class CommandHistory(BaseModel):
2
    commands: List[str] = []
3
    max_length: int = 18  # 18 条命令的滑动窗口
4

5
    def add(self, command: str) -> None:
6
        self.commands.append(command)
7
        if len(self.commands) > self.max_length:
8
            self.commands.pop(0)  # FIFO 弹出最早的命令

触发警告（ai_pentest/meta_tooling/anti_addiction.py:116-168）：当连续相似命令达到 18 次时，返回一个结构化的反思提示：

1
⚠️ 检测到可能陷入循环（已连续执行 18 次相似命令）
2

3
请先思考以下问题来重新制定计划：
4
1. 我的核心假设是什么？
5
2. 过去 18 次的尝试，是否证明了这个假设是错误的？
6
3. 除了当前的方法，还有哪些其他的可能性？
7
4. 是否有更高效的方式（如批量处理、自动化脚本）？

关键设计：警告触发后，计数器重置为 0（anti_addiction.py:162），允许 Agent 在反思后继续执行。执行不相似的命令也会重置计数器（anti_addiction.py:167），即只检测连续相似。

机制二：指数退避重试（Exponential Backoff with Jitter）#

ai_pentest/meta_tooling/anti_addiction.py:205-228 使用 tenacity 库创建重试装饰器：

1
def create_retry_decorator(self, func_name: str = "") -> Callable:
2
    return retry(
3
        retry=retry_if_exception_type(Exception),
4
        wait=wait_exponential_jitter(
5
            initial=0.3,   # 首次重试等待 0.3 秒
6
            max=10,         # 最大等待 10 秒
7
            jitter=0.5      # ±0.5 秒随机抖动
8
        ),
9
        stop=stop_after_attempt(self.max_retries),  # 最多重试 3 次
10
        reraise=True,
11
    )

等待序列大约为：0.3s → 0.6s → 1.2s（加上 ±0.5s 随机抖动），最多 3 次。

可重试错误判断（ai_pentest/meta_tooling/anti_addiction.py:177-203）：

1
@staticmethod
2
def is_retryable_error(exception) -> bool:
3
    # ConnectionError → 可重试
4
    # TimeoutError → 可重试
5
    # HTTP 408, 404, 429, 500-526 → 可重试

机制三：异步超时控制#

ai_pentest/meta_tooling/anti_addiction.py:230-257：

1
async def execute_with_timeout(self, coro, timeout=None, func_name=""):
2
    timeout = timeout or self.command_timeout  # 默认 300 秒
3
    return await asyncio.wait_for(coro, timeout=timeout)

任何工具调用超过 300 秒将被强制终止，抛出 TimeoutError。

3.3 在 Executor 中的集成#

ai_pentest/core/executor.py:63 Executor 初始化时创建 AntiAddiction 实例。

ai_pentest/core/executor.py:431-437 在每次 shell 命令执行前进行防沉迷检查：

1
if tool_name == "execute_shell_command":
2
    command = arguments.get("command", "")
3
    warning = self.anti_addiction.check_and_record(command)
4
    if warning:
5
        logger.warning(f"检测到循环模式: {warning[:100]}...")
6

7
# 所有工具调用都包装重试装饰器
8
retry_decorator = self.anti_addiction.create_retry_decorator(func_name=tool_name)
9

10
@retry_decorator
11
async def _execute():
12
    # 实际执行逻辑

3.4 防护层次总结#

层级	机制	触发条件	行为
L1	相似度检测	连续 18 次相似度 >= 0.85	返回反思提示，重置计数器
L2	指数退避重试	Exception 异常	0.3s→0.6s→1.2s+jitter, 最多 3 次
L3	超时控制	单命令超过 300s	强制终止，抛出 TimeoutError
L4	循环迭代上限	execute_reflect_loop > 100	标记任务为 FAILED

四、Meta-Tooling 层实现#

4.1 设计理念#

Meta-Tooling 层的核心原则是：Agent 不直接执行任何操作，所有工具在隔离的 Meta-Tooling 层中执行，只将结果返回给 Agent。这实现了 Agent 推理与工具执行的解耦。

4.2 架构概览#

1
┌─────────────────────────────────────────────────────┐
2
│                    LLM Agent                         │
3
│           (Planner / Executor / Reflector)           │
4
└──────────────────────┬──────────────────────────────┘
5
                       │ MCP Protocol (JSON-RPC)
6
                       ▼
7
┌─────────────────────────────────────────────────────┐
8
│               MCP Server (mcp_server.py)            │
9
│          ┌────────────────────────────────┐          │
10
│          │      Tool Router / Dispatcher  │          │
11
│          └────────────┬───────────────────┘          │
12
│                       │                              │
13
│    ┌──────────┬───────┼───────┬──────────┐          │
14
│    ▼          ▼       ▼       ▼          ▼          │
15
│ ┌──────┐ ┌───────┐ ┌──────┐ ┌─────┐ ┌──────┐      │
16
│ │Python│ │Browser│ │Termi-│ │Proxy│ │Recon │      │
17
│ │Execu-│ │Automa-│ │nal   │ │     │ │Tools │      │
18
│ │tor   │ │tion   │ │      │ │     │ │      │      │
19
│ └──────┘ └───────┘ └──────┘ └─────┘ └──────┘      │
20
└─────────────────────────────────────────────────────┘

展开收起

4.3 MCP Server 作为中间层#

ai_pentest/mcp_server.py:52-74 定义了 AIPentestMCPServer 类：

1
class AIPentestMCPServer:
2
    def __init__(self):
3
        self.server = Server("ai-pentest-server")
4
        self.python_executor: PythonExecutor | None = None
5
        self.browser: BrowserAutomation | None = None
6
        self.terminal: Terminal | None = None
7
        self.proxy: Proxy | None = None
8
        self.knowledge_base: KnowledgeBase | None = None
9
        self.notes_storage: NoteStorage | None = None
10
        self.recon_workflow: ReconWorkflow | None = None

MCP Server 持有所有工具实例，Agent 通过 MCP 协议（JSON-RPC over stdio）发送工具调用请求，Server 路由到对应的工具实例执行，只返回文本结果。

4.4 五大 Meta-Tooling 组件#

4.4.1 PythonExecutor（代码执行沙箱）#

ai_pentest/core/executor.py:67：self.python_executor = PythonExecutor(path="scripts")

在 Executor 中的调用（ai_pentest/core/executor.py:442-455）：

1
if tool_name == "execute_python_code":
2
    @retry_decorator
3
    async def _execute():
4
        outputs = self.python_executor.execute_code(
5
            session_name=arguments.get("session_name", "default"),
6
            code=arguments.get("code", ""),
7
            timeout=arguments.get("timeout", 120)
8
        )
9
        return "\n\n".join(
10
            f"Output: {output.get('text', '')}"
11
            for output in outputs
12
        )

Agent 发送 Python 代码字符串 → PythonExecutor 在隔离环境中执行 → 只返回输出文本。

4.4.2 BrowserAutomation（浏览器自动化）#

支持双模式运行：

CDP 模式（无代理）：连接到已有的 Chrome 实例
Playwright 模式（有代理）：启动独立 Chromium 并配置 HTTP 代理

Agent 通过 browser_navigate、browser_execute_js、browser_screenshot 等工具与浏览器交互，只收到页面内容/截图等结果。

4.4.3 Terminal（终端会话管理）#

ai_pentest/core/executor.py:457-471 的 shell 命令执行：

1
elif tool_name == "execute_shell_command":
2
    @retry_decorator
3
    async def _execute():
4
        session_id = self.terminal.new_session()           # 创建新终端会话
5
        self.terminal.send_keys(session_id=session_id,     # 发送命令
6
            keys=arguments.get("command", ""), enter=True)
7
        await asyncio.sleep(2)                              # 等待执行
8
        output = self.terminal.get_output(session_id)       # 获取输出
9
        return output

Terminal 封装了 tmux 会话管理，Agent 不直接接触 shell，只通过 send_keys → get_output 的模式交互。

4.4.4 Proxy（HTTP 流量代理）#

ai_pentest/core/executor.py:70-73：与 Caido 代理集成

1
self.proxy = Proxy(
2
    url=config.proxy_caido_url,
3
    token=config.proxy_caido_token
4
) if config.proxy_caido_token else None

Agent 可以通过 proxy_list_traffic 工具查看经过代理的 HTTP 流量，用于分析请求/响应。

4.4.5 Recon Tools（侦察工具集）#

ai_pentest/recon/__init__.py:1-23 导出的侦察工具：

1
- CyberspaceMapper    # 空间测绘（FOFA/Quake）
2
- FingerprintScanner  # 指纹识别
3
- DirectoryScanner    # 目录扫描
4
- JSAnalyzer          # JS 分析
5
- AuthBypassFuzzer    # 鉴权绕过 Fuzz
6
- ReconWorkflow       # 侦察工作流编排

这些工具都在 MCP Server 层实例化和执行，Agent 只收到结构化的扫描结果。

4.5 工具执行的隔离保障#

Executor 中的工具调用流程（ai_pentest/core/executor.py:410-537）：

1
Agent LLM 输出 tool_call
2
    ↓
3
_execute_tool_call() 路由
4
    ↓
5
┌─ 防沉迷检查 (anti_addiction.check_and_record)
6
├─ 重试装饰器包装 (create_retry_decorator)
7
├─ Meta-Tool 执行 (PythonExecutor/Terminal/Browser/Proxy)
8
└─ 返回 ToolExecutionResult(tool_name, success, output, error, execution_time)
9
    ↓
10
结果存入 context_manager.add_message(role="tool", content=result.output)
11
    ↓
12
失败归因 _attribute_failure() → L0-L5 分析
13
    ↓
14
漏洞自动检测 _check_and_save_vulnerability() → 保存笔记

关键点：

Agent 永远不直接执行命令，只通过 Meta-Tooling 层间接操作
每次工具调用都经过防沉迷检查和重试包装
工具输出经过 ToolExecutionResult 标准化后才返回
失败会自动进行 L0-L5 归因
漏洞相关输出自动保存到笔记系统

4.6 Meta-Tooling 层的安全边界#

1
Agent 层（纯推理）
2
    ↑ 只接收文本结果
3
    │
4
    ├── 不直接访问文件系统
5
    ├── 不直接执行 shell 命令
6
    ├── 不直接操作浏览器 DOM
7
    └── 不直接发送网络请求
8
    │
9
    ↓ 只发送工具调用请求
10
Meta-Tooling 层（隔离执行）
11
    ├── PythonExecutor：沙箱化代码执行
12
    ├── Terminal：tmux 会话隔离
13
    ├── Browser：CDP/Playwright 封装
14
    ├── Proxy：HTTP 流量只读访问
15
    └── Recon：封装的扫描工具

展开收起

五、总结#

机制	核心组件	关键文件	设计特点
防灾难性遗忘	PlannerContext + ReflectorContext + ContextCompressor + ChromaDB	manager.py, compression.py, chroma.py	4 层防护：持久化对象 + LLM 压缩 + 向量存储 + STE 经验
逻辑断层消除	L0-L5 归因 + VETO 权力 + 动态规划	levels.py, reflector.py, planner.py	严格递进归因 + 反思驱动重规划 + 被拒策略记忆
防沉迷机制	SequenceMatcher + tenacity + asyncio.wait_for	anti_addiction.py, executor.py	相似度检测 + 指数退避 + 超时终止 + 迭代上限
Meta-Tooling	MCP Server + 5 大工具封装	mcp_server.py, executor.py	推理与执行解耦，标准化结果返回，全链路防护

后记#

贴一些小成果

反编译小程序，前端分析JS绕过签名校验

0176dea473f1fd33534936279799aade

d36e5bad590d5b38bddbf8d65c65fef6

常规接口测试

image-20260311183719577

image-20260311183952004

接口猜测，深度挖掘存在接口

image-20260311184127161

GinTvT

蚂蚁安全

Thu, 15 Jan 2026 00:00:00 GMT

感谢蚂蚁安全，嘻嘻！

蚂蚁1

蚂蚁2

北京

Sat, 19 Jul 2025 00:00:00 GMT

北京#

上次来北京，还是13年前，那次也是我人生第一次做飞机。

刚到北京那会下着大雨，还是凌晨，我们找了一家四合院的酒店住下，那个酒店在什么地方已经记不清了，对于现在的我来说回忆小学有点过于艰难，依稀记得在一个小巷子里头，有很多卖糖葫芦的，各种晶莹剔透的糖葫芦，我拿着个糖葫芦，走着走着，就走到了天安门前，当年也不需要预约，到了地儿买张票就进去了，看着毛爷爷的画像，想起了电视里的皇帝面对众人，众人都要喊着万岁万岁万万岁，懵懂无知的我也对着画像说着，毛爷爷慢睡慢睡慢慢睡，哈哈，我也不知道当初为什么这么喊，只是觉得很有意思。

时间依旧无情，再次来到北京，孤身一人，记忆中的北京已经忘记了，骑着单车，我环绕了北京，边骑，边试图回想当年北京的模样，可怎么也想不起来，骑在北京这方方正正的路上，看着毛爷爷的画像，似乎又回到了13年前，我们第一次来到北京的时候，记忆中的北京已经散去，现在的北京，陌生带着点熟悉。

北京啊北京。

img

地坛

img

198f32e4a7c1f10ed1dc97e00b15f9be

一位朋友的投喂

Tue, 15 Jul 2025 00:00:00 GMT

感谢孙老板的空投，第一次离网上的好朋友这么近！

投喂1

投喂2

.NET审计记录

Fri, 23 May 2025 00:00:00 GMT

.NET审计记录#

最近也是在复健一下代码审计, 顺便记录一下思路

审计准备#

一个正常人的脑子

一个正常人用的电脑

一套net代码

审计工具:dnSpy:https://github.com/dnSpy/dnSpy

案例1#

我们用一个大佬打下来的某套源码来审计, 该系统如果出洞也是通用了()

第一步:看眼路由

简单用登录框看一眼路由结构

image-20260311152250749

抓包看路径

image-20260311152335976

/Home/newLogin 根据这个路径, 没有像login.aspx的文件拓展名, 可以高度确定网站是一个MVC架构, 且存在一个集中的controller

Home是controller, newLogin是方法

所以现在, 我们回到源码中去找他集中的controller

image-20260311152427374

根据他的dll来猜测, system应该是系统的东西, 应该跟controller没什么关系, 其他的一些命名也不是很符合我们要找的controller, 看到JuCheap, 感觉就是他了, 点开JuCheap后, 果然我们发现了controller

image-20260311152458321

依照登录口的路由/Home/newLogin, 我们可以在controller中找到他

image-20260311152534002

既然到这里, 我们再看看他下面的一些东西, 其中有一个叫做Filters的, 这个就是过滤器, 如果方法添加了过滤器, 那就可能没办法从前台发起攻击了

image-20260311152559978

当然也不是绝对, 万一他的过滤器压根就没写东西呢, 别不信, 真有这种

image-20260311152620400

image-20260311152633150

这套代码就写的有点东西, 审计难度也大(其实就是我菜), 接下来我们看一套难度没这么大的

案例2#

这回也是拿一套非MVC架构的来审路径中有.aspx, 这就是非常典型的Web Forms, 这种结构就是单纯的物理文件了

image-20260311152724531

我们直接跳过审计阶段来到漏洞点, 这里接收了参数到DleteTemp中

image-20260311152752690

GinTvT

AI Pentest Agent 架构分析报告

Wed, 01 Jan 2025 00:00:00 GMT

Hello World

Wed, 01 Jan 2025 00:00:00 GMT

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.

Quick Start#

Create a new post#

Terminal window

1
$ hexo new "My New Post"

More info: Writing

Run server#

Terminal window

1
$ hexo server

More info: Server

Generate static files#

Terminal window

1
$ hexo generate

More info: Generating

Deploy to remote sites#

Terminal window

1
$ hexo deploy

More info: Deployment

遗憾依旧贯穿人生

Sun, 15 Dec 2024 00:00:00 GMT

一场电影还是要落幕了，世界上最好的沙鹰使用者，步枪手最长的河，终究再次遗憾收场。很难描述吧，这种心情，故事的结局到底重不重要呢，我想，大多数人都希望着美好的过程会拥有一个美好的结局，可是，悲苦不像享乐，它不会说谎，未来再见吧，我心中的无冕之王！

无冕之王1

无冕之王2

无冕之王3

工大碎片🧩

Thu, 12 Sep 2024 00:00:00 GMT

工大碎片🧩

工大1

工大2

工大3

Steam记录1

Mon, 19 Jun 2023 00:00:00 GMT

谁懂养成系#

30块买个女儿你不买？

我生下来就是为了养女儿的，我TM生生生生养养养养！这是什么？白菜？贴一下。这是什么？白菜？贴一下。这是什么？肥猪？我TM杀杀杀杀杀！妈的，受不了了，一拳把铁匠儿子打爆！妈的，受不了了，一拳把画家打爆！妈的，受不了了，一拳把澡堂打爆！我TM杀杀杀杀杀杀杀杀！女儿可爱捏女儿可爱捏女儿可爱捏😋

img

23巴黎Major

Tue, 16 May 2023 00:00:00 GMT

23巴黎Major#

梦碎巴黎还是没有能创造奇迹啊再会了最好的沙鹰使用者下一次希望能看到你的沙鹰再次闪耀在这个舞台上

img

ShellCode开发

Fri, 12 May 2023 00:00:00 GMT

ShellCode开发#

1.基本没人教的花活，网上会有文章，但是不会解释原理。这玩意其实难度不高，就是要注意的东西多。

2.shellcode开发其实有很多办法，纯汇编，C和汇编又或者纯C++。（像我这种纯FW只能纯C++了）

开发PIC shellcode注意事项#

1.不能使用全局变量，或者用static修饰的变量·使用API时必须动态调用(GetProAddress)·确保调自定义shellcode入口点

2.·用API之前已经加载了与之对应的DLL

3.·所有字符串都必须要用字符串数组的方式替代

·属性——优化——O1/Ob2/Oi/Os/Oy/GL·

属性——代码生成———MT/GS-/GY·

属性——链接器——/INCREMENTAL·

属性——链接器——调试——否

·属性——链接器——高级——入口点（自定义)

所有字符串都要用类似的格式去定义 unsigned char szUser32[] = { ‘u’,‘s’,‘e’,‘r’,‘3’,‘2’,’.’,‘d’,‘l’,‘l’,0 };防止破坏堆栈平衡

先看代码吧，代码是删减版只有模板

一个头文件comm.h

1
#include &lt;windows.h&gt;
2
//这个其实没什么好说的这个头文件主要是在这边定义函数指针
3
typedef FARPROC(WINAPI* FN_GetProcAddress)(
4
    _In_ HMODULE hModule,
5
    _In_ LPCSTR lpProcName
6
    );
7

8
typedef HMODULE(WINAPI* FN_LoadLibraryA)(
9
    _In_ LPCSTR lpLibFileName
10
    );
11

12
typedef int(WINAPI* FN_MessageBoxA)(
13
    _In_opt_ HWND hWnd,
14
    _In_opt_ LPCSTR lpText,
15
    _In_opt_ LPCSTR lpCaption,
16
    _In_ UINT uType);
17

18

19
typedef UINT(WINAPI* FN_WinExec)(
20
    LPCSTR lpCmdLine,
21
    UINT   uCmdShow
22
    );
23

24
typedef HANDLE(WINAPI * FN_CreateFileMappingW)(
25
        _In_     HANDLE hFile,
26
        _In_opt_ LPSECURITY_ATTRIBUTES lpFileMappingAttributes,
27
        _In_     DWORD flProtect,
28
        _In_     DWORD dwMaximumSizeHigh,
29
        _In_     DWORD dwMaximumSizeLow,
30
        _In_opt_ LPCWSTR lpName
31
        );
32

33

34
typedef struct tagApiInterface {
35
    FN_GetProcAddress pfnGetProcAddress;
36
    FN_LoadLibraryA pfnLoadLibrary;
37
    FN_MessageBoxA pfnMessageBoxA;
38
    FN_WinExec pfnWinExec;
39
    FN_CreateFileMappingW pfnCreateFileMappingW;
40
}APIINTERFACE, * PAPIINTERFACE;

展开收起

然后是function.h，一般存放一些自实现的函数，我把我的删掉了

1
#pragma once
2
#include "comm.h"
3
#include &lt;windows.h&gt;
4
#include &lt;iostream&gt;
5
#include &lt;vector&gt;
6
#include &lt;cstdint&gt;
7
using namespace std;

最后是最重要的，注意看注释。

大概的思路：通过PEB（不知道是啥玩意的自己去补基础）去获取Kernel32.dll的地址，从Kernel32.dll中获取导出函数GetProcAddress，再通过GetProcAddress函数获取LoadLibraryA函数。就可以实现从任意DLL中获取任意导出函数进行编程。

1
#include "comm.h"
2
#include &lt;winternl.h&gt;
3
#include "function.h"
4

5

6
// 获取Kernel32.dll模块的基地址
7
ULONGLONG GetModuleKernel64()
8
{
9
    ULONGLONG dwKernel32Addr = 0;
10

11
    // 获取TEB的地址
12
    _TEB* pTeb = NtCurrentTeb();
13
    // 获取PEB的地址
14
    PULONGLONG pPeb = (PULONGLONG) * (PULONGLONG)((ULONGLONG)pTeb + 0x60);
15
    // 获取PEB_LDR_DATA结构的地址
16
    PULONGLONG pLdr = (PULONGLONG) * (PULONGLONG)((ULONGLONG)pPeb + 0x18);
17
    // 模块初始化链表的头指针InInitializationOrderModuleList
18
    PULONGLONG pInLoadOrderModuleList = (PULONGLONG)((ULONGLONG)pLdr + 0x10);
19

20
    // 获取链表中第一个模块信息，exe模块
21
    PULONGLONG pModuleExe = (PULONGLONG)*pInLoadOrderModuleList;
22
    //printf("EXE Base = &gt; %X \n", pModuleExe[6]);
23

24
    // 获取链表中第二个模块信息，ntdll模块
25
    PULONGLONG pModuleNtdll = (PULONGLONG)*pModuleExe;
26
    //printf("Ntdll Base = &gt; %X \n", pModuleNtdll[6]);
27

28
    // 获取链表中第三个模块信息，Kernel32模块
29
    PULONGLONG pModuleKernel32 = (PULONGLONG)*pModuleNtdll;
30
    //printf("Kernel32 Base = &gt; %X \n", pModuleKernel32[6]);
31

32
    // 获取kernel32基址
33
    dwKernel32Addr = pModuleKernel32[6];
34

35
    return dwKernel32Addr;
36
}
37

38
// 通过解析PE格式的导出表,从给定的模块基地址中获取指定函数的地址
39
FARPROC getProcAddress(HMODULE hModuleBase)
40
{
41
    // 获取DOS头
42
    PIMAGE_DOS_HEADER lpDosHeader = (PIMAGE_DOS_HEADER)hModuleBase;
43
    // 获取NT头
44
    PIMAGE_NT_HEADERS64 lpNtHeader = (PIMAGE_NT_HEADERS64)((ULONG64)hModuleBase + lpDosHeader-&gt;e_lfanew);
45
    // 检查导出目录的大小是否为0
46
    if (!lpNtHeader-&gt;OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].Size) {
47
        return NULL;
48
    }
49
    // 检查导出目录的虚拟地址是否为0
50
    if (!lpNtHeader-&gt;OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress) {
51
        return NULL;
52
    }
53
    // 获取导出目录的地址
54
    PIMAGE_EXPORT_DIRECTORY lpExports = (PIMAGE_EXPORT_DIRECTORY)((ULONG64)hModuleBase + (ULONG64)lpNtHeader-&gt;OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress);
55
    // 获取导出函数名称的地址
56
    PDWORD lpdwFunName = (PDWORD)((ULONG64)hModuleBase + (ULONG64)lpExports-&gt;AddressOfNames);
57
    // 获取导出函数名称序号的地址
58
    PWORD lpword = (PWORD)((ULONG64)hModuleBase + (ULONG64)lpExports-&gt;AddressOfNameOrdinals);
59
    // 获取导出函数地址的地址
60
    PDWORD  lpdwFunAddr = (PDWORD)((ULONG64)hModuleBase + (ULONG64)lpExports-&gt;AddressOfFunctions);
61

62
    // 循环计数器
63
    DWORD dwLoop = 0;
64
    // 存储找到的函数地址
65
    FARPROC pRet = NULL;
66
    for (; dwLoop &lt;= lpExports-&gt;NumberOfNames - 1; dwLoop++) {
67
        // 获取当前函数名称的地址
68
        char* pFunName = (char*)(lpdwFunName[dwLoop] + (ULONG64)hModuleBase);
69
        // 检查函数名称是否为"GetProcAddress"
70
        if (pFunName[0] == 'G' &amp;&amp;
71
            pFunName[1] == 'e' &amp;&amp;
72
            pFunName[2] == 't' &amp;&amp;
73
            pFunName[3] == 'P' &amp;&amp;
74
            pFunName[4] == 'r' &amp;&amp;
75
            pFunName[5] == 'o' &amp;&amp;
76
            pFunName[6] == 'c' &amp;&amp;
77
            pFunName[7] == 'A' &amp;&amp;
78
            pFunName[8] == 'd' &amp;&amp;
79
            pFunName[9] == 'd' &amp;&amp;
80
            pFunName[10] == 'r' &amp;&amp;
81
            pFunName[11] == 'e' &amp;&amp;
82
            pFunName[12] == 's' &amp;&amp;
83
            pFunName[13] == 's')
84
        {
85
            // 找到函数名称，获取其地址
86
            pRet = (FARPROC)(lpdwFunAddr[lpword[dwLoop]] + (ULONG64)hModuleBase);
87
            break;
88
        }
89
    }
90
    // 返回找到的函数地址
91
    return pRet;
92
}
93

94

95
void EntryMain()
96
{
97
    APIINTERFACE Api;
98

99
    HMODULE hKernel32 = (HMODULE)GetModuleKernel64();
100

101
    Api.pfnGetProcAddress = (FN_GetProcAddress)getProcAddress(hKernel32);
102

103
    char szLoadLibraryA[] = { 'L','o','a','d','L','i','b','r','a','r','y','A',0 };
104
    Api.pfnLoadLibrary = (FN_LoadLibraryA)Api.pfnGetProcAddress(hKernel32, szLoadLibraryA);

展开收起

GinTvT

Web 安全入门指南

Sat, 11 Mar 2023 00:00:00 GMT

Web 安全入门指南（本文为测试文章）#

欢迎来到 Web 安全的世界！本文将为你介绍 Web 安全的基础知识和学习路线。

一、什么是 Web 安全？#

Web 安全是指保护 Web 应用程序、Web 服务和 Web 数据免受各种威胁和攻击的安全实践。

二、常见的 Web 漏洞#

1. SQL 注入（SQL Injection）#

SQL 注入是最常见的 Web 漏洞之一，攻击者通过在输入字段中插入恶意 SQL 代码来操纵数据库。

示例：

1
SELECT * FROM users WHERE username = 'admin' OR '1'='1'

防御方法：

使用参数化查询
输入验证和过滤
最小权限原则

2. 跨站脚本攻击（XSS）#

XSS 攻击允许攻击者在其他用户的浏览器中执行恶意脚本。

类型：

存储型 XSS
反射型 XSS
DOM 型 XSS

防御方法：

输出编码
输入过滤
使用 Content Security Policy (CSP)

3. 跨站请求伪造（CSRF）#

CSRF 攻击诱使用户在已认证的 Web 应用程序上执行非预期的操作。

防御方法：

使用 CSRF Token
验证 Referer 头
使用 SameSite Cookie 属性

三、学习路线#

第一阶段：基础知识#

HTTP 协议
- 请求/响应模型
- 常用方法（GET、POST 等）
- 状态码含义
- Cookie 和 Session
Web 技术基础
- HTML/CSS/JavaScript
- 前端框架
- 后端开发（PHP/Python/Java 等）
- 数据库（MySQL、MongoDB 等）

第二阶段：漏洞学习#

OWASP Top 10
- 深入理解十大 Web 安全风险
- 实际漏洞复现
- 防御方案实践
其他常见漏洞
- 文件上传漏洞
- 文件包含漏洞
- 命令注入
- 逻辑漏洞

第三阶段：工具使用#

Burp Suite - Web 渗透测试神器
OWASP ZAP - 开源安全测试工具
SQLMap - SQL 注入自动化工具
Nmap - 网络扫描工具
Metasploit - 渗透测试框架

第四阶段：实战演练#

靶场练习
- DVWA（Damn Vulnerable Web Application）
- OWASP Juice Shop
- HackTheBox
- TryHackMe
CTF 比赛
- 参加网络安全竞赛
- 提升实战能力

四、推荐资源#

书籍#

《Web 安全深度剖析》
《白帽子讲 Web 安全》
《Web 应用黑客手册》

在线资源#

实践平台#

五、学习建议#

打好基础 - 不要急于求成，先学好基础知识
动手实践 - 理论结合实际，多动手练习
持续学习 - 安全技术更新快，要保持学习
遵守法律 - 只在授权范围内使用技术
分享交流 - 写博客、参加社区，与他人交流

六、总结#

Web 安全是一个充满挑战和机遇的领域。希望这篇文章能为你提供一个清晰的学习路线。记住，安全是一场永无止境的旅程，保持好奇心和求知欲，不断学习和实践！

参考资料：

OWASP Top 10
Web 安全深度剖析
各大安全厂商技术博客

下一篇预告： SQL 注入漏洞详解

如果你觉得这篇文章对你有帮助，欢迎分享给更多人！ ✨

你好，世界。

Sun, 01 Jan 2023 00:00:00 GMT

你好，世界。#

建站的这个想法，已经遥远到无法追溯，周围的人都没有博客，友链也没有人挂，但是，依旧想要建一个自己的小站，在最开始的时候，用了VPS和域名建了一个自己的小博客，至于域名是什么，应该也非常好猜（），但是成本确实是稍微有那么点高，且现在对于博客的需求也是随缘更新的状态，每次找一个优惠的VPS都要搬迁博客，实在麻烦，最后还是转到了Github上，忙活了一点时间终于将站简单建起。

直到很长的一段时间之后，我终于找到了建站的意义，那么，为什么要建站？

说来话长，长话短说，建站的原因只是为了记录，记录生活，记录学习，记录自己的情绪，记录自己每天的愉悦，忧伤或是感慨，我一直相信，文字是很有力量的，所以我也尝试自己写下一些文字，麻木的生活总是需要一些文字来充实，我一直在记录他人的文字，想象某一天，我也能写出一段有力量，有感情的句子。

我知道，会有很多人喜欢发朋友圈和空间，没必要自己建一个Blog，费时费力也没什么人看，但是，于我而言，QQ微信在很多时候都是发给其他人看的，我建起来的Blog是我自己的，我记录的是我自己的想法，他人的喜欢与我无关。

非常喜欢这位开发者AlynxZhou的一句话，即使一个行走在漫漫星海边缘的小人物，也可以在互联网上拥有属于自己的一片避风港。

在AlynxZhou的开篇下，有一个问题，So my friend, where’s your harbor?

我终于可以回答，This blog is my safe haven.

作为一个计算机专业的学生，依旧以我们最经典的，作为收尾。

1
#include <stdio.h>
2
int main(void) {
3
    printf("Hello World!\n");
4
    return 0;
5
}

Gin Blog

五月AI-SRC赏金记录

AI渗透初步成果

再唱十年！！！

小记录

MCP 统一入口设计思路

概述 MCP（Model Context Protocol）架构采用统一入口设计模式，将原本分散的多个功能整合到单一的工具接口中，通过 action 参数区分不同的子操作。这种设计大幅”#

tags: [“开发”]#

MCP 统一入口设计思路#

📋 目录#

概述#

设计动机#

问题 1：工具泛滥#

问题 2：功能分散#

问题 3：接口不一致#

统一入口的定义#

对比示例#

传统方式：多个独立工具#

统一入口方式：1 个工具 + action 参数#

架构分层#

核心层统一入口（逻辑断层相关）#

功能层统一入口（渗透测试相关）#

专项工具统一入口#

实现模式#

命令模式（Command Pattern）#

参数验证模式#

结果格式化模式#

关键技术细节#

工具注册装饰器#

ToolRouter 的参数映射#

异步调用与重试机制#

设计优势#

减少工具数量#

提高可维护性#

增强一致性#

便于扩展#

设计模式总结#

命令模式（Command Pattern）#

适配器模式（Adapter Pattern）#

单例模式（Singleton Pattern）#

工厂模式（Factory Pattern）#

策略模式（Strategy Pattern）#

观察者模式（Observer Pattern）#

最佳实践#

命名规范#

Action 参数设计#

参数验证#

错误处理#

架构图#

总结#

小聚

AI Pentest Agent 架构分析报告

AI Pentest Agent 架构分析报告#

一、防止灾难性遗忘（Catastrophic Forgetting Prevention）#

1.1 问题定义#

1.2 多层防遗忘架构#

第一层：持久化上下文对象（Persistent Context Objects）#

第二层：智能上下文压缩（LLM-based Context Compression）#

第三层：ChromaDB 向量知识库（Long-term Memory）#

第四层：STE 经验提取（Strategy-Tactics-Example）#

1.3 信息流转闭环#

二、逻辑断层解决方案（Logic Gap Resolution）#

2.1 问题定义#

2.2 P-E-R 协作架构#

2.3 分层失败归因（L0-L5 Failure Attribution）#

2.4 Reflector 的 VETO 权力#

2.5 动态规划闭环#

2.6 逻辑断层消除的完整链条#

三、命令执行防沉迷机制（Anti-Addiction / Loop Prevention）#

3.1 问题定义#

3.2 三大防护机制#

机制一：SequenceMatcher 相似度检测#

机制二：指数退避重试（Exponential Backoff with Jitter）#

机制三：异步超时控制#

3.3 在 Executor 中的集成#

3.4 防护层次总结#

四、Meta-Tooling 层实现#

4.1 设计理念#

4.2 架构概览#

4.3 MCP Server 作为中间层#

概述 MCP（Model Context Protocol）架构采用统一入口设计模式，将原本分散的多个功能整合到单一的工具接口中，通过 `action` 参数区分不同的子操作。这种设计大幅”#