Code Filter fails to setup breakpoints

[Kalagaraz]

On some games when I try to use the code filter and I create a junk category and then click GO, it will stall for a minute or so then say unable to setup breakpoints and failed to initialize. Anyone know why? I don't have any other breakpoints set and I'm using a freshly run copy of MHS. The game has no protection (No gameguard etc...), and other stuff works fine (like memory editing etc...). It's just the code filter that's giving problems.

If anyone can help I would appreciate it.

EDIT:

If I uncheck good guesses it works, but it only finds 85 functions, it crashes on the first one it hits, and it doesn't have any of the game specific functions included in those 85. I can open it in ollydbg and I noticed something I've never seen in a game before. A whole crap load of jmps in a row:

Code: Select all

00401005   /E9 66354800     jmp     00884570
0040100A   |E9 31DD5000     jmp     0090ED40
0040100F   |E9 0CE63400     jmp     0074F620
00401014   |E9 175E2700     jmp     00676E30


there are a couple hundred of these, some simply jmp to retn statements and do nothing, others actually go to the entry points of functions. OllyDbg is also showing a bunch of unknown commands.

Code: Select all

005AC051    FFFF            ???                                      ; Unknown command
005AC053    FFFF            ???                                      ; Unknown command



First time I've seen those too. Does this help with the problem?

Thanks in advanced,
Kalagaraz[/code]

[L. Spiro]

You will need the fix, which I will upload as soon as my faggot connection is less fag.


L. Spiro

[Kalagaraz]

You will need the fix, which I will upload as soon as my faggot connection is less fag.


L. Spiro

Lol you posted while I discovered some new stuff and was editing my original post, please read the section marked EDIT above and see if this helps with the problem. I think it's a problem to do with some kind of protection in the game, rather than your software which works for all other games I've hacked.

[L. Spiro]

The fix, which I made 2 days ago because the same thing happened to me in a game that has no protections etc., has to do with the debugger thinking that breakpoints one address apart are overlapping when they are not, so it rejects setting the breakpoint and thus the error you get when it tries to apply breakpoints to all the Good-Guess functions.

The JMPs you see compose the jump table. Every application has one.

The unknown commands are a failure on the part of OllyDbg.

And the crashes I have no clue. It is common—it happens on a lot of games—but I have no clue why. My debugger is exceptionally stable/solid, and I suspect it has something to do with Windows, or threading (while the game slows down while setting all the breakpoints, threads get backed up, and when they catch up to speed when the game is resumed they may all be running into a lot of breakpoints at once and jamming the debugging pipeline (although my debugger is fully multi-thread safe)).

However, if you continue making logs you get a lot of those functions out of there.
Keep logging and letting the game crash. As long as some of the functions get logged before it crashes there will be a smaller chance of it crashing next time, until eventually it will just stop crashing.


L. Spiro

[Kalagaraz]

The fix, which I made 2 days ago because the same thing happened to me in a game that has no protections etc., has to do with the debugger thinking that breakpoints one address apart are overlapping when they are not, so it rejects setting the breakpoint and thus the error you get when it tries to apply breakpoints to all the Good-Guess functions.

The JMPs you see compose the jump table. Every application has one.

The unknown commands are a failure on the part of OllyDbg.

And the crashes I have no clue. It is common—it happens on a lot of games—but I have no clue why. My debugger is exceptionally stable/solid, and I suspect it has something to do with Windows, or threading (while the game slows down while setting all the breakpoints, threads get backed up, and when they catch up to speed when the game is resumed they may all be running into a lot of breakpoints at once and jamming the debugging pipeline (although my debugger is fully multi-thread safe)).

However, if you continue making logs you get a lot of those functions out of there.
Keep logging and letting the game crash. As long as some of the functions get logged before it crashes there will be a smaller chance of it crashing next time, until eventually it will just stop crashing.


L. Spiro

Alright thanks, can't wait for update. Reading a book called Exploiting Online Games in the mean time Great book so far.

[L. Spiro]

http://www.memoryhacking.com/MemHack/MHS5.005Ex.rar


L. Spiro

[Kalagaraz]

http://www.memoryhacking.com/MemHack/MHS5.005Ex.rar


L. Spiro

thanks, that indeed fixed the problem.

EDIT:

Seems to be breaking on addresses that are not function entry points now. This just a side effect of the "guessing"? or could exe be protected somehow? (code filter runs in run time, but i'm reading disassembled code from static exe) so could it be packed or something? Though I don't think so because PEID did not identify any packing on the exe.

Here is an example of the kind of addresses it's breaking on when I tried to identify the target enemy function.

Code: Select all

.text:0042AF7C                 db 0E9h ; T
.text:00426F49                 db 0E9h ; T


[/code]

[L. Spiro]

Obtaining function entry points is not an exact science. Following disassembly period is not an exact science.

If it is not causing a serious problem, you should just ignore it and use the functions that are correct.


L. Spiro

[Kalagaraz]

Obtaining function entry points is not an exact science. Following disassembly period is not an exact science.

If it is not causing a serious problem, you should just ignore it and use the functions that are correct.


L. Spiro

EDIT: Nevermind I figured it out.

Well the first one was correct. 0042AF7C, which in IDA was the db statement, in ollydbg at runtime was

0042AF7C /E9 BFB82900 jmp 006C6840



^ one of the members in the jmp table that goes to the target enemy function. So i'm guessing the exe is packed or something, but peid still says no packing detected.