Cheat Engine Forum Index Cheat Engine
The Official Site of Cheat Engine
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 


How to wait for the thread context to be set ?

 
Post new topic   Reply to topic    Cheat Engine Forum Index -> General Gamehacking
View previous topic :: View next topic  
Author Message
Hexist
Newbie cheater
Reputation: 0

Joined: 07 Dec 2021
Posts: 10

PostPosted: Thu Jan 11, 2024 6:53 am    Post subject: How to wait for the thread context to be set ? Reply with quote

First of all the script is for Cheat Engine's Graphical Tutorial Level 1

The script works perfectly at first when i Auto Assemble it through the Tools->Auto Assemble, the thread context gets set perfectly this way once i hit the breakpoint by firing a shot in game before enabling the script because of the fact that auto assembling the script runs it, but when i save the address list with the script as a .ct file and reopen both Cheat Engine and the game with the thread context not set and drag my .ct file that has the script in and enable it, the context is not set while checking the statement "if(RBX==nil) then return end" because of the fact that i did not hit the breakpoint by firing a shot right after enabling the script, so the script just returns.

After firing however the thread context gets set through debugger_onBreakpoint() but the script had just returned so its of no use.

How can i wait for the thread context to be set in my script ?
So that it doesnt return immediately and work properly when i reopen both Cheat Engine and the game after just enabling the script once.

And why does the scripts that i auto assemble run themselves after i assemble them? What are the reasons behind this ?
Is it because of error-checking ?


I have the following script:

Code:
[ENABLE]

{$lua}

function break_target()
   target="10003D1D9"
   debugProcess(2)
   debug_setBreakpoint(target)
end

function debugger_onBreakpoint()
     debug_removeBreakpoint(target)
     debug_getContext(0)
     debug_continueFromBreakpoint(co_run)
 return 0
end

break_target()

if(RBX==nil) then return end

shots_fired_addr=(RBX+0x6C)
shots_fired=readInteger(shots_fired_addr)
writeInteger(shots_fired_addr,10)
shots_fired=10



[DISABLE]

{$lua}
writeInteger(shots_fired_addr,0)
shots_fired=0
 
Back to top
View user's profile Send private message
ParkourPenguin
I post too much
Reputation: 150

Joined: 06 Jul 2014
Posts: 4661

PostPosted: Thu Jan 11, 2024 12:30 pm    Post subject: Reply with quote

Need to add `if syntaxcheck then return end` at the beginning of every {$lua} block

Local variables are a thing in Lua

Use "game.exe+offset" instead of a literal address

Breakpoints won't trigger just because you set them. The game must actually run the original code for them to trigger.
In a simpler case, defining a function doesn't mean it'll run. You need to actually call the function for it to run.

Don't use debugger_onBreakpoint. Just set a callback for that particular breakpoint.
Code:
{$lua}
if syntaxcheck then return end

local break_addr = getAddress'gtutorial-x86_64.exe+3D1D9'

[ENABLE]

debugProcess(2)
debug_setBreakpoint(break_addr, function()
  debug_removeBreakpoint(break_addr)
  registerSymbol('shots_fired',RBX+0x6C, true)
  writeInteger(RBX+0x6C, 10)
end)

[DISABLE]
debug_removeBreakpoint(break_addr)

local a = getAddressSafe'shots_fired'
if a then
  writeInteger(a, 0)
  unregisterSymbol'shots_fired'
end

_________________
I don't know where I'm going, but I'll figure it out when I get there.
Back to top
View user's profile Send private message
Hexist
Newbie cheater
Reputation: 0

Joined: 07 Dec 2021
Posts: 10

PostPosted: Sat Jan 13, 2024 12:38 pm    Post subject: Reply with quote

How would you do this on level 3 ? The instruction i put the breakpoint here is run every tick and the script just freezes the game.

Code:
{$lua}
if syntaxcheck then return end
local break_addr = getAddress'gtutorial-x86_64.exe+40F39'

[ENABLE]

debugProcess(2)
debug_setBreakpoint(break_addr, function()
   debug_removeBreakpoint(break_addr)
   registerSymbol('y',RBX+0x28, true)
   writeFloat(RBX+0x28, -0.2)
end)


[DISABLE]
debug_removeBreakpoint(break_addr)

local y = getAddressSafe'y'
if y then
  writeFloat(y, 0.7)
  unregisterSymbol'y'
end


Back to top
View user's profile Send private message
ParkourPenguin
I post too much
Reputation: 150

Joined: 06 Jul 2014
Posts: 4661

PostPosted: Sat Jan 13, 2024 2:16 pm    Post subject: Reply with quote

Code:
gtutorial-x86_64.exe+40F39 - F3 44 0F11 48 28      - movss [rax+28],xmm9
Typo? RAX instead of RBX
_________________
I don't know where I'm going, but I'll figure it out when I get there.
Back to top
View user's profile Send private message
Hexist
Newbie cheater
Reputation: 0

Joined: 07 Dec 2021
Posts: 10

PostPosted: Sun Jan 14, 2024 1:48 am    Post subject: Reply with quote

Code:
{$lua}
if syntaxcheck then return end
local break_addr = getAddress'gtutorial-x86_64.exe+40F39'

[ENABLE]

debugProcess(2)
debug_setBreakpoint(break_addr, function()
   debug_removeBreakpoint(break_addr)
   registerSymbol('y_val',RAX+0x28, true)
end)

writeFloat(RAX+0x28, -0.7)
[DISABLE]
debug_removeBreakpoint(break_addr)

local xd = getAddressSafe'y_val'
if xd then
  writeFloat(xd, 0.7)
  unregisterSymbol'y_val'
end


The following script does not set the coordinates correctly when i ENABLE it. It sometimes sets the coordinates to the desired -0.7 position but its inconsistent. However it always works when i DISABLE it.

Also i have to click on enable button twice at the first time when i want to ENABLE it.

Is there a way to make this a much more smoother and consistent script where i just have to press enable box once for the first time and it sets the coordinates everytime consistently ?

The inconsistencies about setting the coordinate happens especially when i auto assemble the script, for some reason when i save the script and drag the script to address list and then try to use it (after resetting both Cheat Engine and the game), inconsistencies are not as inconsistent as the auto assembled script.

Why is that ?

I was originally thinking of waiting for the thread context to be set after the breakpoint went through debugger_onBreakpoint and afterwards updating global variables to make sure the breakpoint setup never occurs after the thread context has been updated, however this does not seem like a straightforward task. And there is something funky going on with debugger_onBreakpoint. It seems like something similar is happening here.
Back to top
View user's profile Send private message
ParkourPenguin
I post too much
Reputation: 150

Joined: 06 Jul 2014
Posts: 4661

PostPosted: Sun Jan 14, 2024 2:30 am    Post subject: Reply with quote

It's the same exact problem in your first script.
Hexist wrote:
Code:
debug_setBreakpoint(break_addr, function()
   debug_removeBreakpoint(break_addr)
   registerSymbol('y_val',RAX+0x28, true)
end)

writeFloat(RAX+0x28, -0.7)
`debug_setBreakpoint` isn't blocking. It doesn't wait for any breakpoint to trigger. Lua just sets a breakpoint and moves on. As such, `writeFloat` is wrongly placed. RAX means nothing in this context, and therefore `writeFloat` does nothing.

Move `writeFloat` inside the callback passed to `setBreakpoint`. In that callback, the variables RAX etc. are set to the respective registers of the thread that triggered the breakpoint. It does make sense in this context.

The fact that this works at all for you is a bug as far as I'm concerned. CE shouldn't use globals for RAX etc., and even if it did, those globals should be unset when CE continues from the break.

_________________
I don't know where I'm going, but I'll figure it out when I get there.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Cheat Engine Forum Index -> General Gamehacking All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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


Powered by phpBB © 2001, 2005 phpBB Group

CE Wiki   IRC (#CEF)   Twitter
Third party websites