FearLess Cheat Engine

SunBeam wrote: ↑

Wed Sep 30, 2020 11:22 am

^ Game doesn't hide them. The problem is the game sets up a structured exception handler (SEH) and filters hardware breakpoints, so debugging the game either crashes it on some OSes or just doesn't show anything. I've sorted it out with cfemen As far as scanning its memory is concerned, that isn't affected. Just keep in mind to scan on BYTE, not word or dword.

SunBeam wrote: ↑

Sat Oct 17, 2020 10:41 pm

I'm using x64dbg with ScyllaHide plugin (setting: VMProtect). Patch the game's EP to infinite loop (EBFE) then let Steam launch it. As soon as process is created, attach the game with x64dbg. Then check Threads > Main. Double-click it and it will land you where the EP loop is (the EBFE). Restore the 2 EP bytes (EBFE to original ones) here and let the game run. You won't experience any crashes going forward, as I believe whatever anti-debug/anti-attach/anti-breakpoint has implemented never gets to hook, as ScyllaHide does it before it can happen

If you're going to ask for step by step instructions, then that means you've never used x64dbg. Which isn't something I have time to teach at the moment. Sorry.

SunBeam wrote: ↑

Sun Oct 18, 2020 10:56 am

You misread. Once you do the above, CE hwbps will work just fine (I always use VEH). No one said you can't debug with CE while attached with x64dbg.. The whole deal here is ScyllaHide and not letting the game setup hooks in k32 APIs.. that's all

galman33 wrote: ↑

Sun Oct 18, 2020 11:24 pm

...

AronaKallz wrote: ↑

Thu Oct 15, 2020 8:11 am

I have pretty much the same problem as the previous poster, but I think the source of the problem is simply that the game was updated to 1.12.1e, which means the table for 1.11.1 doesn't search in the right spots/in the right ways any more. So, yeah. I don't know how to fix it, but we need an update to the table, I think.

• I've created a patched version of Spel2.exe that has an EBFE loop at the entry point.
• I can launch this patched version through Steam and attach x64dbg + ScyllaHide with the options pictured in SunBeam's screenshot above. I can confirm that ScyllaHide kicked in by checking the logs:

  Code: Select all

  [ScyllaHide] Hook injection successful, image base 00000208E95F0000

• I can use x64dbg to change the EBFE instruction back to its original value (4883), then resume execution and allow the game to run as normal.

• I've scanned for a value that matches my current amount of money (score). After trying to change this value it seems to get changed back after I unpause the game. This is pretty standard stuff and I'd like to be able to use the CE debugger here ("Find out what writes to this address" option).
• I open the Memory View > View > Debug Events window, then use CE to attach the debugger to the game. I see that a whole bunch of debug events are generated so the debugger looks like it has properly attached.
  
• Immediately after attaching the debugger, the Spel2.exe process gets suspended in Windows. I can resume the Spel2.exe process by opening Resource Monitor and resuming the process manually. There are no immediate problems after doing this. I'd be curious to know if this suspension is something I should be concerned about or if Windows just suspends processes that generate lots of debug events.
• After attaching the debugger I can navigate the pause UI just fine, but unpausing the game (which changes the value) causes an EXCEPTION_SINGLE_STEP to be thrown. I can see the details of this exception in x64dbg, and resuming execution causes the game to crash and generate a dump file (which just reiterates that the game crashed because of EXCEPTION_SINGLE_STEP).

• Hardware Breakpoints - causes the EXCEPTION_SINGLE_STEP and crash detailed above
• Int3 Instructions - causes the EXCEPTION_SINGLE_STEP and crash detailed above
• Page Exceptions - continually throws EXCEPTION_SINGLE_STEP and EXCEPTION_ACCESS_VIOLATION while the debugger is attached. If I add those exceptions to the list of exceptions that x64dbg ignores, the game runs like garbage but I can see the opcodes that write to the value in CE, which is a small victory.
• Windows Debugger - I get the following error:
  

1. Should I be worried about the process getting suspended in Windows, or is this expected? If this is a problem, how can I mitigate it?
2. Is there anything I can do to get hardware breakpoints / Int3 instructions working?