Auto-Hack's Assembly Code Not Viewable in Debugger -- Why?

Need Help With an Existing Feature in Memory Hacking Software? Ask Here

Moderators: g3nuin3, SpeedWing, WhiteHat, mezzo

Auto-Hack's Assembly Code Not Viewable in Debugger -- Why?

Postby Zach » Mon Sep 22, 2008 5:38 am

(This is a continuation of my "Backtracking a Complex Pointer - When Do I Give Up?" thread, but it's a completely different problem, hence why the new thread.)

ImageImage

As a brief background, I found seven (end-point) addresses that correspond to the player's health. The first six are identical in nature to those I found and talked about in the aforementioned thread: they just seem to be part of a singly-linked list that are constantly being updated.

The seventh address is the "magic" address I need to backtrack as it is that location which seems to be governing all the rest: changing it instantly updates all the others, changing it changes it in-game, freezing it freezes it in-game, etc.

Simple so far, right?

Well, to cut to the chase, as the above screen shot shows, doing a the "Find what writes to this address" yields one result (good!), but the assembly code in this case is meaningless without seeing it in context, i.e., I need to look at the code to see how the game calculated the value in the ESI register, but when I right-click on it and try to view it in the debugger, I get garbage code. (Rest easy, L. Spiro. Even Visual Studio showed the same garbage code when I tried using it instead.)


So to sum up:
  1. Found address 20BB1790h points to health;
  2. Had MHS tell me what writes to that, but it basically just gave me a circular reference: address/offset = 20BB178Ch+4h;
  3. Did a pointer (and data for that matter) search for 20BB178Ch but got zero hits, so I have to look at preceding lines of code to determine how it was calculated; and finally
  4. Brought up the code in the debugger to do just that but only garbage code is displayed (same garbage code shows up in Visual Studio as well).


How do I proceed?



P.S. Doing a "find what accesses" instead of "find what writes to" pretty much yields the same results as described above.
Zach
I Ask A Lot Of Questions
 
Posts: 16
Joined: Sun Sep 21, 2008 4:50 am

Postby L. Spiro » Mon Sep 22, 2008 8:12 am

Disassembling is not an exact science and disassemblers can always get derailed for any number of reasons.
In this case there may be nothing you can do. Unfortunately I have to suggest OllyDbg for this case. It might be able to show this area correctly.


L. Spiro
Our songs remind you of songs you’ve never heard.
User avatar
L. Spiro
L. Spiro
 
Posts: 3129
Joined: Mon Jul 17, 2006 10:14 pm
Location: Tokyo, Japan

Postby Zach » Mon Sep 22, 2008 9:41 am

Yeah, I'll probably do that, try out OllyDbg I mean. Your and Visual Studio's
debugger show the same garbage code; Cheat Engine's shows different garbage code, but it's still garbage; so it would be interesting if little old OllyDbg actually did the trick. :)

At CoMPMStR's urging (in a PM), I finally fully utilized your Pointer Search ("in Range") method, and I did manage to finally track down a static address, but upon reloading (the game), it turned out not to be correct. A second tracking yielded a chain with one more level of deferencing which told me it wasn't as simple as the hard-coded offsets messing up the expression.

Bottom-line, this is a hell of a lot of work! :P It would be SOOOOOO much quicker and simpler (for me, at least) if I could just debug the darn thing. :evil:

Anyway, I guess I'll figure it all out eventually. 8)
Zach
I Ask A Lot Of Questions
 
Posts: 16
Joined: Sun Sep 21, 2008 4:50 am

Postby Zach » Wed Sep 24, 2008 9:54 am

As a quick update, I was mistaken about Visual Studio; it shows the code stream fine. It's MHS that is getting confused.

MHS detects the memory write as the following (as shown in my first screen shot above):

Image


The actual opcode that's doing the memory write is as follows (taken from Visual Studio's debugger):

Image


So I guess my question is does MHS not support SSE instructions (which is what apparently is confusing it)? No crime if it doesn't. I'm just asking in case this may be a bug. :)
Zach
I Ask A Lot Of Questions
 
Posts: 16
Joined: Sun Sep 21, 2008 4:50 am

Postby L. Spiro » Wed Sep 24, 2008 6:00 pm

It supports all x86 instructions.
As it states in the options and the help file there is a chance for the auto-hack to show a wrong address if you use hardware breakpoints.

If you want to be sure it is showing the correct address use software breakpoints for Auto-Hack.


L. Spiro
Our songs remind you of songs you’ve never heard.
User avatar
L. Spiro
L. Spiro
 
Posts: 3129
Joined: Mon Jul 17, 2006 10:14 pm
Location: Tokyo, Japan

Postby Zach » Wed Sep 24, 2008 11:47 pm

Okay, so I changed the options so Auto-Hack would use software breakpoints, and sure, now it at least cites the correct program address, but it still does not seem to understand SSE instructions. Since you say it should, then I guess this is an official bug report. ;)


Auto-Hack cites the following (correct program address, but unknown instruction):

Image

Opening that address in the debugger yields garbage since it doesn't seem to understand SSE opcodes so just cites them as data bytes/words and thus misinterprets the remaining truncated opcodes:

Image

The above code stream is actually the following:

Image
Zach
I Ask A Lot Of Questions
 
Posts: 16
Joined: Sun Sep 21, 2008 4:50 am

Postby L. Spiro » Thu Sep 25, 2008 9:22 am

I will look into it.


L. Spiro
Our songs remind you of songs you’ve never heard.
User avatar
L. Spiro
L. Spiro
 
Posts: 3129
Joined: Mon Jul 17, 2006 10:14 pm
Location: Tokyo, Japan


Return to Help

Who is online

Users browsing this forum: No registered users and 0 guests