My first real foray into Linux was inspecting network traffic with a program called ShowEQ for EverQuest. At the time, the traffic was unencrypted and had lots of juicy info in it. I used a hub to replicate traffic to my Linux box, and it would draw a live map of the zone and showed where the mobs, NPCS, and users were. It even showed what loot the mobs had on them so you could cherry pick certain ones. The beauty of this was that it was passive and impossible to detect. Eventually SOE wised up and started to encrypt the traffic.
The data has to be decrypted and read, so eventually you reverse engineer the client and figure out how to decrypt on the fly, then they wise up and introduce key based signing, which you eventually try to steal from the client and breaking the encryption again, then anti cheat is implemented... thus, the cat and mouse game is born, lol
Once the siphoning happens on the same machine your client is running on it's easier to detect through anti-cheats at least. If it can run on a completely separate machine it seems like it'd be essentially impossible to detect except through changes in how a user acts like only going directly to the mobs with the juicy loot and ignoring the trash but that's really tough to detect.
Hypothetically the client doesn't really have to know about the juicy loot until it's dropped, right? On a sufficiently fast internet connection, the client doesn't need to know about anything until exactly the time when the player needs to know it, at which point revealing it in a cheating tool is meaningless.
At the very least with everquest (iirc) npcs would sometimes use their loot. I recall tanks occasionally letting the rest of the raid know what weapon drop the boss had on them because they were seeing a different damage type (pierce, slash, bludgeon instead of hit) and the boss was known to sometimes drop a certain piercing weapon (for example).
That being said, I can totally think of a few ways to get around that. It's like you said, the client doesn't really need to know until the enemy is looted.
[Actually, the one exception that I can think of is that rogues can pickpocket certain loot. And while pinging the server to generate loot once the npc is dead feels like it shouldn't be a major problem, having to ping the server to generate loot while the npc is still alive does make the system architect in me feel a bit more nervous ... at the very least for systems as they were when EQ first came out.]
NPCs also gain stat bonus from their equipment. NPCs wear every slot except only 1 wrist,finger,ear. Big difference between a mage pet in full banded vs naked.
Modern games you don't need to unless the boss changed depending on the loot and even then it would be tangential. Don't forget this is EQ2 we're talking about internet back then was sloooooow and online games of that type were pretty new so designs and security were still being sorted out. Now you know from the beginning that any useful information about the enemy and world will be pried out of your game so you go through the whole anti-cheat cat and mouse game.
The final stage beeing the Opt player kill & Bann. Compute a all knowing AI and hold it's behavior against that of players, then cull the closest percentage.
Sending loot on NPCs to every client costs more, not less.
The reason why they probably did it is because NPCs actually used the items. When the froglok King loaded his two handed sword, he was actually using it. And when he didn't load it, he wasn't.
I'll admit I did something similar for a game called Dark Age of Camelot as a teenager. Very educative, learned about both network sniffing, hubs vs switches and Linux.
Was it worth it to give me an advantage in the game? No, I never played the game seriously enough to be able to use it, I think I used it for a week after spending two setting it up, but it was a great learning experience.
I also fell into my first programming experience with DAoC! I worked on fixing some very simple bugs/exploits on an emulated server (C#) back in 2005.
There's a ton of fascinating stories coming out in the last decade around hacking/exploits/etc of games of that era; DAoC, UO, Shadowbane (this one was real bad).
If you don't encrypt your network traffic, you can quite easily decrypt it on another PC (as you can just set promiscuous mode on your 2nd PC NIC), giving you undetectable read-only hacks like "radar", where you basically have a map of the game with the enemy positions, health, gun, ...
If you encrypt it, this is no longer possible.
If a cheater wants to decrypt it, he has to get access to the decryption key, which usually is send over an TLS encrypted connection (with certificate pinning in place) [Or in some cases self made encryption :/].
Therefore he has to either reverse the game to get the certificate or has to attempt to read it while the game is running.
In the first case the game developers (and the Anti-Cheat providers) will try there best by obfuscating the specific regions.
And the 2nd case is basically what AC is all about, and therefore difficult for modern Anti-Cheats.
I think reading the encryption key from memory is usually easy and cannot really be detected in any way if done from the kernel or hypervisor by parsing page tables and accessing physical memory (except by looking for known code if the anti-cheat has as much privileges as the extractor, which the hypervisor approach avoids).
In first approximation, there are only two kind of difficulty levels: the impossible things you don't know how to do, and the trivial things that you do.
I always wished that CPU/GPU manufacturers would make a "online gaming edition" with hardware level encryption/anti-cheat. I know many people would love to play exclusive lobbies where it is virtually guaranteed there are no cheaters.
You can just hook the networking system calls and you have the unencrypted buffer. TLS encryption doesn't do anything since you can just look at it unencrypted on the network function when they pass in the buffer.
If they encrypt before the network functions, you can just look at the callstack and trace the variable containing the buffer backwards until it's non encrypted.
Yes. Sometimes software will encrypt HTTP calls while relying on the operating system certificate authorities, so it's easy to intercept again using tools such as mitmproxy.
Sometimes you will be forced to hack the software, to allow interception or to replace a key. Unless they use a symmetric key that is easily found, but I have never seen that.
It doesn't, we are just in 90's security mindset. We even have the typical idiot here chiming in, "it doesn't have to be perfect". Meanwhile in adult software engineer world, we know we can just not send the state of the entire world to every player and that would also save costs.
Decompiling (in a meaningful way) an optimized binary generated from C without debug symbols is much harder than what the author has shown in C#. It is not impossible, but probably very time consuming.
Versus just reading clean packages from a network.
ShowEQ still works, there is also MySEQ which is Windows based but just reads memory instead. They are fine to use as the current owners of EQ don't really seem to care. Neither app has ever been able to show what loot a mob has except for visible pieces. Some of the data has changed over the years, for example exact mob HP used to be sent, now they just send percentages.
> Neither app has ever been able to show what loot a mob has except for visible pieces.
ShowEQ definitely showed drops at some point. I vividly recall farming lightstones from Willowisp and using ShowEQ to ignore the ones with burned out lightstones.
I would suspect "modern" has a lot more impact than "browser" (notably, aside from more developer awareness of cheating, I would suspect TLS is far more common now, though that can of course be worked around when you control the client). Browser traffic isn't any different from any other type of traffic, the standard packet sniffing tools (tcpdump, wireshark, mitmproxy, etc.) work just fine.
