View previous topic :: View next topic |
Author |
Message |
bismult Cheater
Reputation: 0
Joined: 09 Mar 2022 Posts: 27
|
Posted: Thu Jun 19, 2025 8:57 pm Post subject: executeCodeEx / executeMethod |
|
|
I'm running into issues with setting multiple parameters for executeCodeEx and executeMethod. I need to set RDX and RDI to 0x4, but it's not working. Yes, I 100% have the correct address.
Code: | local gameFunction = 'game.exe+2AD3E4'
local RDX = 0x04
local RDI = 0x04
executeCodeEx(0, nil, gameFunction,
{0, RDX},
{0, RDI}
) |
I've also tried it with executeMethod below. regnr = 2 represents RDX and regnr = 7 represents RDI. What exactly am I doing wrong?
Code: | local gameFunction = 'game.exe+2AD3E4'
executeMethod(0, nil, gameFunction,
{regnr = 2, classinstance = 0x04},
{regnr = 7, classinstance = 0x04}
) |
|
|
Back to top |
|
 |
Eggs_ How do I cheat?
Reputation: 0
Joined: 19 Jun 2025 Posts: 7
|
Posted: Thu Jun 19, 2025 9:26 pm Post subject: |
|
|
i just tried it in windows, it works. I assume you are trying to execute it in Linux, maybe you should also set RSI the documentation doesn't state that the default parameter value is 0 if you don't set it.
Have you put a breakpoint at the function address to check if it gets triggered at all and just doesn't give the desired results.
alternatively you could always inject into a gameloop and use autoassembler code ..
|
|
Back to top |
|
 |
bismult Cheater
Reputation: 0
Joined: 09 Mar 2022 Posts: 27
|
Posted: Thu Jun 19, 2025 9:58 pm Post subject: |
|
|
Eggs_ wrote: | i just tried it in windows, it works. I assume you are trying to execute it in Linux, maybe you should also set RSI the documentation doesn't state that the default parameter value is 0 if you don't set it.
Have you put a breakpoint at the function address to check if it gets triggered at all and just doesn't give the desired results.
alternatively you could always inject into a gameloop and use autoassembler code .. |
I'm also on windows, and I've set a breakpoint at the function to see what parameters are being set. Either only 1 parameter will be set or none. Not sure why this is happening. Calling functions with auto assembler hurts my head lol. I can never get the stack right for some reason.
|
|
Back to top |
|
 |
Eggs_ How do I cheat?
Reputation: 0
Joined: 19 Jun 2025 Posts: 7
|
Posted: Thu Jun 19, 2025 10:20 pm Post subject: |
|
|
bismult wrote: |
I'm also on windows, and I've set a breakpoint at the function to see what parameters are being set. Either only 1 parameter will be set or none. Not sure why this is happening. Calling functions with auto assembler hurts my head lol. I can never get the stack right for some reason. |
but windows x64 calling convension should be rcx = first param, rdx = second param r8 = third param. r9 4th, rest goes onto stack
Without any context there's no way that setting rsi will have ANY effect. Besides the point that executeFunctionEx Can't set RSI at all because it's not part of any parameters passed around in windows.
That's the reason why i thought you were on Linux
|
|
Back to top |
|
 |
ParkourPenguin I post too much
Reputation: 152
Joined: 06 Jul 2014 Posts: 4691
|
Posted: Fri Jun 20, 2025 12:10 pm Post subject: |
|
|
executeCodeEx - the 4th and 5th parameters set rcx and rdx respectively. Naming a local variable EDX or EDI doesn't mean anything.
executeMethod - Only the 4th parameter to executeMethod is special and allows you to specify the register that the pointer to the instance is stored in. All further parameters are the same as executeCodeEx- i.e. the register can't be specified.
See documentation in celua.txt for more details. You should specify something for the timeout to prevent deadlock if something goes wrong. e.g. 10000 = 10 seconds; most calls should finish before then.
That calling convention is almost certainly wrong. Find a call to the function you want to call, and show us the code around there. Set a breakpoint, do something to trigger it, step over code until the function returns, and scroll up a bit to see the call. If that doesn't look quite right, there may have been a tail call involved somewhere. Try dissecting the code of the exe/dll (if the function is in an exe/dll) or the same memory region (if it was dynamically allocated). There should be a menu item under the "Tools" menu of the memory viewer. Go to the start of the function and you'll see a list of all the calls to that function.
_________________
I don't know where I'm going, but I'll figure it out when I get there. |
|
Back to top |
|
 |
|