How pirate video hosts circumvent Cloudflare's TOS

I always find it fascinating to observe the strategies and techniques streaming sites use to abuse free or cheap services on the internet to propagate their content to viewers while keeping hosting costs low. One of the biggest "helpers" for pirates looking to serve media to users has been Cloudflare, due to their insanely generous free plans (I use Cloudflare legally, and it's still insanely generous). I'm sure Cloudflare is well-aware about the attention they attract as a way to proxy media, and they have cracked down many times on abusers. A while ago, they updated their TOS, specifically aimed at prohibiting the abuse of their CDN for video streaming. However, even today, it seems many sites still get away abuse at a massive scale. Let's take a look at the some of the tricks these sites use to trick Cloudflare into service their videos. The only tool you'll need to perform what I'm doing is the developer tools of your browser.

To start with, let's open up the network tab, and refresh the page. We see the usual obfuscated JavaScript files meant to deter authors of streaming app plugins, and in this case we even see that this video host is particularly irritated at what (after some googling) appears to be an anime streaming app, probably scraping their streams and using them in-app:

In case you're wondering why they care, aside from the obvious potential for abuse of their bandwidth, these stream hosts make their money off of ads in the video player. When people rip the stream directly, the host makes no money off them. This is why, of course, we see that an ad network script is loaded from a randomly-generated domain name (of course, they're always changing in a cat-and-mouse game against ad-blocker domain blacklists). Next up, an API call is made on the well-known domain two separate files located on two other somewhat random domains (take-down resistant and abuse-spreading):

We'll skip the thumbnails, it's just for the scrubber thumbnails in the video player. Let's focus instead on the first link, which points to an .m3u8 playlist. The contents of this playlist are fairly normal, and point to sub-lists for various video qualities available in the player:

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=4500000,RESOLUTION=1920x1080
bbbcbcdac4/ceeb;15a38127e50f5f47b5916406d5b9ff059e30af435bb9babb4c476c.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1800000,RESOLUTION=1280x720
bbbcbcdac3/ceeb;15a38127e50f5f47b5916406d5b9ff059e30af435bb9babb4c476c.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=720000,RESOLUTION=640x360
bbbcbcdac1/ceeb;15a38127e50f5f47b5916406d5b9ff059e30af435bb9babb4c476c.m3u8

When we look at a single resolution's file playlist, we see something interesting however...

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-ALLOW-CACHE:YES
#EXT-X-TARGETDURATION:4
#EXTINF:3.083333,
edaacc0000.gif
#EXTINF:3.000000,
edaacc0001.png
#EXTINF:3.000000,
edaacc0002.html
#EXTINF:3.000000,
edaacc0003.js
#EXTINF:3.000000,
edaacc0004.css
#EXTINF:3.000000,
edaacc0005.txt
#EXTINF:3.000000,
edaacc0006.vtt
[...omitted the rest]

What's going on here? This playlist is supposed to be pointing to fragments of the video for the player to load. But instead we see there is a GIF image, a PNG, an HTML file and more! Well, as you may have guessed by now, this is a simple trick used to circumvent Cloudflare's video file detection. If we take a closer look at one of the files, we see that this is being served directly from Cloudflare's cache (meaning it costs the host nothing, and is retrieved with low latency from a local datacenter):

If you look closely, the content-type of the file (in this case a .txt) matches the extension. This makes it more difficult for Cloudflare to determine that the file is actually a video fragment. If we peek at the file, we see the tell-tale FFmpeg metadata (everything media-related uses FFmpeg somewhere in the pipeline, whether legal or illegal):

If you were to download this filename and rename it to .ts, you could easily open it in your video player, and you would find an H264 video stream (with audio). The small and random file size of each fragment of the stream also helps reduce suspicion, as a ~500KB HTML, PNG, JPG etc. file is relatively inconspicuous on the web:

In summary, if you choose randomized file extension + content-type headers of common (and acceptable per Cloudflare TOS) file types seen on your average website, and keep the file size reasonable, it seems you have a better chance of bypassing Cloudflare's abuse filters. It is of course entirely possible that Cloudflare is already aware of this strategy, but pirates are constantly innovating when it comes to the abuse of free services on the web. If an when this method is patched, I'm sure another one will replace it.

Bonus

I said not to pay much attention to the thumbnails file, but it interesting to see that its host is not proxied by Cloudflare. When this is the case, you can usually explore in much more detail what these pirate networks look like, using services like Censys. We see the usual tell-tale signs of such a network, including the use of cheap hosts like OVH, the same ports and software being used across machines, etc.

It's always funny to see the generic landing pages with trendy artwork, and the usual "I'm totally not a pirate video host" text. Too bad their "registration" is closed due to "abuse". Nice overall try at plausible deniability and insulation from the pirate sites themselves :)