my-flipper-shits

GitHub 项目深度分析：aleff-github/my-flipper-shits

项目背景与痛点

Flipper Zero 从诞生那天起，最受关注的从来不是红外遥控或 RFID 嗅探，而是它那根 USB-C 线插进电脑后伪装成键盘的能力——BadUSB。硬件形态足够“无害”，固件里内置的 DuckyScript 解释器又足够直接，于是整个社区真正缺的东西不是机器，而是载荷本身。

这就是 aleff-github/my-flipper-shits 存在的位置。它不提供框架、不造轮子，只做一件事：把 Windows、GNU/Linux、macOS/iOS 三端的 BadUSB 脚本按目录归拢成一份可直接取用的库。名字里那个自嘲的 “shits” 已经说明定位——这不是商业项目，是黑客社区典型的“我攒了一堆东西，顺手开源”式仓库。

痛点很具体。DuckyScript 的语法门槛不高，但真正把一条 payload 跑通，需要处理的事一点不少：目标系统的快捷键路径、Shell 的可用性、命令行的杀软检测、键盘布局的映射差异、HID 枚举到驱动就绪的时间窗口。社区的脚本散落在论坛帖和 gist 里，复制粘贴后往往因为一个 DELAY 少了 800ms 就全线崩盘。这个仓库的价值在于收敛：把反复试错过的时序和调用链固化下来，变成可复用的模板。

核心技术揭秘

BadUSB 的技术底牌并不复杂：设备伪装成一个标准 HID 键盘，逐条把按键事件以 USB 报告的形式推给主机。主机没有任何理由怀疑——它看到的是一个键盘，输入的就是“人”的输入。真正的工程难度全在上层脚本的编排与跨系统差异的抹平上。

从数据流看，一条 payload 的生命周期大致如下：

解释器层面，仓库里的脚本基本只用到 DuckyScript 的核心子集：DELAY 控时序、STRING 输出文本、GUI/CTRL/ALT 组合修饰键、ENTER 提交、REPEAT 重复。少量脚本会用到 HOLD/RELEASE 做长按，或借助 Flipper 扩展指令处理特殊字符。

真正体现设计功底的是三个隐性约定：

其一，延迟的保守化。 几乎所有 payload 开头都有 1000～3000ms 的 DELAY。这不是偷懒，而是为了覆盖 USB 枚举、HID 驱动加载、桌面会话就绪的完整链路。Windows 冷启动时这个窗口可以拉到 5 秒以上。仓库通过统一的保守延迟换取跨机器成功率。

其二，编码载荷绕检测。 直接敲 powershell -Command "IEX(...)" 是最容易被 EDR 抓到的写法。仓库中的多数 Windows 脚本走 -EncodedCommand（Base64 + UTF-16LE），把明文命令行打散成不可读的字符流，同时规避引号转义带来的按键映射问题。这既是免杀手段，也是工程上的必然——DuckyScript 里连续输入复杂引号极易触发键盘布局错位。

其三，键盘布局与输入法的隐性陷阱。 Flipper 需要预设目标键盘布局（US/AZERTY/DE 等），布局不匹配时 STRING 会打出完全错乱的字符。更麻烦的是中文环境：IME 处于激活状态时会吞掉组合键，因此不少 Windows payload 会先执行一次输入法切换（GUI SPACE 或 ALT SHIFT）再进入正题。这类细节在 README 里往往只有一句注释，但恰恰是脚本能否跑通的分水岭。

至于 iOS/macOS 分支，能力边界明显更窄。沙盒机制让持久化几乎不可行，脚本多做 Spotlight 唤起、快捷指令触发之类的轻量操作，本质是“演示可行性”而非“完成完整入侵链”。

功能亮点与差异

与 Rubber Ducky、Digispark 这类老牌 HID 注入设备相比，这个仓库的差异不在技术，而在生态位：

• 零迁移成本。DuckyScript 语法高度同源，Rubber Ducky 的老 payload 稍加调整即可在 Flipper 上跑，社区资产可以直接复用。
• 跨平台目录化。Windows / Linux / macOS 分目录整理，配合命名规范，检索成本极低，比在论坛里翻帖高效一个量级。
• 硬件形态优势。Flipper 是合法售卖的消费级玩具，随身携带不引人注意，这是 P4wnP1、USB Rubber Ducky 这类“一看就有问题”的设备不具备的。
• 社区众包式更新。脚本由多人贡献，覆盖面广，代价是质量方差大——这也引出下文的问题。

应用场景与落地建议

合法且高价值的场景集中在安全评估与意识培训：红队物理入口测试（验证终端 USB 端口管控是否生效）、企业内部钓鱼演练（演示“捡到 U 盘插一下就中招”的真实链路）、以及 HID 攻击的教学演示。

落地时有几条硬性注意点：

1. 必须授权。物理接触式攻击在法律上属于高危行为，任何演练都要有书面范围和见证人。
2. 隔离环境先行。脚本对系统版本、补丁级别、EDR 策略高度敏感，先在目标同构的虚拟机里跑通再上真机。
3. 把它当作检测能力的试金石。真正该关心的不是 payload 能不能跑，而是你们的终端管控能不能拦住一个“合法键盘”。USB 设备白名单、HID 行为审计、PowerShell 约束语言模式（Constrained Language Mode），才是防御侧的正解。
4. 不要迷信脚本时效性。Windows 11 的 UI 路径、默认终端、UAC 策略都在变，仓库里部分脚本可能已经失效，使用前先逐行核对。

综合评价

优点：定位清晰、覆盖面广、上手成本极低；把跨系统的时序与编码经验沉淀成了可直接复用的资产；与既有 DuckyScript 生态无缝衔接。

缺点：质量参差，缺少统一的测试与版本适配标注；不少脚本依赖特定系统版本，随时间推移持续腐化；仓库本身对“授权使用”的约束仅停留在 README 层面，事实上降低了攻击门槛——这是所有公开 payload 库的共同原罪。

一句话总结：它不是技术创新的项目，而是经验工程的集合体。对防守方，它是一份极好的攻击面清单；对攻击方，它是一把已经开刃、但你得自己确认握法是否合法的刀。用它之前，先想清楚你站在哪一边。