2 Commits

Author	SHA1	Message	Date
cc-haha	64691f7672	fix(plugin): reverse-engineering 0.4.0 -> 0.4.2 review fixes ... Self-review of v0.4.0 surfaced three real bugs (would have produced incorrect output to the user / LLM) plus a handful of consistency gaps. None of these block enabling the plugin or break the smoke, but together they erode trust in what the plugin tells the user. Real bugs fixed --------------- 1. commands/triage.md and commands/report.md used a bash-style `${user_config.ARTIFACT_DIR:-artifacts/re-runs}` default-fallback. The substitute regex in src/utils/plugins/pluginOptionsStorage.ts is a plain `\$\{user_config\.([^}]+)\}` capture -- it would have keyed off the literal string `ARTIFACT_DIR:-artifacts/re-runs`, missed it, and returned the unsubstituted match, leaking the `:-default` syntax into the LLM prompt. Worse, manifest defaults (plugin.json `userConfig.ARTIFACT_DIR.default`) are NOT auto-merged into runtime options -- `loadPluginOptions` only reads settings.json + secureStorage. So the only way `${user_config.X}` resolves at all is if the user explicitly set it in the UI; for plugin authors who want a sensible fallback, the variable form isn't actually useful here. Switched both commands to a prose directive ("use ARTIFACT_DIR setting if present; otherwise default to artifacts/re-runs") that the LLM can resolve from context. This matches how the SKILL.md files already wrote the same idea. 2. agents/reverse-engineer.md "When you do NOT have the right MCP server available" still told the agent to point users at the `userConfig` toggle for each MCP. Those toggles (ENABLE_GHIDRA / ENABLE_RADARE2 / ENABLE_JADX / ENABLE_APKTOOL / ENABLE_FRIDA) were removed in the v0.4.0 cleanup -- they never actually controlled MCP loading, only made the userConfig dialog look more important than it was. The fix points users at Settings -> MCP for runtime enable/disable and at the README's prerequisites table for install instructions, both of which are the actual sources of truth post-cleanup. 3. agents/reverse-engineer.md description listed binwalk as a first-class tool in the toolchain bullet. binwalk is not bundled as an MCP -- skills/firmware-blob shells out to the binwalk CLI directly through Bash. Dropped from the description so the LLM doesn't hallucinate a binwalk MCP server when none exists. Consistency gaps fixed ---------------------- 4. README.md opening summary still claimed "five MCP servers ... six skills"; reality is seven MCP servers and eleven skills since v0.3.0/v0.4.0. The capability tables further down were correct, only the lead paragraph was stale. Replaced with a less number- coupled summary. 5. README install snippet hard-coded `C:\Users\70641\cc-haha\plugins` in three places. Replaced with `(Resolve-Path .\plugins).Path` so any contributor's checkout works without editing -- and noted `<repo-root>` semantics in prose for non-Windows readers. 6. README References section didn't list the new GDB and LLDB MCPs added in v0.4.0. Added entries for signal-slot/mcp-gdb and stass/lldb-mcp. 7. Added a README section "LLDB MCP -- fallback if uvx fetch fails" covering the upstream-packaging gap in stass/lldb-mcp (it ships as a single .py without an installable entry point, so `uvx --from git+...` may report `python: can't open file 'lldb_mcp.py'` on first start). The fallback recipe (clone + absolute python3 path) is now in the README rather than something each user has to rediscover. 8. plugin.json keywords were narrower than marketplace.json tags: keywords had 7 entries, tags had 16. Brought keywords up to the 12 most useful for plugin discovery (firmware, embedded, debugger, single-step, ghidra, radare2, frida, gdb, lldb). 9. skills/triage Step 3 routing table mapped "Live process / instrumented session" directly to frida-dynamic. The agent's Stage 3 says to read dynamic-debug-overview FIRST and let it pick between Frida / GDB / LLDB. Updated triage to match -- now any runtime question routes to dynamic-debug-overview, which then picks the right lane. 10. agent description had "iOS -> r2 + optionally class-dump", but skills/ios-analysis actually keeps Ghidra (with the iOS loader) in scope as well. Updated agent to "r2 (preferred, via the radare2 MCP) or Ghidra with the iOS loader" so the LLM knows Ghidra is also a path on iOS. Manifest version bump 0.4.0 -> 0.4.2 (two patch bumps because the first fix pass missed the loadPluginOptions semantics; bumping again re-materialised the cache after the corrected commands content was written). Verification ------------ bun run plugins/reverse-engineering/scripts/validate.ts -> 0 fail / 0 warn (marketplace + plugin schema both clean) bun run plugins/reverse-engineering/scripts/smoke.ts -> 13 passed / 0 failed version=0.4.2, commands=2, agents=1, skills=11, mcpServers=7, skill ids match the on-disk glob Cache materialised at ~/.claude/plugins/cache/cc-haha-builtin/reverse-engineering/0.4.2/ carries the corrected commands without the bash-style default-fallback. Confidence: high Scope-risk: narrow (plugin-only patch; no source code touched, no breaking change to existing skill names or component counts). Tested: validate (pass), smoke (13/13 pass), cache content spot-check of commands/report.md. Not-tested: live `/reverse-engineering:triage` against a real sample end-to-end; the substitution change is text-only and the runtime loader was unaffected.	2026-06-11 01:48:36 +08:00
小橙子	65a042bd08	fix: detect & isolate fake tool_use leaks from non-Anthropic providers (#4) ... * feat(plugin): add reverse-engineering plugin v0.4.0 + project-level codegraph Bundles a multi-platform RE toolkit as a local marketplace plugin that clone-and-enable installs in cc-haha desktop. Covers static (Ghidra, radare2, JADX, apktool, binwalk via Bash) and the gap a previous review called out: dynamic debugging is the lane that matters most for AI-driven RE, but Frida alone cannot single-step or set real breakpoints. This commit fills that gap with three non-overlapping dynamic lanes -- Frida (instrumentation, mobile, broad surveys), GDB (cross-arch single-step + breakpoints, embedded firmware), LLDB (Apple platforms, ObjC/Swift). Architecture coverage spans MIPS / ARM (incl. Cortex-M Thumb) / PowerPC (incl. e200 VLE) / 68k (incl. Mac Toolbox A-line traps) / SuperH / RISC-V / x86-64 / AArch64. The agent picks the right ISA, base address, and load configuration in skills/firmware-blob, then hands off to skills/pe-elf-macho with per-architecture decompilation notes (MIPS delay slots, ARM Thumb interworking, PowerPC TOC/SDA, 68k register banks, etc). Plugin layout (.claude-plugin marketplace + plugin manifests): plugins/.claude-plugin/marketplace.json plugins/reverse-engineering/ .claude-plugin/plugin.json v0.4.0, GHIDRA_INSTALL_DIR + ARTIFACT_DIR userConfig agents/reverse-engineer.md triage -> static -> optional dynamic -> report skills/triage/ file-type identification, packing, routing skills/pe-elf-macho/ Ghidra/r2 + per-arch notes for non-x86 skills/firmware-blob/ raw blob -> ISA + base address + Ghidra/r2 load config skills/apk-analysis/ JADX + apktool, Android attack surface skills/ios-analysis/ IPA bundle + Mach-O, FairPlay-aware skills/dynamic-debug-overview/ decision matrix Frida vs GDB vs LLDB skills/frida-dynamic/ hooks + Memory + CpuContext + Stalker + watchpoints skills/gdb-debug/ cross-arch via gdbserver / qemu-user / qemu-system skills/lldb-debug/ macOS / iOS device / Linux, ObjC/Swift symbols skills/crackme-keygen/ CTF / self-owned binary; ships keygen, not patch skills/re-report/ final structured report with IOCs + confidence commands/triage.md /reverse-engineering:triage <path> commands/report.md /reverse-engineering:report <sample-id> mcp/servers.json 7 MCP servers: ghidra (pyghidra-mcp PyPI), radare2 (npm), gdb (mcp-gdb npm), lldb (stass/lldb-mcp git), jadx, apktool, frida (kahlo-mcp git, all @main pinned) hooks/hooks.json empty placeholder scripts/validate.ts offline schema check via project's validatePluginManifest + validatePluginContents scripts/dev-link.ts Windows mklink /J cache -> repo source so SKILL edits don't require version bump (--restore undoes) scripts/smoke.ts end-to-end: marketplace register -> enable -> update -> reload -> assert detail counts. Counts derived from on-disk source (glob), not hardcoded; idempotent across reruns. README.md install, prerequisites per MCP, dynamic-capabilities matrix, architecture coverage, quickstart with busybox sample, dev-link / smoke workflows Project-level MCP (clone-and-go for any contributor): .mcp.json codegraph (npx -y codegraph serve --mcp); project scope, picked up automatically. Pre-existing user-level codegraph install still wins for users who have one. userConfig of the plugin is honest -- only knobs that actually do something (GHIDRA_INSTALL_DIR substituted into the ghidra MCP env; ARTIFACT_DIR resolved relative to agent cwd at run time). Earlier ENABLE_* booleans were removed because they didn't actually toggle anything; users disable individual MCP servers from Settings -> MCP at runtime. End-to-end verification (server on :3456, vite on :1420): - bun run plugins/reverse-engineering/scripts/validate.ts -> 0 fail / 0 warn (marketplace + plugin schema both clean) - bun run plugins/reverse-engineering/scripts/smoke.ts -> 13 passed / 0 failed (marketplace registration, enable, update 0.3.0->0.4.0, reload, detail assertions including 11 skill ids matching the on-disk glob) - GET /api/plugins/detail -> commands=2 / agents=1 / skills=11 / mcpServers=7 / errors=[] - GET /api/mcp -> codegraph appears with scope=project, configLocation=.mcp.json - Desktop UI Settings -> Plugins -> v0.4.0 listed in enabled group, "11 skills 1 Agent 7 MCP" External tool prerequisites (each MCP needs its underlying tool on PATH; users install per-MCP independently -- none required all at once): Ghidra (Java 17+), r2, GDB (gdb-multiarch for cross-arch), LLDB, frida-tools, JADX (Java 17+), apktool. Codegraph requires either a local global install (npm i -g codegraph) or relies on npx to fetch on first run. Constraint: Cannot single-step from Frida alone -- that's the gap GDB and LLDB fill in this commit. dynamic-debug-overview SKILL is the canonical decision guide for which lane to use. Confidence: high Scope-risk: narrow (additive plugin under plugins/, additive .mcp.json; zero changes to existing source). Plugin loads via the existing PluginManifestSchema path -- no new server-side code added. Tested: bun run plugins/reverse-engineering/scripts/validate.ts (pass), bun run plugins/reverse-engineering/scripts/smoke.ts (13/13 pass), live chrome-devtools MCP smoke against running desktop UI verifying plugin appears with correct version + counts. Not-tested: real underlying-tool integration (Ghidra/r2/JADX/GDB/LLDB must be installed by the user; the plugin only validates manifest shape and component loading). Reverse-debugging (rr) flow is documented in skills/gdb-debug but not exercised in smoke. * fix: detect & isolate fake tool_use leaks from non-Anthropic providers Some third-party Anthropic-compatible gateways (mimo, lgfzer, certain proxies) don't relay native tool_use blocks: when the model wants to call a tool, it ends up emitting an XML-style `<tool_use ...>{...} </tool_use>` element as plain text inside content_delta. The desktop chat renders that as markdown, marked passes the unknown element through as raw HTML, the browser collapses whitespace, and the user sees garbage like `<tool_useid="..."` followed by a smushed shell command. Worse, the model has no signal the call never executed and follows up with apologies ("工具用错了, 重来:") and retries — every "call" is text and nothing runs. Three layers of defense, lowest to highest in the stack: 1. **Source-side priming reduction** (server). The specialistRouter docstring already warned that `key="value"` attribute fragments in model-facing strings make some gateway models switch from real tool_use blocks into XML mode. Three model-facing nudges still embedded `subagent_type="verification"` in their reminders — fix them to use prose ("set the subagent_type parameter to verification") so we stop priming the failure mode: - src/utils/messages.ts (verification_gate_reminder) - src/tools/TodoWriteTool/TodoWriteTool.ts - src/tools/TaskUpdateTool/TaskUpdateTool.ts New regression test src/utils/noKeyValueNudges.test.ts pins all three call sites so a future "typo fix" doesn't accidentally re-introduce the attribute form. 2. **Detection + sanitization** (desktop). New desktop/src/lib/fakeToolUseDetection.ts extracts XML-style `<tool_use>` blocks (closed, half-open mid-stream, multiple consecutive retries, `name`/`id` in either order, quoted or unquoted, inside or outside fenced code blocks) and returns `{ cleanText, blocks[] }`. AssistantMessage uses this before handing content to MarkdownRenderer so the user never sees the XML garbage; copyText also uses cleanContent so users don't paste broken markup. Fenced code blocks (```xml ... ```) are preserved so legitimate documentation examples render as-is. 3. **Provider compatibility tracking** (desktop). New desktop/src/stores/providerCompatStore.ts counts fake tool_use leaks per provider id, persisted to localStorage. After 3 leaks it fires a one-time toast suggesting the user switch providers. Settings → Provider list shows a "工具调用异常" badge on offending providers; saving an edit on a flagged provider re-arms the warning (clearProvider). Above-threshold detection is silent afterward so we don't spam — the badge stays as the persistent signal. The new FakeToolUseNotice component renders an inline grey card above the assistant bubble naming the attempted tool ("Bash") and making it clear nothing ran, so the user knows not to trust any follow-up "Done." claim that depended on the call's output. Verified: - desktop: bun run lint clean - desktop: 28 new tests + existing AssistantMessage.linkrouting (15 total) pass - server: 31 tests across verificationGate, specialistRouter, and the new noKeyValueNudges regression all pass Tested: bun run lint (desktop), bunx vitest run (3 desktop suites), bun test (3 server suites) Confidence: high Scope-risk: narrow --------- Co-authored-by: cc-haha <cc-haha@users.noreply.github.com> Co-authored-by: 你的姓名 <you@example.com>	2026-06-10 20:01:32 +08:00