Scavenger Hunt picoCTF 2021 Solution

Description

1. Step 1

   Part 1: HTML source

   Observation

   I noticed the challenge description said information is hidden 'around this site,' which suggested the first hiding spot would be the most obvious one: the raw HTML source, where developers commonly leave comments that are invisible in the rendered page.

   View the page source (Ctrl+U or right-click > View Page Source). Find a comment containing the first part of the flag: picoCTF{....
2. Step 2

   Part 2: CSS file

   Observation

   I noticed the HTML source linked to an external stylesheet at /mycss.css, and since the HTML comment hinted at more parts to find, I checked the CSS file directly for developer comments that would survive in the raw file even if minified away in the browser.

   The HTML links to a CSS file at /mycss.css. Open it and look for a comment. It contains the second part: h4ts_4_l0

   bash

   curl -s http://<server>/mycss.css

   Copied!

   What didn't work first

   Tried: Viewing the CSS inside the browser DevTools Sources panel instead of opening the raw file URL

   DevTools minifies or reformats the file in some browsers, stripping comments before displaying them. Opening the raw URL directly (or curling it) shows the unmodified source including the comment that holds the flag part.

   Tried: Searching only the HTML source for all flag parts at once

   The HTML only embeds Part 1 in a comment; Parts 2 and beyond are split across separate linked files. Stopping at the HTML source gives an incomplete fragment and no indication of where the chain continues.

3. Step 3

   Part 3: JavaScript file and robots.txt

   Observation

   I noticed the HTML also referenced /myjs.js, and since each linked resource was a potential hiding spot, I fetched it and found a comment pointing explicitly to robots.txt, which is a standard recon file that often exposes paths the server owner wanted hidden from crawlers.

   The HTML also links to /myjs.js. A comment there hints to check robots.txt. Open /robots.txt and find the third part: t_0f_pl4c

   bash

   curl -s http://<server>/myjs.js

   Copied!

   bash

   curl -s http://<server>/robots.txt

   Copied!

   What didn't work first

   Tried: Curling /myjs.js and stopping there without also fetching robots.txt

   The JS comment does not contain a flag part itself - it is a breadcrumb that explicitly says to check robots.txt. Stopping at /myjs.js yields only a hint string, not the third flag fragment, which lives in robots.txt.

   Tried: Assuming robots.txt only lists Disallow paths and grepping for 'Disallow' to find the flag part

   The flag part is embedded in a comment line (prefixed with #), not in a Disallow directive. Grepping only for 'Disallow' misses comment lines entirely; grepping for 'picoCTF' or reading the full file is needed.

   Learn more

   robots.txt is a file at the root of a web server that instructs search engine crawlers which URLs to index or avoid. It is publicly accessible by anyone and is frequently checked during web CTF recon since it often reveals hidden paths or admin areas the site owner does not want indexed - but has not actually protected.

   Sample contents. A real robots.txt entry that exposes the next breadcrumb often looks like:

   User-agent: *
   Disallow: /.htaccess
   # Part 3: t_0f_pl4c

   The Disallow path is a hint, not a defense - search engines respect it, attackers do not.

4. Step 4

   Part 4: .htaccess

   Observation

   I noticed robots.txt contained a Disallow entry for /.htaccess along with a breadcrumb comment, which suggested the server was Apache and that its per-directory config file was accessible directly over HTTP rather than being protected by the usual deny rule.

   robots.txt hints at an Apache server configuration file. Check /.htaccess. It contains the fourth part: 3s_2_lO0k

   bash

   curl -s http://<server>/.htaccess

   Copied!

   What didn't work first

   Tried: Requesting /.htaccess and getting a 403 Forbidden, then giving up

   Many Apache defaults block direct reads of .htaccess with a 403. In this CTF instance the deny rule is intentionally absent so the file is accessible. A 403 on a real server is expected behavior; here it signals the challenge is misconfigured on purpose, so the request is worth making.

   Tried: Trying /apache.conf or /httpd.conf instead of /.htaccess

   The robots.txt breadcrumb references Apache configuration but the per-directory override file is .htaccess, not the global server config files. httpd.conf and apache.conf live outside the web root and are never accessible over HTTP; .htaccess is the only Apache config file that sits inside the document root.

   Learn more

   .htaccess is an Apache per-directory configuration file. It can define URL rewrite rules, authentication requirements, custom headers, and password protection (AuthType Basic). Apache reads it on every request to the directory it lives in, which is why misconfiguring it (forgetting the <Files> deny block) is so common. Out of the box Apache denies direct fetches with a 403, but plenty of distributions and tutorials drop that protection, exposing the server's internal rewrite/auth logic.

5. Step 5

   Part 5: .DS_Store

   Observation

   I noticed .htaccess contained a comment hinting at a Mac-specific hidden file, and since .DS_Store is the notorious macOS Finder metadata file that developers routinely commit and deploy by accident, fetching /.DS_Store was the logical next step even though the file is binary and requires strings to extract readable content.

   .htaccess hints at a Mac-specific file. Request /.DS_Store - this macOS metadata file is sometimes accidentally uploaded to web servers. The file is binary, so do not just cat it; pull plain text out with strings.

   bash

   curl -s http://<server>/.DS_Store -o ds_store.bin

   Copied!

   bash

   strings ds_store.bin | grep picoCTF

   Copied!

   Expected output

   picoCTF{th4ts_4_l0t_0f_pl4c3s_2_lO0k_...}

   What didn't work first

   Tried: Running curl on /.DS_Store and piping directly to grep picoCTF without saving to a file first

   The .DS_Store file is binary and curl may output garbled bytes that corrupt grep's input when piped without the -s flag or a save step. Saving with -o first and then running strings on the saved file is more reliable because strings handles binary input and extracts printable sequences that grep can then filter cleanly.

   Tried: Using cat on ds_store.bin instead of strings to read the flag

   cat outputs raw binary bytes to the terminal, which produces garbage characters and can corrupt the terminal session. The strings utility extracts only sequences of printable ASCII characters from binary files, isolating the embedded filename strings (including the flag) from the surrounding binary metadata.

   Learn more

   .DS_Store files are created by macOS Finder to store folder view settings (icon positions, column widths, etc.) in a proprietary binary format. When developers deploy websites from a Mac without a .gitignore entry for .DS_Store, these files get uploaded to the server alongside the actual web content. They can leak directory structure and file listings - tools like ds_store_exp parse them to reconstruct entire directory trees. For a flag check, strings is enough since .DS_Store stores filenames as UTF-16 strings interleaved with metadata.

Flag

Hidden server files like .htaccess and .DS_Store are often accidentally accessible on misconfigured servers - each file in this challenge hints at the next.