exmap: Maphack, Packet Logger, etc.

[Fire7D]

Can u do, packets are sending to the other device, and other device read these, and we can see map on this other device, not in game?

[harrisonhess]

i just got banned without any previous warning, well rip i guess. There is any way to appeal for a unban? since i havent got the cheater warning before.

[babadu]

i just got banned without any previous warning, well rip i guess. There is any way to appeal for a unban? since i havent got the cheater warning before.

Same, idk how to appeal..

[enaf3n]

I think exmap could be a reason because the game can detect that you have immediately a full cleared (mini)-map instead of playing about one minute on this area. Only a thought.

There were much easier ways to detect this. It was only a matter of time, unfortunately, as it is pretty difficult to completely hide an attached debugger.

Can u do, packets are sending to the other device, and other device read these, and we can see map on this other device, not in game?

I'm already working on a much better anti-detection. I had hoped I would be able to roll it out before this got banned, but unfortunately it's not ready yet.

[henrymiller]

There were much easier ways to detect this. It was only a matter of time, unfortunately, as it is pretty difficult to completely hide an attached debugger.

Are you sure they're banning purely on a debugger being attached? Doesn't seem very GGG like, they've always been very precise with their bans. Checking if their internal state has been modified is also trivial for them and catches all map hacks.

I'm already working on a much better anti-detection. I had hoped I would be able to roll it out before this got banned, but unfortunately it's not ready yet.

Honestly, as long as you modify game-state they will catch it again. Only safe thing to do imo is to be completely external, just reading memory and rendering an overlay.

[enaf3n]

Honestly, as long as you modify game-state they will catch it again. Only safe thing to do imo is to be completely external, just reading memory and rendering an overlay.

You mean like PoeHUD?

You're right that they could be detecting it based on internal state of the minimap. That would detect all maphacks. But it's also not very elegant - it requires them to track extra state. Has the player been on the map long enough to reveal this much? What if the player enables maphack after being on the map for a bit? What if the maphack slowly reveals the map instead of all at once? Do they have the server calculate how much of the map could be revealed at any given time based on a player's movement speed? It is a more complex problem than you think. Conversely, all they had to do to detect that a debugger was present was call IsDebuggerPresent() - or NtQueryInformationProcess() to check for a process debug port in the latest version, since I patched out the BeingDebugged flag in the PEB - and they would not only detect exmap but also detect all the people trying to mess with their game in a debugger. The latter seems like the more likely option to me.

There are tons of ways to detect external processes, the primary one being that you need an open handle to the game to do anything useful, and they can easily walk the handles that are open to their process with absolutely no permissions required. (Their old anti-cheat required administrator privileges to see other administrator processes with open handles, and that may even still be the case, but it is possible to do so with only limited privileges and I am sure they will eventually catch on to that fact.) They can also do things like check gSharedInfo which leaks all kinds of details about other processes that have UIs, or take a screenshot expecting to be able to see the POE frame buffer contents on some portion of the screen but flag when it is being obscured consistently by something.

[henrymiller]

There are tons of ways to detect external processes, the primary one being that you need an open handle to the game to do anything useful, and they can easily walk the handles that are open to their process with absolutely no permissions required. (Their old anti-cheat required administrator privileges to see other administrator processes with open handles, and that may even still be the case, but it is possible to do so with only limited privileges and I am sure they will eventually catch on to that fact.) They can also do things like check gSharedInfo which leaks all kinds of details about other processes that have UIs, or take a screenshot expecting to be able to see the POE frame buffer contents on some portion of the screen but flag when it is being obscured consistently by something.

The problem with isDebuggerPresent() are false positives. Just because there's a debugger present, doesn't mean it's exmap. That's why I was saying GGG has always been very precice with bans. HUD used to have a maphack feature. GGG explicitly only banned people maphacking, not people using the item alterter. Maybe they were too lazy to do something about people only reading memory. Maybe they did it on purpose.

I've debugged PoE before, to find command-line switches for language, to play on garena in english when it was first released. I'm not sure you want to treat that as the same severity as maphacking.

Having a handle to the process open it by itself not be a problem, there's plenty of legitimate reasons to have a handle to a process open. I haven't reversed what exactly GGG is doing, but I'd be seriously surprised if it's any different from all the other ACs that take a look what handles are open. And now you have exactly the same problem space as malware hiding from anti-virus. Plenty of solutions for that.

Yeah, attacking the UI is an option too I guess, don't know anything about it though, so not going to comment.

[deomexuathe]

The problem with isDebuggerPresent() are false positives. Just because there's a debugger present, doesn't mean it's exmap. That's why I was saying GGG has always been very precice with bans. HUD used to have a maphack feature. GGG explicitly only banned people maphacking, not people using the item alterter. Maybe they were too lazy to do something about people only reading memory. Maybe they did it on purpose.

Having a handle to the process open it by itself not be a problem, there's plenty of legitimate reasons to have a handle to a process open. I haven't reversed what exactly GGG is doing, but I'd be seriously surprised if it's any different from all the other ACs that take a look what handles are open. And now you have exactly the same problem space as malware hiding from anti-virus. Plenty of solutions for that.

Yeah, attacking the UI is an option too I guess, don't know anything about it though, so not going to comment.

you know, they are here and they can read. "they were too lazy" can lead them to not lazy anymore lol

[henrymiller]

you know, they are here and they can read. "they were too lazy" can lead them to not lazy anymore lol

I don't mind, I'm just here for the tech, I don't give too many shit about the actual maphacking.

[enaf3n]

The problem with isDebuggerPresent() are false positives. Just because there's a debugger present, doesn't mean it's exmap. That's why I was saying GGG has always been very precice with bans. HUD used to have a maphack feature. GGG explicitly only banned people maphacking, not people using the item alterter. Maybe they were too lazy to do something about people only reading memory. Maybe they did it on purpose.

I've debugged PoE before, to find command-line switches for language, to play on garena in english when it was first released. I'm not sure you want to treat that as the same severity as maphacking.

Having a handle to the process open it by itself not be a problem, there's plenty of legitimate reasons to have a handle to a process open. I haven't reversed what exactly GGG is doing, but I'd be seriously surprised if it's any different from all the other ACs that take a look what handles are open. And now you have exactly the same problem space as malware hiding from anti-virus. Plenty of solutions for that.

Yeah, attacking the UI is an option too I guess, don't know anything about it though, so not going to comment.

There are very few legitimate reasons to have a debugger attached to the game, though. Companies like Discord, Razer, or other makers of in-game overlays may need to attach a debugger to fix their software, but if that's the case they should not be actually playing the game like a normal player so even if their account was banned it would be irrelevant - not to mention that in those circumstances, the game probably wouldn't even be played long enough to receive an anti-cheat request. I'm not saying they treat every debugger user as an exmap user - you're right that it wouldn't be very precise to do so - but simply that it would be totally reasonable to ban anyone that attached one.

What you're saying about PoeHUD isn't true. I was actively developing at the time and had a really solid understanding of the anti-cheat back then. They banned for maphacks, which included all of the public ones because they were all patching the same location in the game. They also banned strictly for PoeHUD for at least one major ban wave by walking the open process handles and using the EXE name or opening the PoeHUD executable on disk to search for PDB strings in the PE header. That is why PoeHUD started using that scrambler as part of their build steps. There are indeed a lot of legitimate reasons to have a handle to the process open, but when the game can reach out and touch those process's backing executables on disk, it's a lot more difficult to hide the fact that it's not legitimate software. It's a similar story when people think that injecting a DLL into notepad.exe or something and then using that "legitimate" process to do the dirty work is going to hide them. There's no reason notepad.exe would ever have an open handle to the game. If they were to use a process that would be expected to have an open handle (say, csrss.exe), generally the permissions granted to the legitimate handle don't quite line up with the ones needed by the malicious handle, so that's another detection vector.

For the record, I'm not trying to be contentious or anything. I really like talking about this stuff which is why I'm spilling walls of text. I'm mainly just trying to dispel the myth that external processes are inherently more safe than internal code, because in my experience that's really not the case.

[henrymiller]

There are very few legitimate reasons to have a debugger attached to the game, though. Companies like Discord, Razer, or other makers of in-game overlays may need to attach a debugger to fix their software, but if that's the case they should not be actually playing the game like a normal player so even if their account was banned it would be irrelevant - not to mention that in those circumstances, the game probably wouldn't even be played long enough to receive an anti-cheat request. I'm not saying they treat every debugger user as an exmap user - you're right that it wouldn't be very precise to do so - but simply that it would be totally reasonable to ban anyone that attached one.

Let's agree to disagree that it would be totally reasonable.

What you're saying about PoeHUD isn't true. I was actively developing at the time and had a really solid understanding of the anti-cheat back then. They banned for maphacks, which included all of the public ones because they were all patching the same location in the game. They also banned strictly for PoeHUD for at least one major ban wave by walking the open process handles and using the EXE name or opening the PoeHUD executable on disk to search for PDB strings in the PE header. That is why PoeHUD started using that scrambler as part of their build steps.

Ah I didn't know they were walking open handles before, makes sense though. But the scrambler is extremely basic. And this is the exact reason I said you're now in *exactly* the same problem space as malware trying to escape signature scans from Anti Virus. And about that, I happen to know a thing or two. PoeHUD doesn't even try to hide, in that sense. There's plenty of things you can do, including the common anti debugging stuff. You can wipe your own PE header in memory, you can (as I'm certain you're familiar with ;-)) do self debugging, mark all pages as guard pages and only decrypt them on the fly, you could even SINGLE_STEP decrypt and reencrypt where performance doesn't matter. If you have the source as in PoEHUD's case: Insert Junkcode etc. Automatically obfuscate the control flow etc.

There are indeed a lot of legitimate reasons to have a handle to the process open, but when the game can reach out and touch those process's backing executables on disk, it's a lot more difficult to hide the fact that it's not legitimate software. It's a similar story when people think that injecting a DLL into notepad.exe or something and then using that "legitimate" process to do the dirty work is going to hide them. There's no reason notepad.exe would ever have an open handle to the game. If they were to use a process that would be expected to have an open handle (say, csrss.exe), generally the permissions granted to the legitimate handle don't quite line up with the ones needed by the malicious handle, so that's another detection vector.

Injecting into nodepad.exe is obviously a dumb idea. There should be *zero* reason for any handles alone to be a problem though, I can come up with dozens of reasons why a random process has a handle on your process. Hex editors with an "open memory" function for example, that probably want VM_READ, VM_WRITE and QUERY_INFORMATION. You simply can not blindly ban for that.

I think if the game reaches out and analyzes your memory in return that's way more scary than it looking at the disc. Very easy techniques around that, process hollowing or process doppelgangig. Worst case, go ring 0 and simply don't have a handle at all. (Side note: As an outsider I find it curious that nobody in the cheating space goes into ring -2 in response to ACs also going ring 0)

For the record, I'm not trying to be contentious or anything. I really like talking about this stuff which is why I'm spilling walls of text. I'm mainly just trying to dispel the myth that external processes are inherently more safe than internal code, because in my experience that's really not the case.

Oh, I find this to be a very interesting discussion.

[enaf3n]

Ah I didn't know they were walking open handles before, makes sense though. But the scrambler is extremely basic. And this is the exact reason I said you're now in *exactly* the same problem space as malware trying to escape signature scans from Anti Virus. And about that, I happen to know a thing or two. PoeHUD doesn't even try to hide, in that sense. There's plenty of things you can do, including the common anti debugging stuff. You can wipe your own PE header in memory, you can (as I'm certain you're familiar with ;-)) do self debugging, mark all pages as guard pages and only decrypt them on the fly, you could even SINGLE_STEP decrypt and reencrypt where performance doesn't matter. If you have the source as in PoEHUD's case: Insert Junkcode etc. Automatically obfuscate the control flow etc.

Everything you say here is totally valid. Those are all things that could be done to make it harder to detect the external process. But, inevitably, there would still be artifacts. It's just an endless cat and mouse game in ring 3 where one side can't hope to outsmart the other for very long.

Injecting into nodepad.exe is obviously a dumb idea. There should be *zero* reason for any handles alone to be a problem though, I can come up with dozens of reasons why a random process has a handle on your process. Hex editors with an "open memory" function for example, that probably want VM_READ, VM_WRITE and QUERY_INFORMATION. You simply can not blindly ban for that.

A legitimate user should not be hex editing a running game. There are no legitimate use cases for a player to have any kind of invasive software with an open handle to the game. Other game companies already ban people for this and so do third-party anti-cheat platforms.

I think if the game reaches out and analyzes your memory in return that's way more scary than it looking at the disc. Very easy techniques around that, process hollowing or process doppelgangig. Worst case, go ring 0 and simply don't have a handle at all. (Side note: As an outsider I find it curious that nobody in the cheating space goes into ring -2 in response to ACs also going ring 0)

True, but with process hollowing you again run into the issue of whether or not that process should be able to legitimately have an open handle with those permissions to begin with. I agree though that going ring 0 makes the issues of reading memory from the game totally go away. Just a simple KeStackAttachProcess() and you're golden. But then there are other issues to contend with - hiding the presence of your driver from various kernel lists, playing nice with PG (assuming you don't want to rootkit your users' machines), not bug-checking the machine, loading the driver without a proper cert (since test signing mode can look suspicious) and without exploits like the Capcom driver being detected, etc. The reality is that most people who make hacks really are not knowledgeable about the way the operating system works at the kernel level, and that can really complicate developing hacks at that level. But I won't disagree that it could certainly give a huge leg-up on a ring 3 anti-cheat. Done right, it could probably even be undetectable. The problem is I've never seen it done right.

To add to that, hiding a hack in SMRAM (which I assume is what you're suggesting when you mentioned ring -2) would be interesting. I don't have much more than tangential experience with that level of depth but from what I understand it would be extremely complicated to support broadly on various hardware. It would be great for a private hack that you gave to a few people, but pretty infeasible for a public hack. Trying to load custom SMM code is no joke and would probably require users to flash your custom firmware and pray that it was stable. Unless of course you're sitting on an exploit that allows you to load SMM code from the OS, in which case I highly recommend you don't waste that on hacks and sell it to a government somewhere instead.

Personally, I think the smartest thing to do to evade detection is running a custom type 2 hypervisor. It has its own problems, of course. There are a lot of ways to detect that you're in a virtual machine, even from ring 3, and they can be pretty difficult to hide if you don't know what you're doing. You also have to develop a different code base for each processor manufacturer (Intel, AMD). On top of that, you still need to run a driver, which could be susceptible to what I was talking about above. But the beauty is SLAT: you can literally change game code right in the game's process and have it be completely invisible to the game and to the operating system. You can also use it to solve many of the ring 0 snags I mentioned.

[henrymiller]

I don't have much more than tangential experience with that level of depth but from what I understand it would be extremely complicated to support broadly on various hardware.

Not exactly an expert either, but from my understanding broad hardware shouldn't be a problem anymore, should be able to develop that as an UEFI runtime driver an relatively easy to install as long as your motherboard allows disabling secure boot or adding your own cert.

Edit: Some quick googling sais you should indeed be able to launch an EFI shell and load option ROMs from a USB stick. No exploits needed.

A legitimate user should not be hex editing a running game. There are no legitimate use cases for a player to have any kind of invasive software with an open handle to the game. Other game companies already ban people for this and so do third-party anti-cheat platforms.

I bet you there are garbage anti virus outthere that open handles and you don't want to try and whitelist them. I've never heard of any AC staight up banning for any process opening a handle without signature checking the "offending" process first. Which ACs do that?

Another scenario would be Ring3 rootkits. You don't want to ban someone because they can't keep their machine clean.

[enaf3n]

Not exactly an expert either, but from my understanding broad hardware shouldn't be a problem anymore, should be able to develop that as an UEFI runtime driver an relatively easy to install as long as your motherboard allows disabling secure boot or adding your own cert.

Edit: Some quick googling sais you should indeed be able to launch an EFI shell and load option ROMs from a USB stick. No exploits needed.

Sounds like an interesting avenue to use, then. But well beyond most people that make hacks.

I bet you there are garbage anti virus outthere that open handles and you don't want to try and whitelist them. I've never heard of any AC staight up banning for any process opening a handle without signature checking the "offending" process first. Which ACs do that?

Another scenario would be Ring3 rootkits. You don't want to ban someone because they can't keep their machine clean.

I didn't mean that they banned for any open handles. Just ones that are tied to invasive software. They don't have to whitelist any software, it's easy to pick out anomalies across a playerbase if you just send back metadata about every process that has an open handle to the game. Also, some game companies like Blizzard don't let you actually sign into a game if it detects certain anomalies, e.g. user-mode rootkits. Though it's mostly to avoid account takeover due to stolen credentials.

[naut333]

If your main purpose of this was to analyze packets could you not just run wireshark in a sandbox?
I am no expert, from what I've read of your work you are miles ahead of me.. but to me it appears you are making it harder then it needs to be for what you are trying to accomplish.
Accompanied with a simple automation script to capture certain lines of code at times of your choice for analysis and you should be good to go.. ie start record capture, do your ingame event you want to watch, end capture, rinse and repeat that process whatever number of times and then do a comparison of the captures to see what packets repeat themselves.
I say to write a script for this as it will decrease the time it takes to start and stop the process which will largely decrease the amount of code you need to decipher.
I used to do something similar to this with cheatengine for locking ammo, health etc, different process here but same idea still applies.