Sign in to follow this  
graveyard filla

how do people cheat / hack ??

Recommended Posts

hi, im working on a small scale online RPG. anyway, i probably should have asked this sooner, but i guess its never too late. when writing the network layer to the game, i want to keep security in mind. but i dont understand how people cheat in the first place. how is it done exaclty? my theory is this, a person will use a program such as ethereal, or some other packet sniffer, to find out what packets the game is recieving / sending. the person then takes guesses at what that data is for, and then tries to intercept and change it. that is, they write a program which listens on the port that your game does, waits for a packet to arrive, changes the data, then sends it to their client. is this how its done? what are some ways to prevent this? my guess is to just have the server verify as many things as possible. that is, have the server check to make sure the player isnt in any walls, make sure he doesnt have 100000000000 gold, etc. but im just not sure. another question, i have played MMORPG where there was duping bugs, and other problems with people exploting the game to make (in game) money. i dont understand how this is possible. for example, couldnt the client check and see if the player suddenly had 1000000000 gold? if the amount of gold was suspicious, the client could send a flag to the server, and then a game master or someone else could watch that person and see if they are doing any exploits. however, i know that in Ultima Online there was a dupe bug that went on and was exploited for possibly years, un detected. why couldnt they set up a system that sent out red flags when they noticed that huge amounts of gold were suddenly in the games database? thanks for any help.

Share this post


Link to post
Share on other sites
Saruman    4339
Your client should just be a dummy terminal, that renders and accepts input (a few other minor things such as predictions, etc). The server should control EVERYTHING and the client should just render it.

Other problems such as radars, etc are inevitable and will happen in any online game, although there are many ways to minimize this from happening.

Share this post


Link to post
Share on other sites
acraig    471
There are a couple of areas where cheating is possible.
1) Information cheats
If you are in multiplayer game you obviously need to send information to players about other players. A client could look at this data and use it to figure out the exact location of players, items. I think this was a cheat that was available for Everquest. It would send information about *alll items* to a client in a sector. This could then be used in something like aim bots or 'treasure finders'.

One way ( which we use in our project ) to solve this is to limit the things that are sent to player. So they are only sent information about things they are close to. So for example, a magic ring may have a '10 metre' radius. So you'd have to be that close to it before the server will even send information about it to the client. This, of course, does not solve all problems but helps.

Second information cheat types can be stuff like lighting. For our game, maps are stored client side. A smart client could figure out a way to turn of lighting effects therefore make spells like blindness useless. To solve this we can come up with better spells with effects that the client cannot get around.

2) Calculation cheats.
This is where the client tries to 'fool' the server into doing something the client should not be able to. For example, changing stack counts on items or sending a 'hit target for 5 damage' when it should really be one.

You are already along the correct track for this. You have to have the server validate this. In our project we have a seperate process that monitors data like this. So it can do random checks or GM's will be able to flag a player for closer monitoring.

Some other ways to cheat are finding possible ways of crashing the server. This often results in some things being in bad states where data that was cached did not get a chance to be written out. This is how I can imagine one way item dupes could occur.

Another way to track things ( after the fact though ) is through data mining. This is where you take a look at all the data in your database and try to spot trends. If you see some guy gain 100k of experience in one day he is most likely cheating.

----------
Andrew

Share this post


Link to post
Share on other sites
hplus0603    11356
Many cheats just attach to the local client, and patches its data in memory to do things the client wouldn't normally let you do. This may be things such as turn off wall checks, or let you press certain buttons more times than one. Once the client is tricked into performing this action, it will send a packet to the server, requesting some action.

To prevent cheating, you have to do two things:
1) Verify all commands and input data from the client; verify against previous game state, and make sure the state update or command follows the game rules.
2) Don't send data to the client that you don't want the client to be able to show to the user. I e, keep a game rules filter on the server side, which decides what you want to show.

Share this post


Link to post
Share on other sites
Toolmaker    967
MapleStory V0.07 is currently using a way to prevent other processes from writing to it's memory. I have no idea how this is done(And interested in it), but the game seems to quit when another process writes to memory.

Before everyone starts monkeying around and rate me down for hacking, I'm not working on a cheat for Maple, nor will I. I haven't tried it. This information came from a certain person who was trying to bypass the ridiculous language filter(Saying "That it ...." will result in cursing, because you said t it = tit.)

This is also something you sohuld look for. Processes that are attached your client or trying to write to it's memory. I think there's a way to enumarate all attached processes.

Toolmaker

Share this post


Link to post
Share on other sites
furthermore    100
Quote:
Original post by Toolmaker
MapleStory V0.07 is currently using a way to prevent other processes from writing to it's memory. I have no idea how this is done(And interested in it), but the game seems to quit when another process writes to memory.

Before everyone starts monkeying around and rate me down for hacking, I'm not working on a cheat for Maple, nor will I. I haven't tried it. This information came from a certain person who was trying to bypass the ridiculous language filter(Saying "That it ...." will result in cursing, because you said t it = tit.)

This is also something you sohuld look for. Processes that are attached your client or trying to write to it's memory. I think there's a way to enumarate all attached processes.

Toolmaker
]

There is a way to enumerate through all attached processes, but what would you look for exactly? I think that AIM automatically attaches a dll that helps in their check to see if you're idle or not.

Share this post


Link to post
Share on other sites
TeamWhore    160
The 'simplest' way to prevent the main kind of cheating people are bringing up here is to make it so the server "doubts" everything the client sends it, as everyone is saying. Basically the server only sends totally necessary info to the client (to minimize things like hacked-graphics-driver wallhacks in FPS games...in this case don't send *all* the level data, just what the client needs), and everything it gets back from the client it verifies for reality. For example, you should never update a client's position solely based on what the client reports to the server is its new position and/or velocity etc. Instead you have the server do all the same checks the client does locally for prediction - eg for collisions, and you also check to make sure that at current speed/heading/whatever the client could feasibly reach the spot he's claiming to be at.

It's not just server *verification* though, as you mentioned about things like the gold. Ideally, a large part of it is not even allowing the client to legally change his stats/gold/etc at all, even via requests. Since the server should know everything that's going on in the world (like when a client runs over an item or whatever), the client shouldn't be able to send this info. For things like when the client can choose whether or not to pick up an item, it should send a generic "pickup whatever I'm standing on" request with no specifics, and the server should then figure out what, if anything, the client can pick up.

A lot of the problems with duping and things are probably glitches in the server code, so that the system I'm describing was partially broken. A guess as to why they didn't setup red flags like you mentioned is because if that code worked, the red flags wouldn't be necessary. If you want redundancy you can setup a system like that, but it might get chaotic trying to keep track of *everything*.

A last note - if you want actual oversight like you mentioned, you might as well just have the clients (or the server) create snapshots of all the pertinent stats every so often, and then you can have an automated system parse them looking for anomolies. But a cheating client could theoretically fabricate the snapshots too (unless they're server-side only), and it might be hard to tell whether many things are cheating or not...

Modify all this to suit your needs...but there's virtually *always* some cheating, no matter what you do.

*EDIT* about the processes stuff - I suppose that's a good measure if it works, but it won't stop a determined hacker who knows what he's doing. You could hack the exe and rewrite the assembly/binary (this can even be done at runtime), and bypass/get rid of that security stuff... There are measures to help against that, but you can hack those too, and on and on. Basically there's always a way to do something to a local exe, and all it takes is one person figuring it out and releasing something that uses it...

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
Quote:
Original post by Toolmaker
... but the game seems to quit when another process writes to memory.
...
This is also something you sohuld look for. Processes that are attached your client or trying to write to it's memory. I think there's a way to enumarate all attached processes.

Toolmaker


Complete, total, and utter waste of time. This was proved pointless approximately 7 years ago when Diablo was hacked using ?softICE? and live memory debugging. If someone has the time/inclination/energy to try hacking like that, they'll sooner or later find softICE and friends.

Here's the hacker solution (you can pass on to your friend if you like)

1. Find the memory you want to change
2. Change it
3. Step through the program letting it "discover" the interference
4. Identify the code that did the discovery
5. Disable it.
6. Go back to 1-2, and this time you won't be stopped

...or variations on that, depending on how many checks the program does. In general, someone who writes self-protecting code doesn't really understand basic security theory and probably ought to get a different job doing something they're competent at instead.

There are things that are worth doing just to slow down the hackers, but for any successful game you just want to either protect it, or not - this half-arsed crap just increases development time (+cost) without making the game any more secure.

redmilamber

Share this post


Link to post
Share on other sites
furthermore    100
Often times in the game industry it is more important to simply try to slow down the piraters and cheaters than it is to actually try and stop them (which is nearly impossible).

Share this post


Link to post
Share on other sites
MaulingMonkey    1730
Quote:
Original post by furthermore
Often times in the game industry it is more important to simply try to slow down the piraters and cheaters than it is to actually try and stop them (which is nearly impossible).


With "traditional" store-front games, yes.

However, pirating can be overcome by having the game pay 2 play (with the internet being an integral component of the game) or otherwise not directly funded by the distribution of the software itself - (like most MMOs, although it will probably have to be a MMO in order to succeed)

And cheaters can be overcome by:

1) Not letting the client be authoritative in any manner (command/response style, for example - the player dosn't say "I mined 8 gold", only that "I want unit XYZ to mine the goldmine ABC", and then the server returning "Unit XYZ got to ___ ... you mined 8 gold" - and the player dosn't say "I start building a tower here", the player says "I WANT to start building a tower here", and then the server can either return "You start building a tower THERE" or "You don't have enough cash to build a tower there".

2) Not giving the client information it shouldn't have. In an RTS, if there's nobody by the enemy base, the server shouldn't send data about the enemy's buildings. The reason that map hacks work in Warcraft 3 is because each client allways knows everything about the game.

3) Making it prohibitively expensive to decrypt information it has been sent due to it possibly being relevant very soon - or to be even more diabloical, also send false positives in the encrypted information (these would be valid data that's bogus - they would never be legitimately decrypted (server never would provide keys) but could be viewed by a map hack (oh no!!! he allready has an army of tanks??!? I'm screwed!!!).

Share this post


Link to post
Share on other sites
Michalson    1657
Quote:
Original post by Anonymous Poster
Quote:
Original post by Toolmaker
... but the game seems to quit when another process writes to memory.
...
This is also something you sohuld look for. Processes that are attached your client or trying to write to it's memory. I think there's a way to enumarate all attached processes.

Toolmaker


Complete, total, and utter waste of time. This was proved pointless approximately 7 years ago when Diablo was hacked using ?softICE? and live memory debugging. If someone has the time/inclination/energy to try hacking like that, they'll sooner or later find softICE and friends.

Here's the hacker solution (you can pass on to your friend if you like)

1. Find the memory you want to change
2. Change it
3. Step through the program letting it "discover" the interference
4. Identify the code that did the discovery
5. Disable it.
6. Go back to 1-2, and this time you won't be stopped

...or variations on that, depending on how many checks the program does. In general, someone who writes self-protecting code doesn't really understand basic security theory and probably ought to get a different job doing something they're competent at instead.

There are things that are worth doing just to slow down the hackers, but for any successful game you just want to either protect it, or not - this half-arsed crap just increases development time (+cost) without making the game any more secure.

redmilamber


You just proved yourself deaf. As just stated, Maple has specific guards that allow it to shutdown immediately upon the detection of a debugger trying to attach itself (yes, there is currently one way around this, which requires windows 98 compatiblity mode and a special VxD, but it can be fixed). It has both general purpose detection (it can detect any generic unknown debugger attaching, and can detect memory changes [it is possible to read so long as not set remote write mode in virtualProtect], and is filled with a list of known debuggers and hacking tools that will cause it to shutdown before any of the above even happens [as with most anti-hacking code, softice is at the top of the list for software to detect]).

Your post makes it sound like you are an amateur who has probably never even seen SoftIce in action, and are simply refering some kind of mythical version of SoftIce that you've hear about. But then that may not be true, you simply make it sound that way by not knowing much at all about what you are talking about.

Share this post


Link to post
Share on other sites
hplus0603    11356
Why use SoftICE when you can use a real ICE?

For those who aren't aware, ICE means "in-circuit emulator" and is the next step up from a logic analyzer. It's a completely debuggable system, built to be instrumented, stopped, single-stepped at the cycle level, etc.

Also, because the OS and CPU have to load the program and execute it, then you can use an emulator to do the same thing (based it on valgrind or whatever), and figure out where the protection actually is in the code. Even if the program "checks for debuggers," if you're running it in a sandbox, you can tell it whatever it wants to hear. Then you patch the code.

Any client is insecure. If there's enough incentive to hack it, it will be hacked. Period. End story.

The best thing you can do is to PUBLISH your networking protocol, and let everybody build clients for your games/servers. That way, you'll get lots of scrutiny, and you'll hear about problems quickly. Then fix them :-) Also, when you consciously publish your protocols, your mind will be focused on the right parts of security, so you'll probably engineer it better.

Share this post


Link to post
Share on other sites
drekkar    122
I dont think maple story is a good example of a secure online game, I've read that the hit detection is done client side, which might be good for pushing down the processing necessary on the server, but now people have the ability to walk around without taking a hit. Also aparently life regen is also client sided, not good :( (aparently also you get kicked off for regaining life too often). Maple story's debugger detection isnt more than a call to IsDebuggerPresent() which can be got around easily, and I think they do CRC checks on their code or something periodically, i just read it but i'm not sure :P. I never did anything with this game personally but just read some stuff from people who have :).

Obviously encrypting your protocol will help to a point - however still dont asume this will protect anything. This will stop simpler crackers, but still people will reverse your encryption. Also encrypting your packets wont be all protecting because when people edit something like their position for example - your encryption will still process whatever coordinates they set.

Generally as said the client should just request actions being done, and the server should check if it's possible, within range, within reasonable values to not crash your clients, correct length packet, etc. Basically asume the player can and will use any possible values for everything in the packets. Generally they can get really creative, and if you give them any openings it could result in total disaster. Also a major thing alot of game developers tend to forget about is speed, be sure to not let them take advantage of this on you :)

A good thing to do to track duping is to ID your high end items, so you could go through your database periodically and make sure no one has more than 1 of the same ID best item in the game :D Maybe since it's a small scale game you could even detect when high end items like this are sold to NPC's, traded, whatever :) I guarantee if you put a great item in the hands of someone who knows how to dupe - they will do it. You could use this to your advantage by letting them 'find' an amazing item, and log all traffic between you and the person who has that special item (of course they will transfer it to some newbie to dupe with to avoid deletion, yada yada) althrough you should be extremely secure when dealing with item transferring/dropping/picking up/whatever so there shouldnt be any duping, but sometimes stuff just happens ;)

Share this post


Link to post
Share on other sites
hi everyone,

thank you all for your replies. i understand a little better now how to design my game. basically i just dont trust anything to be done client side. im still a little confused on how people cheat though.. so it's mostly people attaching a program to the memory of my program? is it possible for them to write a program that could receive the packets my game should and then manipulate the packets and send it to the game, like how i describe in my first post?

also, i know how to make it secure on the game level by making everything server authoritative, but, what about on the network level? im using Raknet which offers secure connections. from the docs:

Quote:

# Uses AES encryption with randomized, chained blocks, preventing unauthorized reads and blocking replay attacks.
# Adds CRCs so that data tampering can be detected.
# Uses randomized, encrypted SYNCookies to prevent unauthorized logins.
# Uses RSA encryption to protect the AES key.


not really sure what any of that means, but it sounds nice [smile]. it says that it add's up to 15 bytes to each packet though. and i can't use it for only certain packets, its either all or nothing. do you think i should turn this on? or should i just try to account for the security on the game level only? is 15 bytes too much for every packet?

thanks again everyone.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
Quote:
Original post by Michalson
You just proved yourself deaf.


I'm sorry if it wasn't obvious, and I'm sorry for not explaining in detail, but I thought it *would* be obvious. As hplus explained in slightly more detail... you can NEVER write an application that prevents debuggers attaching unless you have more power over the user's machine than the user themself has. Whilst MS is trying to get machines built and sold where this would be true (MS + partners would be able to do things to your machine that you could not control because the hardware and software would have a shared secret) it is still far from being reality.

In the meantime, there is nothing you can possibly do to any client machine that the machine's owner (the game-player) cannot outwit, given the right tools, effort, and brain power. This is one of the things peculiar to games that makes game-security much more interesting than normal security - anything that enters or leaves the player's machine is untrustable. The player has NO vested interest in keeping the system secure; quite the opposite.

Quote:
Original post by Michalson
Your post makes it sound like you are an amateur who has probably never even seen SoftIce in action, and are simply refering some kind of mythical version of SoftIce that you've hear about. But then that may not be true, you simply make it sound that way by not knowing much at all about what you are talking about.


Alternatively, it could just be that you missed my point :). Being pedantic, if you re-read my pseudo-code carefully you'll see it was actually written to apply inclusively to your "detection of debugger attaching". Shrug. re: usage, I haven't personally used it since D1, and I haven't played that in many years (D2 is already getting on for a decade old!).

re: being an amateur - yes, I am in no way a professional game-cracker! But I am a security professional in the games industry.

Share this post


Link to post
Share on other sites
Gizz    168
Quote:
Original post by graveyard filla
basically i just dont trust anything to be done client side.


true

Quote:
im still a little confused on how people cheat though.. so it's mostly people attaching a program to the memory of my program?


Not only that. As stated in a previous post, by intercepting data sent from the server to the client, one could gain information that are normally not available (radar exploit).

Also, never, ever send another player IP address. I can't remember which game was using peer-to-peer connection for chat to save some bandwidth. Some users were using it to launch small DOS attack on the other player, resulting in the attacked player not receiving delayed server information (when receiving it) and thus giving an unfair advantage to the attacking player.

Quote:
is it possible for them to write a program that could receive the packets my game should and then manipulate the packets and send it to the game, like how i describe in my first post?


Yes but normally it's the other way around ( outgoing packet are intercepted and modified before getting to the server ).


Quote:
not really sure what any of that means, but it sounds nice [smile]. it says that it add's up to 15 bytes to each packet though. and i can't use it for only certain packets, its either all or nothing. do you think i should turn this on? or should i just try to account for the security on the game level only? is 15 bytes too much for every packet?


Depends on your average packet size and packet throughput. But, if I remember well, you're not aiming for MMO user count so the little extra shouldn't be noticable.

Gizz

Share this post


Link to post
Share on other sites
Harlan    122
Is there nothing that can be done using Data encryption? even if it was hardware assisted encryption/decryption?

For example:
What if every server->client stream was encrypted with mutually secret keys? If that was done, then no packet sniffing would get any information.

What if every client->server message had a digital signature that was applied by hardware? this would verify authenticity of the client message, and prevent spoofing.

At the network layer, this is really all you can do.

You can't prevent someone from changing the source program in resident memory, by watching or modifying the network layer.

(or can you?)

Harlan

Share this post


Link to post
Share on other sites
FireNet    187
SoftICE,WinDASM,HView are all easy to find.It does not take much skill to get past simple protections.

Quote:

by hplus0603
Any client is insecure. If there's enough incentive to hack it, it will be hacked. Period. End story.


End of Story,yours.

Quote:

by drekkar
Obviously encrypting your protocol will help to a point - however still dont asume this will protect anything. This will stop simpler crackers, but still people will reverse your encryption. Also encrypting your packets wont be all protecting because when people edit something like their position for example - your encryption will still process whatever coordinates they set.

Very possible.

So in this case it is best to keep everything server side and let the client be just a graphics shell which just can send instructions to the server to move it's units but will sure put some work on for your server.But this should keep some problems from appearing.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
Quote:
Original post by Harlan
Is there nothing that can be done using Data encryption? even if it was hardware assisted encryption/decryption?


See above. Short answer: no, unless there is a shared secret between CPU/(core of PC) and your game which locks out all OS's on the PC from actually doing anything, OR between (CPU/etc and OS and game) which causes the OS to give more access to the game-code than it does to any code sourced by the *owner* of the PC.

IMHO it's an evil ass-raping scum of the universe style thing to do for MS to propose "owning" part of every physical PC in the world such that the physical owner does not own the PC any more (this is what they were proposing with Palladium, in one of it's guises). In some jurisdictions (notably parts of Europe) this kind of thing was tentatively made illegal many years ago - unfortunately, such laws can be removed, given enough bribes to govt, and MS will probably get them annulled / "corrected" sooner or later :(. Sob.

So, whilst technically speaking it is both possible AND there are prototypes around that would allow it AND MS has shown an interest in bringing it to consumer desktops, you would be a fool to follow that path. Maybe in 20 years time, if MS wins...

Share this post


Link to post
Share on other sites
hplus0603    11356
Quote:
Quote:
If there's enough incentive to hack it, it will be hacked. Period. End story.

End of Story,yours.


Obviously, seeing as I was writing it.

I'm still waiting to hear a story based on facts that ends any other way. Most projects that end up not being hacked aren't hacked because there's no incentive to.

Since you made the point, perhaps you have a different story to tell us?

Share this post


Link to post
Share on other sites
hi guys,

does anyone understand, and not mind explaining to me how the encryption in raknet works, and if its worth using?

again, heres a quote from the docs:
Quote:

# Uses AES encryption with randomized, chained blocks, preventing unauthorized reads and blocking replay attacks.
# Adds CRCs so that data tampering can be detected.
# Uses randomized, encrypted SYNCookies to prevent unauthorized logins.
# Uses RSA encryption to protect the AES key.


could someone explain to me what this means exactly? also, it says it adds up to 15 bytes to every packet. is this worth it?

i mean, i figured that since everything is hackable, this is hackable too, therefore theres no point in using it and i should do security on the game layer (ie make everything server autharatative, i guess this is still the network layer?) and not the network layer. so can someone explain the logic to me in even bothering using encryption? also, rakknet can't do this for only specific packets, its either all or nothing. is there a reason for this? or does it make sence to only encrypt certain packets which you want to be secure.

thanks again everyone.

Share this post


Link to post
Share on other sites
hplus0603    11356
Encryption can help make some hacks harder to construct. Thus, if there's only a mild incentive to hack your client, then enough protection might prevent most people from doing it. It's all about making the effort/reward equation say "too much effort, too little reward".

Remember: when you and your buddies are being chased by a hungry bear, you don't have to outrun the bear; you only have to outrun the slowest of your buddies!

Talking to an indie MMO developer friend, (who has been running his games site for years), it seems that poking at values in client memory is preferred about 99:1 to actually trying to programmatically spoof being the client, by the hackers. He only uses very simple encryption. His system is peer-to-peer, so because you have a trusted server, you have already eliminated 99% of the potential hacker pool :-)

Share this post


Link to post
Share on other sites
DirectXFreak    166
Originally Posted by Saruman:
[
Your client should just be a dummy terminal, that renders and accepts input (a few other minor things such as predictions, etc). The server should control EVERYTHING and the client should just render it.

Other problems such as radars, etc are inevitable and will happen in any online game, although there are many ways to minimize this from happening.
]

How exactly does this work? Would the client send requests to the server based on input? What if the server was not deticated and instead was a player as well, should the host computer be bogged down with everything?

P.S. Please show me how the heck you quote somebody...

[Edited by - DirectXFreak on November 18, 2004 10:58:50 PM]

Share this post


Link to post
Share on other sites
Gizz    168
Quote:
Original post by DirectXFreak
Quote:
Originally Posted by Saruman:
Your client should just be a dummy terminal, that renders and accepts input (a few other minor things such as predictions, etc). The server should control EVERYTHING and the client should just render it.

Other problems such as radars, etc are inevitable and will happen in any online game, although there are many ways to minimize this from happening.


How exactly does this work? Would the client send requests to the server based on input? What if the server was not deticated and instead was a player as well, should the host computer be bogged down with everything?

P.S. Please show me how the heck you quote somebody...


Yes. The client basically only foward the inputs to the server and wait for the outcome. Of course this is a top level description but it's essentially that (add to that dead-reckoning to compensate for latency, etc ).

This work well even if the server is also a client. One thing to remember is that the server won't go through the display process for the clients except for the local one so it won't cost that much.

You still have a problem if the compromised client is the one running the server though :)

btw, This principle work well in a client-server environment, for peer-to-peer, you might want to check other way of doing your networking code, like lockstepping.

As for quotes, heres a Quote [smile] from the faq:
"Quotes
To get a quote effect, just surround the text with quote and /quote tags (tags must be surronded by square bracket [] but I had to edit them for this post to show correctly). In addition, if you'd like to quote another post entirely, click on the icon."

Gizz

Share this post


Link to post
Share on other sites
DirectXFreak    166
I see, now if I were to create a game where I didn't care about cheating (perhaps a hobby game) will this model even benefit me? Would it be better then to just let the client take care of himself?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this