How to Play Rode0day

  1. Download the buggy binaries through the API described here.
  2. Use whatever means you like to find bugs in the program, manual or automated. Rode0day challenges are Linux binaries that take an input filename as part of a fixed command-line argument string. You will know you have found a bug when you have generated an input file that causes the operating system to crash the program.
  3. To get credit for finding a bug, you will submit your crashing inputs via the API. Since we are inserting bugs, we always know the root cause. This means we can disambiguate a number of crashes that manifest at different points but are actually the same bug. Be warned that you will not get credit for additional inputs that crash the program if they rely upon the same root-cause.
  4. When you submit a crashing input via the API you will be rewarded with a judgement, indicating an ID of the bug you triggered and if you are the first team to trigger that bug. Each unique bug you trigger is worth ten points and one bonus point is awarded when you are the first to find a bug.
  5. At the end of the competition, a new Rode0day competition will begin and the old competition will be archived.
  6. Please follow the rules, described below, during each Rode0day

Rules

  1. On the first Wednesday of each month at noon, we begin a new Rode0day, which consists of one or more binaries into which we have injected a number of bugs.
  2. Competitions typically begin at 4:00 PM UTC on the first Wednesday of each month. Competitions end after one month, when the next one begins.
  3. You can only get points for the current competition. After a competition ends, we archive the results. Archived results are far more detailed than those we provide during the current competition. For instance, you can examine the archive to see when each team found each bug. After the competition, you can also download the answers (the set of inputs that trigger the bugs we inserted).
  4. Rode0day competition binaries are available via the API.
  5. The API is how players must submit bugs for scoring.
  6. When we say "submit a bug" we mean provide an input that triggers a bug. You can't get credit by saying "there can be a buffer overflow at this instruction."
  7. You submit one input at a time.
  8. You will only get credit for a bug if it causes the program to crash, i.e., the program exits with a status code greater than 128.
  9. Since we are inserting bugs, we know the root cause of the crashes they cause. If two of your inputs trigger the same bug in a challenge binary, you will only be awarded points for the first, even if the inputs ultimately cause crashes at different parts of the program.
  10. If your input causes the program to crash without triggering any of the bugs we have injected, you will be awarded points for finding a zero-day after a manual review of your submission.
  11. You are awarded ten (10) points for each unique bug you find plus one (1) extra point if it is a "first", meaning you were the first player to find that bug.
  12. Submissions are rate-limited; you may only submit 10 inputs/minute and 10,500 inputs/month.
  13. You may not attack the challenge infrastructure or interfere with other players.
  14. One account per bug-finding system; you may not use multiple accounts to get around rate limits.
  15. The inputs you submit through the API will be made public after the competition ends.