Im not giving my opinion, im using logic and common sense. But I would be glad to look at any evidence you have that proves me wrong. Have you ever used a admin tool before? Rcon? Sounds like you don't even know how they work. Like I said its 2016, every user would have to have his own account with permissions set that would all be logged.
The GM tools were designed specifically for that client, trying to use a GM tool on a newer client would just not work because the structures and packets are different. You can ask people on epvp if you don't believe that. It's the exact same principle as players trying to login as a GM character, the structures are different so you get forced out of the character after logging in. There are loads of threads read some of them, I read loads. Half way through G1 they dropped gg entirely and the lack of staff made it easier for people to exploit the game. The game has also been exploited by normal people from most countries because the game isn't very secure to begin with. If the tool is anything like that german verison of the DE_OPER_TOOL then you need to have information from your computer stored in the database to even connect to the oper tool.
Thanks for clearing that out for me. I wouldn't know how a GM tool works. I only know that it has been used because I saw them performing plvl, item dupe etc. Specially when it has been carried over from all 3 clients in the past, I am under the impression that this will continue here as well.
I don't think this is the result of a 'GM tool' because if it does work like the oper tool then you need to have your computer name and the IP address stored before you can connect the tool to your database. It might be a exploit just within the game (loads exist) and there hasn't exactly been a huge staff presence to deter people from exploiting the game. There are communities dedicated to breaking gameguard who regularly release ways to break it. The issue isn't who joins the game but what protection is in place once gg/hs is broken.
Lol how you gonna say that, then in the next post admit that you are talking out of your ass >< If they doing naughty things its more than likely packet manipulation.
Read what i wrote again, i saw first hand the use of GM tools. You know, like screen share? Yes I have seen it
No, you just made assumptions and made yourself look silly. So yeah lets ban IP's because you think you seen something dodgy, GTFOH. Only IP that needs banning is yours for talking pure ****.
Banning an entire countries IP range isn't going to solve any issues related to hacking/cheating. The real problem is the game itself accepting information from the client, rather than calculating it on the server and sending the information to the client. Quite a lot of people were Vietnamese back in the CS cap days. On Asura there were many players in bands like Thahn Van Mon, Rice Dot Com, Skypia, LuongSonBac, etc. that all had Vietnamese players. I have no idea where these people are getting the idea that there were no Vietnamese players around in the beginning. The server and client code for the game that leaked back in 2012 shows that the original or at least up to 2012, were able to be handled in game some way. The client itself actually has pre-processor compiler options to enable access to other windows in game that allow GMs to do a variety of stuff. Even if the developers decided to change the structures of the classes for packets, it would only break any previously compiled, and outdated clients from previous years. It would still be possible to create a custom tool that uses the new packet structure to access the GM commands. They need to add protection on the server end, and not allow any spawning/creation/etc. of items/mobs/etc. without being logged into an authorized user account. I believe they eventually got around to doing this at GamesCampus, since the admins were talking about how the tools are white-listed to the game publisher's office. The game was originally designed around managing as a GM from the client, which is one of the worst ideas now. Back in the early 2000's this was common for game developers though, and over the years they have adapted. This game is compiled with VC6 and uses the 2003 or 2007 DirectX SDK, but with considering how old VC6 is it's most likely the 2003 version. Considering how much work has been done on this game, and the fact that the game is still compiled using VC6 in 2012 it shows how much of nothing has really changed internally over the years. To give an idea of what I mean, VC6 was released back in 1998.
Wouldn't it be likely the packet structure itself would be randomized in a way to prevent someone from capturing and modifying the packets? AFAIK nobody at least publicly has access to such tools, nobody on the epvp or ragezone or 9dzoom forums have access to to them and if they do, they haven't shared them. I don't fully understand how you would be able to build a tool to emulate gm functions because you would need information stored on the database to access the tool, plus wouldn't you also need to understand the structure itself and AFAIK there is no source or semi source available for anything like that regarding the games files? So it sounds like there are no server to client or client to server authentication to make sure the requests made to the server are legitimate?
The developers can encrypt incoming and outgoing packets, but it is still possible for someone who is willing and capable of reverse engineering to obtain the data used to encrypt the packets. Encryption would definitely stop people from using an old GM client from previous publishers, since none of the data would be understood by the server and assumed to be a junk packet. When you say "need information stored on the database", I can see you don't really understand how computer programs work. A common use for a database would be a server querying the database for user "Blitzcronk". If it finds the user, the server could attempt another search for a value for something like "isGM", and then check if its TRUE or FALSE. Databases are more of a universal save for data, and not something that controls how an application works. The packet structure is defined as a class in C++, and handled on the client and server separately. The client needs to understand what the server is sending, so no matter what somewhere on the user-end the packet structure is going to be available. You can disassemble applications on Windows using various software, one of the most popular and most used is called IDA ( Interactive Disassembler ). You cannot decompile C++, so unless you have access to the game source you are stuck with disassembling the module. Disassembled code will be brought to one of the most low level languages available, x86 assembler on a standard Windows 32bit module. You can find links to a somewhat full source for the client and server somewhere on ragezone.
The source you're referring to is the one Odasm released back on his github from 2005, you couldn't really make a huge amount of use for it as the structures are different, we studied some of the structures back during server development but with each compilation of the client, the structures and headers are changed. You can easily do this yourself, get the github and check out some of the structures, write a raw socket and send the packet and you may or may not be stopped by gameguard. Packet deciphering and reversing isn't exactly beginners territory and neither is assembly so to start kind of ranting on about creating raw sockets for packets yourself and then using Olly and IDA to reversing them to study the packet structures is a bit of a waste of time but whatever you feel is necessary when insulting users with "I can see you don't really understand how something works, let me be a **** here and break down things to patronize you a bit more". With a standard security practice of when data is sent and received by client/server, the packets being sent by the client should be encrypted and then decrypted when the server acknowledges them. What the server fails to do in our case is have any conscious sense of security, there are bit shift/compressions and the bytes of the packet are not changed. The packet is simply sent over tcp/ip or udp and acknowledged by the server. The server doesn't care if the packet is malformed or legitimate, it just accepts it. The server needs to be rewritten so it understands what packets are legitimate and which are not and block the ones which are not as mentioned through dynamic byte changing and bit shifts. Look through a number of the packet structures and headers, not much security. Blocking a range of IP addresses because of server insecurity is just stupid and we cannot really afford to lose members as it is. We're not putting this into some debate or discussion, I only replied because I had a few things that you might have missed out during your misinterpretation of what the person said. He/she was referring to how the oper_tool works, you need to have your IP addresses, SQL server information to connect to the database and your computer name stored within the database or else you are not connecting to it. I don't think he/she was asking for a step by step guide on how a computer program works.
The source is from 2005? That's nice to know, thanks for the information. He asked a question and assumed incorrectly about how something worked, so I explained it to him. It's not my fault you interpreted it incorrectly and got upset. Explaining how something works is how people learn and just because someone is unfamiliar with a topic doesn't mean they are incapable of retaining information. You should get off your high horse and stop believing you're better than everyone else. Yes, a packet may be accepted but shortly after the server realizes the data was trash it's dropped. The server packet process function actually shows how it interprets the data. After bit shifting the second byte in the packet buffer, it uses multiple cases in a switch statement based off of the second byte to decipher the type of data being received. If you were to get into a switch case, the functions that are called afterward are dependent on the actual size of the packet. Each function call casts the buffer to a C++ class structure and stores the data inside of it. If the packet you're sending is incorrectly sized or you assume an incorrect variable location, the data the server may interpret can be garbage. This could lead to anything, which in your case is having your connection dropped from the server. All of this information is from the server source that you stated is from 2005 and according to everyone else here, is changed now. Blitzcronk stated that they didn't fully understand how someone could make a tool without access to source code, or a database. I explained that a database doesn't define or control the game internally, and that the packet structure is defined on the client. I can understand how it would be confusing for someone when the flow of the program itself may depend on database information. The whole point of the post was to inform Blitzcronk of how it's possible without full source code, or the server files to create a tool that is capable of doing what was asked. There isn't even an actual need to create a tool to do it for you, it's all possible through the game client itself. All you need is access to the games memory, and then it's your choice from there. Depending on what you want to do, you could end up calling the packet send function or changing the values in your client so it's sent as a normal packet.
