How hard for thud to use not methods 2 bypass?

[godfeast]

I won’t say I fully understand everything, but been lurking in some bot forums with currently active bots for d3.

The point was made that they are using vm to hook into memory before the encryption process begins b

Can thud do this? Do you guys have the experience to make it happen and the willingness to do so?

I’m asking to get a heads up because, quite literally, I won’t play d3 without thud as the game ui is just pathetically bad.

I don’t enjoy d3 without it, so if your done, I’m uninstalling the game.

[Kace36]

I think KJ has mentioned he will have parts of it working soon. He and Enigma have been able to get some of it going again from what I've read.

FYI there isn't any encryption. Blizzard has apparently done something with the memory structures. You, see, the reason Enigma, and then KJ, were able to put this tool together is b/c they know what pointer structures in memory equal what particular attributes (i.e. if they know where your player's data is for your XP, total xp, xp required for next level, etc... they can simply read that from that memory location and then put a graphic overaly on the experience bar at the bottom of the screen). It seems what has happened is Blizzard has markedly changed the way the memory structures work now, they appear to be dynamically generated (or something similar), much, much harder to find the correct data.

The other thing is that bots, while some of the core technology needed to do either one is the same, are different than a "HUD" tool. A bot doesn't need to read nearly as much player data. It mainly needs to input keyboard and mouse commands. It doesn't even really need to know what skills you have technically. It just needs a "profile" to hit the correct keyboard/mouse commands that correspond to the keys for activating skills (i.e. 1, 2, 3, 4 on the action bar, etc...). Which is why if you tried to use a Witch Doctor Helltooth build profile on a Demon Hunter Shadow build profile you would get all kinds of weird stuff happening b/c the wrong keys are being pressed by the bot.

Yes, it needs to be able to read monster data, scan the "map area" within a certain radius to find monsters, read affix data to be able to avoid affixes, etc... and needs to do some of those same things you would need to do with a HUD. I'm just saying it doesn't need to read nearly the same level of player and world data to do what it does.

Disclaimer: I have not looked at this code. I've only poked around with Enigma's earlier MapHack, the minimal version he released after the THUD breakage, using dotPeek in VS2017, and that was very, very briefly. I'm gleening this information from a long career in computer science and software development.

[R3peat]

I think KJ has mentioned he will have parts of it working soon. He and Enigma have been able to get some of it going again from what I've read.

FYI there isn't any encryption. Blizzard has apparently done something with the memory structures. You, see, the reason Enigma, and then KJ, were able to put this tool together is b/c they know what pointer structures in memory equal what particular attributes (i.e. if they know where your player's data is for your XP, total xp, xp required for next level, etc... they can simply read that from that memory location and then put a graphic overaly on the experience bar at the bottom of the screen). It seems what has happened is Blizzard has markedly changed the way the memory structures work now, they appear to be dynamically generated (or something similar), much, much harder to find the correct data.

The other thing is that bots, while some of the core technology needed to do either one is the same, are different than a "HUD" tool. A bot doesn't need to read nearly as much player data. It mainly needs to input keyboard and mouse commands. It doesn't even really need to know what skills you have technically. It just needs a "profile" to hit the correct keyboard/mouse commands that correspond to the keys for activating skills (i.e. 1, 2, 3, 4 on the action bar, etc...). Which is why if you tried to use a Witch Doctor Helltooth build profile on a Demon Hunter Shadow build profile you would get all kinds of weird stuff happening b/c the wrong keys are being pressed by the bot.

Yes, it needs to be able to read monster data, scan the "map area" within a certain radius to find monsters, read affix data to be able to avoid affixes, etc... and needs to do some of those same things you would need to do with a HUD. I'm just saying it doesn't need to read nearly the same level of player and world data to do what it does.

Disclaimer: I have not looked at this code. I've only poked around with Enigma's earlier MapHack, the minimal version he released after the THUD breakage, using dotPeek in VS2017, and that was very, very briefly. I'm gleening this information from a long career in computer science and software development.

Im sry but u got no clue what ya talking about

[Kace36]

Im sry but u got no clue what ya talking about

Well, sorry, but I'm not sure what you are talking about. Do you think you could be slightly more clear? No clue? How exactly? I find that more than a little curious, and to be honest it comes off as combative for the sake of being combative. Just saying :/. If you do believe you know what you are talking about then why don't you attempt to correct or refute any statement you believe to be false? Exactly what do you believe is wrong? I mean seriously. At least say something. You find my post uncredible, but, "Im sry but u got no clue what ya talking about", is credible?

[enigma32]

Well, sorry, but I'm not sure what you are talking about. Do you think you could be slightly more clear? No clue? How exactly? I find that more than a little curious, and to be honest it comes off as combative for the sake of being combative. Just saying :/. If you do believe you know what you are talking about then why don't you attempt to correct or refute any statement you believe to be false? Exactly what do you believe is wrong? I mean seriously. At least say something. You find my post uncredible, but, "Im sry but u got no clue what ya talking about", is credible?

Not trying to be an ass, but this section is pretty much nonsense

FYI there isn't any encryption. Blizzard has apparently done something with the memory structures. You, see, the reason Enigma, and then KJ, were able to put this tool together is b/c they know what pointer structures in memory equal what particular attributes (i.e. if they know where your player's data is for your XP, total xp, xp required for next level, etc... they can simply read that from that memory location and then put a graphic overaly on the experience bar at the bottom of the screen). It seems what has happened is Blizzard has markedly changed the way the memory structures work now, they appear to be dynamically generated (or something similar), much, much harder to find the correct data.

There is encryption. The structures has not changed, at least not more than a typical patch. A pointer structure is not a thing, except the structure of a pointer, which makes it just a pointer. If we know where attributes are, then we can show it on an overlay, well duh. Some of the links (pointers) between structures changed (encrypted). Memory structures are not more dynamically generated than before. They're dynamically allocated but that's just how runtime allocation works.

[obsolete1102]

Not trying to be an ass, but this section is pretty much nonsense There is encryption. The structures has not changed, at least not more than a typical patch. A pointer structure is not a thing, except the structure of a pointer, which makes it just a pointer. If we know where attributes are, then we can show it on an overlay, well duh. Some of the links (pointers) between structures changed (encrypted). Memory structures are not more dynamically generated than before. They're dynamically allocated but that's just how runtime allocation works.

Insert obligatory "OHHHHHHHHH" -- anyway, thanks for what you do enigma, keep it up.

[Kace36]

Not trying to be an ass, but this section is pretty much nonsense There is encryption. The structures has not changed, at least not more than a typical patch. A pointer structure is not a thing, except the structure of a pointer, which makes it just a pointer. If we know where attributes are, then we can show it on an overlay, well duh. Some of the links (pointers) between structures changed (encrypted). Memory structures are not more dynamically generated than before. They're dynamically allocated but that's just how runtime allocation works.

I appreciate that you mention you're not trying to be an ass. I honestly do. Thank you. However, let's not be too pedantic about this. The pointer information was for non-programmers. We don't need to talk about the semantics of a pointer versus a "pointer structure". I didn't mean it in some weird struct object context; it's just a lay person way to encapsulate the idea b/c most people don't know what "pointers" are. But that is where you get the data (obvious to us, not to others).

As to the encryption part, I did plainly make a disclaimer at the bottom of my post (in bold). Plus I got that particular bit, btw, from Enigma's post:

Wrong. I'm not decrypting anything....<snipped>

Link to quote (Memory patch is up, RIP D3)

If we apply some simple propositional, symbolic logic, then there is a fallacy created by the disjunction from the two posts.

Proposition 1: The code is not encrypted (per the quote, "I'm not decrypting anything").
Proposition 2: The code is encrypted. (per the comments above).

Proposition 1 and 2 cannot both be true.
Conclusion: A fallacy exists in these premises.

If the code is encrypted but the data you need in order to read world/player data from memory is not encrypted, or has already been decrypted for you, then the whole point about encryption is irrelevant as it relates to the tool usage and my comments; and we shouldn't be harping on it. Unless you mean obfuscated encryption, as virtually all modern codebases use to some degree; hardly encryption though.

Otherwise the code is actually encrypted, which requires you to decrypt it, in which case the other quote above is false. If the relevant code were truly encrypted, you would have to decrypt it, in some way, at some point. That's why I'm saying this just seems silly and pedantic, b/c at best it's irrelevant to the topic.

The only way to make those propositions result in anything but a false conclusion is with the following:

A Compound Proposition: The code is encrypted, but I do not need to decrypt anything to access the data we are referring to.
Conclusion: The premise could be valid. (However please realize this then means that the entire argument on encryption, in the context of these comments, had no purpose).

---

Anyway, guys, my point was most of the people reading this are lay people, not programmers or computer scientists. They don't know what obfuscation is (it's not encryption either). They don't know what pointers are, or how memory works for that matter. I don't claim to know details of the Diablo 3 architecture, I have made that point already. I haven't gone so far as to try poking around or reverse engineering even one thing. I looked at your first release of MapHack code, 5-10 minutes maybe (?).

However, that is how you must do it, regardless of encryption, regardless of how they arrange the world data in memory now. My point was to describe to the person I was responding to how the overlay works, how the tool works, and, most importantly (what the real topic was about), why it's different than a bot, in a very broad sense. And that is how it works. It's the only way it can work. The same goes for the bots, nothing I said about them was nonsense. They do need to read some world data, obviously, but much less than you need for something like THUD - mainly it's just pressing buttons for the keyboard/mouse. Nothing was inaccurate about it. I was not trying to describe pointers, encryption, or obfuscation.

What I did mean, though, about "dynamically generated" (again, lay people, most of the people, even ones who think they know what their doing, are not scientists or programmers and don't *really* understand lots of it) is that they have either significantly changed the structure of the memory (which are just pointers, whether a struct, a class, those all end up as a pointer on the stack or heap either way), which holds player data, or they are moving it around so that you cannot easily find it. I mean... come on now. They may have moved the pointers from the stack (temporary lifetime objects usually) to the heap (longer lifetime objects). They may be deallocating the memory, or modifying it to move the world/player data, either from stack to heap, or simply moving some of that data to a new address. I don't know. That wasn't the point though.

I do appreciate the work you put into a fine tool, Enigma, I just don't appreciate the other guy calling me out for something he likely has no idea about it, and if he does, he didn't bother to describe the issues. It felt hostile. At least he could explain himself. But even with your quite respectable comment I still go back to my earlier symbolic logic example b/c it just seems like semantics about "pointer structure" and bit of irrelevant stuff about encryption. Just saying. Anyway.

Edit: I do not mean this to be combative or offensive in any way. I really don't. To anyone. So please don't take it that way. Please. I'm just defending my post and giving reasons why I find inconsistencies and a few issues. I did say I don't know the D3 architecture, but I have developed games (in the dark ages, yes, lol, but still ), and I don't [typically] post unless I'm pretty dang confident. I just don't find anything wrong with it. The worst part though is I see it as a disservice to the community or lay people who will take it the wrong way over largely semantic issues or b/c someone interpreted aspects incorrectly. Thank you for reading.

[napouser2]

look situation is much more complicated than a simple discussion with logical falicies like its encrypted or not encrypted

some things are now encrypted some things are not

portions of the map are still accesible wich makes the job of enigma easier somewhat almost just as before therefore allows him to make a maphack

same applies to rosbot since they have easy access to map data they can map the map (?!?) with points of interest and with a simple (sort of) pathing algorithm to tell the bot repeat to go on each point until u run out of points or until u find an exit

+ the fact that devs of rosbot get paid

those things allowed the bot to be able to work
now as far as skill yes it is somewhat easier since the bot can blindly press buttons assuming u set the correct skills in correct slots altho this does not mean u can make a bot with just a map hack and the algorithm

however the thud is a different deal
we talking about 4328990 different indicators and numbers about game states quests bounties items icons exp cooldowns debuffs and the need to update all those realtime wich means to read all portions of memory even the non map data wich are mostly encrypted on the fly

like for instance how the hell the thud knows if u just killed the boss and needs to reset the rift progression counter?


as far as the original poster the vmware is not used to read the memory or anything but its used by most rosbot botters as a method to bot and using the pc at the same time

the issue with rosbot is that the devs dont want to inject in memory the actions such as keyboard and mouse but use ur actual keyboard and mouse
this is done supposedly to add an extra form of security so u dont get banned (as if that would save all those thousands that got banned already)

therefore if the program needs ur mouse and keyboard ur computer is basically locked


now the idea of having a vmware to play diablo and the bot used on host so diablo does not discover the bot that running in memory is just stupid
takes years to develop there are 1000 different problems with it like lags and incombatibilities and finally u can fix the problem with simply running bot in admin mode and d3 in stadart mode so it wont have access to admin memory


hope those help
have in mind that the situation and the technical aspects of this is much more complicated and will most likely become even more complicated in the future

[enigma32]

Thank you for reading.

You've now earned my respect, but for D3 you only have some clue, which you state yourself Explaining in simple terms is fine, but I don't like when simple turns into inaccurate I like facts.


Let me sort this out with being encrypted or not, in layman's terms.

The executable is packed. This may or may not be encrypted, but it does not matter. In order for the program to execute, it must unpack itself. Think of this as a self-extracting zip archive. This unpacked version is accessible using different methods and tools. So far so good.

Now, lets look at the program data living in memory while the program runs. Imagine your hard drive, filled with files, directories, shortcuts. Your data is organized, grouped, and you can follow different paths to move up and down a hierarchy and take shortcuts. Now imagine some shortcuts are corrupted. They still exist, but they no longer point to anything that makes sense. They might be pointing to an address that doesn't even exist on the disk. Imagine directories and files without a parent folder, how would you navigate to these? This is essentially what Blizzard has done: corrupted (encrypted) some pointers that makes pieces of data fit together (files and directories forming a hierarchy and paths). The program (D3) knows exactly where it has "corrupted" these, each in a unique way. It also knows fully well how to fix them, which it does whenever it needs to follow one of these paths. But it does it in a way where it's not possible to read externally with any form of accuracy.

So what's this vm and hooking into memory mentioned in OP? Short answer: injection (I'm presuming) and not something THUD will do. Longer answer? Injection, making a program run code inside another one, patching it to do things differently, such as putting the pointers aside and exposing them before the program corrupts (encrypts) them, or similar during the process of fixing them.

Why does Enigma.D3(MapHack) work? Lets go back to the hard drive example. At a known location on the disk, depending on the type of file system, lies a table/index of all the files, directories and other type of entries. A similar table exists in D3 memory as well, keeping track of all allocated chunks of memory, their adresses and sizes. If you know enough about the data you expect to find, you can test these chunks until you find a match. Voila, no path needed, you found your data (file) anyway. The data itself is not encrypted, the path leading up to it is (it might be).
Is the path to this table encrypted? No. Could they do that? Yes. Can it still be found? Yes, I've got some ideas at least.

[FurryBeast]

Let me sort this out

Kudos Sir!

I think it was Einstein that said something in lines of "If you cannot explain something clearly and in simple language, you do not understand the matter". I love seeing things written in a way that I could read to 10 YO kid knowing he would understand the subject.

[KillerJohn]

alpha release: https://www.ownedcore.com/forums/dia...ml#post3838594

[johnbl]

@enigma32 sorry if this sounds too noobish, but could you actually use injection to figure out the exact algorithm that D3 is using to decrypt the pointers/find the correct addresses and then use that algorithm on TH (or any other program) to read the memory without injection?

[enigma32]

@enigma32 sorry if this sounds too noobish, but could you actually use injection to figure out the exact algorithm that D3 is using to decrypt the pointers/find the correct addresses and then use that algorithm on TH (or any other program) to read the memory without injection?

Injecting won't help understanding the algorithm. Running with debugger attached could, but it sounds like this is complicated since 2.6 patch. Otherwise it's looking at the assembly code and trying to figure out the flow. If the algorithm is found, then sure, could probably decrypt externally.

[KillerJohn]

Such a reverse engineering doesn't make too much sense, because they can easily switch the encryption algorithm with every release. In fact they can easily generate insanely complex algorithms for pointer access.

[R3peat]

@enigma32 sorry if this sounds too noobish, but could you actually use injection to figure out the exact algorithm that D3 is using to decrypt the pointers/find the correct addresses and then use that algorithm on TH (or any other program) to read the memory without injection?

I talked about decrypting pointers with Enigma like 1 week after the patch and i also found code which they use to decrypt specific pointers. The only problem is that they use dynamic values which they grab from somewhere. Those things cant be proper reversed without being able to attach a debugger which isnt possible atm