Skip to content

Bot Virus v1

Objective

Build a containerized browser bot that completes the supplied task while passing the challenge's enabled anti-bot checks. The score is based on the runner's evaluation of the submitted image, not on a locally reported value.

Evaluation flow

  1. Retrieve the current input from GET /task.
  2. Produce the required miner_output containing bot.py and Dockerfile.
  3. Send the input and output to POST /score using X-API-Key.
  4. Inspect the latest evaluator feedback at GET /result.

Only the score endpoint requires authentication. Task retrieval, result retrieval, health, and API docs endpoints are public to the challenge network.

Requirements

  • Supply exactly bot.py and Dockerfile.
  • Build for linux/amd64.
  • Implement the complete bot directly and visibly in submitted bot.py. It must accept the assigned URL, open it in a headless Chromium-compatible browser, find and click #verify-button, then wait until window.BV_SUBMITTED === true.
  • Handle ordinary browser failures safely and always close a browser driver or equivalent browser process that was created.
  • Make the bot robust to fresh sessions and browser/runtime variation.
  • Use an established public upstream or challenge-maintained base image only. Miner-owned, personal, unknown, private, or arbitrary registry images are prohibited.
  • Keep the image self-contained; the runner builds and executes untrusted miner containers in an isolated environment.
  • Follow the live OpenAPI schema. Payload fields may evolve between challenge versions, so do not copy an old request body blindly.

Submission rules

Network access

The bot may contact only its assigned verification URL for browser verification. Do not download or fetch code, packages, assets, scripts, or other dependencies at build or evaluation time. Do not use external services or exfiltrate data.

Required files and limits

The score request must contain exactly the two required files. Their content is validated before evaluation:

File Maximum lines Validation
bot.py 2,000 Checked by Ruff using the challenge's TOML configuration.
Dockerfile 500 Must be supplied as the image definition.

The line limits apply to the submitted file contents. Exceeding either limit causes the submission to be rejected. Missing, renamed, duplicated, or extra files are invalid.

Implementation and container restrictions

bot.py must contain the complete miner-authored implementation. Do not hide or introduce implementation through a package, executable, generated or encoded payload, or another program launched by bot.py.

The Dockerfile may use only the base image's native OS package manager (such as apt, apt-get, apk, yum, or dnf) and its default, unmodified package sources. Install only public OS-level packages needed for the headless browser and bot: browser binaries/drivers, virtual-display tools, fonts, and ordinary system dependencies. Normal package-list cleanup is allowed.

Do not use language/application package managers or installers, including pip, uv, poetry, conda, npm, yarn, or gem. Do not fetch code or dependencies using curl, wget, git, URLs, archives, wheels, private indexes, or indirect shell commands. Do not add third-party apt repositories, PPAs, keys, or signing configuration; install unrelated packages; compile, generate, or unpack application dependencies; use remote ADD, multi-stage builds, or COPY --from. Ordinary COPY of the platform-provided bot folder and bot_runner.py is allowed.

Do not add malicious, obfuscated, bypass, persistence, privileged-execution, or host/container security-control modification logic.

Validation feedback

Evaluator feedback is intentionally brief and is not a code review. A passing integrity check reports exactly:

Script is legitimate and follows the challenge rules.

Using an application/language package manager; fetching code or dependencies; adding an untrusted repository or registry; or otherwise introducing dependencies or implementation outside the base image's default OS sources returns exactly:

Prohibited package installs are used.

The similarity evaluator applies the same dependency restrictions before comparison. A restricted install or hidden-code path is not compared to the reference and returns:

{"similarity_score":1.000,"reason":"used restricted installs"}

Other failures return one generalized category only, for example Submission does not meet the required runtime criteria., Submission violates the challenge security rules., or Submission has an invalid file structure. The evaluator does not disclose specific detections, implementation details, or bypass techniques.

Scoring

The runner applies two layers of checks:

  • Simple Bot is the first layer. It is a pass/fail gate containing common bot-detection checks.
  • Browser-web is the main check. Its configured browser sessions determine the submission's score.

Failures to build or run the image, timeouts, a failed Simple Bot gate, and failed browser-web checks affect the score according to deployed challenge config. Use GET /result for evaluator feedback; it is the authoritative result for a submission.

Local check configuration

Set these Boolean fields in the challenge repository's .env to enable or disable the local evaluation layers independently:

BV_CHALLENGE_SIMPLE_BOT_CHECK_ENABLED=true
BV_CHALLENGE_WEB_CHECK_ENABLED=true

Use true to enable a check and false to disable it. At least one check must remain enabled. These settings are for local testing; production evaluation uses the deployed challenge configuration.

API discovery

The deployed challenge exposes Swagger UI at /docs, ReDoc at /redoc, and the OpenAPI contract at /openapi.json. Use these endpoints to verify current payload schema and authentication requirements.