![[GUIDE] HardwareID in a Nutshell](https://www.elitepvpers.com/forum/iconimages/sro-pserver-guides-releases/guide-hardwareid-nutshell_ltr.gif){kind=small}
Hello people of Silkroad,
It’s come to my attention that a lot of you are struggling with offering a decent method to uniquely identify your clients. Let’s fix that.
So what’s the problem? Why are we all failing against replay attacks?
The answer is because the server has no methods of verifying for authenticity.
B-b-b-u-t dude, I eNcRypT my packet and the server dEcRypTs it.
Sure, that works. Unless florian0 decides to deconstruct your DLL.
Can you please tell us what you want to say already?
Okay. What you’re missing is a server role. Right now, your server is pretty much useless. You’re entirely dependent on your client to generate and encrypt the data. Your server simply decrypts whatever is sent to it and probably checks whether the same data is online right now or not.
Please elaborate.
So assuming my hardware id is “ihaveahugepenis” and I encrypt it using blowfish with a key “fayox” to get “dce466cafd59f7af96b915765c6fa025”. Now I send the encrypted string to my server and attempt to decrypt it. The server decrypts it, checks if there’s someone connected who also have a “hugepenis“. If it’s not found then okay proceed to login and if it is, disconnect. This works but, you assumed nobody knows your encryption method/key. You’re wrong. They’re on everybody’s machine. They just need some skills and they can emulate the process (happened a few times).
So what? I will use a better encryption method and virtualize my DLL.
That might slow most people down. After all, bypassing your little hwid protection isn’t all worth it.
But then comes Eslam Galull’s way of trolling. What he’s doing right now is just saying FUCK YOU to whatever is happening on your client. He’s exploiting what I mentioned earlier; the lack of a server role.
Again, your server is basically decrypting whatever you’re throwing at it then, checking whether someone is connected. So basically, all packets generated from all machines are valid on any of these machines as long as the machine is not connected.
PROPOSED SOLUTION:
1 – Client-generated timestamps:
This is basically you just appending a timestamp to your packet data. You then encrypt it and send it to the server.
Your server then decrypts the packet and checks this timestamp for when this packet was generated thus, providing you with a method to check whether the sent packet has been generated by the client or actually cached and reused.
The downside is that since the process is still solely client-based, you could change your machine time, generate some packets and send them at the appropriate time.
2 – Handshake:
This is really simple. Just like any handshake, the client generates something and sends it to the server then the server signs that something (say with a timestamp) and resends it to the client. The client then sends whatever he received again to the server. This is so close to a 3-way handshake protocol.
Making it even harder:
So here one could argue that unless the time-interval in which every packet is valid is so small, you could still generate a packet one some other machine and use it.
There’s actually a nice way of knowing whether your packet was created on your machine or not. Why don’t we bound the packets to the sessions? Each packet will be encrypted using some random number. For now, let’s say the session id.
The client will receive a multi-encrypted packet that whose key is only found on the server. The server will attempt to decrypt the packet using the session id and checks for the timestamp.
Will the replay attack still work?
To pull this off you would need to actually figure out the encryption used on the server. This is extremely hard if not impossible if you use an asymmetric cipher.
A few remarks:
Client encryption: You're encrypting your client-generated hwid so it's not easy for anyone to send different data to the server with false information. This step is just making someones life harder.
Server encryption: This ensures that you can't attempt to modify the data sent to you by the server and also that other packets generated for other sessions can't be used across other ones (as the server will fail to decrypt the packet because it will attempt so using a wrong key).
Hardware-Id: There actually isn't something as a hwid. This is essentially something you put together using some pieces of information from your hardware devices: MAC Address, HDD Serial Number, CPUID, etc. How you combine or check these totally depends on your implementation.
Bypassing Hardware-Id checks: Find away to emulate the functions that generate those ids. As far as I heard, qqdev has been writing something that does that (avoiding this is annoyingly difficult and I doubt is worth it at this point, hint; might require some kernel-level bullshit).
It’s come to my attention that a lot of you are struggling with offering a decent method to uniquely identify your clients. Let’s fix that.
So what’s the problem? Why are we all failing against replay attacks?
The answer is because the server has no methods of verifying for authenticity.
B-b-b-u-t dude, I eNcRypT my packet and the server dEcRypTs it.
Sure, that works. Unless florian0 decides to deconstruct your DLL.
Can you please tell us what you want to say already?
Okay. What you’re missing is a server role. Right now, your server is pretty much useless. You’re entirely dependent on your client to generate and encrypt the data. Your server simply decrypts whatever is sent to it and probably checks whether the same data is online right now or not.
Please elaborate.
So assuming my hardware id is “ihaveahugepenis” and I encrypt it using blowfish with a key “fayox” to get “dce466cafd59f7af96b915765c6fa025”. Now I send the encrypted string to my server and attempt to decrypt it. The server decrypts it, checks if there’s someone connected who also have a “hugepenis“. If it’s not found then okay proceed to login and if it is, disconnect. This works but, you assumed nobody knows your encryption method/key. You’re wrong. They’re on everybody’s machine. They just need some skills and they can emulate the process (happened a few times).
So what? I will use a better encryption method and virtualize my DLL.
That might slow most people down. After all, bypassing your little hwid protection isn’t all worth it.
But then comes Eslam Galull’s way of trolling. What he’s doing right now is just saying FUCK YOU to whatever is happening on your client. He’s exploiting what I mentioned earlier; the lack of a server role.
Again, your server is basically decrypting whatever you’re throwing at it then, checking whether someone is connected. So basically, all packets generated from all machines are valid on any of these machines as long as the machine is not connected.
PROPOSED SOLUTION:
1 – Client-generated timestamps:
This is basically you just appending a timestamp to your packet data. You then encrypt it and send it to the server.
Your server then decrypts the packet and checks this timestamp for when this packet was generated thus, providing you with a method to check whether the sent packet has been generated by the client or actually cached and reused.
The downside is that since the process is still solely client-based, you could change your machine time, generate some packets and send them at the appropriate time.
2 – Handshake:
This is really simple. Just like any handshake, the client generates something and sends it to the server then the server signs that something (say with a timestamp) and resends it to the client. The client then sends whatever he received again to the server. This is so close to a 3-way handshake protocol.
Making it even harder:
So here one could argue that unless the time-interval in which every packet is valid is so small, you could still generate a packet one some other machine and use it.
There’s actually a nice way of knowing whether your packet was created on your machine or not. Why don’t we bound the packets to the sessions? Each packet will be encrypted using some random number. For now, let’s say the session id.
The client will receive a multi-encrypted packet that whose key is only found on the server. The server will attempt to decrypt the packet using the session id and checks for the timestamp.
Will the replay attack still work?
To pull this off you would need to actually figure out the encryption used on the server. This is extremely hard if not impossible if you use an asymmetric cipher.
A few remarks:
Client encryption: You're encrypting your client-generated hwid so it's not easy for anyone to send different data to the server with false information. This step is just making someones life harder.
Server encryption: This ensures that you can't attempt to modify the data sent to you by the server and also that other packets generated for other sessions can't be used across other ones (as the server will fail to decrypt the packet because it will attempt so using a wrong key).
Hardware-Id: There actually isn't something as a hwid. This is essentially something you put together using some pieces of information from your hardware devices: MAC Address, HDD Serial Number, CPUID, etc. How you combine or check these totally depends on your implementation.
Bypassing Hardware-Id checks: Find away to emulate the functions that generate those ids. As far as I heard, qqdev has been writing something that does that (avoiding this is annoyingly difficult and I doubt is worth it at this point, hint; might require some kernel-level bullshit).
