Plugin blacklists / whitelists

[KillerJohn]

Hi all!

Due to the increasing number of HUD hacks used for automation, I decided to add plugin blacklists or whitelists in the next release.
Also Dashboard will be re-enabled AND the version-check through Dashboard will be mandatory. Sorry for everybody in "blocked" countries, thank this for the hackers, not me (eg: ZyHelper, etc)
HUD will send all plugins to the Dashboard for validation.

PROs and CONs for black/whitelists:

blacklist
PRO: plugin developers can develop without the necessity of plugin-validation
CON: fuckers will abuse this by changing 1 byte randomly in the .cs files to avoid hash-based blacklisting. Proposed solution: the pure IL expression tree should be the base of the checksum but this is a huge work.

whitelist
PRO: easy for me. Check the arrived plugins once a week and enable the clean ones. Can not be abused by idiots.
CON: slow process, plugin development/test will be almost impossible from now. Proposed solution: a few battle tags for the most active plugin developers can be whitelisted so they can freely use any kinds of plugins.

Another proposed solution is a combination of the two:
- on low game difficulties blacklisting will apply only
- on high game difficulties whitelisting will be enforced

I am waiting for feedback, thank you!

[ToxicPhenom]

Not a fan of either.

It will (like most other things) hurt the normal users. Hackers gonna hack anyway (maybe get a positive checksum and inject it instead of a non certified ?).
Like you said Blacklisting will be a PITA for you to make right.
Whitelisting sucks because only curated users will be able to develop new plugins and every change has to be certified by you.
I personally write my own and do not distribute them so i couldn't use them any longer (yeah develop on low difficulty but can't use in real situation unless i send it to you to certify it and get whitelisted even though i do not intend to share them)

In the end it's your decision and peoples opinion will only make a small difference if any.

[FoxPox]

blacklists / whitelists

This shit wasn’t invented by hackers

[RNN]

The Whitelist would make learning difficult and limit personalization:
Initially, before trying to create your own complete plugins, you start by experimenting, modifying small code snippets of known plugins or those included by default
People with more programming knowledge will always want to customize existing plugins to suit their preferences or needs. For them, Turbohud would lose a lot of extra value
The blacklist will try to skip it continuously and it would be convenient to apply persuasion measures, for example, block users (battletag) / pcs (hardwareid) or mark systems that repeatedly try to avoid it. Maybe there is a privacy problem?
The decision is complicated

[s4000]

wondering if the blacklist will make Hud ever slower?
for the whitelist, I think you will have to check thousands of plugin as people make small modification for each plugin.

[Feel_Good]

it's nice to see how cheat program developers are fighting each other.... maybe you should just settle the dispute and work together?! What is the point here i dont get it?! Thud is also against Blizzard terms and Zyhelper/Thud or what ever just makes life easier for those who still play the game.

[JackCeparou]

Blacklist : almost not doable, even with the IL tree approach it's just a matter of reorganizing code flow.
Whitelist : well, heavy work, kill hotfixes and user feedback on quick iterations, kill the newbie way of modifying existing plugins trying to understand how it works, i don't see any PRO for this..

And what about customization, all whitelisted ?

A mix of the two depending on the difficulty, well, to be honest : too much work for what it worth.

That's a cat and mouse game, it's just annoying to (not) be the mouse

My 2c.

[emilo0212]

I don't care what you choose, got a work-around for both of them, so my helper is safe

Just thought I'd let you know that whatever you do, nothing is gonna help

[MrOne]

Like someone say "Hackers gonna hack anyway" and in this case im against this because i almost every time need to customize every plugin (change color, font, size, position etc).
My question is, KJ do you have some new information about someone who make automatization using TH or you just overreacting?

[thewhatguy]

Theres a public discord which offers a helper for this season. KJ is on that discord.
At first, i don't think whitelisting is the way to go, plugins without modification doesn't work for most people.

Also theres no way to learn how to code plugins if you cant even test...

greetings
patrick

[KillerJohn]

The other option is to introduce memory randomization which would have a big impact of HUD's performance.
For that I have to
- re-allocate most parts of the collector (which holds the current state of the game)
- forbid get-only properties in plugin classes

At this point a "randomization" cycle must be applied at every few seconds:
- save the values of properties of all plugins
- unload plugins and re-create them
- use reflection to set the values of plugin properties automatically back to the original value (if it is a resource like font), or if it is a pointer then replaced by the current value

[KillerJohn]

The Whitelist would make learning difficult and limit personalization:
Initially, before trying to create your own complete plugins, you start by experimenting, modifying small code snippets of known plugins or those included by default
People with more programming knowledge will always want to customize existing plugins to suit their preferences or needs. For them, Turbohud would lose a lot of extra value
The blacklist will try to skip it continuously and it would be convenient to apply persuasion measures, for example, block users (battletag) / pcs (hardwareid) or mark systems that repeatedly try to avoid it. Maybe there is a privacy problem?
The decision is complicated

this gave me a good idea:
Just add blacklisting, however not for plugins, but battle tags.
So if I check once a week the plugins sent by TurboHUD to Dashboard then I flag the malicious plugins and all users who used those plugins will be blocked from using HUD for a period of time (let's say 5 days).

This is very easly to implement and fair with everybody.
What do you think?

[thewhatguy]

this gave me a good idea:
Just add blacklisting, however not for plugins, but battle tags.
So if I check once a week the plugins sent by TurboHUD to Dashboard then I flag the malicious plugins and all users who used those plugins will be blocked from using HUD for a period of time (let's say 5 days).

This is very easly to implement and fair with everybody.
What do you think?

Not sure, but getting there.
If the casual enduser who has no clue suddenly finds a plugin he likes, but doesnt know its blacklisted, will be blocked for 5 days.
Why not do this method without 5 days cooldown?

[KillerJohn]

Not sure, but getting there.
If the casual enduser who has no clue suddenly finds a plugin he likes, but doesnt know its blacklisted, will be blocked for 5 days.
Why not do this method without 5 days cooldown?

Automation plugins are forbidden, that is clear for everybody. Also I can highlight that on the download page too.
I won't handle reclamations, that's sure. Also it is the automation plugin's owner's responsibility to warn the people about it is malicious and forbidden.

[thewhatguy]

Automation plugins are forbidden, that is clear for everybody. Also I can highlight that on the download page too.
I won't handle reclamations, that's sure. Also it is the automation plugin's owner's responsibility to warn the people about it is malicious and forbidden.

Okay i see that.
Then maybe publish a list of illegal namespaces, I think some people would use like System.IO without malicious intent, like some plugins did for writing own stats.