一部二手OnePlus 8,插上USB无线网卡,丢进目标网络就能自己干活——破解WiFi、扫描内网、找漏洞、写报告,全程不用联网。开发者在Show HN发布的Nightcrawler v0.1.0,做的就是这件事:把完整的渗透测试流程,压缩进一部改装安卓手机的GPU里跑。

这不是又一个"AI写代码"的демo。渗透测试这个行当,过去要么靠人肉专业团队现场作业,要么靠Nessus、Metasploit这类桌面/云端工具做自动化扫描。Nightcrawler的关键变化在于:它把决策这一步的AI推理彻底搬到端侧,用一个12亿参数的本地小模型(LFM2.5-1.2B-Instruct-Heretic)在手机的Adreno 650 GPU上跑,不依赖任何云端API。

隐蔽扫描的逻辑:像人类测试员一样"泡"在网络里

传统扫描器图快,一次性对所有主机开火,IDS/IPS一眼就能揪出来。Nightcrawler反其道而行:每轮只对一个目标做一个小动作,主机之间轮着来,靠数小时的积累慢慢建立认知,项目文档里称之为"像耐心的人类测试员"。这套慢节奏,配合伪装流量和nmap -T2低速扫描,是它对外宣称"更难被检测"的核心逻辑。

架构上分四层:决策交给本地模型,Scope Proxy校验每条命令是否越界,Kali MCP Server负责真正执行nmap、curl、smbclient这些命令,Web Dashboard和SQLite数据库负责监控和留痕。

决策到执行的四层链路 本地模型 决定下一步 Scope Proxy 校验/拦截越权 Kali MCP Server 真正执行命令 Dashboard/DB 监控与留痕 唯一的安全阀在第二层,一旦失灵,后面无人拦截
README里的几个数字 1.2B 本地模型参数量 27 漏洞利用剧本 24,956 条CVE数据库 v0.1 当前版本号 这些数字全部来自作者自述,尚无第三方复现

一个绕不开的疑问:安全护栏经得起审吗

Scope Proxy是这套系统唯一的"合法性开关"——它决定命令能不能落到目标网络上。问题是,README对它的描述只有"校验并阻止越权操作"这一句话,没有代码审计记录,也没有第三方红队测试过它能不能被绕过。

护栏软不软,得靠人查,不能靠作者自己说牢靠。
  • 风险.一旦Scope Proxy存在漏洞或被绕过,一部"投放后无人值守数小时"的手机,就从授权渗透测试工具变成了未经授权的入侵设备,而这中间可能没有人在场察觉。

这不是吹毛求疵。项目本身也承认,12亿参数模型的命令成功率大约只有五成,靠5次失败重置、5分钟卡死检测这类工程手段去兜底。模型本身不可靠,护栏就更该经得起推敲——但目前能验证这道护栏的,只有作者自己写的代码和自己跑出来的72小时测试记录。

同名撞车提醒:证据只能到README为止

值得提醒读者的是,网上另有一个同名为"Nightcrawler"的项目,今年7月底同样在Hacker News出现过讨论,那是一个基于Python和mitmproxy的桌面端被动扫描代理,专门检测不安全响应头、过时JS、XSS这些Web层面问题,跟手机端AI渗透代理完全是两回事。那个项目的作者自己也承认,代码大量由LLM生成,处于beta阶段,存在细微bug和幻觉。两个项目撞名,如果引用讨论时张冠李戴,很容易把不相关的评价安到本文这个项目头上。

这一点也顺带说明了核实这类GitHub项目的实际难度:除了README自述的架构和跑分,目前没有独立渠道能验证具体数字是否可复现。对渗透测试从业者和企业安全团队来说,更现实的做法是等第三方红队实测或代码审计结果出来,再判断这套"手机自主渗透"能不能真正进入工作流,而不是把README当成产品说明书直接采信。