CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

ros2-dds-attack

ROS2/DDS network attack: unauthenticated topic enumeration, message injection, and telemetry interception against robotic platforms and autonomous systems.

Quality

77%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Critical

Do not install without reviewing

Fix and improve this skill with Tessl

tessl review fix ./packages/decepticon/decepticon/skills/standard/iot/ros2-dds-attack/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

75%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-structured, lean attack playbook with concrete executable commands, explicit safety gating on the destructive injection phase, and clear phase sequencing. The main gaps are minor: a few named-but-unshown tools, no post-action verification/feedback loop, and no offloading of secondary content (e.g., the MiR ROS1 variant) into reference files.

Suggestions

Add a short post-injection verification step (e.g., re-subscribe to /cmd_vel or observe robot state via /diagnostics) to close the feedback loop after the gated publish in Phase 3.

Either give 'ddsspy'/'rtpspy' a one-line usage example or drop the mention in favor of the fully-specified docker and cyclonedds alternatives.

Verify the cyclonedds Python snippet against the actual cyclonedds API (DomainParticipant lookup), or replace it with a known-good discovery snippet so all code paths are executable.

DimensionReasoningScore

Conciseness

Efficient throughout: commands, capture filters, and tables dominate, and the Background paragraph conveys attack-relevant specifics (multicast discovery, no auth, 20+ exposed topics) rather than generic filler. Not 5: minor trims possible (the acronym expansion 'ROS2 (Robot Operating System 2) uses DDS (Data Distribution Service)' and a few explanatory sentences). Not 3: there is no padded section or re-teaching of concepts Claude already knows.

4 / 5

Actionability

Mostly executable, copy-paste-ready guidance: docker ros:humble invocations, tshark/tcpdump filters with ports and multicast addresses, a complete ros2 topic pub payload, and find/ss one-liners. Not 5: minor gaps — 'ddsspy'/'rtpspy' are named without usage or install steps, and 'dp.lookup_topicdescriptions()' in the cyclonedds snippet is dubious API usage. Not 3: nearly everything is concrete and executable, not pseudocode.

4 / 5

Workflow Clarity

Phases 1–4 are clearly sequenced with pre-flight checkpoints: multicast reachability verification (ip route/ping/tshark) before enumeration, and the gated 'STOP' attestation (safety_critical_confirmed=true, zero-velocity safest PoC) before any publish — so the destructive-operation validation cap does not apply. Not 5: no post-action verification or error-recovery feedback loop (validate → fix → retry) after injection or capture steps. Not 3: checkpoints are explicit, not merely implicit.

4 / 5

Progressive Disclosure

Good structure with clear section headers, a topic-of-interest table, ATT&CK mapping, and clearly labeled external references; no bundle files exist, and the skill is self-contained. Not 5: at ~185 lines everything is inline — e.g., the MiR ROS1 variant section is a natural candidate for a separate reference file. Not 3: organization is clear and nothing is buried.

4 / 5

Total

16

/

20

Passed

Description

70%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A concise, specific description that names the domain and three concrete attack actions with distinct niche triggers. Its main weakness is the missing 'Use when...' trigger clause in the description field itself — the explicit trigger guidance lives in metadata.when_to_use rather than the description — and it omits the credential-extraction phase covered in the body.

Suggestions

Append a 'Use when...' clause to the description (e.g., 'Use when engaging ROS2/DDS robotic platforms — robots, autonomous systems, Unitree, MiR — for topic enumeration, telemetry interception, or command injection') so explicit trigger guidance lives in the description field, lifting completeness.

Fold one or two natural trigger synonyms users would say (e.g., 'ros topic', 'unitree', 'MiR') from metadata.when_to_use into the description to improve trigger term coverage.

Mention the credential/key-extraction phase (e.g., 'and extraction of hardcoded keys and credentials after shell access') so the description covers all four phases in the body.

DimensionReasoningScore

Specificity

Lists three concrete, domain-specific actions ("unauthenticated topic enumeration, message injection, and telemetry interception") against named targets ("robotic platforms and autonomous systems"). Not 5: the body also covers credential/key extraction and the ROS1/MiR variant, which the description omits — a minor coverage gap. Not 3: three named actions exceeds the '1-2 concrete actions' anchor.

4 / 5

Completeness

Has a clear, concrete 'what' (three enumerated attack actions) but the 'when' is only weakly implied via 'against robotic platforms and autonomous systems' — there is no 'Use when...' clause or equivalent explicit trigger guidance in the description field itself, which caps completeness at 3 per the judging guidelines. Not 2: the 'what' is specific, not vague; not 4: no explicit 'when' is present.

3 / 5

Trigger Term Quality

Good natural keyword coverage in the description itself: "ROS2", "DDS", "robotic platforms", "autonomous systems", "message injection", "telemetry interception". Not 5: common variations a user would naturally say ("ros topic", "rclpy", "unitree", "MiR") appear only in metadata.when_to_use, not in the description field. Not 3: coverage is well beyond 'some relevant keywords'.

4 / 5

Distinctiveness Conflict Risk

"ROS2/DDS network attack" is a clear niche with distinct trigger terms (ROS2, DDS, robotic platforms); minimal conflict risk with any other skill. Anti-drift check: the anchor-4 example ('minor overlap with closely related skills') does not fit better — these terms would not plausibly trigger the wrong skill.

5 / 5

Total

16

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

Total

15

/

16

Passed

Repository

PurpleAILAB/Decepticon

Path

packages/decepticon/decepticon/skills/standard/iot/ros2-dds-attack/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.