Capcom took down fearlessrevolution MHW trainer

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

Re: Capcom took down fearlessrevolution 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 fearlessrevolution 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 fearlessrevolution 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
Fearless Donors
Fearless Donors
Posts: 173
Joined: Thu Mar 02, 2017 8:46 pm
Reputation: 107

Re: Capcom took down fearlessrevolution 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: 3026
Joined: Sun Feb 04, 2018 7:16 pm
Reputation: 1389

Re: Capcom took down fearlessrevolution 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: 3594
Joined: Thu Mar 02, 2017 7:48 pm
Reputation: 1252

Re: Capcom took down fearlessrevolution 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.

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

Re: Capcom took down fearlessrevolution 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: 39
Joined: Wed Mar 22, 2017 9:07 pm
Reputation: 19

Re: Capcom took down fearlessrevolution 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: 3594
Joined: Thu Mar 02, 2017 7:48 pm
Reputation: 1252

Re: Capcom took down fearlessrevolution 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.

predprey
Fearless Donors
Fearless Donors
Posts: 173
Joined: Thu Mar 02, 2017 8:46 pm
Reputation: 107

Re: Capcom took down fearlessrevolution 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: 532
Joined: Sat May 06, 2017 2:28 pm
Reputation: 128

Re: Capcom took down fearlessrevolution 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.

predprey
Fearless Donors
Fearless Donors
Posts: 173
Joined: Thu Mar 02, 2017 8:46 pm
Reputation: 107

Re: Capcom took down fearlessrevolution MHW trainer

Post by predprey » Tue Dec 11, 2018 3:11 pm

Alright so currently we have these options then:
1. StealthEdit
2. Manually disabling integrity checks
3. DBVM Memory Cloak (Not sure if it's placebo or some conflict with D's protection, DBVM seemed to be slowing my entire desktop down a little)
4. I came across another way for RIP rerouting similar to StealthEdit, the guy was using CE breakpoints and scripting in the modification of RIP. I did something similar before which was the DNOP debug nopping lua extension. But good luck with the performance hit here.

EDIT: Cross-compared a CODEX and an original executable, seems like the page protection overwriting is due to some added routines in the CODEX version. Probably part of their solution to patch D's protection in real-time.
Last edited by predprey on Tue Dec 11, 2018 8:09 pm, edited 1 time in total.

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

Re: Capcom took down fearlessrevolution MHW trainer

Post by SunBeam » Tue Dec 11, 2018 3:35 pm

This "not all memory is checked" reminds me of Blizzard's Battle.net.dll :D They added checks to verify the common hook spots for health, resources, mana, etc. - - but don't freakin' check the instructions operating the cheat toggles :) #4 was used by zths in his The Walking Dead table, via Lua (encoded table; decompiled by yours truly), however there was no protection there and the break-spots aren't triggered constantly. So yeah, #4 will suck fat cock if the instructions are used constantly. Bottom line is there are quite a few methods, so advertising or gloating with some method in a pompous manner isn't something unique and doesn't make you special, sadly - - for CH.

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

Re: Capcom took down fearlessrevolution MHW trainer

Post by STN » Wed Dec 12, 2018 9:15 pm

CaliberCH wrote:
Wed Dec 12, 2018 5:31 pm
For my part in escalating it, I apologize, but honestly the bulk of this is from other people who started this and propagated it, and revel in this sort of shit, due to their gutter lives or something. This IS the step child to fearlessrevolution site after all, so I should know better, and not expect anything different. That's on ME.


Caliber, can you please stop lumping fearlessrevolution into this? I don't know if you know but i don't run fearlessrevolution and have no power at all in any of their decisions. If they have wronged you in some way, go and talk to them. How can I help?

I don't appreciate you acting like a victim like i have wronged you in some way. You knew what you were doing and the community didn't like that. I simply had to step in and restore order. I actually went further and allowed this discussion.

You're welcome to post your findings and help etc or even argue in the appropriate place, i don't have anything against CH but i don't like threads being derailed and it seems that MHW thread is a shit magnet for some reason :), have banned one dude in that thread in past.

predprey
Fearless Donors
Fearless Donors
Posts: 173
Joined: Thu Mar 02, 2017 8:46 pm
Reputation: 107

Re: Capcom took down fearlessrevolution MHW trainer

Post by predprey » Fri Dec 14, 2018 1:05 pm

Manually disabling integrity checks is really tedious. As far as I can see the routine for checking the hash is split up by static jmps and the jmps can be anywhere in the entire routine. There is some sort of signature but not an easy one such as an AOB which CE can use to catch and patch all the checks. Instead, it is a instruction signature where some instructions are always present in the execution flow of the integrity checks.

There is a 5th method which I thought of but haven’t really test out if it is valid which is to just update the checksums themselves after the executable code is changed. Could be that the checksums location are also checked.

UPDATE: Recalculating checksums works. Should be the cleanest and fastest solution, will provide a working table soon 8-)
Last edited by predprey on Fri Dec 14, 2018 9:46 pm, edited 1 time in total.

Post Reply

Who is online

Users browsing this forum: Google [Bot]