DEV Community: Krishnadev R

Found Out How Pirate Streams Were Using TikTok's CDN

Krishnadev R — Thu, 18 Jun 2026 14:43:44 +0000

So the other day, I was checking out some streams, how I can personally setup a stream in my own website, So I came across this sketchy y'know illegal stream. so I was like I had to know the source, so I do some inspection, basically network tab stuff, redirects me to some other site which was actually providing the stream and the first one was just embedding it. So when I came across the origin website, messing around it. so I open the network tab, checkout the requests, so there were two calls that mattered. the first was an api call that came back with an .m3u8 — and if you've not seen one, that's just a text file, a plain list of urls pointing at the little video chunks the player stitches together.(I found out about this the same day btw).the second call was the player actually going to that cdn and pulling the chunks. so I was a bit surprised there, I'm seeing tiktok's cdn there, being used for a illegal stream. and let's leave that part so I check the cdn req's response and its a image. blank image, from the avatar bucket of tiktok. so I was like confused how tf is the stream working with this.

so i pull the image down and look at them. and the front of it is a totally legit png, and then a few dozen bytes in it hits IEND. that's the marker that literally means "the image ends here." a normal png would just stop there.
this one didn't. it kept going.so i look at all that extra junk after IEND, and it's not random — there's a pattern. one specific byte, 0x47, showing up every 188 bytes like clockwork. and that's the tell: 0x47 every 188 bytes is the mpeg-ts sync byte. it's the fingerprint of video. ts segments. the exact thing an hls stream is made of. (got to learn all this the same day btw).

so the "image" was a real png for the first few dozen bytes, and then ~5 mb of straight-up video bolted onto the back of it.so its a polyglot file basically

A polyglot file is a single file that is valid in two or more different file formats at the same time

So knowing this was like a big deal to me, and me noticing the bucket made me wonder if it was the specific upload endpoint of tiktok that the exploiters were using. so yea I turn on vpn, go to tiktok, tryout uploading some files myself, verified the bucket, it was the same. so next step was making a polyglot file myself with a hidden message. then did the upload. downloaded the file. checked if my marker was still there and there it was! so yea verified. understood how exactly the exploiter's were using tiktok's cdn for streaming.

Idk if this is a big deal to anyone else, but it was pretty interesting for me. If I made/wrote any mistakes, my bad. Thanks for reading

I'll attach a diagram that I made for myself for better understanding with the post incase anyone wants to idk get a look at it, understand it.

[Boost]

Krishnadev R — Tue, 10 Feb 2026 02:58:47 +0000

Building a production grade infra for my project with Zero users.

Krishnadev R ・ Feb 9

#devops #aws #docker #backenddevelopment

Building a production grade infra for my project with Zero users.

Krishnadev R — Mon, 09 Feb 2026 19:13:35 +0000

So I had just finished building my fitness/progress tracker app's backend, basically a node app with Postgresql. It was already deployed on a ec2 machine which I go ssh into, take a pull and create the new image and run it.But at that time I thought this setup is boring. let's complicate it and make it production level, like how big apps do, so I did take refference of one production app I'm working on for the setup, read a few blogs, did gpt, understood one of the most common/stable setups in the industry. idk if that is even right. please do correct me if I'm not.

So after the research my data flow was ready. planned the entire infra setup for the application. below is an image I created in erasor:

so I'll give a walkthrough of the flow of a request,when a user makes a request, it hits our 'alb' - i.e is a layer 7 load balancer sitting in the public subnet and has its own security group which allows only http/https.

The alb then forwards the request to a target group, which maintains a list of healthy ec2 instances. The Target Group constantly health-checks our instances by hitting the /health endpoint every 30 seconds. If an instance fails two consecutive checks, it's marked unhealthy and traffic stops flowing to it.

These ec2 instances are managed by an auto scaling group, which ensures we always have a minimum of 2 instances running and can scale up to 10 based on CPU load. The instances sit in private subnets with no public IPs — they're protected by a security group, which only accepts traffic from the ALB.

ok so atlast it reaches our ec2 machine. there I've setup nginx, there wasn't any need but i just wanted to experiment, so nginx acting as a reverse proxy inside the ec2 machine proxies our request to our dockerized containers. so if we have multiple containers running we can proxy requests to those multiple containers. even tho I haven't set that up. will do it some upcoming day tho ig.

the app processes the request and if it needs data, it talks to our postgresql database on rds. the database sits in its own private subnet with a security group that only lets our ec2 instances connect to it

once the app finishes processing, the response travels back through the same path: docker container → nginx → alb → user. this might look like a long journey, long journey it feels now that I'm writing it down.so this would be the req flow.

and behind the scene we have promtail, an agent that ships logs to our monitoring server. where we have grafana+loki setup. which helps us monitor the load and logs of our zero user app.

and let me just wrap this up with the ci/cd part. whenever i push or merge to the main branch, a github actions workflow kicks off. it builds a docker image of the latest code, pushes it to ecr (amazon's container registry), then connects to each ec2 instance via ssm and does a rolling deployment — pulls the new image, stops the old container, starts the new one, runs a health check. waits 45 seconds between instances so there's always at least one server handling traffic. zero downtime deployments.

so guys any thoughts on how this could be better or any mistakes i made? idk any feedback would be appreciated