 |
Cheat Engine
The Official Site of Cheat Engine
|
| View previous topic :: View next topic |
| Author |
Message |
abystus
Expert Cheater
 Reputation: 1
Joined: 09 Dec 2010
Posts: 140
|
 Posted: Wed Feb 22, 2012 11:08 am Post subject: Trace Problem (6.#) |
 |
|
I am having a problem getting the "Trace" feature to work properly. For some odd reason, it will not show all instrucitons processed up until my breaking address. I have taken the time to list my steps below, so that someone may be able to point out my error.
"Hit Me" Step 2 in the Tutorial App
| Code: | - Find the Address holding the value that the "Hit Me" button modifies.
- Move the found address to the "Address List" (bottom).
- Right click the Address, and choose "Find out what writes to this address".
- Attach Debugger.
- Press Decrease button (lists my writing ASM in the debugger).
- Highlight the line in the debugger, and press Show Disassembler.
- Right click 00420F3E sub [ebx+00000458],eax in the "Memory view" (top), and choose "Break and Trace instructions".
- Leave default settings, and stop condition is blank (figure it should stop on the address I right clicked)
- Press OK, and line is highlighted green.
- Press the "Hit Me" button again, but only one line is listed in the trace (00420F3E sub [ebx+00000458],eax) |
I would have assumed there would be more than one line executing when I press the button? I have also noticed that when it does work (listing multiple lines that the program executed) on other programs/games, that the instruction stopped on was not my highlighted address (actually nowhere near it). Any help is appreciated in getting this much desired feature to work (I use several debuggers with trace options, but have never run into this sort of problem before). Hopefully this problem is just an oversight on my part (maybe I missed a step?).
|
|
| Back to top |
|
 |
Dark Byte
Site Admin
 Reputation: 475
Joined: 09 May 2003
Posts: 25987
Location: The netherlands
|
| Posted: Wed Feb 22, 2012 11:28 am Post subject: |
|
|
| Quote: |
- Find the Address holding the value that the "Hit Me" button modifies.
- Move the found address to the "Address List" (bottom).
- Right click the Address, and choose "Find out what writes to this address".
- Attach Debugger.
- Press Decrease button (lists my writing ASM in the debugger).
- Highlight the line in the debugger, and press Show Disassembler.
|
you forgot to click on the STOP button in the previous window.
This leaves the breakpoint on write there, so while break and trace is tracing it breaks on a different breakpoint which takes precedence (the previous breakpoint is handled before the single step bp), and handling that specific breakpoint does not set the single stepping back like it would have if it was the expected breakpoint
_________________
Tools give you results. Knowledge gives you control.
Like my help? Join me on Patreon so i can keep helping |
|
| Back to top |
|
|
abystus
Expert Cheater
Reputation: 1
Joined: 09 Dec 2010
Posts: 140
|
| Posted: Wed Feb 22, 2012 11:35 am Post subject: |
|
|
| Dark Byte wrote: |
you forgot to click on the STOP button in the previous window.
This leaves the breakpoint on write there, so while break and trace is tracing it breaks on a different breakpoint which takes precedence (the previous breakpoint is handled before the single step bp), and handling that specific breakpoint does not set the single stepping back like it would have if it was the expected breakpoint |
That seems to have done the trick. One more thing, why does the trace list my breaking address first, and then everything that follows it (seems it lists my breaking address, then moves forward instead of listing what happened before it)? Shouldn't it list everything (the last 1000 executed lines) up until the break address (the break address should be last in the tree)? I'm used to the trace stopping at the executed address, and giving a road map of everything before the breaking line. I really appreciate the quick answer on the previous question.
|
|
| Back to top |
|
|
Dark Byte
Site Admin
Reputation: 475
Joined: 09 May 2003
Posts: 25987
Location: The netherlands
|
| Posted: Wed Feb 22, 2012 11:42 am Post subject: |
|
|
That is what break and trace does. It breaks on the specific address and then traces the instructions for the given amount of time.
What you describe sounds more like a normal breakpoint with a stacktrace.
To do that just set a normal breakpoint at the instruction (f5) and when it breaks on it the stacktrace window at the bottom right should show the calls (if you're on 64-bit windows the 32-bit ce version is recommended if you wish to use the os supported stacktrace)
_________________
Tools give you results. Knowledge gives you control.
Like my help? Join me on Patreon so i can keep helping |
|
| Back to top |
|
|
abystus
Expert Cheater
Reputation: 1
Joined: 09 Dec 2010
Posts: 140
|
| Posted: Wed Feb 22, 2012 12:06 pm Post subject: |
|
|
| Dark Byte wrote: | That is what break and trace does. It breaks on the specific address and then traces the instructions for the given amount of time.
What you describe sounds more like a normal breakpoint with a stacktrace.
To do that just set a normal breakpoint at the instruction (f5) and when it breaks on it the stacktrace window at the bottom right should show the calls (if you're on 64-bit windows the 32-bit ce version is recommended if you wish to use the os supported stacktrace) |
I tried your steps, but only one line was listed in the stack trace. Now in the "The following opcodes write to" window (bottom) I see:
| Code: | 00420F38 - E8 83B7FEFF - call 0040C6C0
00420F3D - 40 - inc eax
00420F3E - 29 83 58040000 - sub [ebx+00000458],eax <<
00420F44 - 8B B3 44040000 - mov esi,[ebx+00000444]
00420F4A - 8D 45 D4 - lea eax,[ebp-2C]
EAX=00000001
EBX=002597D8
ECX=00000000
EDX=00000000 |
This section actually does list some of the lines that happened before (and after), but it's not a complete map. Maybe an example would help:
Lets say 12345678 is my characters health address. Now we want to see the path taken when an enemy struck my character. Normally I would set a break point on my writing address (writing to 12345678), and use a trace to find everything that executed before the damage was delivered to my character. When the break point executes the trace would halt, and would have listed all instructions that processed before that point. In cheat engine, how would you accomplish something similar?
When setting a break point on the line 00420F3E sub [ebx+00000458],eax (f5), clicking "Hit Me", viewing the stack trace (bottom, or View>Stacktrace) only listed:
| Code: | PC Stack Frame Return Parameters
00420F44 | 0158F474 | 0158F474 | 00489A74 | Ox0056919C, 2485896, ...
|
I am looking for something similar to (along with the call procedures defined) :
| Code: | 00420F20 call 0040B0C0
00420F25 call 0040CF40
00420F2A push eax
00420F2B test eax,eax
00420F2D jne 00420FBC
00420F33 mov eax,00000005
00420F38 call 0040C6C0
00420F3D inc eax
00420F3E sub [ebx+00000458],eax |
Thanks again for all your help in this matter.
Edit:
I tried again with the 32 bit version (reread your listing the different versions on a 64 bit machine), and it listed a lot more in the stack trace window. However, I am looking for more of a detailed structure setup similar to the Break and Trace layout (instructions, bytes, etc are listed).
|
|
| Back to top |
|
|
Dark Byte
Site Admin
Reputation: 475
Joined: 09 May 2003
Posts: 25987
Location: The netherlands
|
| Posted: Wed Feb 22, 2012 12:27 pm Post subject: |
|
|
That is not possible with ce. Register states are not recorded before the breakpoint hits
(perhaps in the far future doing a constant trace won't slow down a game to 0.1 frame a minute)
But to distinguish between an enemy and you I recommend using the "Find out what addresses this code write to"
Rightclick the addressed to pop up extra information like registers and stack and then use data dissect to find out how to distinguish between them
_________________
Tools give you results. Knowledge gives you control.
Like my help? Join me on Patreon so i can keep helping |
|
| Back to top |
|
|
abystus
Expert Cheater
Reputation: 1
Joined: 09 Dec 2010
Posts: 140
|
| Posted: Wed Feb 22, 2012 1:58 pm Post subject: |
|
|
| Dark Byte wrote: | That is not possible with ce. Register states are not recorded before the breakpoint hits
(perhaps in the far future doing a constant trace won't slow down a game to 0.1 frame a minute)
But to distinguish between an enemy and you I recommend using the "Find out what addresses this code write to"
Rightclick the addressed to pop up extra information like registers and stack and then use data dissect to find out how to distinguish between them |
Maybe feature could be implemented (optional to the user of course), as I wouldn't think logging the instructions (last 1000-2000 instructions executed) would be that detrimental on today's PCs (I deal with several debuggers that do the proposed, with little to no effect on the running game. Only when they are accessing the hard drive by writing a file of the log do you normally experience slowdown.). Also, if a trace was to affect the games performance, it would be expected by the user, as you usually don't trace for long periods of time (you usually have the break in place, ready to perform the action that causes the break when starting the trace).
Just something to think about for the future, as a break than trace wouldn't really aid me in finding the hit routine, disabling collision checks, or anything else that would happen before a break occurred. Hopefully something like this gets implemented in the future (I can't believe I'm the first to request such a feature). Thanks for all your help.
|
|
| Back to top |
|
|
Dark Byte
Site Admin
Reputation: 475
Joined: 09 May 2003
Posts: 25987
Location: The netherlands
|
| Posted: Wed Feb 22, 2012 3:00 pm Post subject: |
|
|
Do those debuggers run in 64-bit windows? Because with the patch protection of win64 and the refusal of ms to document the gd/dbg_ctl I cant see a generic working way to do that
Same reason why I didn't suggest using the kernelmode debugger which can return the paths taken before bp hit(still no register states)
But perhaps I am misinterpreting the feature request. Do you want to see the register states of the instructions before the breakpoint hits or do you just want to see the code/opcodes only? (Clicking the stacktrace address will show the code)
Or do you wish to record all the different itteration from one specific spot till another specific spot?
_________________
Tools give you results. Knowledge gives you control.
Like my help? Join me on Patreon so i can keep helping |
|
| Back to top |
|
|
abystus
Expert Cheater
Reputation: 1
Joined: 09 Dec 2010
Posts: 140
|
| Posted: Wed Feb 22, 2012 3:28 pm Post subject: |
|
|
| Dark Byte wrote: | Do those debuggers run in 64-bit windows? Because with the patch protection of win64 and the refusal of ms to document the gd/dbg_ctl I cant see a generic working way to do that
Same reason why I didn't suggest using the kernelmode debugger which can return the paths taken before bp hit(still no register states)
But perhaps I am misinterpreting the feature request. Do you want to see the register states of the instructions before the breakpoint hits or do you just want to see the code/opcodes only? (Clicking the stacktrace address will show the code) |
Basically a list of instructions (ordered by execution) up until the break. I just need the path the code took. Example:
| Code: | - I set a break point on the line: 00420F3E sub [ebx+00000458],eax.
- I start the "Trace" feature that would be logging instructions (not worried about register values).
- I make my break execute by pressing the "Hit Me" button.
- The trace would then halt (turn off), and display the last 1000-2000 instructions it recorded before the break point executed (in a textbox, tree view, etc...).
- Done (until I turn trace back on, and hit my break again) |
Output would be as follows (doesn't list register values, but gives a map of where it went, and what lines were executed):
| Code: |
...
00420F2A push eax
00420F2B test eax,eax
00420F2D jne 00420FBC
00420F33 mov eax,00000005
00420F38 call 0040C6C0 (this called sub would be defined after this line)
00420F3D inc eax
00420F3E sub [ebx+00000458],eax
|
Keep in mind that the debuggers I use are for various emulators for various systems (MAME, PSX, N64, etc...). You technically are already monitoring the registers, and PC counter for when a break point executed. I don't see why logging (in memory) what it sees would be all that much slower. The displaying of the log would only be done when the break point halted (turned off) so that the thread of the application wouldn't be tied up refreshing the textbox, listview, etc... on each instruction executed.
You may want to test this "feature" out on your own to see if there is such a speed reduction to the game play. The way I see it, if your already halfway there by checking for the break point, then storing the last 1000 or so addresses in memory shouldn't be that big of a speed hit. Whenever you eventually do hit the break point, just dump the accumulated contents to display.
Thank you for at least allowing me to elaborate on the feature. I think it would be a great tool (especially for advanced ASM hacks) for one of the best (if not the best) pc cheat tool out there. I will look more into the stack trace if you think it will provide something useful, but I think I'm looking for something structured along the lines of Break and Trace, but in reverse. Thanks for your feedback!
|
|
| Back to top |
|
|
Dark Byte
Site Admin
Reputation: 475
Joined: 09 May 2003
Posts: 25987
Location: The netherlands
|
| Posted: Wed Feb 22, 2012 4:14 pm Post subject: |
|
|
An emulator knows the state it is emulating but because the system it is emulating is slower than the actual system, you do not notice the decrease in speed. But on windows you should imagine the speed as running an psx emu inside a pc emulator inside the n64 emulator to get an idea of the speed if every instruction is seperately emulated and every register is recorded
Anyhow, if you just wish the execution path then really check the stacktrace.(Perhaps someone could write a lua script that build a tree with thatdata)
On a sidenote, the cpu does provide a feature to record all the branches taken. Next ce version does make use of this but not yet for backtracing(and you need a specific intel cpu) but i'll see about adding usage of this feature for backtracing in the version after the next one
(With this feature as it is now you can find code executed a specific time, e.g. if you hit a wall 7times, you can search for code that is executed 7 times)
_________________
Tools give you results. Knowledge gives you control.
Like my help? Join me on Patreon so i can keep helping |
|
| Back to top |
|
|
abystus
Expert Cheater
Reputation: 1
Joined: 09 Dec 2010
Posts: 140
|
| Posted: Wed Feb 22, 2012 4:21 pm Post subject: |
|
|
| Dark Byte wrote: | An emulator knows the state it is emulating but because the system it is emulating is slower than the actual system, you do not notice the decrease in speed. But on windows you should imagine the speed as running an psx emu inside a pc emulator inside the n64 emulator to get an idea of the speed if every instruction is seperately emulated and every register is recorded
Anyhow, if you just wish the execution path then really check the stacktrace.(Perhaps someone could write a lua script that build a tree with thatdata)
On a sidenote, the cpu does provide a feature to record all the branches taken. Next ce version does make use of this but not yet for backtracing(and you need a specific intel cpu) but i'll see about adding usage of this feature for backtracing in the version after the next one
(With this feature as it is now you can find code executed a specific time, e.g. if you hit a wall 7times, you can search for code that is executed 7 times) |
I see where your coming from via the emulation example you gave. I will look more into the stack trace when I arrive home (currently at work), and see if it provides any help in the area I'm looking to trace. I will be looking forward to the features (back tracing, branches taken) you mentioned being implemented into the next build of CE. Thank you for taking the time to answer my questions in a detailed manner.
|
|
| Back to top |
|
|
jojje
How do I cheat?
![]() Reputation: 1
Joined: 11 Oct 2010
Posts: 3
|
| Posted: Tue Sep 25, 2012 3:48 pm Post subject: |
|
|
Sorry to awake an old thread, but I haven't been able to find out whether or not the following was ever implemented.
| Quote: | | On a sidenote, the cpu does provide a feature to record all the branches taken. Next ce version does make use of this but not yet for backtracing(and you need a specific intel cpu) but i'll see about adding usage of this feature for backtracing in the version after the next one |
If implemented and described, where can I find this information?
What's the feature called (so I can search for it) ?
And @Abystus: No you're not the only one that have been missing this feature sorely. Backtracing manually, step by step, checking register values at each branch is a real PITA..
|
|
| Back to top |
|
|
Dark Byte
Site Admin
Reputation: 475
Joined: 09 May 2003
Posts: 25987
Location: The netherlands
|
| Posted: Tue Sep 25, 2012 4:14 pm Post subject: |
|
|
If you use kernelmode debugging you can use these commands:
| Code: |
debug_setLastBranchRecording(boolean): When set the Kernel debugger will try to record the last branch(es) taken before a breakpoint happens
debug_getMaxLastBranchRecord() : Returns the maximum branch record your cpu can store (-1 if none)
debug_getLastBranchRecord(index): Returns the value of the Last Branch Record at the given index (when handling a breakpoint)
|
Use this in combination with manually set breakpoints
Also, are you sure the stacktrace or any of the secondary stackviews isn't usable ?
_________________
Tools give you results. Knowledge gives you control.
Like my help? Join me on Patreon so i can keep helping |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
