17 posts tagged with "2026 年"

内容速览​

• 适用场景： 已获授权的内部渗透测试、验证码逻辑验证和安全工具研发。
• 实现方法： 使用 ai.FunctionCall 与 ai.imageBase64 提取验证码，再分别接入基础脚本、并发任务和 Web Fuzzer 热加载流程。
• 关键结论： Yaklang 可以在不单独维护 OCR 服务的情况下完成图像识别与请求编排，但测试范围和并发强度必须遵循授权边界。

常见问题​

是否必须额外部署 OCR 服务？​

不需要。文中的方案通过已配置的 Yakit AI 网关调用多模态模型，并让模型按指定字段返回验证码文本。

这个流程可以用于任意网站吗？​

不可以。验证码识别和登录测试只能用于自有系统、靶场或已经获得明确授权的目标。

打开一个后台管理系统，一般来说可能仅仅是一个登录框。用户名、密码、验证码——三个输入框，一个提交按钮。密码可以爆破，用户名可以枚举，但验证码这个东西，一直是渗透测试中一个绕不开的拦路虎。

Ghost Bits is a WAF bypass technique that has drawn heavy attention in the security community lately; Black Hat-related talks and multiple CVEs (such as CVE-2025-41242) all touch on this technique. In real penetration testing, Ghost Bits encoding itself is not hard — a few lines of script will do. But every time the workflow is "open the editor → modify code → run the script → copy the result → paste it into the tool," the sheer number of steps easily breaks your train of thought. To address this we wrote a Yak Codec plugin: select a payload, right-click, and the encoding result is emitted directly, eliminating the hassle of switching back and forth between windows.

Content Overview​

• Target scenario: Plugin authors and platform maintainers who want their security plugins to be searched, selected, orchestrated, and executed by an AI Agent.
• How it works: Plugins, Tools, Blueprints, Skills, and Focus Mode are abstracted into a unified Capability set, then executed through layered intent routing, progressive disclosure, capability-catalog Grounding, and a unified dispatcher.
• Key conclusion: A plugin store is not only a script download entry point; it can also become the Agent's capability catalog. Discoverability, constraints, and result verification matter just as much as model capability.

FAQ​

Does integrating a plugin with AI require rewriting an adaptation layer?​

No. Following the flow described in this article, a plugin author only needs to enable "Expose to AI" and add an accurate plugin description to enter the unified capability catalog.

How does the system reduce the chance of the AI picking the wrong plugin?​

Capabilities first pass through intent routing and catalog Grounding, then the candidate set is progressively narrowed. The execution phase is still managed and verified by the unified dispatch pipeline.

Background​

In the past, if you wanted to expand the security capabilities of an AI, there were usually two approaches:

In 2026, large-model capabilities are widely seen as having entered a plateau: the brute-force aesthetics of simply piling on more compute now yields sharply diminishing marginal returns, and high-quality human training corpora are nearing exhaustion. Confronted with this bottleneck, the industry's focus has begun to shift. There is a growing consensus that the era of competing purely on models is fading, and an era of competing on Harness Engineering has arrived. It is much like building a car: once you have squeezed the engine's horsepower to its physical limit, further gains in overall vehicle performance can no longer come from staring only at the engine — your attention must turn to the systems that actually harness that engine, such as the drivetrain and the steering wheel.

Quick Overview​

• Applicable scenarios: Security teams that need to perform phased code audits on large projects, organize vulnerability evidence, and get assisted SyntaxFlow rule generation.
• Implementation approach: First explore the project and build a scan plan, then audit by category, verify each piece of evidence one by one, generate a report, and produce PoC examples or rule suggestions driven by risk.
• Key conclusion: The value of AI lies in organizing exploration, verification, and reporting into a traceable workflow; high-risk conclusions and PoCs still need to be reviewed in isolated, authorized environments.

FAQ​

Does AI audit jump straight to vulnerability conclusions?​

No. The workflow described breaks project exploration, scan planning, categorized audit, evidence recording, and report generation into independent phases, requiring conclusions to trace back to specific evidence.

Can auto-generated PoCs be used directly against production targets?​

No. PoCs are intended for risk reproduction and verification within an authorized scope; their inputs, impact, and execution boundaries should be reviewed in an isolated environment.

As Memfit AI's new features expand and the related mechanisms mature, we can now extend existing AI capabilities to our other products. This article focuses on the new attempts we have made in the AI-powered extension of the IRify tool.

In the previous article Memfit AI Professional Memory: Before the Agent Acts, It Reads Through Your Knowledge Base, we solved the Agent's "knowledge" problem. Through the built-in knowledge-base system, the Agent — before executing an attack — can, like a senior expert, first review the enterprise's private testing and compliance documents, ensuring its actions never depart from the compliance baseline.

Over the past few months, Yaklang has completed its second relatively systematic round of performance optimization along four lines: SSA, CodeScan, SyntaxFlow / SFVM, and ANTLR / front-end.

If you look only at the commit log, it reads like a string of scattered fixes, refactors, and experiments; but when you put all of this work together, you find it actually revolves around the same goal:

Make IRify genuinely able to compile more stably on large projects, scan more efficiently, and execute rules more controllably — while giving the subsequent third and fourth rounds of optimization clear points to land.

When an AI Agent runs into something it does not know​

In the previous article: Memfit AI: A Production-Grade AI Agent That Does Not Get Lost Over N Hours of Continuous Penetration Testing, we talked about how Memfit AI works autonomously like a real human penetration testing engineer — planning tasks, executing attacks, and dynamically adjusting strategy. It ran for more than two hours and produced 18 vulnerability findings and a full penetration testing report.

在前端加密、动态签名、一次性 challenge 这类场景里，单纯“会不会发包”其实不是重点。真正麻烦的是，测试链路里往往多出一段必须自动完成的前置或后置逻辑，例如：

01 发起真正业务请求之前，先去拿一段 challenge

02 把 challenge 解开，得到 nonce

03 用 nonce 计算签名，再把签名补到请求头里

04 请求成功之后，返回值本身还是密文，还要再解一遍

如果只是偶尔测试一次，这些动作手工做也不是不行。但一旦要开始反复调试、批量发包、联动 MITM 和 Web Fuzzer，这套流程如果没有一层统一能力接管，就会很快变得难用。

在这篇文章里，我们不去讨论太多架构层面的设计，而是直接拿 Vulinbox 里的一个动态挑战响应接口做演示，看看如何把这条链路真正挂到 Yak 的全局热加载中，让用户在 Web Fuzzer 和 MITM 里都能直接受益。

Does it sound like magic?