Hello, I would like to restrict access to my ServUO server only for my custom client. I want to disconnect anyone attempting to connect in any other way and display a warning message at the bottom left corner. The warning message should read, "To log in to the server, please download our custom client from our website." I believe this system can be implemented by sending packets from the server. Is there anyone here who has the ability to create this system? I am willing to pay whatever the cost may be.
- Thread starter yigitbaba
- Start date
OP
What is the thing you refer to as combination exactly, how is it done? I really don't understand anything about these coding matters.
OP
I don't think the method I'm looking for is this, I don't believe what I want will come out with the method you mentioned.
OP
It's not something I can do.
OP
The ideas are great, but I don't have the knowledge to implement them.
I wonder if ClassicUO team and ServUO could work together to where you could generate a key on ServUO side and link it to a client and if you didn't have the key it wouldn't let it connect allowing for disabling some features and things as well? Just ideas.
It'd be really complicated to implement.
Basically you'll have to somehow first set up a website to create credentials
then, forward those credientials to a database the server can use
use IO/file operations of .net or create your own to iterate over the list of credentials
probably separately on a different server-computer that can send RPC remotes back & forth from and to the server for really large shards
or some better means of organizing old credentials no longer used after a certain # of days to keep the folder iterations fast
if the credentials in the folder are found than that's the first step
then, some means of generating a client tag inside the client launcher that connects to the server
the server then iterates over its list of credentials and checks for this client tag
if found, then that's the second step
the server would also need to be able to keep track of a generated clientID and any other forms of identification on the server,
which would need to be proactively hashed and regenerated each login. that's the third step.
then this would enforce client verification
however the client would also need to use an implementation of an hashing algorithm imho
to pregenerate credentials the server could also validate, historically cross comparing various data points of that client on the server
it's a heck of an idea and a hell of an implementation, but would enforce client verification
one step further would be to consolidate the entire process of the website into the direct workings of the server
that would only take implementing a custom GUI interface on the ClassicUO client launcher
however at that pojnt you may as well also utilize a system of IO/file reading to determine if all of the contents of the client's files also match the server's latest copy of those files, including all artwork and everything else.
that would be slow on the server so, on a separate thread...
or the server would send a bunch of IO files similar to a cookie for the client to verify,
that introduces the concept of people bypassing to get advantages or bypassing client verification to cheat
maybe on several separated threads have those dedicated to logging players in and verifying their client files or something,
and only share any data between threads when actually finishing a validation
that would just require tweaking of thread-queue executions whenever a player attempts to login and that could lessen overhead
Sooo....
1. Client wants to login
2. First, distract target onto a blind queue.
2.1 Counter cross to left cheeky onto another thread for overhead reasons, (y) handling a queue of handshaking requests;
3. The client performs a wild haymaker of file-dumping
3.1 Each file needs to be written to IO and send over the network to the server,
perform elbow block and body shot every file's content against an existing clone.
3.2 Than blocking furrow left, send requests to the client to simultaneously begin a new thread
and check the client's ClassicUO version or other custom files exist in a custom client also.
3.3 If the client cannot verify that, than weaken right jaw and send a request to check for the client's tag or something
4. Once verified, break cracked ribs and traumatize their solar plexus anyhow,
and get them to verify a set of credentials created within the client interface.
4.1 Dislocate jaw entirely, and on the server backcheck whether these credentials pre-exist
by iterating over a folder's contents for the particular custom IO operation file's contents... pre-existing credentials excuse me.
4.2 End with a huge kick to diaphragm, verifying the client or IP banning.
2. Perform uppercut onto a queue to a separate thread handling handshaking; process
3. The client dumps their client files into an IO file and sends that across the network,
each file's contents would need to be decrypted and sent to the server to validate an existing clone.
4. The server completes validation, and finishes that particular client's verification,
sending their next process to client logging in.
I think its all doable on the server actually without much implementation,
but you need to be willing to mess around with the client and figure out through visual studio's referencing what's doing what
Basically you'll have to somehow first set up a website to create credentials
then, forward those credientials to a database the server can use
use IO/file operations of .net or create your own to iterate over the list of credentials
probably separately on a different server-computer that can send RPC remotes back & forth from and to the server for really large shards
or some better means of organizing old credentials no longer used after a certain # of days to keep the folder iterations fast
if the credentials in the folder are found than that's the first step
then, some means of generating a client tag inside the client launcher that connects to the server
the server then iterates over its list of credentials and checks for this client tag
if found, then that's the second step
the server would also need to be able to keep track of a generated clientID and any other forms of identification on the server,
which would need to be proactively hashed and regenerated each login. that's the third step.
then this would enforce client verification
however the client would also need to use an implementation of an hashing algorithm imho
to pregenerate credentials the server could also validate, historically cross comparing various data points of that client on the server
it's a heck of an idea and a hell of an implementation, but would enforce client verification
one step further would be to consolidate the entire process of the website into the direct workings of the server
that would only take implementing a custom GUI interface on the ClassicUO client launcher
however at that pojnt you may as well also utilize a system of IO/file reading to determine if all of the contents of the client's files also match the server's latest copy of those files, including all artwork and everything else.
or the server would send a bunch of IO files similar to a cookie for the client to verify,
that introduces the concept of people bypassing to get advantages or bypassing client verification to cheat
maybe on several separated threads have those dedicated to logging players in and verifying their client files or something,
and only share any data between threads when actually finishing a validation
that would just require tweaking of thread-queue executions whenever a player attempts to login and that could lessen overhead
Sooo....
1. Client wants to login
2. First, distract target onto a blind queue.
2.1 Counter cross to left cheeky onto another thread for overhead reasons, (y) handling a queue of handshaking requests;
3. The client performs a wild haymaker of file-dumping
3.1 Each file needs to be written to IO and send over the network to the server,
perform elbow block and body shot every file's content against an existing clone.
3.2 Than blocking furrow left, send requests to the client to simultaneously begin a new thread
and check the client's ClassicUO version or other custom files exist in a custom client also.
3.3 If the client cannot verify that, than weaken right jaw and send a request to check for the client's tag or something
4. Once verified, break cracked ribs and traumatize their solar plexus anyhow,
and get them to verify a set of credentials created within the client interface.
4.1 Dislocate jaw entirely, and on the server backcheck whether these credentials pre-exist
by iterating over a folder's contents for the particular custom IO operation file's contents... pre-existing credentials excuse me.
4.2 End with a huge kick to diaphragm, verifying the client or IP banning.
2. Perform uppercut onto a queue to a separate thread handling handshaking; process
3. The client dumps their client files into an IO file and sends that across the network,
each file's contents would need to be decrypted and sent to the server to validate an existing clone.
4. The server completes validation, and finishes that particular client's verification,
sending their next process to client logging in.
I think its all doable on the server actually without much implementation,
but you need to be willing to mess around with the client and figure out through visual studio's referencing what's doing what
Last edited:
This is for my own use. To connect to my server, I must use the ClassicUO that I have modified, and other clients and auxiliary logins cannot. Pay attention to the directory of the phone, which is different from the original directory path. Of course, I can't log in to other servers with this modified one.
It should be noted that the restrictions made when the client data version is higher than 7.0 are only effective
Download address:
My MobileUO
Besides the mobile version, there are also PC versions available
What kind of overcomplicated solutions are those? There are 2 simple solutions to this problem:
1. using custom ClassicUO client - this is the simplest solution, just add some kind of key to a login packet (like 0xAD). On server check the existance of correct key and react accordingly.
2. inject custom code that does the same as 1, into a specific dll that UO clients use. (i don't want to mention specifics here)
Keep in mind that any solution you choose, can potentially be "hacked" or overcome.
1. using custom ClassicUO client - this is the simplest solution, just add some kind of key to a login packet (like 0xAD). On server check the existance of correct key and react accordingly.
2. inject custom code that does the same as 1, into a specific dll that UO clients use. (i don't want to mention specifics here)
Keep in mind that any solution you choose, can potentially be "hacked" or overcome.
You need to modify ClassicUO and send a new custom packet to the server on login. When the server receives the packet (whatever you decide to send, numbers, strings, etc.) it crosschecks it to what "it should be".
If what the Client sent was correct, it should tell the player that everything is correct and nothing else happens.
If it's not correct, it tells the player that the Client version is incorrect and kicks them a couple of seconds later (give time to read the error).
This is a simplification of the mechanism, that needs only one packet to be created and sent by the Client and one handler on the Server.
If you want it more complicated, the Server could also answer with a packet that the Client should handle and decide to continue working or terminate.
As mentioned by Gobik, all solutions are hackable with more or less effort.
Even this solution, to make it secure you'd need to encrypt the packet and also obfuscate the code that handles what the packet sends.
Up to you to decide if it's worth the effort ^^
If what the Client sent was correct, it should tell the player that everything is correct and nothing else happens.
If it's not correct, it tells the player that the Client version is incorrect and kicks them a couple of seconds later (give time to read the error).
This is a simplification of the mechanism, that needs only one packet to be created and sent by the Client and one handler on the Server.
If you want it more complicated, the Server could also answer with a packet that the Client should handle and decide to continue working or terminate.
As mentioned by Gobik, all solutions are hackable with more or less effort.
Even this solution, to make it secure you'd need to encrypt the packet and also obfuscate the code that handles what the packet sends.
Up to you to decide if it's worth the effort ^^