Re: [Nel] RE: Nel miscellanea

[Tony Hoyt]

"Nel List" <address@hidden> wrote:
> > >because this isn't a perfect world, what keeps a user from just
> > recompiling
> > >the code with for instance wireframing enabled to give himself an
> > >unfair advantage over the other users. This is a real possibility
> > >with GPL. My
> 
> If the data goes over the wire to the user's machine, it is visible
> to an enterprising user (witness ShowEQ). Re-compiling the client
> doesn't change this in any real way (as long as all decisions are
> made on the server).

  Some possable results of allowing the client to be released to the
general public have been disccused before.  I believe someone here
published a link to a website discussing this very issue, focusing on
two key problems with open source clients.  And this is no matter what
format you end up following, includeing the complete "Only send client
location of things local to the player, and only the bare bones data as
well (Location, moveing, apperence, and health in % for the case of a
RPG style online game)

  1) Radars: These are specialy dangerous for Player vs Player combat.
since it can allow someone to know instantly 1) Who are your enemies
around you, 2) How much health they have, and depending on how clever
the hacker is 3) how strong the player is vs you.  The last bit of data
comes from the fact that some online games offer you some clue as the
level of the people around you, as well as monsters for your
information.  This kind of information can lead to unfair advantages. 
In Dark Age of Camelot, which is said to have taken the minimalist
apporach to sending data to players, even they have recently had
concernes about such "radar" 3rd party applications.   ShowEQ is all
about this, and exploits the fact that the game sends all monsters spawn
information to the client constantly.  Although not Player spawn
information unless local to the player.

 2) Auto-aimers: This doesn't sound like it could be a problem on say
MMORPG's but it can be if it means players can auto-target the weakest
player in a Player vs Player conflict and constantly attack them.
Auto-targeting is still a problem here, no matter where it came from.

   2a) Derived from this we get, Auto-Clickers or in other words,
applications that automaticly perform repedative actions or  a macro of
complex actins.  Perhaps, again in a RPG setting,  a healer could then
put all his healing action onto a long string of intelligent macros that
will watch some players health levels, and then auto-send a heal command
at say 40% loss.  That's a combination of auto-targeting and
auto-commands.  Reverse this for Combat mages,  Auto-targeting for spell
attacks.. You get the idea.

  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.

  Now that's enough examples at the moment.  As you can say, and as the
article said before (I wish I had the link) This problem is quite
serious even if the source is not released.  Packet sniffing and reverse
engineering will always result in the hackers discovering everything
they need to know to make there tools work.

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

  1) Re-arrange the order of data in the packets every build or whenever
you can.  This forces the hackers to re-sniff and learn all your packets
again each time you come out with a new version of the client.

  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
know a whole lot about encription but hopefully there's something that
can be done to perlong the chance that the hackers will be successfull. 
Please note that even this method is not invulnerable to de-compileing
the application.

  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
can get really fancy with this, and make the port the client connects to
the server for game data the result of a function based off of data sent
from the 'connection' port and user data.  That idea may only work with
tcp/ip though.

  There are a thousand tactics you can use.  But all of them are simply
slowing measure to prevent hacking.  Hackers are only successful nine
times out of ten because the client never changes for long periods of
time, and when it does change, changes only very minorly so.  This
makeing it easy for a  hacker with enough time on his hands, (Or on the
hands of a small team of them) to decode the packets, and then engineer
a soultion to decode the packets for there own use.  ShowEQ is the best
result of such a product (http://www.sourceforge.com/projects/seq)  The
most trouble they ever have, is when the packets change size slightly,
or the encription changes.   Other then that, it knows everything about
anything that goes on.

  Tony

> 
> 
> > We have unified the export / bulid process for all NeL 3d media.
> 
> What I've found lacking the most when looking through the NeL sources
> is simply documentation on how to build and use it; especially under
> Windows. There's all kinds of miscellaneous DSW files scattered over
> the source tree, and nowhere does it say which ones should be built,
> in what order, or what the other requisite tools/libraries needed are.
> 
> 
> > Yes, the scripts was missing ! Sorry for this. It should be ok now.
> 
> Does this mean you don't have an automated daily build? Having a
> machine that checks out a clean source into an empty directory, and
> turns the crank to build the real product, is a must-have for any
> engineering organization. You may find that if your build is too
> complicated to get that going, effort you put into fixing that may
> improve the issue above, too.
> 
> 
> 
> _______________________________________________
> Nel mailing list
> address@hidden
> http://www.nevrax.org/mailman/listinfo.cgi/nel