Capcom took down Cheathappens MHW trainer

Post your topics and discussions here that you can't find a good section for.
User avatar
SunBeam
Administration
Administration
Posts: 2442
Joined: Sun Feb 04, 2018 7:16 pm
Reputation: 959

Re: Capcom took down Cheathappens MHW trainer

Post by SunBeam » Sun Dec 09, 2018 3:45 pm

@CaliberCH: Here's my last bit of information to you and these games: https://www.forbes.com/sites/olliebarde ... 135b3f2ae2. Dark Souls Remastered == Namco; has integrity checks; Monster Hunter World == Capcom; has the same logic in the integrity checks. Gee, tough cookie; I wonder if this "cross-licensing" was applied to their anti-cheat protection as well.. From the looks of it, DSR and MHW have the same exact type of shit scanning executable memory.

User avatar
Empress_Ravenna
Expert Cheater
Expert Cheater
Posts: 161
Joined: Mon Oct 09, 2017 11:42 pm
Reputation: 11

Re: Capcom took down Cheathappens MHW trainer

Post by Empress_Ravenna » Sun Dec 09, 2018 10:33 pm

Accounts been hacked.. just gotta repost this on all my threads till i can figure out how to erase my last days worth of hacked messages!!
Last edited by Empress_Ravenna on Mon Dec 10, 2018 10:31 am, edited 1 time in total.

predprey
Expert Cheater
Expert Cheater
Posts: 110
Joined: Thu Mar 02, 2017 8:46 pm
Reputation: 66

Re: Capcom took down Cheathappens MHW trainer

Post by predprey » Mon Dec 10, 2018 8:51 am

So from what I read it seems there are 2 main school of thought for defeating the integrity scanners:
1. Interrupting code execution at desired hooking point and redirecting to a copy (not 100% exact, e.g. hard coded jump addresses) of the code page where modifications can be made freely.
2. Having each scanner return the correct CRC.

For the first option, it branches into two ways for redirection of the RIP instruction pointer.
A. Stealthedit plugin which Squall's table uses.
B. VEH Detour a la Fling
I'm guessing the difference between the two is just the exception handler they use, the former using the Windows default Structured exception handler the latter using the newer vectored exception handler? But the principle behind both is to hook the specific int3 interrupt instruction and make the original code non-executable. This triggers a page fault when the code page is executed, the plugin/trainer then redirects the instruction pointer to a copy of the original code where modifications can be made without being checked for integrity.

This leads us to a 3rd option which is DBVM Memory Cloaking. The inner workings are explained on GitHub but basically it also makes a copy of the original code. All read/write operations are redirected to the copy while execute operations are done on the original. So I'm guessing the integrity scanners will get redirected the copy of unmodified code while the original executable memory can be modified freely.

The second option is the one Caliber uses I suppose? I'm not sure how it works exactly, I have in mind two possibilities a. modify the code in such a way that there is CRC collision b. modify the integrity checks or associated routines themselves. Given how troublesome and limiting it is to generate a hash collision, I'm guessing it is the latter. I'm guessing the latter is also not easy since the integrity checks are obfuscated behind D's VM? If too many people uses this method, Capcom can easily update the integrity checks again, changing the code signatures etc. so the layman without any reversing knowledge will not be able to find all the integrity scanning code by themselves. Plus, there is always the possibility of one integrity check being left out resulting in a crash/undetermined behaviour. This is similar to issues encountered when defeating D protection, but I digress.

So weighing both options, we will have some slowdowns if we choose the first option. Depending on how frequent a code is executed, the triggering of page faults can lead to negligible or noticeable performance hits. Assuming the developers are reasonable people, they probably only check code that are not frequently accessed so their DRM/anti-cheat will not negatively impact clean playing players. We can then also assume that our page faults should not impact performance much, that is until we back the developers into a corner and they double down on their protection. For more infomation please refer to Injustice 2 Robin Gorilla microstutters. DBVM will also have some slowdowns due to all code having to pass through the additional DBVM layer. If we use the second option, we can expect some unpredictable crashes and behaviour depending on whether we caught all integrity checks and if Capcom updated the checks or added new ones.

Ultimately, I think we should all pray that developers do not force you to grant them ring 0 access to check if you have cheatengine or some memory modification program running in the background in order to play their blockbuster AAA game. Or that they are given the right to charge you for felony in federal court for trying to hack your single player experience because they want to add in a microtransaction economy to their historically single player franchise. For more information please read Devil May Cry 5.

eTheBlack
Fearless Donors
Fearless Donors
Posts: 138
Joined: Fri Mar 10, 2017 10:41 am
Reputation: 21

Re: Capcom took down Cheathappens MHW trainer

Post by eTheBlack » Mon Dec 10, 2018 9:02 am

Empress_Ravenna wrote:
Sun Dec 09, 2018 10:33 pm
hmm... >;D

RUN! MEN HIDE! >;D

Hissss!!!


and anyhow ya interesting Topic this has been but i have other stuff to do now... byes!

Image
What the fuck is wrong with you

User avatar
SunBeam
Administration
Administration
Posts: 2442
Joined: Sun Feb 04, 2018 7:16 pm
Reputation: 959

Re: Capcom took down Cheathappens MHW trainer

Post by SunBeam » Mon Dec 10, 2018 10:13 am

@predprey: A few remarks (feel free to interfere where due):
  • there are also timed/on-trigger checks; same scanners, but this time around "powered" by an in-game event (e.g.: gaining XP from a kil); to submit to the non-grinding alignment, this event would have to happen both not rarely, nor frequently (see Assassin's Creed: Unity); else there's a huge loss in performance, if, for example, they use the crypto markers on a health_read routine
  • most of the reads are done on a table of hashed VAs; good thing the public scripts hit the spot, tipping them off which locations to include in that list
  • there's no additional coding in the CH trainer; pure and blunt re-routing of the readers - so not SEH, not VEH; just JMPs - didn't expect anything else, to be honest; hence my condescending attitude on his pompous preaching (how else would he be able to say "there are 82 scanners" if not going through the tiresome grinding?
  • "If too many people uses this method, Capcom can easily update the integrity checks again, changing the code signatures" - - exactly the logic behind the "I know the scanners location is different" statement; the VA can easily change if they change some compiler settings, not to mention every VMProtected target will use unique VMs with each enveloping action; so, for example, if you start doing some RE on v1.0's VMP and devs decide they forgot some shit, even though game doesn't get updated to v1.1 and is still v1.0, the fact that there's a new .exe will fuck up your analysis; different VMs..
  • the post I referenced in my rant, taking you back to tuts4you, mainly MistHill's explanation, should suffice to work your way around the handlers; sure, might not be digestible for any reader, hence losing patience and blatantly ignoring the whole explanation unless there's some method or source-code to be used (yes, am still referring to Caliber here), but should prove a nice read, at least
@eTheBlack: Shit-posting, that's what's wrong with him/her. PMed me as well stating Caliber stole stuff from his/her "script". No proof though; so I'm sticking to shit-posting.

User avatar
Empress_Ravenna
Expert Cheater
Expert Cheater
Posts: 161
Joined: Mon Oct 09, 2017 11:42 pm
Reputation: 11

Re: Capcom took down Cheathappens MHW trainer

Post by Empress_Ravenna » Mon Dec 10, 2018 10:24 am

Accounts been hacked.. just gotta repost this on all my threads till i can figure out how to erase my last days worth of hacked messages!!
Last edited by Empress_Ravenna on Mon Dec 10, 2018 10:32 am, edited 1 time in total.

ins
Noobzor
Noobzor
Posts: 9
Joined: Fri Aug 11, 2017 3:59 pm
Reputation: 0

Re: Capcom took down Cheathappens MHW trainer

Post by ins » Mon Dec 10, 2018 10:58 am

Sad to see companies abusing dmca and w.e. to go after hardworking trainers :(
But I guess that is what the end users wanted when they paid for invasive tech in the first place.

Remember: Capcom/Denuvo/et.al. is the real enemy. A purely technological cat/mouse game would be of benefit to all, but when they threaten with "real world consequences" because they can not compete otherwise, they're just being dicks - perhaps the future is in 10$ loot crates.

I think we should all pray that developers do not force you to grant them ring 0 access to check if you have cheatengine or some memory modification program running in the background in order to play their blockbuster AAA game. Or that they are given the right to charge you for felony in federal court for trying to hack your single player experience because they want to add in a microtransaction economy to their historically single player franchise
I do not think praying will help. the only way to combat these invasive methods would be for customers to actually stop paying to have their 'rights' removed, and we know that will never happen. So, lets just enjoy the journey while it lasts.
Last edited by ins on Mon Dec 10, 2018 11:42 am, edited 1 time in total.

predprey
Expert Cheater
Expert Cheater
Posts: 110
Joined: Thu Mar 02, 2017 8:46 pm
Reputation: 66

Re: Capcom took down Cheathappens MHW trainer

Post by predprey » Mon Dec 10, 2018 11:18 am

SunBeam wrote:
Mon Dec 10, 2018 10:13 am
  • "If too many people uses this method, Capcom can easily update the integrity checks again, changing the code signatures" - - exactly the logic behind the "I know the scanners location is different" statement; the VA can easily change if they change some compiler settings, not to mention every VMProtected target will use unique VMs with each enveloping action; so, for example, if you start doing some RE on v1.0's VMP and devs decide they forgot some shit, even though game doesn't get updated to v1.1 and is still v1.0, the fact that there's a new .exe will fuck up your analysis; different VMs..
Correct me if I'm wrong but the integrity check trigger locations are separate from the table of hashed VAs right? Knowing all memory locations that are checked still does not help us find all the triggers to reroute/disable. Without rigorous in game testing, there is no way to confirm we caught all the triggers. Though if there is an easy way to do so, patching triggers would no doubt be the better approach with minimal performance impact.

User avatar
SunBeam
Administration
Administration
Posts: 2442
Joined: Sun Feb 04, 2018 7:16 pm
Reputation: 959

Re: Capcom took down Cheathappens MHW trainer

Post by SunBeam » Mon Dec 10, 2018 12:31 pm

Let's assume you find all the spots by doing simple on-read grinding with an executable (get your hook spot; debug on access its first byte; see what accesses that; then take the first byte of the instruction reading your byte; find out what accesses that; and so on). If the developers update the game (either the version or just the executable alone), then all those locations will be lost. So what would you do.. grind again on the new executable? Task might be tedious given the time spent or involved procedures (aside from debugging, you might be required to hot-patch some of the scanners to continue finding out others).

So, predprey, yes and no; the VAs are for both the scanner-instructions-to-be-checked and game-executable-code-to-be-checked. Why would they split them up? :) It wouldn't make any sense to me, as a developer. If they're mixed up together, it makes the task harder for the reverser. But then again, the reverser doesn't want to split them as well; just patch the core of the detection routines. Given the same function's spliced across the executable, it's pretty tedious to find each and every scanner. Sure, you might get the hang of it so the "82" scanners-patching can be replicated easily (scripted) at some point in time. Or simply fingerprint the structure of the scanner function (the reader part) and scan whole memory for occurences. Break on all instances and see if the debugger stops and on which; and what happens when the read occurs. That's one way to tell, approximately, how many scanners are there. Wouldn't surprise me if Caliber did exactly that :P Doesn't take a genius to find one scanner, Ctrl+F the bytes (give or take the spliced JMPs) and count them. There's no need to check if they break or not, the effect alone on the public is enough -> "there are 82 scanners"; people: "omfg, wow". Smug smile after that.

Let's assume this is the xor_after_read part of a scanner:

Code: Select all

32 02             - xor al,[rdx]
48 83 C2 01       - add rdx,1
FF 4D 00          - dec [rbp]
Theoretically you can scan whole protector's memory for this pattern: 32 02 48 83 C2 01 FF 4D 00. Check if found locations are indeed those 3 instructions (the bytes might be part of other instructions, thus invalid ASM) and break on all. See which are triggered and count them up. That's how you get fast that "82".

But.. you won't get all :) Here's why:

Code: Select all

32 02             - xor al,[rdx]
E9 xx xx xx xx    - jmp loc_1
..
loc_1:
48 83 C2 01       - add rdx,1
E9 xx xx xx xx    - jmp loc_2
..
loc_2:
FF 4D 00          - dec [rbp]
That's called splicing. Can be done with JMPs along and/or junk code. Here's another example:

Code: Select all

32 02             - xor al,[rdx]
E9 xx xx xx xx    - jmp loc_1
..
loc_1:
48 83 C2 01       - add rdx,1
F9                - stc
E9 xx xx xx xx    - jmp loc_2
..
loc_2:
F8                - clc
F6 C4 85          - test ah,-7B
FF 4D 00          - dec [rbp]
That's the reason I said it might be a tedious task :P But hey, we're all adventurers out here ;)

Now.. regarding the memory copy or file copy and why it wouldn't work. Let's assume we have this function:

Code: Select all

read_god_toggle:
00007FF7A50C90C0 | 8A 81 80 07 00 00                          | MOV AL,BYTE PTR DS:[RCX+780]                         |
00007FF7A50C90C6 | C3                                         | RET                                                  |
This would be a core function that the engine uses to check-up on god status. Simply put, there's a BOOL at 0x780 in the structure referred-to by RCX that, if set to 1, will enable god in-game. Let's assume there's no other way to toggle it (no other read/write functions but this one) and you don't want to use breakpoints to read RCX and manually set that 1. Let's say you wanna hook it, thus place a JMP at 7FF7A50C90C0. Once you do that, the code changes to:

Code: Select all

00007FF7A50C90C0 | E9 3B 7F FF FF                             | JMP 7FF7A50C1000                | <- our hook
00007FF7A50C90C5 | 90                                         | NOP                             | <- evening out bytes
00007FF7A50C90C6 | C3                                         | RET                             |
..
00007FF7A50C1000 | 8A 81 80 07 00 00                          | MOV AL,BYTE PTR DS:[RCX+780]    | <- original
00007FF7A50C1006 | E9 BB 80 00 00                             | JMP 7FF7A50C90C6                | <- JMP back and resume flow
Once you do that, the scanner I mentioned earlier kicks in and instead of finding 8A 81 80 07 00 00 at 00007FF7A50C90C0, it finds E9 3B 7F FF FF 90. Of course the XOR result will be different, thus a computed/expected hash of the memory section will fail; crash. Let's assume now you wanna fix that. Without breakpoints and just hooks/patches, you would do the exact same hooking approach, but this time on the "xor al,[rdx]" instruction of the scanner. Its size is 2 bytes; a near-JMP needs 5. If there's JMP splices, you can re-route those and JMP back to the spliced JMP's destination ;) OK, you do that, you hook the scanner, you make it so you feed the original bytes to the XOR routine and everything works nice. But wait.. why is the game still crashing? Well, that's because there's another scanner checking up the scanner checking up on your game hook :P Nice, eh?

So the approach above has to be replicated to all the possible scanners you find checking up on any piece of code you hook; inside the hook either feed the original bytes to the XOR loop (you'd need a list to keep track of them) or simply trace the code structure to find the loop exit and storage of the computed XOR hash. Once found, restore it to the value you know should be the correct one. Thus you can work with a table of hashes, which makes things a lot easier.

Now.. back to why copies of the memory would fail when changing the checked pointer. Quick background derived from the above method: you can make a copy of the game memory - allocate enough memory, duplicate the executable (you might need to duplicate all, not just the - usually - .text executable section), then at the XOR spot instead of letting the scanner check your RDX, you feed the calculated pointer to the original address in your copy. So:
  • xor al,[rdx] reads the byte of 7FF7A50C1000 (0x8A)
  • swap rdx (7FF7A50C1000) with its equivalent from your memory copy (let's say 7FFFA50C1000; at this copy location the byte is 0x8A)
  • you can now hook 7FF7A50C1000 and won't crash from this alone; scanner will check 7FFFA50C1000
The approach above has to be replicated to all locations where scanners exist/are triggered/etc. Alternately, you can easily write-up a generic function that uses as parameters the offset deducted from address - module base, to which you apply the copy's module base ;) Thus you end-up re-routing all scanners to 1 function.

Still haven't gotten to the fail part :) Bear with me.

Back to our function:

Code: Select all

read_god_toggle:
00007FF7A50C90C0 | 8A 81 80 07 00 00                          | MOV AL,BYTE PTR DS:[RCX+780]                         |
00007FF7A50C90C6 | C3                                         | RET                                                  |
What I've seen protectors do nowadays is to run a RDTSC instruction or some timer to determine a "timestamp" of the process code state in memory. And when they do that, they store the result somewhat close to the function above. The computed hash will then take into account this "timestamp". Much like the Enigma machine. Encrypt one layer, add something extra, encrypt the next layer, and so on. Done in waves. Here's a demo:

Code: Select all

read_god_toggle:
00007FF7A50C90C0 | 8A 81 80 07 00 00                          | MOV AL,BYTE PTR DS:[RCX+780]                         |
00007FF7A50C90C6 | C3                                         | RET                                                  |
00007FF7A50C90C7 | 44 32 2C 38                                | XOR R13B,BYTE PTR DS:[RAX+RDI]                       |
The result of the RDTSC operation is a DWORD in RAX. This is stored at 7FF7A50C90C7. When the compute is done, code between 7FF7A50C90C0 and 7FF7A50C90C7+4 is hashed. You get a DWORD as result (e.g.: 78923C4A). Now.. if you create that memory copy when 7FF7A50C90C7 is 0x382C3244, chances are another encryption cycle occurs, at which point a different RDTSC result is stored at 7FF7A50C90C7 (e.g.: 45 38 29 3A). Since you copied the memory with the old RDTSC value, well.. guess what happens with all the bypassing logic described above ;) Yup, your hash goes to shit.

The reason StealthEdit is, in my opinion, the best choice here is you don't have to deal with re-routing code with so much hassle. Like you put it, predprey, read/write operations are redirected to the copy, execute operations are done on the original :) And not in the DBVM fashion.

Fun times.

User avatar
STN
Founder
Founder
Posts: 3358
Joined: Thu Mar 02, 2017 7:48 pm
Reputation: 830

Re: Capcom took down Cheathappens MHW trainer

Post by STN » Mon Dec 10, 2018 1:31 pm

Empress_Ravenna wrote:
Mon Dec 10, 2018 10:24 am
Accounts been hacked.. just gotta repost this on all my threads till i can figure out how to erase my last days worth of hacked messages!!
Not cool man, i am gonna have to snip post editing permissions from normal users now and you're the one that tipped me over the edge.

I can see from your post records it's you all along unless the hacker is in your home.
For site updates, follow FRF's official Twitter, Facebook

Don't PM me asking for cheats, I'll just ignore you. Use the search function instead.

User avatar
SunBeam
Administration
Administration
Posts: 2442
Joined: Sun Feb 04, 2018 7:16 pm
Reputation: 959

Re: Capcom took down Cheathappens MHW trainer

Post by SunBeam » Mon Dec 10, 2018 1:44 pm

Told him/her to quit with the random bashing; didn't believe a word (and in general) till proven. Guess this isn't an intricate individual; could've faked some screenshots or something, at least :P The approach of "I've been hacked" is pathetic, if you ask me. Not to mention "yeah, close this topic as it's not interesting anymore" right after I asked for proof :D Kids..

User avatar
Visi
Cheater
Cheater
Posts: 32
Joined: Wed Mar 22, 2017 9:07 pm
Reputation: 19

Re: Capcom took down Cheathappens MHW trainer

Post by Visi » Mon Dec 10, 2018 11:57 pm

STN wrote:
Mon Dec 10, 2018 1:31 pm
Empress_Ravenna wrote:
Mon Dec 10, 2018 10:24 am
Accounts been hacked.. just gotta repost this on all my threads till i can figure out how to erase my last days worth of hacked messages!!
Not cool man, i am gonna have to snip post editing permissions from normal users now and you're the one that tipped me over the edge.

I can see from your post records it's you all along unless the hacker is in your home.
Couldn't you just ban them instead of restricting features for normal users? :(

User avatar
STN
Founder
Founder
Posts: 3358
Joined: Thu Mar 02, 2017 7:48 pm
Reputation: 830

Re: Capcom took down Cheathappens MHW trainer

Post by STN » Tue Dec 11, 2018 3:22 am

Visi wrote:
Mon Dec 10, 2018 11:57 pm


Couldn't you just ban them instead of restricting features for normal users? :(
Problem is it's very common. Almost in any thread, there will be someone editing their post out usually something like "i figured it out, nvm" or something similar. Or someone gets salty over something and bam edits out all their posts.

This was never allowed anyway past a certain time limit in old forums, i thought it was the same here. Will set the same thing here and only allow editing for a certain time period.
For site updates, follow FRF's official Twitter, Facebook

Don't PM me asking for cheats, I'll just ignore you. Use the search function instead.

predprey
Expert Cheater
Expert Cheater
Posts: 110
Joined: Thu Mar 02, 2017 8:46 pm
Reputation: 66

Re: Capcom took down Cheathappens MHW trainer

Post by predprey » Tue Dec 11, 2018 1:41 pm

predprey wrote:
Mon Dec 10, 2018 8:51 am
For the first option, it branches into two ways for redirection of the RIP instruction pointer.
A. Stealthedit plugin which Squall's table uses.
B. VEH Detour a la Fling
I'm going to have to correct myself here, it seems StealthEdit uses vectored exception handling which is required for catching those page faults it causes. I believe Caliber's "VEH Detour" is referring to this instead. FLiNG's newest trainer does not seem to be using this method, I think he removed some options that are failing the integrity checks and crashing. His remaining options all work fine but I believe they modify the executable code directly and uses sections that aren't checked instead. Meanwhile, StealthEdit does not seem to be working completely as the game seems to be detecting the protection level of the checked pages and reverting them, thus the page faults aren't being triggered.

User avatar
BooBoo
Fearless Donors
Fearless Donors
Posts: 513
Joined: Sat May 06, 2017 2:28 pm
Reputation: 104
Contact:

Re: Capcom took down Cheathappens MHW trainer

Post by BooBoo » Tue Dec 11, 2018 1:46 pm

predprey wrote:
Tue Dec 11, 2018 1:41 pm
predprey wrote:
Mon Dec 10, 2018 8:51 am
For the first option, it branches into two ways for redirection of the RIP instruction pointer.
A. Stealthedit plugin which Squall's table uses.
B. VEH Detour a la Fling
I'm going to have to correct myself here, it seems StealthEdit uses vectored exception handling which is required for catching those page faults it causes. I believe Caliber's "VEH Detour" is referring to this instead. FLiNG's newest trainer does not seem to be using this method, I think he removed some options that are failing the integrity checks and crashing. His remaining options all work fine but I believe they modify the executable code directly and uses sections that aren't checked instead.
This is correct, There is a lot of places in the binary where the scanners don't check.

Post Reply

Who is online

Users browsing this forum: No registered users