adb-karrot

SUSPICIOUS. The skill is internally consistent, but its stated purpose is to help an AI agent bypass Play Integrity and LIAPP protections, automate login/actions, and operate with detection avoidance. Install trust is mostly local/offical-tool based rather than a random payload, so this is not confirmed malware, but it is a high-risk offensive mobile bypass/automation skill with disproportionate capability for an AI agent and screen data flowing to an external vision API.

No explicit malware (e.g., network exfiltration, reverse shells, cryptomining) is demonstrated in this fragment. The primary security concerns are (1) unsafe command execution in _run_adb using shell=True with interpolated command strings (command injection potential if any interpolated values become untrusted), (2) trusting tamperable /tmp checkpoint files for resume-driven execution of device actions, and (3) executing external helper scripts via uv run (supply-chain risk). The presence of a hardcoded phone number increases privacy exposure. Overall risk is moderate-to-high for integrity and safety, low evidence for overt malicious payload within this single file.

No clear evidence of explicit malware (no backdoor/persistence/system damage/keylogging shown). However, the module has security-relevant risks: (1) possible command injection due to subprocess with shell=True in `_run_adb` if `cmd` is ever influenced by untrusted input, and (2) intentional exfiltration of on-screen UI content to Anthropic when AI Vision is enabled (screenshot bytes are read and sent). The snippet also appears corrupted/merged, limiting certainty. Recommend reviewing the full repository, especially how `_run_adb` is called and where AI Vision responses are used.

No direct evidence of malware (e.g., reverse shell, persistence, cryptomining, or obvious data exfiltration) is present in this file. However, security and privacy risks exist: (1) subprocess.run with shell=True is a high-risk pattern for command execution; (2) hardcoded phone/neighborhood are used and the phone is logged to /tmp; (3) screenshots are saved to /tmp; and (4) critical behavior is delegated to karrot_ai_vision and karrot_smart_detector, which may perform network calls using an API key or include malicious logic. Those dependencies must be audited to rule out supply-chain sabotage or exfiltration.

No direct evidence of intentional malware (backdoor/RCE/stealth credential theft) is present in this fragment. However, the design creates a high privacy/data-exfiltration risk: during authentication/verification screens, it may capture screenshots that include phone numbers and one-time verification codes and then transmit those screenshots (base64-encoded) to a third-party vision API for classification. Additionally, an example uses `shell=True`, which could become dangerous if command strings are influenced elsewhere. Treat this as a security-alert primarily for sensitive-data handling rather than malware.

This module is primarily an ADB-driven login automation wrapper that injects plaintext credentials into a target app UI and optionally checks device logcat for specific integrity/bypass-related error patterns (“-18” / play integrity). No explicit in-module malware behavior (e.g., network exfiltration, persistence, reverse shells) is evident from the fragment provided. The main security concerns are (1) credential exposure risk due to CLI plaintext handling and `adb shell input text`, and (2) supply-chain execution risk because it runs additional local helper scripts via `uv run` from project-relative paths without integrity verification—if those scripts/dependencies are compromised, they could perform malicious actions. Overall risk is moderate: not clearly malicious itself, but security-relevant automation and execution-chain trust must be reviewed.

This module is not clearly malicious in the classic sense (no visible backdoor, exfiltration, or dynamic payload), but it is a high-impact ADB automation tool tailored to an app signup/verification workflow. It can facilitate automated account enrollment/verification and includes security-hygiene issues (subprocess.run with shell=True) plus privacy concerns (hardcoded default phone number and printing it to stdout). Given the truncated/incomplete end of the file, confidence is moderate; the primary supply-chain concern is abuse potential and command-execution hygiene rather than overt malware payloads in this fragment.

This appears to be an ADB automation/testing launcher with optional OCR-based UI verification. No explicit malware indicators (e.g., exfiltration, backdoors, reverse shells, or credential theft) are present in the provided fragment. The primary risks are operational/destructive impact on the connected device (`pm clear` wipes app data) and indirect supply-chain/execution risk from running a repository-local OCR script via `uv run` (dependency resolution and integrity of `.claude/skills/...`). Due to the snippet’s truncation, confidence in full behavior is limited.

This module is primarily an ADB UI automation tool that taps screen coordinates on a specified Android device. It includes randomness in timing and coordinate selection explicitly consistent with evading interaction/automation detection. There are no clear indicators of classic malware in this snippet (no exfiltration, persistence, or credential theft), but the ability to remotely execute input-tap commands on a device is an abuse-enabling primitive and should be reviewed in context (where it is used, which devices are targeted, and whether any additional logic exists elsewhere in the package).

No executable code is shown, but the fragment functions as an operational playbook to interpret mobile integrity/fraud detection signals and to run/maintain an integrity-bypass workflow. This strongly suggests security-evasion intent and an attempt to avoid enforcement that restricts transactions/payments and other features when “verification failed” or detection keywords appear.

This fragment does not show concrete malicious code, but it documents a high-impact capability: automated login with 2FA completion (including SMS-driven code handling) and capture of session/authentication metadata (including session tokens if accessible), plus references to potentially bypass-oriented workflows. Risk is therefore driven by misuse and sensitive credential/session handling rather than demonstrated malware in this excerpt. Review the actual workflow implementation to verify how verification codes and session tokens are handled (logging, storage, propagation) and whether bypass-related steps can undermine security controls.