Verifying addon is unmodified
 

Question:
Is there a way to "authenticate" that another player is using the same unmodified version of an addon?

I'm currently in the early design stages of a new addon. This addon is a mini game that can be played between players. I'm entertaining the idea of having collectibles in this mini game, and those collectibles would be earned by completing achievements, like killing a specific boss, looting a certain item or the like (I don't play retail so the target is classic tbc, so no actual achievements).

Now, the problem I see with this is that one could easily cheat by modifying the addon or the saved variables. I can think of some steps to make it harder to cheat, but most of them are quite easily bypassable unless there is a way to make it possible for a player to verify that another player is using an unmodified version.

I'm aware that there is no built in way to do this, and I'm already sure the answer to my question is no. But if anyone of you whom are surely much smarter than me can think of some way to do it, I would love to hear your ideas.

There is really only 1 way and it's very unlikely you'll be able to accomplish it. That is by the means of obfuscation and I think the only company that was ever allowed to do so was PopCap with their Bejeweled and Peggle games.

Obfuscation doesn't really do anything to detect if the code was already tampered with. Some addons like KSK attempt to use CRC and hashes to secure communication, but in the long run, you're just wasting resources. The inclusion of such code is basically handing your users a way to fake your data anyway.

If you really care that much about anti-cheat, don't make it as a WoW addon. The source is by design, exposed for everyone to see whats going on and obfuscation is outright banned. Not to mention you don't have hardware access to do hash/CRC checks on your own files.

I don't suggest actually doing this... but here is a rudimentary peer-to-peer verification system you could build upon.

----

When Alice sends information to Bob signifying progress toward an achievement, she keeps a record of that info in her own saved variables.

When Bob later wants to tell Charles about his achievement, he hashes Alice's name (to protect Alice's privacy) and gives Charles the hash as a 'proof' of the achievement.

If Charles knows Alice, Charles will realize its her because he already has a hash of her name. He will ask Alice if Bob's claim was true. If Alice says yes, then Charles may carry on believing it. If Alice says no, then Charles will doubt Bob's claim.

This rudimentary system will fail if Alice resets her saved variables. Thus, consider two additional safeguards:

• Achievements should be "over-earnable" meaning you continue making "progress" even after you earn them; this gives Bob additional opportunities to prove his trustworthiness in future interactions
• Instead of everyone hashing Alice's name, Alice could hash her own identify including something pseudo-random like GetTime(). This becomes her identify that she gives everyone; if her saved variables ever wipe, she essentially takes on a new identity (think's she's new again) and does another self-hash with a different GetTime()

Using a 3rd party to process data unrelated to them is borderline malware. Something that'll get you banned by your host.

If you are referring to the rudimentary system I described, it is predicated on Alice, Bob and Charles knowing each other and participating in a mutual activity; and their transactions being essential to that activity.

This would be no different than, say, a decentralized guild bank add-on.


If A, B and C don't know each other or are pestering each other with workloads unrelated to their mutual transactions, then of course that would be grossly inappropriate.