Memory patch is up, RIP D3

[Kace36]

Is there a possible way to read data by sniffing packets?
Completely out of memory

Nope. Doesn't quite work that way. The game data is in memory on the client side. Data on the network is sent back and forth to Blizzard only for the purposes of multiplayer games, connecting to battle.net, and such things, but [most of] the data about the game will be client side in memory. It's possible that you could get some info from packet sniffing in multiplayer games, which may be encrypted, that wouldn't be too serious an issue, however the main problem is it wouldn't be very useful data anyway. Essentially some basic data that tells each client to update the coordinates of other players you are connected with, display their appropriate health, status, achievement broadcasts, etc...

[KillerJohn]

Nope. Doesn't quite work that way. The game data is in memory on the client side. Data on the network is sent back and forth to Blizzard only for the purposes of multiplayer games, connecting to battle.net, and such things, but [most of] the data about the game will be client side in memory. It's possible that you could get some info from packet sniffing in multiplayer games, which may be encrypted, that wouldn't be too serious an issue, however the main problem is it wouldn't be very useful data anyway. Essentially some basic data that tells each client to update the coordinates of other players you are connected with, display their appropriate health, status, achievement broadcasts, etc...

I need some of the stuff you smoked before this post.
Single player games are no different from multiplayer at all (most stuff happens on the server side).
You are talking about Diablo 2

[KillerJohn]

Hello KJ,

First thank you for bringing us a great tool that made my Diablo life much easier.

I paused Diablo for a while after reaching guardian in S12, and came back to discover the mess Blizzard did with the game. Instead of increasing the game quality they just ruined the game. I was really sad to see that THud would not work anymore. Then I read some comment by KJ indicating that the user info data was not available anymore, or maybe in such a mangled way that it was not usable. This is indeed a big part of TH that goes away, but maybe, if KJ still has enough motivation, the rest of TH could be workable until the missing parts are solved.

I was thinking of inventory and object management. KJ do you believe that it would be possible to bring that back ? I was specifically thinking of the Ancient/Primal overlays, the Gem level and the augment level, and object name display while not identified.

This may be seen by many as a very small portion of what TH used to provide, but it would be a nice restart.

Anyway I'll respect any choice you make on that matter.

Cheers

Well, I am still evaluation my options...

...just kidding...

...the only option is @enigma32, and I am constantly sniffing around him to steal his code and ideas and solutions and beg for ways to read the new memory layout.
I can not recommend to donate to him because it is still not sure that I can fix HUD based on his findings, but I think supporting him can't hurt anybody (except your paypal account).

[notnairda]

I'm interested to hear why not

When the game is accessing to pointers, if they really were encrypted, the game would instantly crash because it would try to read at a random place.
Usually the pointer that you get is from a pointer that doesn't change.
Any pointers that change will ALWAYS have somewhere in their traces a pointer that never changes.

Pretty sure havok's work the same way as denuvo in this case. Or actually any games existing.

[notheoneyouthink]

The game data is in memory on the client side. Data on the network is sent back and forth to Blizzard only for the purposes of multiplayer games, connecting to battle.net, and such things, but [most of] the data about the game will be client side in memory. It's possible that you could get some info from packet sniffing in multiplayer games, which may be encrypted, that wouldn't be too serious an issue, however the main problem is it wouldn't be very useful data anyway. Essentially some basic data that tells each client to update the coordinates of other players you are connected with, display their appropriate health, status, achievement broadcasts, etc...

And, the network data is encrypted using SSL anyway, which would be infinitely stronger than any obfuscation they're doing in the client.

[enigma32]

When the game is accessing to pointers, if they really were encrypted, the game would instantly crash because it would try to read at a random place.
Usually the pointer that you get is from a pointer that doesn't change.
Any pointers that change will ALWAYS have somewhere in their traces a pointer that never changes.

Pretty sure havok's work the same way as denuvo in this case. Or actually any games existing.

Well, obviously the game doesn't try to use the encrypted value as a pointer It decrypts it first! So why not just read the decrypted value? Because it lives on the stack which is constantly being overwritten.

And, the network data is encrypted using SSL anyway, which would be infinitely stronger than any obfuscation they're doing in the client.

Last I checked, there was no SSL. Back then I managed to read messages using WinPcap and then decode them There's a bunch of magic numbers in them though that makes them a PITA to patch.

[notheoneyouthink]

Last I checked, there was no SSL. Back then I managed to read messages using WinPcap and then decode them There's a bunch of magic numbers in them though that makes them a PITA to patch.

My bad, I had my wires crossed. Was referring to the RESTful API, not the in-game messaging/TCP. Sorry about that and thanks for catching.

[Kace36]

I need some of the stuff you smoked before this post.
Single player games are no different from multiplayer at all (most stuff happens on the server side).
You are talking about Diablo 2

What I meant though is the actual game data is all in memory. There is absolutely no reason to send all the player data across the network. It would be very wasteful to do so. The only thing they really need to send over the network is some basic data about any other players location in the world, achievement broadcasts, messages to players, etc...

[enigma32]

What I meant though is the actual game data is all in memory. There is absolutely no reason to send all the player data across the network. It would be very wasteful to do so. The only thing they really need to send over the network is some basic data about any other players location in the world, achievement broadcasts, messages to players, etc...

The data is in memory yes, but it comes from the server Positions, animations, casts, sounds, scenes, weather, game tick (clock), direction that someone is looking, projectiles, attribute changes, etc. etc.

It might sound wasteful, and like a lot of data, but it isn't And they send a bunch of messages at a time, so it's not adding latency to every single message.

[Kace36]

The data is in memory yes, but it comes from the server Positions, animations, casts, sounds, scenes, weather, game tick (clock), direction that someone is looking, projectiles, attribute changes, etc. etc.

It might sound wasteful, and like a lot of data, but it isn't And they send a bunch of messages at a time, so it's not adding latency to every single message.

Hmm. I haven't looked at this code to anywhere near the extent you have, so I'll take your word for it. However, it does seem a bit wasteful. Why would they send all information about the game world, including local player world data, except for multiplayer situations? I suppose maybe they did it for security and control so they are intercepting all data on battle.net servers. That makes a bit more sense I could see.

That creates another head scratcher though. If that is indeed true, again I havent looked, ive really mainly just used dotpeek and vs2017 community dotpeek addon to run the disassembler to debug some sessions of your maphack code, but if that's true, then yea, why not just read it off the network layer? Especially if it's not using ssl (obvious reason they wouldnt is the huge performance impact).

Why look for any player data using the player data at preknown pointer address locations (obviously they have modified the pointers and now there is some kind of dynamic and unfixed address for each player data you previously were reading but still why do it even back then?). Was there a reason you went with that versus reading all player and world data from the network stack?

Thanks, appreciate your responses

[enigma32]

Why would they send all information about the game world, including local player world data, except for multiplayer situations? I suppose maybe they did it for security and control so they are intercepting all data on battle.net servers. That makes a bit more sense I could see.

If the game could run singleplayer without any or much server interaction, then that would mean the server code is in the client. Wouldn't take long before private servers started to pop up, and offline gameplay hacks.

If they wanted to save some network bytes, sure, they could give the client more control. But then they have 2 modes to test and support, instead of having 1 solution for any number of players.

why not just read it off the network layer

1. WinPcap must be installed.
2. Sniffing should start before joining a game, otherwise the state is incomplete.
3. Can't tell what UI is visible.
4. Easier to read game assets from memory than opening the CASC file system.
5. Network latency might be an issue (some desync should be allowed by client/server).

Also, I already had my framework before attempting this So if anything, it would just be a way to increase performance by skipping some memory reads. But this I've managed to optimize quite a bit since.

[Kace36]

Thanks for the reply. That all makes sense. It sort of confirms the suspicion I mentioned earlier that if that's what they were doing it was for various security reasons, keeping the game from being hacked as easily.

It just seems extremely odd to send all the player/world data over the wire to the server (even though I realize it's not all "that much"). However, I can also definitely see how it applies to the security and blocking the ability to more easily hack (or setup private servers like you mentioned). I just really wouldn't have guessed that's how they were doing it; but I guess with the proliferation of online play in recent years the game architecture has shifted considerably to this type of design in order to deter hacks, unlicensed play, or setting up private servers. Interesting. I like your code btw, very nice work. Clean and elegant stuff.

[maper]

When the game is accessing to pointers, if they really were encrypted, the game would instantly crash because it would try to read at a random place.
Usually the pointer that you get is from a pointer that doesn't change.
Any pointers that change will ALWAYS have somewhere in their traces a pointer that never changes..

It is possible to wrap the stored pointer in a class that implements the encryption and decryption in its accessors - so yes, they are really encrypted.

These changes lead me to believe they are leaning more towards a D3 xpac then D4 why would these memory changes be needed for a game they are planning to making content for?

These changes aren't indicative of anything. They are just porting over the same protection they have in other games.

[notnairda]

It is possible to wrap the stored pointer in a class that implements the encryption and decryption in its accessors - so yes, they are really encrypted.

Sure it's possible to wrap them. So what? You just have to access them when they are being decrypted. It makes it harder, but not raping the THud, or anything. It can't be encrypted the whole time, it's just impossible. Why? Because the game would just crash, as I said.
There is always at least one time when the address is right. They can't stay encrypted the whole time.

About the class you mentioned, again. Well, yea, that could be true, if your HP, damage, and actually whatever was visible to a player with THud were not visible to a player without it. THud just makes the default hud more sexy, but you can see all the info (apart from EHP and shit like that, but that's only math that you can still grab). The entire value can be encrypted, but it doesn't change anything, a string is being printed at some point and that's what makes you able to grab it (had to get decrypted for that moment).

The only actual pain in the ass is no decent debugger, and without an internal cheat/gui etc it makes things harder, because you are restricted to external.

Anyway, I don't think this is a right place to "argue". I've already sent a PM to KJ, awaiting his answer. THud is far from being rekt, you have my sword on it.

[maper]

Sure it's possible to wrap them. So what? You just have to access them when they are being decrypted. It makes it harder, but not raping the THud, or anything. It can't be encrypted the whole time, it's just impossible. Why? Because the game would just crash, as I said.
There is always at least one time when the address is right. They can't stay encrypted the whole time.

About the class you mentioned, again. Well, yea, that could be true, if your HP, damage, and actually whatever was visible to a player with THud were not visible to a player without it. THud just makes the default hud more sexy, but you can see all the info (apart from EHP and shit like that, but that's only math that you can still grab). The entire value can be encrypted, but it doesn't change anything, a string is being printed at some point and that's what makes you able to grab it (had to get decrypted for that moment).

I think the confusion here is that you are assuming it will be decrypted in-place, which it is not. The decryption takes place in a temporary stack variable, so you either have to hook the point in the game code (therefore making memory modifications) where the decrypted value will be used in order to reliably use that stack variable, or you have to decrypt the value yourself when you read it.