I Built Something That Feels Illegal And This Is Why I Did It

Just because software can verify something doesn't mean it is actually verifying what you think it is.

Recently, I built something called DisPlay MKishoreDev/display.

The name is basically what it sounds like:

Discord + Play.

It started with something incredibly ordinary: I wanted some cool Discord profile stuff.

And somehow, that turned into me learning about game detection, process spoofing, advertising systems, platform rules, and one of the most important things I've been thinking about lately:

I came back to Discord and suddenly there were Quests

I've been much more active on Discord recently because of freelance work, developer communities, and random technical communities I've joined.

And if you've spent enough time on Discord, you've probably noticed something:

Some people's profiles look really good.

Cool avatars.

Profile decorations.

Banners.

Effects.

Meanwhile, I had basically ignored all of that.

I originally installed Discord years ago, and I remember seeing Nitro and thinking:

"Nah, I'm not paying for that."

Nothing against Nitro. I just never needed it enough to pay for it.

But when I started using Discord more recently, I noticed something I hadn't really paid attention to before:

Quests.

Discord's current system describes Quests as a rewarded advertising format. Instead of simply showing you an advertisement, Discord gives you an activity related to a game or piece of content, and completing it can give you a reward.

And honestly?

I think that's pretty clever.

It's basically advertising disguised as something you can actually want

Normally, advertising is:

Here's an ad. Watch it.

YouTube does it.

Websites do it.

Apps do it.

And most of us have developed the ability to mentally ignore advertisements after approximately three seconds.

Discord took a different approach.

Instead of saying:

"Watch this advertisement."

it can say:

"Play this game for 15 minutes and get something for your Discord profile."

Now there's an incentive.

Discord gets advertising revenue.

The game gets exposure.

And I get something I actually want.

That's a pretty smart three-way exchange.

Discord even calls Quests a way for players to discover games while earning rewards for playing, streaming, or watching content.

And recently, those rewards have become much more interesting through Discord Orbs.

Instead of just getting a single game-specific avatar frame, Discord introduced Orbs as a virtual reward currency earned from eligible Quests. You can save up Orbs and redeem them in the Discord Shop for profile decorations, avatar effects, and even limited-time Nitro Credits (like 3-day Nitro access passes).

So naturally, I wanted to earn some.

Then Discord said: "Download the game."

This is where my enthusiasm disappeared.

Some Play Quests have a requirement like:

Play this game for 15 minutes.

That doesn't sound unreasonable.

If you're already a gamer with the game installed, it's basically nothing.

But I am not sitting here with a gaming PC and unlimited storage.

My laptop was never really designed for gaming.

I tried a couple of these quests and immediately discovered the actual cost wasn't necessarily the 15 minutes.

It was everything before the 15 minutes.

Download the launcher.

Download the game.

Wait.

Use storage.

Heat up the laptop.

And eventually...

15 minutes.

That felt ridiculous to me.

Some modern games are enormous. A game can take up tens or even 100+ GB of storage.

I couldn't mentally justify downloading that much data just to satisfy a short promotional requirement.

And the funniest part?

Sometimes I wasn't even interested in the game.

Then I noticed something weird

I eventually discovered something that made me stop and think.

For the Quest I was trying, it appeared that the important thing was that the game was running.

Not necessarily that I was sitting there actively playing it.

One of the examples that made this particularly obvious to me was Roblox.

The Quest could specify a particular experience inside Roblox.

I wasn't actually interested in playing it.

I launched Roblox, left it running, and waited.

Eventually, the Quest registered the required activity.

And I remember thinking:

Wait. What exactly is Discord checking?

That's the question that started the entire project.

I asked AI what was happening

I did what I usually do when I encounter something I don't understand.

I asked AI.

The explanation was basically that desktop applications can observe running processes and identify applications based on information exposed by those processes.

That sounded obvious once explained.

But it changed how I looked at the entire thing.

Discord doesn't have to know that I'm physically sitting in front of the game.

Software can't look through my screen and magically determine whether I'm having fun.

It can observe signals.

A process exists.

An application is running.

Certain information is available.

A timer progresses.

Then a system can use those signals to determine whether a requirement has been satisfied.

And suddenly, this wasn't really about Discord anymore.

It was about verification.

So naturally, I went down the GitHub rabbit hole

I started searching GitHub for projects related to Discord's game detection and Quest behavior.

And there were quite a few.

Some were old.

Some were archived.

Some relied on behavior that had already changed.

Some attempted to manipulate things directly through Discord's web client.

That last category was particularly interesting because it showed me something about building software against platforms you don't control:

your code is only as stable as the assumptions you're making about someone else's system.

Discord changes.

Its client changes.

Its detection changes.

Its security changes.

Something that worked a few months ago can suddenly become useless.

And that's exactly what I was seeing with some of those older projects.

Then I discovered spoofing

Eventually, I decided I didn't want to copy some old script.

I wanted to understand the problem myself.

And that's where I ended up building DisPlay.

There was just one funny problem.

I didn't know what I had built.

I was working on the project, asking AI for help with documentation, and it used the word:

spoofer

I had seen the word before in other contexts, but I had never really understood what it meant here.

So I looked it up.

And suddenly everything clicked.

What is a spoofer?

In simple terms, spoofing means making something appear to be something else to another system.

That's the broad concept.

Imagine a security system looking at a badge.

It doesn't necessarily know who you are as a human being.

It sees information presented by the badge and decides what that information means.

Software can work similarly.

A program can make certain information appear differently to another program.

That's the general idea behind spoofing.

In the case of DisPlay, the interesting part was process identity.

Instead of dealing with an enormous game installation, I explored whether a lightweight local process could present the kind of information that Discord's game-detection mechanism looks for.

┌─────────────┐
│ Select Game │
└──────┬──────┘
       ↓
┌─────────────────┐
│ Find Executable │
└──────┬──────────┘
       ↓
┌─────────────────┐
│ Create Process  │
└──────┬──────────┘
       ↓
┌──────────────┐
│ Discord sees │
│ game process │
└──────────────┘

And that's what made the project so interesting to me.

I had basically built something and then discovered the technical vocabulary for it afterward.

That's one of my favorite things about programming

Sometimes learning happens backwards.

You don't always go:

Learn concept → build project → understand result.

Sometimes it's:

Have problem → experiment → accidentally build something → ask what it is → discover concept → understand what you built.

That's exactly what happened here.

I didn't start with:

"Today I'm going to learn process spoofing."

I started with:

"Why am I downloading this giant game?"

And ended up learning about process detection.

That's why I like building random little projects.

You never really know what you're going to learn.

But there's a very important line here

At this point, someone could look at DisPlay and immediately say:

"Isn't this just cheating?"

That's a fair question.

And I don't think the answer should be:

"No, because I wrote it."

That's not how ethics works.

There's a difference between:

Can I technically do this?

and:

Should I do this?

And there's another difference between:

Is this technically possible?

and:

Does the platform allow it?

A piece of software doesn't become permitted simply because it doesn't damage someone's computer.

Platform Terms of Service can prohibit behavior even when there isn't some dramatic real-world harm.

So I don't want to describe DisPlay as some magical "legal Discord hack."

That's not a claim I'm qualified to make.

The safer way to describe it is what it actually was for me:

an experiment into how application/process detection works.

And anyone using software against a platform should understand that technical possibility and platform permission are separate questions.

I wasn't interested in stealing anything

This distinction matters to me.

I wasn't trying to steal somebody's account.

I wasn't trying to access another person's computer.

I wasn't trying to damage Discord.

I wasn't trying to break into anything.

I had a frustrating user experience and wanted to understand the technology behind it.

That doesn't automatically make every possible use of the resulting software acceptable.

But it does explain my motivation.

There's a difference between exploring how a system works and trying to harm people through it.

And honestly, that's something I think developers need to become much better at understanding.

The real problem is the verification model

The more I thought about it, the less interested I became in whether my project worked.

I became more interested in whether Discord's original verification method was actually measuring the right thing.

Suppose Discord says:

Play this game for 15 minutes.

What does Discord actually need to know?

Does it need to know:

"Was the executable running for 15 minutes?"

Or:

"Did the user meaningfully interact with the game for 15 minutes?"

Those are completely different questions.

A running process proves that a process is running.

It doesn't necessarily prove that someone is playing.

And that isn't unique to Discord.

It's a general software problem.

A website can know that you opened a page.

That doesn't prove you read it.

An online course can know that you opened a lesson.

That doesn't prove you understood it.

A fitness app can detect movement.

That doesn't necessarily prove what kind of activity you performed.

The signal you're measuring isn't always the behavior you're actually interested in.

That's the part of this whole experience I found genuinely fascinating.

And Discord seems to know this too

Here's where my criticism of Discord becomes much less one-sided.

Because Discord has already started moving beyond the exact model I'm complaining about.

Discord's Cloud Play Quests allow supported games to be played through cloud streaming without downloading or installing the full game.

That directly addresses one of my biggest complaints.

No huge download.

No massive storage requirement.

No waiting for installation.

Discord has also recently announced Play Quest+, which moves beyond simply rewarding time spent and instead allows Quests to reward actual gameplay actions.

For example, Discord says Play Quest+ can use objectives such as completing a tutorial, finishing a match, or playing with a friend.

And that's exactly the direction I would prefer.

What if the Quest actually measured gameplay?

Imagine this.

Instead of:

Play Game X for 15 minutes.

You get:

Complete one match.

Or:

Finish the tutorial.

Or:

Play one round with a friend.

Now the Quest isn't simply measuring time.

It's measuring an actual interaction with the game.

And that's much more meaningful for the advertiser too.

If I'm a game developer, I don't really want people to open my game, leave it running in the background, and disappear.

I want them to experience the game.

That's the entire point of the advertisement.

And Discord's newer Play Quest+ approach is already heading in this direction.

There's another problem: not everyone has the hardware

This is something I think gets overlooked.

Discord is heavily associated with gaming.

But being on Discord doesn't mean you have a gaming PC.

You might have:

• an old laptop
• a school computer
• limited storage
• slow internet
• limited mobile data
• no dedicated graphics card
• no interest in installing enormous games

And that's okay.

You can still be a Discord user.

You can be a developer.

You can be part of a gaming community.

You can talk to your friends.

You can contribute to servers.

You can build bots.

You can create communities.

You don't necessarily need a machine capable of running a 100 GB game.

So when a reward is locked behind downloading a massive game, the barrier isn't really 15 minutes of gameplay.

It's hardware.

Bandwidth.

Storage.

Time.

I actually like Discord's business model here

This might sound contradictory after everything I've said.

I don't hate Quests.

I don't even hate the idea of advertising on Discord.

Discord needs to make money.

And not everyone wants to pay for Nitro.

Nitro is one way Discord monetizes its service, while Quests provide another route where advertisers fund rewarded experiences and users can earn things without directly paying for them. Discord's current Orbs system even lets users exchange Quest-earned rewards for things such as Nitro credits and shop items.

That's clever.

And honestly, I prefer this kind of advertising to a platform simply filling every possible piece of empty space with banners.

Discord knows its audience.

Its audience likes games.

Game companies want players.

Discord has the communities.

So they connect the two.

That's good product thinking.

My issue is with the friction in some implementations.

Advertising doesn't have to feel like advertising

That's what I think Discord got right.

YouTube can say:

Watch this ad.

Discord can say:

Try this game and get something cool.

The second one feels less annoying because I'm getting something back.

It's still advertising.

But it's advertising designed around an incentive.

Discord itself markets Quests to game companies specifically as a way to get people discovering and playing their games.

I understand why game companies want it.

I understand why Discord wants it.

And I understand why users want the rewards.

The only question is:

Can the system make that exchange better?

I think it can.

“What happens if Discord changes everything?”

Honestly?

That's expected.

DisPlay could stop working tomorrow.

Discord could change its detection.

Discord could change its Quest verification.

Discord could remove a particular behavior.

Discord could introduce a completely different system.

And that's okay.

In fact, I'd rather Discord improve the system.

A project like DisPlay isn't something I want to depend on forever.

The funny thing about reverse-engineering behavior is that you're building on assumptions that the original developer can change whenever they want.

If Discord improves its Quest verification, my project becomes less useful.

That's not really a loss.

It means the platform got better.

And I found the bigger lesson somewhere completely different

Around the same time I was thinking about all of this, I came across a line that was circulating among developers:

“Do not forget how to code. AI won't build illegal apps. You will.”

That sentence stuck with me.

Not because I think AI is incapable of generating harmful code.

It obviously isn't that simple.

What interested me was the responsibility behind it.

AI can generate code.

AI can explain code.

AI can help you understand unfamiliar concepts.

AI can make it dramatically easier for someone to build something they don't fully understand.

But the person using the software still has to decide what they're building it for.

And that distinction is becoming increasingly important.

Knowing how to build something doesn't tell you whether you should

This is probably one of the biggest things I've learned from building random projects.

You can make something technically impressive and still make a terrible decision.

You can write perfect code for a terrible purpose.

You can use AI to produce thousands of lines of code and still not understand what you've created.

And you can also build something questionable-looking for a completely different reason:

curiosity.

The responsibility doesn't disappear just because you're experimenting.

That's why I don't think developers should stop learning about how systems work.

Quite the opposite.

Learn how they work.

Understand their weaknesses.

Understand their assumptions.

Understand the rules around them.

And then make a decision about what you're going to do with that knowledge.

The internet is full of people making those decisions

I've also been seeing more conversations recently about teenagers being approached online for shady technical work.

One example circulating on LinkedIn involved a teenager being approached through Telegram about building a malicious remote-access tool.

I won't get into instructions or technical details of malware here.

What matters to me is the decision that came afterward:

he declined.

That's the part I find more interesting than the malware itself.

Because being technically capable isn't just about being able to say:

"I can build that."

Sometimes it's being capable enough to say:

"I can build that. I'm still not going to."

That's a completely different kind of skill.

Maybe that's what being a developer actually means

When I was younger, I thought being good at programming mostly meant:

knowing more syntax.

Then it became:

building more projects.

Then:

understanding systems.

Now I'm starting to think there's another layer:

knowing what you should do with what you understand.

That's not something a programming language can teach you.

Python can't teach ethics.

JavaScript can't teach judgment.

AI can't automatically give you values.

Documentation can't tell you whether your motivation is good.

You have to figure some of that out yourself.

So what did DisPlay actually teach me?

Technically, I learned about:

• process detection
• application identity
• spoofing
• Discord's game-presence ecosystem
• how fragile undocumented behavior can be
• how advertising systems use verification
• why a simple timer isn't necessarily a great measurement

But personally, I learned something else.

I started with:

"I want that Discord reward."

Then:

"Why do I have to download this?"

Then:

"What is Discord actually checking?"

Then:

"Can I understand how that works?"

Then:

"What's a spoofer?"

And finally:

"Maybe the system doesn't need to work this way at all."

That's a much more interesting journey than simply getting an avatar decoration.

I don't want Discord to remove Quests

If Discord somehow sees this (probably they won't, I'm not famous or anything, just another developer and Discord user lol):

Please don't take the wrong message from this.

I'm not against Quests.

I actually like the concept.

I'm not asking Discord to stop collaborating with game companies.

I'm not asking them to stop giving users rewards.

I'm not saying every Quest should disappear.

I just think the verification could become smarter.

If a game is enormous, give users a cloud option.

If a game supports meaningful gameplay events, verify those instead of just time.

If someone doesn't have the hardware, give them another type of Quest.

Maybe there could be browser-based games.

Community activities.

Creative challenges.

Developer quests.

Short demos.

Watch-and-learn quests.

There are so many possibilities.

The community is much bigger than the people who can download whatever game happens to be promoted that week.

And maybe that's the best outcome

This isn't even unique to Discord.

We've seen this cycle happen across software for years.

Someone discovers a behavior that wasn't necessarily intended to be a public feature. They build a tool around it. People start using the tool. Eventually, the platform notices the behavior and changes something on its side.

And suddenly the tool stops working.

Discover → build → platform notices → platform changes → tool breaks.

It's almost like an unofficial API: it might work perfectly today, but the owner of the system can change the rules whenever they want.

That's also what makes projects like DisPlay interesting to me. I'm not building on some permanent contract with Discord. I'm building around an observed behavior. If Discord changes that behavior tomorrow, the project might simply stop working.

And honestly, that's fine.

If the change makes the Quest system more accurate, accessible, or secure, I'd rather see that happen than keep fighting the platform forever.

I don't want DisPlay to become a never-ending battle between my code and Discord's code.

If Discord improves its Quest system tomorrow, that's actually a good thing—in fact, that's the thing I actually want.

If they make it possible to try games without huge downloads, great.

If they verify meaningful gameplay instead of a process simply existing, even better.

If they create more accessible Quest types, I'll probably use them.

Because the goal was never:

"Beat Discord."

The goal was:

"Understand why this works the way it does."

And that's what happened.

I built something before I knew what it was called

That's probably my favorite part of this whole story.

I didn't set out to learn about spoofers.

I didn't have a roadmap saying:

Day 1 — Learn process spoofing.

I had a laptop heating up because I didn't want to download a massive game for a 15-minute promotional task.

So I got curious.

I searched.

I experimented.

I built.

Then I learned the terminology.

And somewhere between the code, the Discord Quest, the GitHub rabbit hole, and all the questions about whether something is technically possible versus whether it should be done, I realized something:

Programming is often less about knowing the answer and more about being curious enough to ask a better question.

My original question was:

"How do I complete this Quest?"

The better question turned out to be:

"What exactly is this system trying to prove?"

And that's the question I want to keep asking.

Because sometimes the most interesting project isn't the thing you build.

It's the thing you understand after building it.

DisPlay

DisPlay is an experimental project I built while exploring Discord's application/process detection behavior.

It isn't a statement that bypassing platform rules is acceptable, and technical possibility shouldn't be confused with permission under a platform's Terms of Service.

For me, the interesting part was the learning process — discovering what process spoofing meant, understanding how software can make decisions from observable signals, and questioning whether those signals actually represent the behavior we're trying to measure.

Quickstart Tutorial

If you want to clone and inspect the project locally:

# Clone the repository
git clone https://github.com/MKishoreDev/display.git

# Navigate into the project directory
cd display

# Install required dependencies
pip install -r requirements.txt

# Run DisPlay
python main.py

And honestly?

If Discord makes Quests better enough that I never need a project like this again...

I'll take that as a win.