Uds Diagnostic Test
PassAudited by ClawScan on May 10, 2026.
Overview
This is a coherent UDS/CAN diagnostic testing skill, but it performs high-impact local hardware setup and ECU testing actions that should only be run in an authorized lab environment.
Install this only if you intend to run UDS/CAN diagnostics on authorized hardware. Review the setup script, dependency source, sudoers recommendation, CAN parameters, generated test script, and any SeedKey DLL path before execution. Prefer a dedicated bench/test machine and avoid running state-changing UDS tests on production vehicles or shared CAN buses.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
Running the skill can change CAN interface state and interrupt other CAN users or tools on the machine.
The CAN initialization script uses privileged local commands to load kernel modules, reconfigure CAN interfaces, and potentially kill processes holding the CAN interface. This is expected for SocketCAN setup but can affect the host and connected hardware.
sudo modprobe ${mod} ... sudo fuser -k /sys/class/net/${CHANNEL}/ ... sudo ip link set ${CHANNEL} type can ... sudo ip link set ${CHANNEL} upRun it only on a dedicated test machine or authorized ECU bench, verify the CAN channel/bitrate before execution, and avoid force-cleanup unless needed.
Future CAN setup commands covered by that sudoers rule can run as root without a password.
The README recommends a persistent passwordless sudoers rule for CAN setup commands. It is disclosed and scoped to CAN-related commands, but it still changes the system privilege boundary.
echo "$(whoami) ALL=(root) NOPASSWD: /sbin/ip link set can* type can *, /sbin/ip link set can* up, /sbin/ip link set can* down, /sbin/modprobe can*, /usr/bin/fuser -k /sys/class/net/can*" | sudo tee /etc/sudoers.d/can-setup
Only add the sudoers rule on trusted test machines, review the exact rule before applying it, and remove it when no longer needed.
A malicious or untrusted SeedKey DLL could execute arbitrary native code on the test machine.
Generated tests can load a Vector SeedKey DLL/native library for SecurityAccess. This is purpose-aligned for UDS $27 unlocking, but loading native libraries executes code from that library in the local process.
self.dll = ctypes.cdll.LoadLibrary(self.dll_path) ... SEEDKEY_DLL_PATH = "{seedkey_dll_path}" ... seedkey_dll = VectorSeedKeyDll(SEEDKEY_DLL_PATH, SEEDKEY_VARIANT, SEEDKEY_OPTIONS)Use only trusted vendor SeedKey libraries from verified paths, avoid paths supplied by untrusted survey files, and disable SecurityAccess DLL loading when not required.
If run on the wrong ECU, vehicle, or shared CAN bus, tests may change device state or disrupt other systems.
The documented UDS coverage includes services that can reset an ECU, clear diagnostic information, write data, control I/O, run routines, and change DTC settings. These are expected diagnostic-test actions but can affect real devices.
UDS服务覆盖 ... ECUReset ... ClearDiagnosticInformation ... WriteDataByIdentifier ... IOControlByIdentifier ... RoutineControl ... ControlDTCSetting
Use the skill only on authorized targets, preferably on a bench setup, and review the generated test plan before executing state-changing services.
Dependency resolution may pull newer package versions from the configured package index.
The setup script installs dependencies from a package index, and requirements.txt uses version ranges rather than pinned hashes. This is normal for Python environment setup but depends on trusted package sources.
"$VENV_DIR/bin/python" -m pip install $pip_flags --no-cache-dir -r "$SKILL_DIR/requirements.txt"
Use a trusted package index, consider pinning versions or hashes for regulated test environments, and review dependency changes before use.
