aobscanmodule

[Inquiry7]

Hello! First off, love what you've done and has this been extremely helpful.

I am aware you said you would only add support for things you need. However, if you have time when you stop by to update this project again, could you consider adding driver/dll view support? I am attempting to scan/write to a dll that interacts with an exe on the target computer, but am unable to due to the dll not being pulled/recognized.

Thank you!

[Metick]

Hey! Thank you for the compliments.

What exactly do you mean with adding driver/dll view support? DLL view support should already be added because i iterate the modules, and when looking through memory it should display which region is from which module.

[chuckmorris420]

Hey! Thank you for the compliments.

What exactly do you mean with adding driver/dll view support? DLL view support should already be added because i iterate the modules, and when looking through memory it should display which region is from which module.

I agree with the OP. This tool has been great help performing scans and changing values manually (for which I am very grateful for) but I sadly cannot use precompiled scripts as they rely on aobscanmodule.

Attempting to use auto assemble with the following script throws an error calling the DLL.

[ENABLE]

aobscanmodule(Stamina,game.dll,F3 41 0F 11 08 8B 48 10 E8 C1 F7 38 00 41 8B 47 48)
alloc(newmem,$1000)

label(code)
label(return)

newmem:

code:
nop
// org nop = movss [r8],xmm1
mov ecx,[rax+10]
call game.dll+9575C0
mov eax,[r15+48]
jmp return

Stamina:
jmp far newmem
nop 3
return:
registersymbol(Stamina)

[DISABLE]

Stamina:
db F3 41 0F 11 08 8B 48 10 E8 C1 F7 38 00 41 8B 47 48

unregistersymbol(Stamina)
dealloc(newmem)

[Metick]

aobscanmodule is Cheatengines Lua API, which i don't support as you might know. and I won't be spending time, for the time being on adding support for it, but feel free to provide me with information on what i have to replicate to add support for it.

[Inquiry7]

If I'm not mistaken, I believe it would be "Enumerate DLL's and Symbols" from Memory View/View/Enumerate DLL's and Symbols. Thank you for the reply.

[Metick]

If I'm not mistaken, I believe it would be "Enumerate DLL's and Symbols" from Memory View/View/Enumerate DLL's and Symbols. Thank you for the reply.

I believe that to support CheatEngine Lua api, i'd have to inject a .dll. (quote me if i'm wrong) to make a injection through DMA w/o picking up any detections for anticheats it will be kinda hard to do. especially when executing the payload. there isn't any good way of doing it without the user manually doing work on what function to use to execute the payload.

support for it can be added, just that it wouldn't be a "one for all" solution

[songce74]

Very nice project, thanks to @Metick

But I also found the problem as @Inquiry7 mentioned, the "Enumerate DLL's and Symbols" from Memory View/View is empty.
I want to contribute but I don't know what is under the hood of "Enumerate DLL's and Symbols" function in CE.
Is anyone familiar with Cheat Engine's source and knows what APIs are involved in "Enumerate DLL's and Symbols" function? I may implement those APIs into this plugin.

Thanks.

This screenshot should explain what I am talking about

[songce74]

Hey! Thank you for the compliments.

What exactly do you mean with adding driver/dll view support? DLL view support should already be added because i iterate the modules, and when looking through memory it should display which region is from which module.

@Metick Could you double-check that the memory window does display which region is from which module? As you can see from the screenshot above, the memory window does not show module names.

May I ask what version of Cheat Engine are you using?

[Metick]

Very nice project, thanks to @Metick

But I also found the problem as @Inquiry7 mentioned, the "Enumerate DLL's and Symbols" from Memory View/View is empty. I want to contribute but I don't know what is under the hood of "Enumerate DLL's and Symbols" function in CE. Is anyone familiar with Cheat Engine's source and knows what APIs are involved in "Enumerate DLL's and Symbols" function? I may implement those APIs into this plugin.

Thanks.

This screenshot should explain what I am talking about

Thanks for being interested in contributing to my project! I should've already implemented Enumerate Dlls and symbols, Personally I never use a 2pc setup, so might be a issue when you use 2 computers on how i enumerate the process of the target computer? Or maybe not fully implemented, but it works on 1pc setup as far i'm aware.

for your question which CE version i'm using, I'm using a custom compiled version of CE. which should be more or less based on CE 7.5 version

[songce74]

Some updates on this:

I've spent some time debugging this Plugin and tried to solve this problem. It seems that CheatEngin does use the APIs implemented in this plugin to get the module list. Instead, they use Lua scripts to get module lists and show them on the window. I don't know if we can use the plugin to replace Lua function yet. If anyone has more information, please tell me about that.

However, I still managed to find a workaround to let CE have the correct Module List and show the correct module offsets, just like the screenshot:

The way I use is to write a Python script that read module list through DMA and generate a Lua script which can be executed by the CE.

vmm = memprocfs,Vmm(['-device', 'fpga'])

process = vmm.process('EscapeFromTrakov.exe')
module_list = process.module_list()

with open("script.txt", "w") as f:
        f.write('sl=createSymbolList()\n')
        f.write('sl.register()\n')
        for m in module_list():
              f.write(f'sl.addModule("{m.name}", "", {hex(m.base)}, {m.image_size}, true)\n')

[lauralex]

If you want the module list, you have to compile CE from the master branch, because of this fix which was applied after the 7.5 release:

And since the szExePath is null we would have an exception (I debugged it using IDA).
This is where module32first/next is invoked and we don't set the szExePath:

The commit after the 7.5 release (first image) fixes it by comparing the szModule instead of the szExePath

[Metick]

If you want the module list, you have to compile CE from the master branch, because of this fix which was applied after the 7.5 release: And since the szExePath is null we would have an exception (I debugged it using IDA). This is where module32first/next is invoked and we don't set the szExePath: The commit after the 7.5 release (first image) fixes it by comparing the szModule instead of the szExePath

nice find! Just confirmed it and you're right. Luckily CE doesn't really care if it's a valid path or if it's a path at all (as far i'm aware atleast). from now on in the latest version of the plugin it will show the binary name even when using the stable version of CE.