Cheat Engine

[Chris12]

1:

[Dark Byte]

1:It's just an estimate based on disassembling several bytes in front and see which distances result in the current address being one of them without any invalid/abnormal instruction inbetween

2: No, a function does not HAVE to start at a 16 byte alignment and if it uses pascal/fastcall without stackframe there is no way to find out it's a function start.
At best you could check if there is a pointer (unaligned) to that function and disassemble all the code and look for a reference to that function

3: in ce you'd do the code dissect, but that's not in lua yet. It's similar to disassembling all the code and look if it references the function. Check answer2

[Chris12]

1:
Thats what I thought
But why does this function work like this when CE already has a better algorithm to detect a very similar case.
I mean, when you set the disasm view to a "wrong" address inside a function it will still show some (garbage) disassembled code.
But as soon as you turn the mouse-wheel it will "snap" to the nearest correct address and then display the correct disassembly.

You could also see if it's possible to disassemble the second-previous instruction. If not, then the current offset to the previous instruction is most likely a few bytes off. That should improve the heuristic a bit at least. (Maybe thats how CE snaps to the correct offsets when scrolling??)


2&3:
Disassemble all the code and look for references.
I'd rather use the dissect-code feature. It seems to be really well done and bug-free.
Besides I don't really know how to do the same thing myself properly in Lua.
And won't it be slow and use way to much memory when done in lua? (70mb game dll)

Do you have any plans on making the dissect code features accessible trough Lua?
It would be enough to have: dissectCode(moduleName), getXrefs(address), getReferencedStrings(moduleName)
It's all stuff that's already there, but I don't know how difficult / timeconsuming it is to expose those functions.


4:
Is there a way to get / set the comment of a line in the dissassembler?


5:
Is there a way to access the exposed Lua functions from a plugin? (like getPreviousOpcode and disassemblerview_getSelectedAddress)
I can understand that you don't want to mess with the "old" plugin system now that we have the new lua engine, but you can just add a "string ExecuteLuaScript(string)" (same as in the "LuaEngine" window) and automatically make all of CE's Lua functions available for plugin writers too
Because I'd rather program with a C-like language than Lua

Thank you so much for your support db <3

[Dark Byte]

1: It is the same algorithm
When you turn the mouse wheel it uses getpreviousopcode to find the best possible previous opcode according to those rules (disassembling multiple offsets and see which result has the most normal code)
Because the start opcode is now different the subsequent opcodes might be different as well.

2&3: I was going to add he disassembler class which provides specific data like "Lastinstruction.IsCall IsJump , ReferencesX" but I guess I can also add the dissected code class


4: Not yet, but I guess I could add functions for it

5:
Yes, the lua state is exposed to the plugin. Check out the forcedinjection plugin on the main site where I make use of lua

[Chris12]

IsCall, IsJump, flags would be cool to have in addition to ReferencedBy, ReferencingX.

Yeah mofifying comments is really needed. It would allow providing the results of custom code-dissection passes over the modules.

Wouldn't it be better to let dissect code Do its job and then "fix" the instructions when they're not changed instead of trying to snap to a correct offset every time the asmView is scrolled? or let's the user manually lock/unlock the assembler view? It feels like a rather unsafe way to handle the code.

Well whatever it seems to be good enough for now

Any idea when the disassembler flags and/or code dissect features and comment editting functions are exposed ?
I can't wait to code some awesome IDA style code-analysis plugins

edit: Can't find where lua_dostring is defined in the forcedinjection plugin :/
I can only spot this at the end of the CESdk.h file:

[Dark Byte]

You can press the left and right buttons to change the address by 1 in the disassembler, this is useful for joined instruction tricks

It will probably be in next version, but not sure when it gets implemented in the svn.


lua_dostring is an export of the lua 5.1 dll, just get the module handle to that dll, get the proc address, and call it with the lua state pointer

[Chris12]

lua5.1-32.dll in the ce directory doesn't export lua_dostring.
do I have to use luaL_loadstring and lua_call ?

[Dark Byte]

Ah yes, lua_dostring is just a macro/wrapper for loadstring/pcall. So yes, you'll need to call those two exports. (Just define that function yourself)

[Chris12]

Nice! I got most of the important Lua functions imported.
When I'm finished we will have a solid .Net plugin sdk.

Now I'll just have to wait until those features are exposed to Lua / the plugin system. If I can help somewhere please tell me

Btw did you get a chance to checkout why my plugin might crash on startup but not when loaded from the ce settings (I tried delaying and loading with a Lua script too but it crashes too)

An Thank you for adding those requested features. I have a ton of ideas for awesome plugins which will make CE much more powerful

[Dark Byte]

No, i can't really see what goes wrong, and i only have vs2008 which refuses to open the project
Perhaps the application. methods cause a problem when there hasn't been any window created yet.
Just comment out almost everything in initialize and see what causes it

Also, not that it matters too much, you're telling ce your plugin uses sdk version 1. That will cause ce to treat your plugin slightly different

[Chris12]

I can't attach it here because it says I exceeded my storage space. So here's the link.
http://www.mediafire.com/?gm81g7pn6vgbh2n

It's now set to .net framework 3.0.
Also I removed nearly all code.
On vs2008 you can just open the project by going to file->new->project from available code.

Then add a reference to the dll in: packages/UnmanagedExports.1.2.3-Beta/lib/net/

You don't really have to compile the plugin yourself, it is included. You can also run ce in a debugger and see where it crashes.

Maybe changing it so CE uses the same loading technique at the beginning (and with lua: loadPlugin()), as it does when loading from the settings dialog will help?

[Dark Byte]

Do you have a 64-bit dll I can test ? I currently don't have any debug environment for 32-bit ce. (Only at the very end when porting ce to 32-bit)

Does it still crash if you remove that showMessage line?

[Chris12]

Yes it still crashes when I'm removing the showmessage. As I said, it crashes before any code is executed.
But I found a workaround. (more on that later)

I suspect it's because the dll isn't a normal dll with normal exports.
Loading it causes a real avalance of LoadLibrary calls because the CLR is loading itself.
The exported functions are actually only long-jumps to the CLR-JitCompiler.
When CE calls exports of the dll, the function compiles "itself" and runs.

Maybe CE is loading the plugins in an unusual way (not LoadLibrary)?
Or it's somehow calling the exports before the library is completly loaded (but I don't beleive that's possible since LoadLibrary is synchronous and holds a "loader lock").

For my workaround I took some time to coded an extra dll in c++ that spins up the CLR.
It transfers control to a managed "meta plugin" which in turn loads all managed plugins it can find in CEs plugin directory.

I planned to load each plugin into its own AppDomain but because of speed and complexity I trashed that idea (for now).

Works really well so far, so you can move this issue to low priority for now
For now the proxy c++ dll is only 32bit, but it's on my list to also provide a 64 bit version.
Does CE already know if a dll is x86/x64? Luckily .NET supports "AnyCPU" so I only have to write my "real" plugins once.

If you are still interested in fixing this bug I can compile a 64bit version of the old plugin for you though, just tell me.

By the way. Do you think it would be possible to also add functions (lua or not) to get and set those "exta-comments" or "annotations" at the top?


edit:
Everything's running smoothly now.
But there's definitly some race-condition with RegisterFunction(...)
It won't work or sometimes crashes when the main window isn't created yet.
I suggest delaying plugin loading until CEs mainwindow is fully shown. Even when GetMainWindowHandle() isn't 0 it sometimes doesnt work.
However a Sleep(50) fixes it.


edit2:
I don't know how exactly CE saves the information about xrefs it gathered by "code dissect", but it would be important to be able to add to this data.
If CE only saves this information as comments to functions (as seen in the pic i included here) and not inside some additional data structure then
"change comment" would be enough. Otherwise I'll need something like "addReference(address)" in addition to "getReferences(address)".

[Dark Byte]

ce uses the same code to load the plugin at startup as it does when using the settings. (pluginhandler.LoadPlugin() followed by pluginhandler.EnablePlugin(), which calls LoadLibrary and GetProcAddress)

The only difference is that it loads the plugin when the settings get loaded(After the window has been created, inside the onShow code), and at that time there is no multithreading going on, so I don't know why that sleep() would make any difference. (Unless one of the injected dll's has spawned a thread and is doing something to ce's memory, like initializing something your dll needs?)


(And yes, I noticed that the symbolhandler doesn't deal with this dll properly)

[Chris12]