Subject: [Nel] RE: Nel digest, Vol 1 #214 - 9 msgs

From: "Jon Watte" <[email-masked]>
Date: Fri, 4 Jan 2002 10:52:01 -0800

>   2b) The final and worse form of this, Bots.  Auto-hunters that can run
> around, and hunt for players hour after hour without the player actually
> being there or only occasionaly monitoring.  Quite unfair from my stand
> point.

If this is a real problem, you should ask yourself what your game 
offers a real human being to actually enjoy. If the game is reducible 
to a simple series of scripted actions (or even a complex series of 
scripted actions) then it'll become monotonic for a human sooner rather 
than later. Witness EQ: if you didn't have the human communication 
element, it would SUCK as a game.

>   Possable solutions. These just came to me.  These will only work in a
> closed source solution.

Security through obscurity doesn't work.

>   1) Re-arrange the order of data in the packets every build or whenever

This leads to much more testing for you, and only deters hackers a short 
while when you update the version. It doesn't work over time. (Verant does 
it for EQ -- ShowEQ still lives)

>   2) Update/change your encription: Again, they will discover what you
> are using, and just changeing one of the keys won't be enough.  I don't

This leads to much more testing for you, and only deters hackers a short 
while when you update the version. It doesn't work over time. (Verant does 
it for EQ -- ShowEQ still lives)

>   3) Change the ports you use for communication: Again a delaying tactic
> at best.  It's not a great solution but, it's better then nothing.   You

This is not even a delaying tactic. Any packet sniffer will show you 
what the new port is, and changing that constant in the radar app is 
going to be a simple re-compile. If you do it a lot, and I was writing 
a radar app, I'd just have the radar app sniff the network and look at 
all UDP packets, and figure out what the port is automatically. It's 
so weak as to be fully ineffective.

Proper design and tight server-side control is the only way to avoid 
hacking users to have an advantage over non-hacking users.

-- Jon

PS: To the others replying on the list: PLEASE don't quote the ENTIRE 
messages. It's quite annoying in digest mode.

---

From: Tony Hoyt <[email-masked]>
Date: Fri, 4 Jan 2002 14:21:46 -0500

"Jon Watte" <[email-masked]> wrote:

> scripted actions) then it'll become monotonic for a human sooner
> rather than later. Witness EQ: if you didn't have the human
> communication element, it would SUCK as a game.

  This problem is evident in all games, From Quake to Dark Age of
Camelot.  I spoke to a man who claimed to have develop a dual bot
application, where computers, playing a game with two accounts, had the
two characters work in sync to automaticly fight in a small area over..
and over.. and over.  He took the work out and just recieved all the
reward.  Now if you believe this claim, and I can't say honestly I have
any real evidence that his claim is true, I would be seriously concerned
about this kind of player.   True, it took a lot of work to make the
bot, but once done, this guy, can leave the bot alone to successfully
advance his characters without much intervention.  That's just plain
unfair in my book.  Little work for a great deal of reward. 

> Security through obscurity doesn't work.

  The the examples I gave where really just simple ideas to just like
you said, Slow them down a little.  To make this soulution work would
require you to constantly make these changes on at least a weekly
basises.  In other words, constantly updateding the packets, the
encription, etc.  And a lot of this could be done without much testing
between builds at all.  This would then make the whole process much more
annoying to reverse engineer.  I'm not saying that you should trust the
client more even after these tacktics, it's just you as the developer
should at least feel a little better that these simple tactics will at
least give them constant headaches.  But there's almost nothing you can
do to stop them.

> hacking users to have an advantage over non-hacking users.

  This is true, and this was implyed(sp) from the begining.  I'm just
trying to offer ways to help deter hackers,  But when you got 100
people, many of them working together out to cheat and create these
applications then your going to face an uphill battle no matter what. 
You must address it strongly with clear design that can address the
issue without much impact to development and testing, or embrace it in
some fashion.  Then again you could just make it not worth it at all and
have a non-game chat world.  Then there's no point in doing anything but
just have fun. :-)

> messages. It's quite annoying in digest mode.

  That was an honest mistake, I ment to remove the text from the end in
my last post, sorry.

  Tony