It's well known that botting is one of the most great thread for MMORPG games. Since it's releatively easy to detect clint injection, I wonder how can MMORPG detect botting from server side. Thanks for any help.
By reading some papers, I figure this question by myself.
Here are two kind of major bot detection methods: detected by Sufficient Condition and detected by Necessary Condition.
For Sufficient Condition, it's always useful to detect behavioral action or social action.
For Necessary Condition, it's usually useful to detect Transaction Network Analysis.
Related
Suppose I make a class diagram for a social network system such as facebook. Should the notifications and discussion messages have their own classes?
I do really think they should. I made a full class diagram for such a system, with notifications and messages as classes, but my teacher told me to exclude them. Now I am confused.
This is a very interesting question for three reasons.
1. What’s the scope?
This is a core question for any work that you’ll do in your developer career: what’s the scope of the system?
is it just core social networking functionality of one to many communication, like you had on Facebook in its early days?
or is it a full clone of facebook, including its messaging features, but also its advertising and moderating features?
If it’s the first, you’ve done too much. If it’s the second, you forgot important parts.
Rule 1: Whenever there is a doubt about the scope, clarify it with your coach/manager/stakeholder before thinking you know what there is to do.
This will avoid you the frustration of doing work that is not valued. It will avoid your future customers the frustration of not getting what they’ve expected, or paying too much for something they didn’t ask for.
2. What’s the approach?
Whenever you model some software, there’s a purpose. Class diagrams can be used for different purposes. For example:
is it for analyzing the requirements? In this domain, you will certainly have a class for Post, Comment and UserAccounts as well as associations between them. But you’d limit yourself to the “problem space” and not address the software solution and its UI.
is for the design of the system? then it probably should address how the system will work, and give some more details about how the UI will interact with the domain object. This kind of diagram might be more detailed and show the “solution space”.
Rule 2: if asked to do some modeling, always clarify the purpose. In the real world, if not asked explicitly to model, clarify the agreed approach within your team.
3. Always clarify with the person the closest to the source
(the subtitle is already the rule).
Now, is the notification a part of the UI, because they shows posts that changed and it’s part of the solution design? Or is it part of the domain, because the need for notification is independently of the chosen software solution? And because moreover notifications need to be tracked and delivered, and the they will work differently on mobile apps (push) and on web pages (pull)? As you see there is some room for interpretation, and depending on his/her arguments, the teacher is not necessarily wrong.
Conclusion
As you see, it’s not right or wrong: there are a lot of nuances between the two. There are plenty of reasons that could justify your teacher’s position. I see at least two other unrelated ones:
to adapt the time of the exercise to the average capability of your class (which would be a good sign for you)
because the teacher already know the next questions and he/she already know that notifications will make it much more difficult (which would show that the teacher was nice).
My advice: trust your teacher, and in any case engage a discussion to understand the arguments, before jumping to quickly on unproven conclusions.
Key takeaway: requirement analysis and modelling are a communication activity more than a technical activity. Whenever there’s a doubt, engage discussion with your stakeholders before seeking advice from strangers on the net ;-)
How can a server, i.e. a remote host acting as a central service for multiple clients, detect malicious or invalid clients akin to Blizzard's Warden. In some way, these kinds of software ask a client for specific information every once in a while, which cannot be easily faked from a non-official client.
What I'm wondering is, how can such a mechanism be implemented so that it's hard or impossible to reverse engineer from the client side? Is there any such technique for open source client software (closed source server)?
Short answer: You can't. The client is fundamentally untrustable. Blizzard (and other purveyors of anti-cheat software) are engaged in a constant arms race with the cheaters. You can't just implement it once and be done with it; you have to constantly monitor your product (either heuristically or via player reports) for cheating, then figure out how to programmatically evaluate if someone is cheating.
The longer answer is that you keep your "secret sauce" detection off the client; the client instead just collects information, which it forwards to a trusted machine for analysis. This can make it harder for cheaters to avoid detection, since they only know what information is being collected, not what is being done with it. Eventually though, they'll figure out how to spoof that information, and your anti-cheat mechanism will need to then deal with that problem.
What you can do is implement heuristics in your server code to detect players who are sending inputs that should not otherwise be possible, and then flag those accounts for review or ban. This does nothing detect malicious software on a client, but it can detect the effects of that malicious software. So while you may not be able to pinpoint what is sending those invalid inputs, you can still act no the account.
More specifically to your question, though, it's impossible to give you examples, because you have to define what constitutes "cheating" in the context of your application, and then device methods for detecting it. This is a very domain-specific problem, and to make it more complex, you're unlikely to find open-source implementations of such systems, because they necessarily rely on obscurity to detect cheaters.
I'm implementing a game app based on cocos2d-x. In order to technically prevent cheating, one of the ideas to do is using HTTPS for all the client-server communication, which make it difficult to get the data format / game logic and send modified request to cheat. (I know "prevent" is actually impossible but for increasing the cost of making game cheating it's ok : ). My question is,
In Cocos2d-x, how to make HTTPS request? Possible?
In a more general case, technically what to do to reduce such game hacking? What strategy to hold?
For native cross platform C++ networking you may consider using Boost C++ libraries. Boost.Asio is the one used for networking.
Boost.Asio link:
http://www.boost.org/doc/libs/1_53_0/doc/html/boost_asio.html
Boost.Asio tutorials link: http://www.boost.org/doc/libs/1_53_0/doc/html/boost_asio/tutorial.html
Although not officially supported (only due to lack of regression testing on iOS and Android), Boost runs without any problems on iOS and Android (and probably other C++ based mobile platforms as well).
To prevent cheating you usually rely on an external source (which can be your game server) e.g. if your game relies on the time of day you may get the time form an external server. You may use encryption libraries for data transfer on the client and server side.
by using curl library you can make https connection.
if you want technically protect your game use you own strong encryption technique.
Thanks
Hi this is a problem we face all the time. If the cheating is limited to the cheater's instance the questions is academical and should be studied on your spare time.
On the other hand when your income is impacted or when the cheater's actions impact other players and degrade the game experience you should put some effort on testing the game state for inconsistencies, secure the client/server transactions and deal with cheating in very subtle ways to avoid completely deterring the cheaters' interest.
C++ https implementations are available with curl and boost.
Concerning the game data, the simplest way to test for inconsistencies are scores. You can add a few indicators to avoid polluting your leaderboards. You can add special checksums based on the score's components (time spent in game, number of power ups and score multipliers received...) if you can recalculate the score on the server and if inconsistencies are discovered you can deal with it.
Also you can grab instants of the game state and a few commands, encode that and replay the sequences on the server to check for inconsistencies. Deal with cheaters however you like.
When playing on a server let the server manage the gamestate and allow no client side game state changes that would impact players. Check for input consistency etc...
When using micro transactions each micro transaction should be verified with the vendors servers before being fully committed to the player's account.
Even if these papers 1, 2 from valve refer to fps games they should give you some pointers as to how to deal with state inconsistencies (introduced by communication delays). It should help in avoiding fake positives and ruining the experience for non cheaters.
The API provides the emit/send callback mechanism to acknowledge received messages. However, this callback doesn't get fired in case of disconnect or error. It appears to me that upon a disconnection one would need to go through some rather messy procedures to clean up outstanding sent messages (e.g. - assume a use case where you may want to store messages for forwarding later, etc.). Any simple ideas out here on how to accomplish this? Wondering if I'm missing something.... Thanks.
The Real Underlying Issue
This issue isn't just limited to socket.io. It is a well known problem called the Two Generals' Problem.
Two armies, each led by a general, are preparing to attack a fortified city. The armies are encamped near the city, each on its own hill. A valley separates the two hills, and the only way for the two generals to communicate is by sending messengers through the valley. Unfortunately, the valley is occupied by the city's defenders and there's a chance that any given messenger sent through the valley will be captured (this scenario assumes that while the two generals have agreed that they will attack, they haven't agreed upon a time for attack before taking up their positions on their respective hills).
You are trying to reach Common Knowledge over an unreliable link.
At any stage of the communication over socket.io the link can be broken, and a callback can be sent but the other side could not be sure that it arrived.
What Can Be Done
You need to embrace the fact this is always a possibility. There is no trivial solution for this. This problem and its generalization are still actively studied in fields like Multi-Agent Systems research.
What can still be done in your specific case
There are some common approaches to mitigate this issue.
What I did when designing an application using socket.io is attach IDs to messages, if a disconnect happens and one side tried to send an already-sent message, the receiving side will be aware that the message was already received.
Note that in practice you don't need to do this everywhere.
More Reading on the Issue
Related question here in SO
The Byzantine Generals Problem by Microsoft Research (LESLIE LAMPORT, ROBERT SHOSTAK, and MARSHALL PEASE) which discusses the problem and suggests some solutions
Acclaimed Book by Yoav Shoham that talks about Multiagent systems and how they address this issue.
Blog post about this problem in TCP.
I repeatedly find that establishing user requirements is one of the hardest parts of my job. This is for several reasons, for example, lack of shared technical vocabulary, incomplete understanding of domain on my part, inability of user to 'imagine' completed UI / product, etc etc.
Since this appears to be an ongoing challenge for me, has anyone here had a 'eureka' moment that has really helped them with this part of developing? For example, I have heard of the book 'Domain Driven Design', but not read it yet. Has anyone found a book, online resource of piece of advice that has really turned things around for them?
I won't aspire for eureka experience, however, if you are interested in DDD, which is about establishing common language for you and the users (among other things), than if you don't have access to the book, look for the Domain-Driven Design Quickly on DZone.
Generally speaking, any time user cannot imagine the thing and therefore state proper requirements, go for the prototyping (if you can). Recently I was pleased by really super simple tool which is a Firefox extension called Pencil, which enables easy and quite fast prototyping even for non-programmers. It is far from perfect, but it enables you to create own components and it is extensible.
Are you creating the user requirements on your own or are you actually interacting with the user to generate the requirements?
If you are creating a piece of software without a customer then starting with a simple high-level mock-up of what I want to create is where I will usually start and will formulate my User Requirements how I think a user would use the software.
If you have a customer I would suggest breaking the software into smaller modules (manageable chunks) and sitting down with the user to talk to them, step-by-step, how they want the module to function.